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