The team at The Understanding Group (TUG) is made up of seasoned veterans of dozens of enterprise web development projects in Agile environments. Many of us have extensive understanding of the technology and processes it takes to build complex interactive websites.
Yet at TUG, we don’t actually build the websites—or even create what are considered traditional requirements specifications.
This can be jarring on first glance. In fact, my own experience as an enterprise requirements and business analyst led me to struggle with TUG‘s philosophy when I first started consulting with them. Ultimately I decided that what TUG was doing was indispensable for complex websites.
So, what did I learn, and how did I change my mind? Well, basically I found TUG‘s methods answered the ghosts that have been plaguing web development for twenty years:
- Formal requirements rarely actually convey understanding.
- The methods developed to get true understanding don’t scale.
Requirements Deserve Understanding
Why do standard software requirements fail?
Ultimately, they just don’t explain what needs to happen. The Grand Master of software project management, Alistair Cockburn, wrote in 2002 that:
In the computer industry we write specification and design documents as though we can actually explain what we mean. We can’t. We can never hope to completely specify the requirements or design.
The realization that requirements don’t work very well is the wellspring of iterative software processes like Agile. What Agile did was to create better feedback between needs and results by building small units of value in tight-knit, stable groups of producers, designers, and product managers in focused sprints.
To put it another way, the Agile process is a mechanism for creating true shared understanding in a way that traditional requirements cannot. Compared to what was happening in software development before Agile, this approach was revolutionary and wildly successful.
TUG agrees that understanding needs approaches other than the standard requirements specification.
Big Projects Deserve Understanding, Too
That being said, Agile methodologies generally have two major problems:
- They do not facilitate—and in some ways actively hinder—grand product strategy.
- They struggle when confronted with thorny, irreducible problems that characterize complex digital ecosystems.
In other words, by going small, Agile often loses the big picture. Furthermore, the strategies developed to scale it up often just magnify the deficiencies.
These issues are two sides of the same coin. When a large problem must be chunked down into six-week sprints, the ability to keep large concepts in superposition starts to slide around. The inability to grapple with these issues means that the outcome of Agile projects sometimes is less than the sum of its parts.
Many Agile proponents are aware of this issue. They just don’t know how to address it without returning to the bad old days of useless reams of requirements specifications.
TUG believes there is a known practice that can guide big picture understanding, in the form of the traditional building architect. Just like our counterparts in the built environment, TUG‘s information architects provide the vision and leadership for realizing complex projects.
And just like an architect’s plans are not expected to actually define how to build a building, TUG‘s development process is not a set of business specifications that can be decomposed to functional requirements. We search instead for ways to convey good fit between what you intend and how people experience it.
This approach is sometimes called “sprint zero,” a period of planning and discovery that is critical as an input to the systematic development of software, especially for Agile software environments.
So, we love Agile at TUG. We just believe that it could be aided with a broader strategic vision to create even more shared understanding at multiple levels in the project and the organization.
In our next blog post, we’ll talk about how our process of Programming, Analysis, Synthesis, and Specification (or PASS) facilitates this effort, through what looks like a very traditional, systematic, and cascading set of deeper phases of understanding. Stay tuned!
