Software Development
December 2003
The Right Tool for the Job
When it comes to methodologies, one size doesn’t fit all. By examining all the options, you can create a mix-and-match approach that best suits your project.
By Scott W. AmblerOne of my grandfather’s favorite sayings was “Use the right tool for the job”—common-sense advice that applies to a wide range of situations. Unfortunately, as Mark Twain observed, common sense isn’t very common—many organizations seem to struggle with identifying the best software processes for them. To succeed, you must understand the available options, as well as the issues surrounding software process selection.
“Common Software Processes” illustrates the leading software processes—and there’s a wide range to choose from. Some processes are agile; some are not. Some are full lifecycle; some are not. Some are well defined; some, such as Extreme Programming, are nearly philosophical in nature. The good news? There’s a lot to choose from. That’s the bad news, too.
Waxing Philosophical
How do you pick the right tool for the job? When it comes to software process selection, I’m guided by several key philosophies:
- One size does not fit all. A team of three people will need a significantly different process than a team of 30 or 300. A team exploring a new problem domain will need to take a different approach than one building a system based on known and stable requirements. Although a single process is convenient for senior management and for the various IT groups that support development teams, in reality, most organizations will need to support several processes if they want to succeed at the software game. The software job varies; therefore, the right “process tool” for the job must also vary.
- You must tailor. You can’t simply choose a process and use it outright; you must tailor it for your situation. A leading cause of failure of Rational Unified Process (RUP) projects is the tendency of process-immature organizations to examine RUP and say “There’s a lot of good stuff here; this is perfect for us.” These organizations then install the base RUP product and tell their staff to follow all of its 3,000+ HTML pages. There is a lot of good stuff in RUP, but you need only a small subset of it. In fact, Rational’s guidelines are clear about this, yet many ignore that advice—to their peril. Recognize that not only your organization, but each project team is unique, so you need software processes that reflect the realities actually faced by individual teams.
- Not all processes are created equal. Some, such as the Enterprise Unified Process (EUP) and IEEE 12207, are full lifecycle, including both software development and post-development activities, whereas others, such as the RUP and XP, cover only the software development process. In fact, some methodologies such as Scrum and Agile Data (AD) focus only on one aspect of software development; in this case, project management and data-oriented development, respectively.
- Not everyone needs to be agile. Just as many organizations use a mix of technologies from Cobol to Java to Web services, it’s very likely that you’ll need a similar mix of software processes. Not all of the processes in “Common Software Processes” are agile, nor do they need to be. Sometimes the right process for the job is rigid and prescriptive, and that’s OK.
Risk-Based Selection
It’s easy to say that you need to use the right process for your project—but very difficult to achieve. Barry Boehm and Richard Turner provide good advice in Balancing Agility with Discipline: A Guide for the Perplexed (Addison-Wesley, 2003), presenting a risk-based approach for choosing a methodological strategy for a project. They advise that uncertain requirements, complex technologies and low employee turnover favor agile projects, whereas larger teams and a diverse group of stakeholders lend themselves to more prescriptive methods. They note that you’ll probably need to tailor agile methods with prescriptive techniques to scale them, and, similarly, tailor prescriptive methods with agile techniques to make them more effective—it isn’t a black and white world, after all.
My experience is that cultural issues are important, and Boehm and Turner concur. Do the people on a project team require a well-defined process or are they comfortable with one that is looser? “Comparing Leading Software Processes” evaluates processes using two factors: definition and scope. The horizontal axis indicates how well defined the processes are, while the vertical axis addresses the methodologies’ scope, or completeness. Some methods, such as Agile Modeling (AM) and Test-Driven Development (TDD), are partial approaches, whereas others, such as DSDM and FDD, address the entire lifecycle. If you need to develop a single project, processes such as XP or RUP are good candidates. However, if you must address the full system lifecycle, you may need to adopt the EUP or IEEE 12207, as well.
To pick the right process for your job, you need to understand the strengths and weaknesses of your options, and mix and match techniques to arrive at the right approach. Many organizations find that the partial processes such as Scrum, AM and TDD provide commonality among teams following differing base processes such as XP, FDD and RUP. Maybe things aren’t as difficult as they appear, after all.
Scott W. Ambler is a senior consultant with Ronin International Inc. His latest book is Agil Database Techniques: Effective Strategies for the Agile Software Developer (Wiley, 2003)
