In This Issue
- The Risks with Traditional Approaches to Modeling
- Hot Links
The Risks with Traditional Approaches to Modeling
One of the unfortunate aspects of industry-level paradigm shifts, such as what we're seeing with the move to agile software development, is that the followers of the incumbent paradigm often get to set the tone of the conversation. A perfect example of this is that traditionalists will often claim that agile approaches are riskier than traditional approaches when in fact practice shows that the exact opposite is true. With this newsletter I intend to turn the tables on traditionalists by summarizing the inherent risks in their preferred approaches to modeling.
To set the stage, I'd like to summarize some recent findings of two surveys that Dr. Dobb's ran this year. First, March's Dr. Dobb's Agile Adoption Survey (summarized in the August issue of Dr. Dobb's Journal) found that 69 percent of respondents work in organizations taking an Agile approach on one or more projects. Second, our survey explored the success rate, and more pertinently how organizations define success, on software development projects. This survey, to be summarized in my upcoming December 2007 "Agile Edge" column, discovered that respondents indicate a 72 percent success rate on Agile projects compared with a 63 percent rate on traditional projects. My point is that not only are organizations adopting Agile approaches they're finding them more successful, facts which traditionalists should take note of.
Let's focus on the risks associated with traditional modeling. For the sake of this newsletter traditional modeling is defined as the creation of relatively detailed models, which may be visual such as UML diagrams or data models or text-based such as use cases, early in the project. You may or may not review and accept them, and you may or may not baseline them and channel modifications through a change management process. In other words, if you create a requirements specification or a detailed architecture/design model in the first few weeks or months of a project then you're taking a traditional approach.
There are two specific risks associated with taking a "big requirements up front (BRUF)" approach to modeling. First, with a BRUF approach you effectively ask your stakeholders to predict what they're going to need months or even years from now. This is the worst possible time for making these decisions because this is when the stakeholders know the least about the solution. In effect you're asking them to visualize something but providing them with no concrete feedback, such as working software, against which to validate their vision. We've known for decades that people aren't good at defining what they want, but when they see something they're good at indicating what they don't want. You therefore run the risk of actually building a system which reflects the information contained in the specification. Although traditionalists believe that building to spec is a good thing, in reality if proves to be a very bad approach because what you deliver won't be what people actually want. The Standish Group's Chaos Report v3 reported that projects which took a BRUF approach, when they delivered something at all, on average deployed software of which 45 percent of the delivered functionality wasn't used by end users and 19 percent of which was rarely used. This level of waste seems incredibly risky to me, particularly when it can be easily avoided by working in priority order and delivering working software incrementally.
The second risk with BRUF is that having a detailed requirements specification provides you with a false sense of security that you understand stakeholder needs. This in turn demotivates you from exploring and rethinking the requirements as the project progresses, reducing the likelihood that you'll recognize and address any deviations from what your stakeholders actually want. Not only does BRUF increase the chance of building the wrong thing, it decreases the chance that you'll detect that you're doing so.
There are three primary risks associated with taking a "big design up front (BDUF)" approach to development. The first is that with a BDUF approach you're being asked to make serious technical decisions when you know the least about the problem domain, increasing the chance that you'll choose the wrong path. Lean/agile approaches instead advise you to make these sorts of decisions at the last possible moment when you can safely make them, instead of at the beginning. Second, a detailed architecture/design motivates you to overbuild your system -- it's in the design, so you'd better build it, whether the stakeholders really need it or not. How many times have you seen project teams spend the first six months of a project building great frameworks which will support all future needs, only to discover that a lot of the framework isn't needed at all? Unless you get the design perfectly right, which is very difficult to do in practice, you'll end up building far more than you need to. Third, the more modeling and documentation that you do, the greater the chance that'll you'll commit to the documented approach because of the investment that you've made in the work. This occurs even when the design is known to be questionable -- on traditional projects it's often too much effort to rework the design approach once you've started down a specific path.
There are two risks to be concerned about with "big modeling up front (BMUF)" approaches in general. The most obvious one is that overall project cost is driven up with the creation, review, and maintenance of overly detailed models and documents. This is something which the Agile community refers to as "traveling heavy".
Second, and what isn't so obvious, is that there are few opportunities for process improvement pertaining to traditional approaches to modeling and documentation. The problem is that the feedback cycle between creating the models up front and validating the models with working software is too long, often months or even years in length. It's common practice for up-front modelers, particularly business analysts and data analysts, to swoop in at the beginning of a project to do their work, get it accepted, and then move on to the next project. By the time you determine, through system integration testing (SIT) and user acceptance testing (UAT), whether the models actually reflect reality the modelers are often long gone. Worse yet, so many other people have been involved with the actual construction that it's incredibly easy for the modelers to blame them for any problems -- the models were reviewed and accepted after all, so the problem must be in the implementation. This lack of concrete accountability may explain why the traditional modeling community has been stuck in their BMUF rut for almost 30 years.
There are clearly serious problems with traditional approaches to modeling. However, a fair question is whether traditional approaches address risks which agile approaches do not. The answer is a resounding "no" to the consternation of many traditionalists. Traditional modeling approaches provide the opportunities to think things through early in the project, thereby reducing the risk of starting off on the wrong track. However, initial agile requirements and architectural envisioning also enable you to do that, practices which the Dr. Dobb's 2007 Agile Adoption Survey showed the vast majority (77 percent) of agile teams do in practice. Yes, you still need to communicate your project status to people outside of the project, something that is traditionally done via models and documents. However, agilists find that the regular delivery of working software provides a far more accurate and concrete assessment of current project status, making Agile project teams far more easier to govern in practice than traditional teams. Agile governance is the topic of my forthcoming November 2007 "Agile Edge" print column.
In short, traditional approaches to modeling increase your risk of building software that people don't want, working under a false sense of security which in turn prevents you from questioning what you're doing, increase the chance that you'll make architectural decisions too early, that you'll overbuild the system, that you won't want to deviate from your questionable strategy, that your overall costs will be higher, and that you won't have easy opportunities for process improvement. Worse yet, the few risks that traditional modeling approaches do seem to deal with are better addressed through Agile Modeling strategies
Hot Links
Survey Says... Agile Has Crossed the Chasm summarizes the results of the 2007 DDJ Agile Adoption Survey.
"Governing Agile Software Development" in the upcoming November 2007 issue of Dr. Dobb's Journal shows how Agile projects prove to be far easier to govern in practice that traditional projects.
"Success Rates of Software Development Projects" in the upcoming December 2007 issue of Dr. Dobb's Journal explores how organizations define project success, apparently "on time and on budget" isn't as important as we've been led to believe. It also compares the success rates of Agile, traditional, data warehouse, and offshore projects, finding that Agile project teams lead the way.
Architecture Envisioning: An Agile Best Practice describes how to do initial architecture modeling on agile projects.
Requirements Envisioning: An Agile Best Practice describes how to do initial requirements modeling on agile projects.
Examining the "Big Requirements Up Front (BRUF) Approach overviews and discusses evidence as to why comprehensive modeling up front puts your project at risk.
Agile Documentation strategies are described in detail here.
The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
The Agile Models Distilled page provides links to overviews of a wide variety of models.
The principles of Agile Modeling v2 are described here.
The practices of Agile Modeling v2 are described here.
Check out the Agile Modeling mailing list here.
