So you think you’re following Scrum?

I have a prediction. If you take the Nokia “Scrum Test” you are going to score somewhere less than 7. That means you aren’t doing Scrum, you’re doing “ScrumButt:”

A ScrumButt is a sort of like Scrum implementation… but some changes that were too painful have been left out… Companies in this category tend to only experience moderate success with Scrum, i.e revenues up 0-35%. This is very different from the design goals Jeff Sutherland had for Scrum, i.e. to create hyper productive teams and hyper-profitable companies.

In 2005 Bas Vodde, agile pioneer and coach within Nokia Networks, created the original test. In 2008, Scrum co-creator Jeff Sutherland extended the test by introducing new questions and a scoring model. Today, Jeff works with openview venture partners to help investors make money by only investing in companies with state of the art software development capabilities.

The test itself is incredibly informative — and the results usually much more so. Merely answering the questions posed in the Nokia Test will reveal some obvious shortfalls in most Scrum implementations. But take care to answer honestly and objectively. It’s not a bad idea to make the exercise a team activity, reaching serious consensus on the answer to each question.

Scrum and Agile becoming widely accepted

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.

Rational Scrum

Recently I tried out a variant on methodology that I’ll dub Rational Scrum. I’ve been trying to put together a few thoughts about the overall process for months, and finally found some time for it.

Just as people have specializations, so do processes. Applying one process to all situations is just as wrong as calling your dentist when you need brain surgery.

Rational itself is an excellent methodology and scales very well. Starting with only a few Rational artifacts, it can almost feel like Extreme Programming. Yet, the Rational body of work provides a framework that supports a much more comprehensive methodology… something less than full-on Spiral development, but still robust enough to handle large-scale, distributed team development.

However, for all that I like Rational, it does have some holes… and these are plugged most wonderfully by Scrum. In fact, Rational and Scrum benefit each other so well I’ve started referring to the combination as “Rational Scrum.” As with most methodologies, it does not define every possible response to every possible situation, but the combination of these two techniques is very robust and complete.

The processes complete each other by addressing mutual weaknesses. Scrum steps in to fill a gap in organization and team management. Conversely, Rational brings a structured, risk-driven approach to Scrum that is lacking.

Continue reading

Navigating the methodology maze

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.
Continue reading