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.
In practice, however, many organizations ran aground with RUP when they tailored it to be something similar to the waterfall-style processes from yesteryear that they were familiar with. This is often referred to as RUPifall. Another common mistake was to say to themselves “wow, there’s a lot of great ideas here, we need to do them all” and as a result they would create a process that was far too heavy to meet their needs. In either case the problem was that they often didn’t have the process expertise required to right-size their process. We also see this with organizations starting from frameworks such as ITIL, COBIT, and CMMI so this clearly isn’t just a RUP problem.
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.
In practice organizations run aground with Scrum because they don’t have the process expertise to expand it to meet their needs. One only has to count the number of “How does X fit into Scrum?” conversations occurring in agile discussion forums online, or at user group meetings or conferences, to see that this is true. Step back for a moment and ask yourself how much time and effort has your organization invested in trying to adopt Scrum. Could it not have been more streamlined?
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?
This middle ground strategy isn’t without its faults. A challenge with DAD is that it explicitly reveals that agile software development, or as we prefer to say agile solution delivery, is complex. This is particularly true in enterprise-class situations where teams are often facing combinations of scaling factors such as larger team size, geographic distribution, and regulatory constraints. DAD makes it explicit that teams need to invest a bit of time up front to perform initial scoping, initial architectural modeling, and initial planning (all in a lightweight manner of course). This sort of pragmatic thinking can be inconvenient for less-experienced developers who just want to jump in and start coding. Because DAD promotes the philosophy of enterprise awareness it purposely bakes in strategies for governance, DevOps, and working with IT-level groups such as your enterprise architects and data management team to name a few. This can also prove to be inconvenient for developers who want to narrowly focus on doing what’s convenient for their team as opposed to what’s best for their organization.
The following infographic summarizes the main points in this blog posting.
We hope that you’ve found this blog posting enlightening. Even if you are well along the way of your Scrum adoption, or of evolving your RUP-based approach, you can still benefit from switching over to DAD. Scrum teams will find that it addresses many of the issues that you’re still struggling with, and RUP teams will find that it shows how to work in a far more lightweight manner. Organizations will find that it provides a much better foundation from which to scale agile strategies.