The Agile Executive

Making Agile Work

Posts Tagged ‘Techno-Economic Paradigm

The Real Cost of One Trillion Dollars in IT Debt: Part II – The Performance Paradox

with 7 comments

Some of the business ramifications of the $1 trillion in IT debt have been explored in the first post of this two-part analysis. This second post focuses on “an ounce of prevention is worth a pound of cure” aspects of IT debt. In particular, it proposes an explanation why prevention was often neglected in the US over the past decade and very possibly longer. This explanation is not meant to dwell on the past. Rather, it studies the patterns of the past in order to provide guidance for what you could do and should do in the future to rein in technical debt.

The prevention vis-a-vis cure trade-off  in software was illustrated by colleague and friend Jim Highsmith in the following figure:

Figure 1: The Technical Debt Curve

As Jim astutely points out, “once on far right of curve all choices are hard.” My experience as well as those of various Cutter colleagues have shown it is actually very hard. The reason is simple: on the far right the software controls you more than you control it. The manifestations of technical debt [1] in the form of pressing customer problems in the production environment force you into a largely reactive mode of operation. This reactive mode of operation is prone to a high error injection rate – you introduce new bugs while you fix old ones. Consequently, progress is agonizingly slow and painful. It is often characterized by “never-ending” testing periods.

In Measure and Manage Your IT Debt, Gartner’s Andrew Kyte put his finger on the mechanics that lead to the accumulation of technical debt – “when budget are tight, maintenance gets cut.” While I do not doubt Andrew’s observation, it does not answer a deeper question: why would maintenance get cut in the face of the consequences depicted in Figure 1? Most CFOs and CEOs I know would get quite alarmed by Figure 1. They do not need to be experts in object-oriented programming in order to take steps to mitigate the risks associated with slipping to the far right of the curve.

I believe the deeper answer to the question “why would maintenance get cut in the face of the consequences depicted in Figure 1?” was given by John Seely Brown in his 2009 presentation The Big Shift: The Mutual Decoupling of Two Sets of Disruptions – One in Business and One in IT. Brown points out five alarming facts in his presentation:

  1. The return on assets (ROA) for U.S. firms has steadily fallen to almost one-quarter of 1965 levels.
  2. Similarly, the ROA performance gap between corporate winners and losers has increased over time, with the “winners” barely maintaining previous performance levels while the losers experience rapid performance deterioration.
  3. U.S. competitive intensity has more than doubled during that same time [i.e. the US has become twice as competitive – IG].
  4. Average Lifetime of S&P 500 companies [declined steadily over this period].
  5. However, in those same 40 years, labor productivity has doubled – largely due to advances in technology and business innovation.

Discussion of the full-fledged analysis that Brown derives based on these five facts is beyond the scope of this blog post [2]. However, one of the phenomena he highlights –  “The performance paradox: ROA has dropped in the face of increasing labor productivity” – is IMHO at the roots of the staggering IT debt we are staring at.

Put yourself in the shoes of your CFO or your CEO, weighing the five facts highlighted by Brown in the context of Highsmith’s technical debt curve. Unless you are one of the precious few winner companies, the only viable financial strategy you can follow is a margin strategy. You are very competitive (#3 above). You have already ridden the productivity curve (#5 above). However, growth is not demonstrable or not economically feasible given the investment it takes (#1 & #2 above). Needless to say, just thinking about being dropped out of the S&P 500 index sends cold sweat down your spine. The only way left to you to satisfy the quarterly expectations of Wall Street is to cut, cut and cut again anything that does not immediately contribute to your cashflow. You cut on-going refactoring of code even if your CTO and CIO have explained the technical debt curve to you in no uncertain terms. You are not happy to do so but you are willing to pay the price down the road. You are basically following a “survive to fight another day” strategy.

If you accept this explanation for the level of debt we are staring at, the core issue with respect to IT debt at the individual company level [3] is how “patient” (or “impatient”) investment capital is. Studies by Carlota Perez seem to indicate we are entering a phase of the techno-economic cycle in which investment capital will shift from financial speculation toward (the more “patient”) production capital. While this shift is starting to happens, you have the opportunity to apply “an ounce of prevention is worth a pound of cure” strategy with respect to the new code you will be developing.

My recommendation would be to combine technical debt measurements with software process change. The ability to measure technical debt through code analysis is a necessary but not sufficient condition for changing deep-rooted patterns. Once you institute a process policy like “stop the line whenever the level of technical debt rose,” you combine the “necessary” with the “sufficient” by tying the measurement to human behavior. A possible way to do so through a modified Agile/Scrum process is illustrated in Figure 2:

Figure 2: Process Control Model for Controlling Technical Debt

As you can see in Figure 2, you stop the line and convene an event-driven Agile meeting whenever the technical debt of a certain build exceeds that of the previous build. If ‘stopping the line’ with every such build is “too much of a good thing” for your environment, you can adopt statistical process control methods to gauge when the line should be stopped. (See Using 3σ  Control Limits in Software Engineering for a discussion of the settings appropriate for your environment.)

An absolutely critical question this analysis does not cover is “But how do we pay back our $1 trillion debt?!I will address this most important question in a forthcoming post which draws upon the threads of this post plus those in the preceding Part I.

Footnotes:

[1] Kyte/Gartner define IT Debt as “the costs for bringing all the elements [i.e. business applications] in the [IT] portfolio up to a reasonable standard of engineering integrity, or replace them.” In essence, IT Debt differs from the definition of Technical Debt used in The Agile Executive in that it accounts for the possible costs associated with replacing an application. For example, the technical debt calculated through doing code analysis on a certain application might amount to $500K. In contrast, the cost of replacement might be $250K, $1M or some other figure that is not necessarily related to intrinsic quality defects in the current code base.

[2] See Hagel, Brown and Davison: The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion.

[3] As distinct from the core issue at the national level.

Predicting the Year Ahead

leave a comment »

Cutter Consortium has published predictions for 2010 by about a dozen of its experts. My own prediction, which examines the crash of 1929, the burst of the “dot-com bubble” in 2000 and the financial collapse in 2008, is actually quite bullish:

I expect 2010 to be the first year of a prolonged golden age. Serious as the various problems we all are wrestling with after the 2008-2009 macro-economic crisis are, they should be viewed as systemic to the way a new generation of revolutionary infrastructure gets assimilated in economy and society.

In addition to the techno-economic view expressed in the Cutter prediction, here are my Agile themes for 2010:

  • Agile moves “downstream” into Release Management.
  • Agile breaks out of Development into IT (and beyond) in the form of Agile Infrastructure and Agile Business Service Management.
  • SOA and Agile start to be linked in enterprise architecture and software/hardware/SaaS organizations.
  • Kanban starts an early adoption cycle similar to Scrum in 2006.

Acknowledgements: I am thankful to my colleagues Walter Bodwell, Sebastian HassingerErik Huddleston, Michael Cote and Annie Shum who influenced my thinking during 2009 and contributed either directly and indirectly to the themes listed above.

Open Source Software and Agile Software Development: Parallels and Lessons for Enterprise IT

with one comment

Cutter Consortium has published the Executive Update entitled Open Source Software and Agile Software Development: Parallels and Lessons for Enterprise IT by Sebastian Hassinger (“Seb”) and me. Here is the abstract:

The phenomenon of open source software (OSS) is a recognized and mature aspect of the global IT market with profound implications for enterprise IT. A newer trend emerging is the various disciplines and methodologies that fall under the rubric of agile software development, which has a number of interesting parallels with and similarities to OSS. With the adoption en masse of OSS projects, such as Linux and Apache, by the mainstream enterprise customer, there is a track record of more than 10 years with which to gauge the extent and the nature of the impact on the enterprise. While agile has not yet reached the level of adoption that OSS enjoys, all indications are positive for that occurring in the near future. By examining its parallels with OSS, one can make inferences about the nature of the long-term potential impact of agile.

I am honored to co-publish with Seb!

(If you have not yet “e-met” Seb, here is his bio:

Sebastian Hassinger has worked in the IT industry for more than 25 years in large firms and as an entrepreneur. He founded two ISPs, helped launched several startups, and held senior strategy and business development roles with Apple, IBM, and Oracle. Mr. Hassinger created the first customer support Web site for Apple Computer. At IBM, he helped create a new business unit in the Tivoli subsidiary to address the needs of system management in the Internet era; worked on special projects for Tivoli’s CTO, including defining an Internet protocol for management of dynamic services; and was Senior Strategist for IBM’s Pervasive Computing initiative. At Oracle, Mr. Hassinger is Director of Market Development, where his specific responsibilities include developing the financial services market worldwide and the Asia-Pacific horizontal market. He holds MBAs from Columbia University and London Business School, is a published author, and holds more than a dozen software and business model patents. He can be reached at shassinger@gmail.com).

The Case for Agile Business Service Management

leave a comment »

BSM Review has just published my article The Case for Agile Business Service Management. Here is a key para from the article:

During turbulent times such as the past year, Agile business service management enables the business to become more competitive by speeding up the pace of delivery of new functionality and accommodating changes in business requirements as part of standard operating procedures. Like a computer chess program that extends clever tactics into the strategic realm [The New Yorker 2005], it compensates for the lack of prolonged periods of techno-economic stability through business Agility, substituting speed, flexibility and momentum for traditional long range planning. It is particularly noteworthy that Agile business service management applies equally well to companies pursuing adaptive strategies as to those betting on shaping strategies [Hagel et al 2008].

As indicated in a previous post, the article outlines the research agenda I will be pursuing. Specifically:

  • How is agile BSM implemented and delivered? …measured?
  • What are the benefits of agile BSM to the business objectives of development? …ops? …test?
  • Who carriers responsibility for agile BSM delivery and implementation?
  • Who benefits from agile BSM delivery & implementation?
  • How are these benefits applied?
  • When is Agile BSM expected to be understood and accepted by the business entities?
  • Where is agile BSM likely to be wholeheartedly implemented first?
  • What is the impact of Agile BSM on ISV’s (as distinct from IT “shops”)?

Listeners to Live Recording of Four Principles, Four Culture, One Mirror are well aware of my view of scaling downstream – it is the most tricky of the three dimensions of Agile scaling (up, out, downstream). IMHO Agile BSM is the first step toward effective scaling downstream.

Role of the Agile Leader in Reconfiguring the Business

with one comment

Click here for the slide deck from my Agile 2009 presentation. 

Abstract: The presentation applies Agile thinking to critical aspects of strategy and execution at a time of uncertainty and disruption. The essential point is simple and logical: Agile values and principles are indivisible. To succeed, they must be applied not just to R&D, but also to customer and company, simultaneously. This requires reconfiguration of customer relationships, employee policy, software development, and the relationship that binds the three. The resulting paradigm shift could lower the cost of software and produce prosperity similar to the one induced by ultra-cheap oil in the 50’s.

Perspective: In addition to being a ‘think-piece,’ the presentation offers pragmatic recommendations for the Agile champion in three critical areas:

  •  It explains how the Agile champion can cross three chasms that tend to form in the course of large scale Agile rollouts.
  •  It explores how to apply Agile priciples to software deployment and operations.
  • It shows how earned value management can utilize ‘real time’ customer feedback in companies that embrace end-to-end Agility.

Punching Above Your Weight Class

leave a comment »

Authors Hagel, Brown and Davison use an interesting metaphor in a recent Harvard Business Review article on strategy in time of constant change:

Today’s new Digital infrastructure in fact gives relatively small actions and investments an impact disproportionate to their size. To use a boxing metaphor, companies can now punch above their weight class.

Compare the Digital infrastructure with traditional infrastructures such as water canals, railroads or highways. Unlike these classical means of communication and transportation, Software is unique in being integral part of the Digital infrastructure as well as being a major piece of what gets transported over the  infrastructure.  Best I know no other entity ever played such a dual role in as meaningful a manner.

The metaphorical punch Hagel, Brown and Davison use as an illustration for the leverage provided by the Digital infrastructure is particularly intriguing due to to the malleability of software. Delivery methods for products and services over the Digital infrastructure could evolve the way product feature and functions do. If the product continues to evolve after initial delivery, the opportunity presents itself to do Agile in the deep sense recently proposed in The Lean Startup: iterative customer development alongside Agile product development that includes iterating on the delivery method.

Written by israelgat

April 21, 2009 at 8:40 pm

Marauder Strategy for Agile Companies

with one comment

Colleague Annie Shum sent me the URL to a recent post by Clayton Christensen in The Huffington Post. In this post Christensen characterizes “disruption” in the following manner:

Disruption is the causal mechanism behind the “creative destruction” that [economist Joseph] Schumpeter saw so pervasively at work in capitalist economies. [Links added by IG]

Christensen’s post is largely about the automobile industry. It, however, ties nicely to an email exchange Jeff Sutherland and I had about Agile as a disruption inside the company vis-a-vis its intentional use as a disruptive methodology in the market. To quote Jeff:

We are starting to see organizations like yours that can use Scrum to disrupt a market. There is a tremendous amount of low hanging fruit out there. Dysfunctional companies that can’t deliver. I’ve been recommending a “Marauder” strategy to the venture group. Find a company who has a large amount of resources. Set them loose like pirates on the ocean and they seek out slow ships and take them out.

Carlota Perez, who has been often cited in this blog (click here, here and here), is a disciple of Schumpeter. I really like the way the “dots” are connected: Schumpeter –> Perez –> Christensen –> Schumpeter. Their theories of disruption and constructive destruction express themselves nicely in the business design proposed by Jeff.