According to an informal poll conducted by Cranky PM, Agile methods (Scrum in particular) has been penetrating deeply into the enterprise. Specifically, in 2006, you reported that a sizable majority of product development used a waterfall methodology (55%), with Scrum garnering a mere 7%. In 2008, the picture is very different. Scrum and its Agile cousins account for nearly 60%, where waterfall has dropped to a mere 28%. While it’s a small statistical sample, the figures are encouraging.
An operational, successful team is more than a set of interchangeable, anonymized skill sets, a fact the software industry is starting to realize. A cohesive team is far more than a room full of engineers. It’s a step toward maturation of the industry that is long overdue.
In some industries involvement of the “whole team” is almost assumed. Would you buy a car that had never been tested in a safety lab? How about try out a new instrument configuration on an airplane, knowing it had been redesigned by engineers and not pilots? Does it seem reasonable to build a house without hiring an architect? Each of these examples will more often lead to failure than success.
Yet the software industry, particularly the commercial industry (as compared to Military, for example) has been ploughing along without whole teams for decades—a trend that seems to be getting more and more negative attention. Recently evolving standards such as Extreme Programming, Agile methods, Scrum and the Rational Unified Process have all incorporated whole team concepts into their methodologies.
The Whole Team Approach
The term “Whole Team” defined: What is it and why is it so important?
The concept behind the “whole team” is that building a product without representation from every stakeholder is fundamentally flawed. It takes constant, comprehensive involvement through every aspect of the product life cycle in order to guarantee timely delivery of a well-designed product. For example, without a quality assurance organization’s involvement, it is almost certain that customers will discover incomplete requirements after delivery. If the user perspective is not considered early on, it’s very likely the product won’t be accepted or even usable until a second generation is built. Failing to involve software testing and configuration management means failure to deliver working code. And not involving program management, marketing and even financial oversight can lead to a host of problems in execution. All of these situations arise from lack of whole team involvement and can easily lead to a product stumbling out the gate or outright failing.
Project managers and team leaders have an extensive array of development methodologies at their disposal. Over the past 20 years methodologies to fill every conceivable development need have evolved. Rapid development techniques, long-range waterfall or spiral management models, “extreme” programming and iterative methodologies only name a few. Each one targets a different perceived project need, with some focusing on getting the job to market as quickly as possible while others emphasize reliability and reproducibility. From the Rational Unified Process and XP to waterfall and SCRUM, how can you decide what methodology is “right?” And when is it right? Where is the methodology for choosing the right methodology?
Standardizing on a single methodology is often not the right decision, either. A single technique is often not adequate for the myriad variables of software development. Organizations frequently make the mistake of selecting a single methodology and applying it rigidly to all technology projects. We wouldn’t choose a single vehicle for all conceivable transportation needs — such as taking out the sports car to haul furniture on Friday and jetting to the office in it on Saturday. Yet this happens all the time as organizations choose a single development methodology and employ it in all projects.
Compounding this difficult decision is the complexity involved in many aspects of methodology implementation. How can the plethora of options be evaluated? What is important for your project? How can the interaction of your team’s maturity with different methodologies be evaluated, and what impact should it have on your decision? Many so-called “best” methodologies are rejected out of hand for being too invasive, requiring too much artifact production or being too constraining. More often than not these beliefs stem from an incomplete understanding of the methodology and sometimes even its core principles. At Bold Development, where I directed evaluation and selection of methodology standards, I meet three different individuals who had “practiced the Rational Unified Process” and yet had negative experiences, laden with heavy process, excessive documentation and artifact production, as well as very poor results. Such indicators usually mean that the process is poorly understood and, sure enough, each person I interviewed had misconceptions about the Rational Unified Process. In the end, it wasn’t the Rational Unified Process that failed, but rather that the execution was in many regards misguided:
“A process should not be followed blindly, generating useless work and producing artifacts that are of little added value. Instead, the process must be made as lean as possible while still fulfilling its mission to help developers rapidly produce predictably high-quality software.” —Kroll, Kruchten (The Rational Unified Process Made Easy: A Practitioner’s Guide to Rational Unified Process)
Such problems are not limited to the Rational Unified Process (RUP). Extreme Programming (XP) horror stories abound where projects spin out of control, seeming to operate in chaos mode with no roadmap, schedule or forethought. At SeeBeyond, where I directed world-wide support operations, it was clear that standardization on Extreme Programming had resulted in over-reaching the bounds of what it could accommodate. The recurring problems of misunderstood goals, inability to plan for the future and missed delivery dates clearly indicated that the methodology was not working. Perhaps not surprisingly, this most often stems from a poor understanding of XP itself — and that includes understanding what the creators of the process originally intended.
Choosing the right tools to get the job done is time consuming. Development process is not a simple, one-size-fits-all equation. Project teams have a wide array of techniques available to them — but it’s important to remember that its the project, not the manager, that chooses the methodology. That is to say, the parameters of the project as a whole must be taken into consideration when deciding what methodology to use. These parameters include project complexity, scope, planned change, stability of the project, expected duration, team makeup and team maturity and other elements of your organization. Understanding the sometimes subtle and not so subtle variations between methodologies is critical. Choosing a methodology that works for the team and accommodates project needs is, at best, tricky.