It often starts as a seemingly plain training request. Having decided to go the agile route, a client would like Cutter to train a certain number of employees in one agile method or another. We collect data on the demographics of the target population: architects, UI designers, product managers, project managers, developers, testers, and so on. We then move on to discuss the way these folks are geographically dispersed and what the team structure for the launched agile teams will be. Once these parameters have been nailed down, it largely becomes a matter of figuring out the logistics for training and coaching. A fairly straightforward process for rolling out the agile process, one might say.

The catch, time and time again, is that the problem to be solved had been defined from the outset in too narrow a manner. Naturally enough, a client wrestling with software challenges tends to gravitate toward improving the software method(s) in use. It is a small step from here to the conclusion that effective training and coaching are the only services that really need to be provided by the consultant(s).

The typical outcome of such a narrowly defined engagement is improved tactical agility. The teams become quite good at responding to frequent change needs. Stories get added, modified, deleted, or reprioritized fairly effectively and (many times) efficiently. The improvement can be assessed, and very possibly quantified, in quite a few ways. Yet, it is quite difficult, if not impossible, to point out the actual business benefits. The improvement in the process is clear enough to anyone who cares to examine it, but the end-to-end functioning of the software still leaves much to be desired. The “so what?!” question is typically raised under such circumstance: could it be the case that the resources put into the agile initiative could be better invested elsewhere?

My view on the subject — before, during, and after the engagement — is that an improved software process is a necessary but not sufficient condition for attaining the desired business results. Obviously, elaborate business plans are next to impossible to implement if the software process crumbles underneath them. However important tactical agility through a robust agile process is, it cannot on its own address strategic adaptability nor supply-demand alignment issues. To succeed as a business from a software perspective, you need all three: agility, adaptability, and alignment.

Lack of strategic adaptability is the end result of the accumulation of all “sins” that had been committed “against” the code prior to starting a new page with agile. The investment you put into improving the software process will probably pay off nicely in terms of quality, productivity, and time-to-market at some point in the future. Unless the level of your technical debt on the existing code is really low, however, your overall software system — old in combination with the new — will be slow to adapt. In addition to investing in agile, you will need to invest in pushing down the level of technical debt that had accrued over the years. You might choose to think of the investment in agile as primarily forward-looking. In contrast, cleaning up the technical debt mess might (erroneously) seem like backward-looking. However, both need to take place. As a matter of fact, doing the two together is quite synergistic, as technical debt is an excellent metric for driving agile software development.

If you step back to examine how the technical debt accumulated in the first place, you are very likely to find out that the vicious cycle depicted in Figure 1 has been taking place for years on end. It is not lack of expertise or the difficulty of development across the pond that got the software in trouble (though these might be contributing factors of secondary importance). Rather, it is the inevitable system dynamics that prevail when supply (i.e., team capacity) is misaligned with demand (i.e., requirements).

Figure 1 — The vicious cycle of technical debt.

Aligning supply with demand is in many ways the acid test for the long-term success of your agile initiative. Our knowledge of the agile process has increased dramatically over the past 10 years. Likewise, progress in technical debt measurement, reduction, and prevention has been quite impressive during the past couple of years. We know enough about agile methods and technical debt techniques to improve the state of affairs in all but the most desperate situations. As Figure 1 illustrates, we also possess a fairly good understanding of how misalignment could lead to the accumulation of technical debt of biblical proportions. What are often lacking are the discipline, will, and determination to force alignment.

My recommendation on supply-demand alignment in the sense defined in this article is to use the data structure of the enterprise depicted in Figure 2 as the tool for forcing alignment at multiple levels of abstraction. The principle is simple: the grand total of development and technical debt reduction work (probably expressed as dollars) at the epic level can’t exceed the amount allocated at the respective theme level. Likewise, the grand total of development and technical debt reduction at the feature level can’t exceed the amount allocated at the respective epic level. Ditto for the story level: the grand total of development and technical debt reduction at the story level can’t exceed the amount allocated at the respective feature level.

Figure 2 — Data structure of the enterprise.

You can opt to traverse the data structure of the enterprise in a top-down manner or in a bottom-up fashion. Whatever direction you choose, you must maintain the integrity of the calculations (i.e., the grand total in one level can’t exceed the respective allocation in the level above). Maintaining this integrity is quite possibly the number-one responsibility of the stakeholders you pick to govern the software process in your company.

Israel Gat, Director, Agile Product & Project Management Practice

avatar

Israel Gat

Israel Gat is Director of Cutter Consortium's Agile Product & Project Management practice and a Fellow of the Lean Systems Society. He is recognized as the architect of the Agile transformation at BMC Software. Under his leadership, BMC software development increased Scrum users from zero to 1,000 in four years. Dr. Gat's executive career spans top technology companies, including IBM, Microsoft, Digital, and EMC.

Discussion

  5 Responses to “Agility, Adaptability, and Alignment”

  1. Thanks for another great post.

    I agree that “tactical agility” is a necessary, but not sufficient competency for achieving sustainable business benefits. Too often, though, management folks are happy to impose lean/agile practices upon the development teams in an attempt to get more work done, but are less willing to make the tough decisions necessary to align demand with capacity and mitigate the need for shortcuts that lead to technical debt. Ironically, in doing so, they never reap the full benefits of the agile/lean initiative and may even determine that it was a waste of time.

    In your practice, have you found ways to get this point across to management, perhaps through games or simulations?

  2. avatar

    Thanks for the kind words, Jeff.

    I use a deck of slides entitled “Tenets of Scrum” with every executive team I train/coach. The whole deck is about the ‘hand shake’ (i.e. working agreements) between the executives and the team level “Scrummers.” One of the slides is about aligning business with development. If the exec team is genuinely interested in such alignment we jointly do the alignment work. If they don’t, I merely say “You will only get out of Scrum (or any other software method) as much as you would invest in it.”

    Best,

    Israel

  3. The point that I am missing on the many blogs on agile on the Cutter site is that agile is the oposite of structure, strategy or process maturity. I usually call agile anarchy for enterprises. However it is important that we have agile as the way of process maturity will allways stop inovation. However I do not believe it makes any sense to join both sides into a unified way, instead I see that agile will be the R&D of a company with ideas then to be implemented in the process driven main stream via change management. What I am really after is to see how this could best be played out within an Enterprise setting.

  4. avatar

    IMHO Agile is very synergistic with structure, strategy and process maturity. Any Agile project at scale that does not build on these three critical elements is likely to fail.

    Mike Rosen, Hillel Glazer and I developed Total Agile Management (see http://bit.ly/gEUDVz)- precisely for that purpose. Here is an excerpt:

    “Total Agile ManagementTM (TAM) is an approach developed by Cutter Consortium that incorporates the best practices of Agile, software engineering, and architecture to address change, quality, complexity and consistency with a unified set of principles and practices.”

    Best,

    Israel

  5. The implementation of Agile in an enterprise has wide-ranging positive impacts beyond simply R&D process. It has been experience that a successful agile implementation does have impact upstream impacts (e.g. portfolio funding decisions by executives) and downstream impacts (e.g. go to market, sales and support).

    To fully realize all the benefits of agile in its entirety, you must look beyond the “factory”.

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>