Save 40% on books and eBooks + 70% on videos now through May 31*—use code PROGRAM. Shop now.
Proposed approaches to building products, software or otherwise, will come and go. One thing that seems to be constant through all this change is that the voice of the latest and greatest is convinced that they have solved the problem once and for all.
Television will be the death of radio, satellite and cable will be the death of broadcast. The only time something truly usurps the market is when a clear choice has to be made, and this is usually when it doesn’t make sense (usually financial sense) to support competing standards. Betamax and VHS, HD DVD and Blu-Ray.
While there may be a clear winner when it comes to the final product, this will never be the case when it comes to deciding how we build that product. Just as there are myriad types of product and cultures within teams, there will never be one best approach, ever. Indeed, differentiating on the approach we use, and how efficient we can become with that approach, is a driver that will always produce refinements in the future. A few years from now, we will look back with bemusement at how quaint Blu-Ray was.
While there is great value in agile approaches, there remains this problem with how it is pitched. The agile promise is almost always presented against a backdrop of poor examples of ‘that traditional approach’, but there is danger that the agile community is being told to throw out the baby with the bath water.
Let’s take an example of how to discover the scope of work for a project, a prime example of a false dichotomy in how it is presented to the masses. In many cases, the agile community is told to eschew those big old, stodgy, requirements documents, in favor of story cards, brief descriptions of features or goals for the system. There are a million shades of gray between requirements as ‘written documents’ and story cards. Indeed, both ends of the spectrum can be equally evil dogma.
A good analyst isn’t hung up on ‘written documents’, but on understanding that context in which we need to develop our software. She brings a massive toolkit to the table: data analysis techniques, state analysis, use cases, quality analysis, myriad others. She’s not hung up on slavishly using a specific set for every project, much less hung up on filling out every section of someone else’s requirements template. What gets captured is the agreements that are made by the right stakeholders getting together to make the right decisions. This information is then used throughout the project as the context for building the solution.
A good analyst makes sure that the team understands and agrees that they have the right context. This comes from discussions with the right people involved, looking at the system from different perspectives. This takes knowledge of a wide range of tools, and when to apply them, as well as knowledge of who needs to be involved in each conversation. Discovery of issues and needs in the domain is best facilitated using vehicles other than the source code for the solution.
A static requirements document is as incomplete as a set of story cards. One can chew up an incredible amount of time to produce information that is not referred to when the product is built, the other can send the team into development with little understanding of the overall context, complexity of the problem, or an appreciation of the efficiencies that can be had from seeing the system from different perspectives. A different approach is needed in either case for all but the most trivial of systems (and no, I wouldn’t do a big requirements document for a trivial system).
The argument is to start light, learn as you go. Anything else is bad, is waterfall, you will fail. While not all in the agile community spout off like this, there are enough to make it a cacophony.
If we step back and look, the good suggestions in the agile community are refinements of good suggestions that predate the movement. We don’t need a common enemy of bad waterfall projects to learn and refine our techniques over time, and I think that we can actually reach more people with the strong positive value of agile if we drop the rhetoric, if we recognize there is no one best approach, and if we can get away from the rabid dogma. - JB
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.