Aug 202013

Much has been written, presented and debated in the past few years on the “right way” for executives and policy makers to reinvigorate companies, markets and economies. The distinguished scholar Carlota Perez suggests fundamental changes to the way growth and prosperity get measured. Along somewhat similar lines, Steven Denning focuses on the damage inflicted through adherence to the tenet of maximizing shareholder’s value. Gary Hammel, elaborating on another thread that Perez touches on, advocates values over value. Last but not the least, Hagel, Brown and Davison emphasize the power of pull for both designing the right system and designing the system right [i].

While the debate spans some topics that are clearly beyond the scope of responsibilities a typical executive is entrusted with, it is quite relevant to the Agilist concerned with end-to-end process implementation. Agile principles can, of course, be beneficially applied to product delivery departments such as dev and test. However, the real benefits to be had can only be attained through applying agile principles to the overall business process, not “just” the software development process. As pointed out by Tasktop’s Dave West in his recent Agile 2013 presentation, many/most of the Agile implementations tend to be of the Water-Scrum-Fall variety. In such implementations the Agile process in R&D is “sandwiched” between before-and-after corporate processes that are Waterfallish in nature. From a system perspective, incoherence at one point or another of such systems is pretty much inevitable due to incongruence of operating principles across the “Water,” the “Scrum” and/or the “Fall” components of the system. This reality and its operational manifestations are illustrated in Figure 1 and Figure 2 respectively.


Figure 1: The Reality of Water-Scrum-Fall

(Source: Dave West’s Agile ALM Presentation in the Agile 2013 Conference)


Figure 2: Incoherence(s) in a Typical Water-Scrum-Fall Implementation

(Source: Dave West’s Agile ALM Presentation in the Agile 2013 Conference)

Drawing upon Figures 1 and 2, Figure 3 examines what typically happens before the Requirements and planning phases and after the Release phase in Dave’s Water-Scrum-Fall “sandwich”. Incoherence can easily happen across any two of the circles depicted in Figure 3. For example, your business strategy, and the corresponding product portfolio, might not be aligned with the capacity of your Scrum team; a mandatory regulatory process could easily diminish, and possibly undo, the hard-earned time-to-market gains attained through agile in R&D; or, if your corporate strategy is to maximize shareholder’s value, the quarter-to-quarter predictability required of the Agile process is quite likely to exceed what any Agile software method can deliver. As colleague and friend Jim Highsmith astutely pointed out, Agile is a reliable process, not a predictable process.


Figure 3: A Typical Corporate End-to-End Context

What is an executive to do under such circumstances? In her outstanding series of presentations entitled Internet Trends, Mary Meeker foresees and foretells the emergence of “‘On my Watch’ executives at ‘Traditional’ companies.” If you are such an executive in a ‘traditional’ company, how do you actually establish coherence across the various layers of your end-to-end process? Obviously, you can’t just sit on your hands waiting for maximizing shareholder’s value to cease being a cherished tenet. If you do, you might find yourself waiting for a long period of time that will render Meeker’s ‘On my Watch’ paradigm pretty meaningless.

IMHO, the only practical choice these days with respect to coherence an ‘On my Watch’ executive can attain is picking the least risky point of incoherence[ii]. You might be willing to accept some incoherence between your portfolio management process and Agile in R&D; or, you might prefer to live with incoherence between the Agile process in R&D and marketing; possibly, you might choose to accept a certain level of incoherence between the rigor of your release process and the pressing demands of a community you manage. Hard, and quite possibly painful and distasteful that the choice might be, it is your only pragmatic degree of freedom during a period in which technology, finance and society struggle to reestablish equipoise[iii].

I recently posed the “choose the point of your incoherence” dilemma to Pete[iv]– a CTO client of mine who is implementing an agile transformation in his company as a way to make the business as fluid and responsive as the context of digital technologies demands. Pete pondered for a little while and ultimately picked the Scrum Masters as his preferred point of incoherence. His rationale for so picking was straightforward: as the Scrum Masters report in his organizations, Pete is on top of project execution and project status data. With these kinds of data at his fingertips, whenever a painful incoherence arises he can resolve it directly, meaningfully and effectively at the C-level.

You might, of course, choose your organizational incoherence at quite a different place than the one Pete chose for his company. You might even find yourself revising your initial choice and picking your preferred point of incoherence in quite a different place than your first choice. To paraphrase Jessica Alter: “… [it] is not just about how it works, it is about the process of how you get it to work.”

In the context of today’s digital realities, wherever you pick your point of incoherence, it will be much superior than trying in vain to align every link in your corporate level end-to-end process. Accept the inevitability of incoherence in your end-to-end system, choose the point you are most comfortable with and manage the incoherence whenever it flares up.

[i] Needless to say, many other authors that are not mentioned here have made significant contributions to the topic. The rationale for my picking just a few is straightforward: this is merely an illustrative list (as distinct from a comprehensive survey) for the purposes of the thesis discussed in this post.
[ii] For a deep analysis of the imperative need to make such a choice, listen to Paul Robertson’s magnificent talk Pursuing Perfection: The Art and Paradox of Leadership.
[iii] Perez actually perceives such imbalances as transitory periods that are in the very nature of technological revolutions. See Technological Cycles and Financial Capital: The Dynamics of Bubbles and Golden Ages.
[iv] To ensure confidentiality, I use “Pete” here instead of the CTO’s real name.


 Leave a Reply

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=""> <s> <strike> <strong>