The Agile Executive

Making Agile Work

Archive for the ‘Risk Assessment and Mitigation’ Category

Threads from Washington, DC

with one comment

Rally’s July 23 Agile Success Tour in Washington, DC was somewhat unique demographically. About 50% of participants work for the government. Moreover, many of the commercial enterprises represented in the event derive a significant amount of their revenues from federal government contracts. The Agile challenges encountered by these folks reflect practices that are not necessarily applicable to “pure” commercial environment. For example, one of the participants asked me about Agile for a project of 500 developers/testers in which her company is the prime contractor for 100 subcontractors! (Recommendation: must devise a business design enabling her company to profitably invest in laying a joint Agile infrastructure across all these subcontractors. Such infrastructure leads to standardization of the Agile data. Click here for details).

In spite of the different demographics, most of the Agile issues brought up in DC were quite similar to those expressed in previous Agile Success Tour events. The bureaucracy with which various Agile champions in DC need to deal with might be stricter (due to security/confidentiality aspects of much of the development carried out in DC), but the underlying needs and dynamics are not really different from those in other cities in which Success Tour events were held.

Here is a sample of enlightening threads I listened to or participated in during the event:

  • The business fabric has not quite caught up with Agile methods. In particular, Agile contracts are not yet where they need to be. The costs associated with “ECOing the contract” each time a change in requirements is made offset the methodical benefits of Agile. We need to find a way to “encode” Agile principles in contracts.
  • In pitching software methods to their executives, Agile champions need to go beyond the benefits of Agile. Risk and risk mitigation are of equal importance. See The View from the Executive Suite for detailed guidance on the subject.
  • The benefits of Agile have to be expressed in terms of the business of the business. One has to go beyond capturing “just” the operational benefits and address financial and business benefits. Peter Drucker’s famous quip “Companies make shoes!” applies. Click here for examination of the quip in the Agile context.
  • Innovation through affordable experimentation is an Agile benefit that is under-represented in many discussions Agile champions hold. See the new edition of Jim Highsmith‘s Agile Project Management for an excellent discussion of this critical benefit.
  • Agile is about uncertainty, not about complexity. To demonstrate the power of Agile, choose a project of high uncertainty. Complexity in such a project depends on your risk tolerance – it could be either low or high. Be aware that various issues related to complexity might manifest themselves on the surface as process issues. See Uncertainty, Complexity, Correctness for an in-depth discussion of the subject.

Next stops of the Agile Success Tour “train” are in Boston, Chicago, Seattle and London. Stay tuned…

Written by israelgat

July 26, 2009 at 6:01 pm

Recommendations from Santa Clara

with 4 comments

So much was going on simultaneously in Rally’s Agile Success Tour event in Santa Clara! More than 140 participants, an eclectic panel, 6 breakout sessions, numerous 1-1’s and, of course, a ton of spontaneous interactions. This posts in many ways represents my own “thread” within this very gratifying event. My Rally colleagues will no doubt supplement this post by commenting on the various activities and interactions in which I was not able to engage.

The number one question I was asked in the course of the event was about the difficulties quite a few software development champions encounter in the course of attempting to coalesce successful Agile projects into comprehensive initiatives at the corporate level. Team successes with Agile sometimes remain isolated islands of excellence within corporate “oceans.” The proven  ability of a capable Agile champion to carry the day in specific project does not necessarily lead to adoption of Agile as part of an all-encompassing corporate doctrine. Just like the Geoffrey Moore entrepreneur who demonstrates success in the early days of his/her start-up but does not quite make it big time, the Agile champion often struggles to cross an adoption chasm and make his/her way to “main street.”

Colleagues Ryan Martens, Dave West and Tom Grant discussed how to apply Agile in combination with Lean to elevate Agile from the project level to the corporate level. There is no need to repeat their good work (click here for example) in this post. Instead, here are the tactical suggestions I gave in Santa Clara to various Agile champions who looked for recommendations how to elevate Agile:

  1. A statement of Agile benefits is not sufficient. It must go hand-in-hand with an assessment of the risks (plural!) associated with the Agile expansion. See A View from the Executive Suite for details of the recommended approach.
  2. Statements of Agile benefits and corresponding risk mitigation approaches are not sufficient. As Peter Drucker quipped, Companies make shoes! To be relevant at the strategic level, the Agile program must be tied into the top initiatives a corporation carries out.
  3. Statement of Agile benefits, risk mitigation and strategic relevance are not sufficient. These statements must be accompanied by a clearly articulated approach to managing the cultural aspects of extending and expanding Agile. If at all possible, opt for for building on the strength of the current culture. It is much more difficult to try to change a culture. Moreover, it take a long time to transform a culture. See my forthcoming presentation Four Principles, Four Cultures, One Mirror in Agile Roots for details.

I will allow myself to repeat my recent assessment from the NYC event as it applies so well to the Santa Clara event:

I came out of the Santa Clara event convinced that we as a movement have a great opportunity on our hands. What we -Agilists – do works quite well. The need clearly exists to elevate Agile to the enterprise level. We will be solving a real problem in so doing.

Written by israelgat

June 6, 2009 at 10:17 am


with 3 comments

The approach Eric Ries advocates for the Agile start-up has been covered in previous posts (click here and here). Basically, Ries sees the need to iterate on the customer problem alongside iterating on the solution to the problem. Furthermore, a process of discovery – finding the customer – accompanies iterations on the problem and on the solution.

In a note today entitled Three Designing Bears, Kent Beck brings up a great example for the approach Ries promotes:

[JUnit] Max is a bootstrapped product, so I need to find revenue as quickly as possible. I have no idea what people might actually pay for in a testing tool, so I need to try things as quickly as possible. Features only need to be finished enough to give me reliable feedback about their value. Will people pay for features like those? If so, I can afford to finish them later.

Various other threads are quite relevant to and consistent with the ideas of Ries and Beck. For example, commenting on Flickr in The Art of Agile Development, James Shore highlights their speedy {code –> test –> stage –> deploy} cycle:

When a user posts a bug to the forum, the team can often fix the problem and deploy the new code to the live site within minutes.

When coupled with “real time” user feedback, the confluence of speedy development with fast deployment reduces the risk of developing features that are never or seldom used. It applies to both start-ups and established enterprises. It opens the door for new software business designs that would have been considered infeasible just a few years ago. For example, one could enhance the Marauder Strategy (“seek out slow ships and take them out”) proposed by Jeff Sutherland by competing not “only” on velocity of development, but on accelerated deployment cycles and ultra-fast feedback loops.

Written by israelgat

May 6, 2009 at 10:26 pm

Standish Group: “More Projects Failing”

with 5 comments

The Standish Group has published its CHAOS Summary 2009 report. Here are two excerpts from the press release:

“This year’s results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions” says Jim Johnson, chairman of The Standish Group, “44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used.”

“These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures”, says Jim Crear, Standish Group CIO, “They are low point in the last five study periods. This year’s results represent the highest failure rate in over a decade.”

Written by israelgat

May 2, 2009 at 9:52 am

Pains from Los Angeles

with 14 comments

Click here, here and here for stroke-by-stroke coverage of the March 26 Rally event in Los Angeles by Zach. From my own interactions with participants during the event, I compiled the following  list of the most painful issues between an Agilist and his/her executive(s):

  1. The “sausage syndrome”: “Don’t bother me with details how you do the software – just get it done” seems to be the attitude of numerous “business executives.”  I must admit I still don’t get it. Software is becoming pervasive on an unprecedented scale. And, software is becoming bigger and bigger component of just about any product in which it is embedded. Ditto for software as part of the business process. What is your recipe for success if you (as an executive) don’t get down and dirty on such a major component of your business?!
  2. Agile as part of the overall software engineering fabric: This issue is a close cousin of the “sausage syndrome”. Expectations of Agile are unrealistic as it is not grasped holistically as one layer in the overall context of  the art of programming. We direly need a construct like the OSI Reference Model for software engineering.
  3. Agile and the real customer: Much of the emphasis is still on Agile in R&D. The real customer is not iteratively integrated  in the development process. In spite of a ton of data to the contrary, we often drive the iterative development process under the fallacy that the customer problem is well understood.
  4. Agile in the business context: Discussion are usually focused on $$. Most Agilists do not seem to be well equipped to discuss Agile in the contexts of  risk mitigation and compliance.
  5. Assimilating Agile: Little understanding that apprenticeship is a wonderful way to learn Agile. Precious few invest sufficiently in on-going Agile consulting and coaching.

I started the event stating that I feel like one foot in cold water, the other in hot water: we accomplished so much over the past few years, yet much more could and should still be accomplished. I finished the event with precisely the same feeling: a ton of enthusiasm for Agile in the trenches; the immense opportunity to harness this enthusiasm at the enterprise level is not quite happening yet.

Early Warning Signs

with 3 comments

Colleague Michael Mah describes comparing time-to-market, productivity and quality of a project team against industry averages as being outside the elevator. With the focus on iteration and release, it feels like being in an elevator – precious little contact with the outside world. For example, you do not know where other elevators are headed and what their speed is until you step out of the elevator. As long as you are in your “elevator”, it is quite difficult to objectively assess whether your Agile roll-out is or is not going well.

Until you collect  the data and acquire the analytics to compare your team to other project teams in the industry, here are a few early warning signs for Agile implementations  that might be heading toward trouble. Like everything in Agile, they give you the opportunity to take the input as call to action and apply the necessary measures to improve your process.

Time spent with Agile teams in the trenches

This is the simplest yet the most reliable warning sign. If you are the executive in charge of the Agile roll-out, examine your calendar over a certain period of time with respect to two questions:

  1.  Do I spend enough quality time with the Agile teams to be able to notice the rest of the early warning signs listed below?
  2. Am I involved in a manner that clearly demonstrates my support of and commitment to the Agile roll-out?

The data you collect from your calendar is simple. For example:

You do not need to say much in any of these forums. You might even choose to be completely silent through a stand-up meeting . However, you must spend quality time with the teams that are getting into Agile. Allocating 20-25% of your time to being with the Agile teams in the trenches is quite appropriate, particularly in the initial roll-out phases.

Failure to prioritize

The great advantage of this warning sign is that it can be spotted fairly early. In its implicit form, this sign manifests itself as multiple backlogs when one backlog should have sufficed from a product perspective. In its explicit form it manifests itself as everything is important statements and pressures. In severe cases you might even notice that the Product Owner is not really part of the team, that an us versus them attitude prevails.

Chronic reductions in scope

Flexibility is very different from mushiness around the minimum credible line of a release. Repeated reductions in scope, as distinct from substituting one requirement for another, is a certifiable sign of trouble. Something is wrong if reductions in scope happen one iteration after another. Something is terribly wrong if team members believe the Agile philosophy is supportive of scope reductions in an unconstrained manner.

In some cases the heart of the matter might be as simple as inadequate estimation techniques, not inadequate execution. However, until estimation accuracy improves, relationships between R&D and marketing and sales are likely to be strained.

This warning sign tends to manifest itself later rather than earlier in the Agile release. However, it is quite easy to spot.

Weak focus on outcome

This warning sign is a close cousin of chronic reduction in scope. It usually manifests itself as misplaced focus. For example:

  • The focus is on the team progress rather than overall project progress
  • Output numbers become more important than outcomes
  • Managers and directors bicker about which team was “behind”
  • Product marketing changes the backlog frequently under the “Agile flexibility” banner

Not keeping up

Keeping up with all facets of Agile practices amidst short iterations can be quite demanding. Watch out for repeated  failures to keep up with:

  • Builds
  • Continuous integration
  • Defects/testing
  • Completing stories within the iteration
  • Resolution of blocking issues
  • Regular bi-weekly demos
  • On-going release-ability
  • Technical debt

This warning sign is best used in the aggregate rather than in a discrete manner. To properly use this sign, watch for cumulative effects rather than a single failure.

 Acknowledgements: Many thanks to Igor Bergman, Walter Bodwell, Mike Lunt and Roy Ritthaler for sharing their warning signs with me and with the readers of this blog.

Written by israelgat

February 21, 2009 at 9:24 am

Agile Contracts

with 2 comments

Pragmatic programmers have been wrestling with Template Zombies– folks for whom form takes precedence over content – since time immemorial. The fight has intensified in the late 1990’s and early 2000’s as Agile methods got traction. This tension can now be seen in Agile contracts: precise and definitive contractual language does not easily lend itself to expressing fluid Agile concepts which rely on “infinite” number of feedback loops. This difficulty manifests itself as transaction costs. In particular, the bargaining costs and policing costs associated with Agile contracts can be significant. The number of contract types summarized in Alistair Cockburn‘s list of Agile contracting ideas is illustrative of how tricky it is to wrestle an Agile contact to the ground.

Building a Contract around Agile Principles

As indicated in the post The Core Principle Behind Agile, the effectiveness and efficiency of Agile is based on doing the most important things at any point in time. Hence, an Agile contract must preserve this principle. After all, what is the point of developing software in an Agile manner if the most fundamental Agile principle cannot be contractually adhered to in an economical manner?!

The key to solving this riddle is understanding the fundamental risk each party is striving to minimize:

  • The client needs to minimize market risk – the software is being contracted to accomplish some business or market objective
  • The Agile provider must minimize delivery risk

These two perspectives do not actually conflict with respect to changing the software along the way. As a matter of fact, being able to change product definition during the development cycle is in the client’s best interest in a world of constant disruption. For the experienced Agile software provider, changes from one iteration to another, sometimes from one day to another, are anyway a standard operating procedure. As long as the Agile process does not change, the delivery risk need not get out of hand.

It follows that the fundamental question under investigation here is the construction of a suitable vehicle for enabling requirements to change during the development cycle without getting bogged down in tedious inter-company bargaining and policing processes. Change in itself is not the core issue.

Money for Nothing

In an Agile 2008 presentation entitled “Money for Nothing and Your Change for Free”, Jeff Sutherland described a novel Agile contract. It is a fixed price contract that allows the client to terminate it at any point in time. When the client terminates a contract, he is only billed for the remaining 20% of unbilled contract value.

The phenomenon on which the money for nothing contract is based is exponential accumulation of value in highly productive Agile teams versus linear payment terms. In the “50-90” case discussed in The View from the Executive Suite post, the customer would be billed for 60% (50+0.2X50=60)  of the contract value. The corresponding accumulated business value for the client at the point of contract termination is 90%.

Your Change for Free

In addition to permitting early termination, Sutherland’s scheme allows substitution. The customer can add or change requirements on the fly as long as he is willing to de-commit an equivalent amount of labor. Upon presenting a new requirement, a new story card (call it X) will be added to the release to implement the new requirement. In return, a couple of less hefty story cards (call them Y and Z) will be moved from the release to the backlog. The contract terms do not change. The contract administrator merely notes that X will be implemented instead of Y and Z.

The Firm, the Market and the Law

It is fascinating to consider the money for nothing scheme in the context of the concepts introduced by Coase in The Firm, the Market and the Law. Using the termination and substitution clauses described above, Sutherland reduces Coase’s costs of the price mechanism to the level that makes the Agile contracts viable in the market. How appropriate it is that the reduction in the cost of the price mechanism is done in the context of Agile methods that strive to reduce cost!

Written by israelgat

January 29, 2009 at 1:19 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