The Agile Executive

Making Agile Work

Archive for January 2009

Uncertainty, Complexity, Correctness

with 2 comments

The most frequent misconception I encounter in preliminary stages of Agile adoption is about the exact “pain” Agile addresses. Time and again I witness the surprise of executives, who are not deeply versed in software engineering, when I point out to them that poor technology and packaging choices often manifest themselves as process pains.  In many ways it is like the way pain “travels” in the human body. The back muscle I pulled yesterday during a long flight led to contraction of my neck muscles at night, giving me a headache today. A couple of  Tylenol caplets might help some, but a muscle relaxant is likely to be much more effective.

Three Dimensions to Consider

Following Jim Highsmith’s teachings on coping with uncertainty versus coping with complexity, the conceptual framework I use to frame the subject in the context of Agile engagements has three dimensions, as follows:

  • Uncertainty
  • Complexity
  • Correctness

I literally ask the person with whom I am discussing a project to characterize the nature and status of his project for me, and more importantly for himself, in terms of these three dimensions. Once the project has been characterized in such a manner, our discussion progresses to how each of the three project dimensions could be addressed.

Uncertainty versus Complexity versus Correctness

Agile is all about effectively addressing uncertainty, I say. I stress that Agile does not address complexity per se. It might indirectly help with complexity if it leads you towards deeper thinking about Complex Adaptive Systems. For example, you might consider evolving the product architecture in the course of your Agile project instead of pre-defining it. However, Agile is not a “medicine” for complexity pains.

Nor is Agile about correctness. A hyper-productive Agile team could actually go fast nowhere implementing a poorly conceived product. The “real time” feedback  loops of  the project team might help uncover that a product is mis-conceived. However, independent of the team feedback, you still need to determine what correctness means to you and how you would assess it as the product evolves.

Levels of Correctness

An intriguing question for enterprise level Agile deployment is at what level you should “measure” correctness:

  • Product level?
  • Solution level?
  • Service level?
  • Business process level?
  • Strategy level?
  • Policy level?
  • All of the above?

I will address this important question in length and depth in forthcoming posts on Agile Portfolio Management.

Written by israelgat

January 17, 2009 at 9:46 am

Your Battle of the Somme

leave a comment »

The 1916 Battle of the Somme is considered to be a disaster of the first order in the annals of British military history. By the end of the first day on the Somme, the butcher’s bill amounted to 60,000 British casualties. When the offensive tapered off after four and a half months of repeated attacks, the bill grew to 420,000 British casualties. “The thing is terrible”, said Lloyd George – Britain’s prime minister at the time – “and beyond human nature to bear, and I feel I can’t go on any longer with the bloody business.”

The contrast between the meticulously prepared battle plan on the one hand, and  the meager results the offensive achieved on the other hand, has been the subject of numerous studies since WWI. One of the most important factors that emerged in years and years of research is the lack of timely feedback. Front line troops did not have the means to report their situation to the immense military machine behind that was supposed to support them. As a result, combined arm tactics collapsed. For example, the rigid fire-plan for the rolling artillery fire dictated moving the barrage forward at a predetermined pace. The pace, arguably, had taken into account a realistic rate of progress by the infantry. As the British infantry in most cases got bogged down fairly quickly, after a short while it lost the benefit of close artillery support. Highly inspired that the British infantry was, courage under fire only led to astronomical casualties.

It is easy to attribute the blame to inadequate communication technology. After all, a few cell phones would have made quite a difference. Tempting that such attribution is, it ignores a deeper truth – the people over process truth.

The vast majority of British troops in 1916 consisted of “Kitchener armies” – citizen soldiers who came to the flag to replace the regular British army that got decimated in the first few months of the war. Though trained for battle during 1915 and the first half of 1916, the inexperienced troops were not trusted by the general staff that toiled to prepare a magnificent battle to end the war. The battle plan mandated  moving forward upright and in straight line, wave after wave. The perceived “danger” of the troops taking cover and not restarting the advance once they had laid down precluded any tactical initiative and flexibility.

Fast forward to software engineering today. I can certainly appreciate the complexities and risks involved in moving from Waterfall model to Agile software development. For example, your teams might not be sufficiently trained and coached in Agile methods. Naturally, you do not want to change the software process before a certain level of competence using Agile processes has been attained. At Digital Equipment Corporation we used to call it the monkey on the tree phenomenon. Tempting that a new branch on the tree might be, a monkey does not hop over from one branch to another if the prospect of falling down between the two branches is high.

Various obstacles to starting an Agile roll-out, let alone an enterprise level Agile roll-out, could indeed be standing in your way. I would, however, encourage you to pay special attention to your deeper feelings with respect to your “troops”. In your heart of hearts, do you really trust your troops? Do you believe requirements should be dynamically moved between release and backlog in response to the latest insights gained in the trenches? Do you expect product innovation to come from repeated experimentation at the individual team level? Is it acceptable to you to follow the technical intuition of a young and talented developer?

If you have not yet started training some of your product management, development and test resources in Agile methods, I suspect trust, and her twin brother control, might be the core issues you or your company are wrestling with.

Written by israelgat

January 16, 2009 at 11:50 am

The Core Principle Behind Agile

with 2 comments

Hyper-productive Agile teams, reaching twice, thrice and even higher level of productivity compared to industry average, have been reported by various consultants and practitioners, including Jeff Sutherland, Michael Mah and me. I run into a lot of questions about the reported case studies. Often times I sense that the executives quizzing me about the accomplishments of BMC Software are wishing at some level to find something extraordinary that would explain how my project teams accomplished hyper-productivity. In other words, the reported productivity figures are sometimes considered too good to be true in general.

IMHO Agile hyper-productivity stems from a very simple universal principle: everyone on the team does only the most important things at any point in time. Effectiveness and efficiency are the results of systemic elimination of less important features, functions and tasks.

Various executives ask me the question “Should I adopt Lean Agile or should I do Scrum ?” The answer I invariably give is “To my way of thinking, the two apply the same principle: Lean Agile focuses on eliminating waste; Scrum focuses on the elimination of “waste” in form of the less important.”

I will cover the “secret sauce” of BMC Software’s sucess with Agile methods in forthcoming posts. Before doing so, I would like the reader to come to terms with the following view: the secret sauce we used at BMC was “just” creating the environment within which the less important was eliminated.  What we did was a successful implementation of the core principle: “Do only the most important things at any point in time”.

In a way, our secret sauce was grasping this fundamental principle and developing a whole socio-technical system to free the principle from the metaphorical chains of archaic methods.

Written by israelgat

January 15, 2009 at 5:53 pm

Posted in Starting Agile

Tagged with , ,

Evolutionary System Development

leave a comment »

Mary Poppendieck pointed me at the recent Evolutionary System Development paper by Denning et al. The authors make two points which could be of particular interest to viewers of this blog, as follows:


  1. “All the evidence says that evolutionary processes work for systems large and small…”
  2. “… risk taking is the fastest route to fitness.”
Highly recommended!

Written by israelgat

January 14, 2009 at 7:11 pm

The View From the Executive Suite

with 4 comments

A few days ago I had the pleasure of spending a couple of hours with Bob Rockwell. Bob is the managing partner of AdviSoar, a Lewisville, TX consulting company specializing in coaching and developing executives, and teaching people the skills to develop executive relationships. “Helping Good People Do Great Things!” is AdviSoar’s mantra.

Business Risks Agile Addresses

Bob’s view of Agile, like any corporate executive, is business oriented. Important as the benefits to R&D are, Bob believes Agile is all about mitigating business risks. He specifically highlights the following as risks that Agile may be well suited to address:

  • Monetary risk: the level of investment it takes till one can have a meaningful “sniff test”.
  • Market risk: changes in the market in the window of time between concept and delivery. In particular, Bob is concerned about the risk of missing a market opportunity due to a too-constraining design document or a too-long development time. Additionally, Agile would seem to offer the potential of new discovery that could have market value.
  • Competitive risk: a rival in the market starts delivering faster or “better” by adopting Agile methods.
  • Execution risk: will the software be on-time? Will the business executive in charge get early warning signs in case the software project is in trouble?
  • Brand risk: tarnishing of image due to poor quality or miss-met expectations.
  • Innovation risks: shipping mediocre software (based) product due to insufficient experimentation and insufficient or ineffective “user” input through the process.

In other words, Agile for Bob is about running and growing the business, not about running R&D.

Laws of Software Engineering


Our discussion of the risks Agile mitigates led to highlighting a few “cheat sheet” points an executive should keep in mind with respect to doing or utilizing software:

  • The investment in software development is typically less than half the overall life-cycle investment in software.
  • The longer you take to address technical debt, the higher you pay.
  • The accrual of business value in well run Agile projects is exponential (see chart above); in contrast, the investment is linear in traditional waterfall processes. In the graph above, taken fromJim Highsmith’s Agile 2006 presentation “How to be an Agile Leader”, 90% value is captured upon delivering 50% of features.

We ran out of time before we could discuss the classical laws of software evolution established by Lehman and Belady. I have no doubt we will get into them next time Bob and I meet. In particular, the question how applicable these classical rules are to Agile software projects is a topic I plan to discuss with Bob in length and depth. Also, a social contract for Agile is on the “agenda”…

Stay tuned….

Written by israelgat

January 14, 2009 at 2:34 pm

Choosing Between Two Disruptions

with 2 comments

A couple of weeks ago I was talking shop with a colleague of mine – the co-founder and CTO of a fascinating software company. He was bemoaning the paralysis that was affecting his company. Every executive was playing it safe, too safe. It was next to impossible to finalize their CY2009 plan as no executive would give hard commitments, let alone be aggressive about making commitments. My colleague was worried. Big time.
The fascinating thing about our conversation was that my anguished colleague was quite bullish about Agile methods. His was an informed bullishness – he is a very astute developer who grasps the potential of Agile in a deep manner. While worried about the financial crisis working its way from Wall Street to Main Street, my colleague was quite willing to invest in Agile methods in more than one way. It was intuitively clear to him Agile is not only a good risk to take, it is the right kind of risk to take these days.

The Risks of Introducing Agile

The risk you take rolling Agile on a large scale is the possible process disruption you introduce in your company. There are several risks; at the top of the list:

  • R&D productivity could go down before it goes up.
  • Marketing might be hesitant to promote features that are not 100% guaranteed to be in the forthcoming release.
  • Sales will need time to elevate the playing fields from selling function/feature to selling value.
  • Customer Support must revise support policy to accommodate frequent releases.

I would not take any of these risks lightly. Any one of them could get you and your company in serious trouble.

I would, however, suggest you look carefully into the nature of the Agile disruption. Like a set of nested Russian dolls, the disruption to your company’s established modus operandi masks the disruption Agile creates in the market. When it comes to Agile, you face the Innovator’s Dilemma in the Christensen sense. 


The Risks of Avoiding Agile

As software becomes more and more pervasive, it does not really matter whether you are in Information Technology, Financial Services, Transportation, Retail or any other vertical. The strategic question you need to consider is your company’s competitive position in the market vis-a-vis rivals who will successfully adopt Agile:
  • How would you cope with a competitor who is much faster to market than you?
  • How would your cost structure be viewed by industry analysts when your rivals rip the benefits of hyper-productive Scrum teams?
  • Would your brand be negatively affected if you fell behind on quality? 
  • How would your strategic customers assess your response time to requests for enhancement compared to nimbler players in the field?

While Agile may cause what seems like negative disruption internally, the need for so doing is often dictated by a corresponding disruption in your markets, where you can’t choose to avoid the disruption. You need to do a risk assessment of the internal disruption Agile might cause versus how you will be affected by market disruption if you do nothing, or something other than Agile.

Written by israelgat

January 13, 2009 at 10:26 pm

Leading from Within – Tonight in Austin

with 2 comments

Update: see presentation above, or download directly.

Tonight I’ll be giving a presentation at the Austin IEEE meeting entitled “Leading from Within.” It examines the “secret sauce” for enterprise level Agile deployment with special emphasis on the virtues of the Agile leader.

You can see full details, including a map to the location on the Austin IEEE site.

Written by israelgat

January 13, 2009 at 4:50 pm

Posted in The Agile Leader

Tagged with