Is your organization concerned with the cost and time required to adopt agile strategies? Are you just starting out with agile and hoping to improve your chances of success by learning from the experiences of those who have gone before you? Are you part way into your agile transformation but struggling to figure out how it all fits together? If you answered yes to any of these questions please read on.
In this blog posting we discuss what it means to “right size” your software process to meet the needs of the unique situation that your team finds itself in. We discuss two common anti-patterns: starting with a process framework that is much too large for your needs and starting with one that is far too small for your needs. We argue that it’s much better to avoid these extremes and instead take a middle-ground approach by starting with a toolkit that is much closer to your actual needs.
Extreme #1: Large process repository
The first process right-sizing anti-pattern is to start with a large process repository, the classic example being IBM’s Rational Unified Process (RUP). Although RUP is much maligned within the agile community the fact is that if you were to examine it with an open mind that there are many very good ideas promoted by RUP. Be that as it may. The basic strategy with RUP is that you need to tailor down the process, often dramatically, to meet the unique needs of the situation your team finds itself in. To do this requires significant process expertise, time, and money.
Extreme #2: Small methodology
At the other extreme is the right-sizing anti-pattern of starting with a small methodology, the classic example in this case being Scrum. Although there is significant support for Scrum within the agile community, or at least among people who are new to agile, we’ve been seeing for a long time now that organizations are also running into trouble with this approach too. With Scrum the idea is that you add in the techniques that Scrum doesn’t address to right-size your process. Because Scrum proves to be only a very small part of the overall picture, to do this requires significant process expertise, time, and money.
A few years ago Forrester Research discovered that the majority of organizations “doing Scrum” had actually tailored it into what they called Water-Scrum-Fall (others call this Scrumifall). As we describe in Going Beyond Scrum this occurs for several reasons. First, Scrum doesn’t address the full delivery lifecycle, instead choosing to focus on the construction portion of it. As a result organizations tend to stick with what they know, a heavy project initiation phase and a heavy solution deployment phase. Second, Scrum only addresses only a small portion of what you need and explicitly leaves technical issues up to you. These issues include topics such testing, programming, architecture, governance, documentation, deployment and many others. As a result teams are left to piece together a process strategy that works for them, at the very same time that they’re struggling to understand the fundamentals of agile and lean software development. They rarely have the process expertise to do that and as a result end up having to hire hordes of expensive Scrum coaches, few of whom seem to understand the enterprise-class realities that your teams actually face. This is a risky and expensive proposition indeed.
The Effective Middle Ground
Both of these anti-patterns represent extremes: start with something large and cut it down to size, or start with something small and build it up to meet your needs. Why not start with something much closer to what you actually need? Doesn’t that make a lot more sense? Why do you need to do all this process work? Because someone wants to sell you tooling? Because someone else wants to sell you expensive coaching and questionable certification strategies? Isn’t it time to consider a more pragmatic strategy?
The Disciplined Agile (DA) toolkit is a more effective middle ground. It addresses the full delivery lifecycle, as does RUP (but not Scrum), and even gives you several choices from which to select. Sometimes a Scrum-based lifecycle is appropriate, sometimes a Lean lifecycle is, other times a continuous delivery lifecycle is best, and sometimes an exploratory “lean start up” lifecycle is. Different teams, different situations. DAD starts with a lightweight approach, as does Scrum but not RUP, helping you to avoid the bloatware of RUP and filling in the numerous blanks left by Scrum. DAD also gives you lightweight tailoring advice in the form of process goal diagrams, in many ways a cross between mind-maps and decision trees, that make your process choices explicit. The RUP process tailoring advice, if you bother to read it at all, is rather heavy handed and the Scrum tailoring advice boils down to “you’re smart, you can figure it out and if your run into trouble hire a coach.” Isn’t it time to abandon the extremes?
The following infographic summarizes the main points in this blog posting.