The Agile Executive

Making Agile Work

Posts Tagged ‘CXO

The Business Value of Agile Software Methods

with 3 comments

I conducted 10 sessions this year on the topic Socializing Agile with Your Executives. The various Agile champions that attended these sessions identified two major obstacles to successful vetting of the topic:

  1. Lack of hard quantitative data.
  2. The “It won’t work here” syndrome.

This post is about the first of the two – lack of hard quantitative data. A follow-on post will deal with the second obstacle.

Michael Mah‘s landmark study How Agile Projects Measure Up, and What This Means to You has been my recommendation for the Agile champion who needs to elevate his/her Agile pitch from qualitative to quantitative. This excellent study in nicely supplemented now by The Business Value of Agile Software Methods: Maximizing ROI with Just-in-Time Processes and Documentation by Rico, Sayani and Sone. It is an excellent fit for the champion promoting Agile for the following reasons:

  1. The book captures, analyzes and synthesizes the results of hundreds of systemic research studies.
  2. It provides data on the various Agile methods without favoring one over another. Furthermore, the authors are quite explicit in stating that it not the method itself but the fit of a method to a company/culture/environment that counts.
  3. It places equal weight on costs and benefits of Agile, thereby giving the reader a good grasp on trade-offs. This grasp can be enhanced through free downloads of cost and benefit spreadsheets from the corresponding Download Resource Center.
  4. A very impressive aspect of this new book is the broad spectrum of the metrics it provides. Just about any business metric your CIO/CFO/CXO might use as the basis for his/her decision-making process, including Real Options Analysis (ROA), is provided. Moreover, the book encourages the use of multiple metrics, clearly indicating the pro and cons of individual metrics. For example:

The business value of Agile methods may be as much as 90% higher than NPV using ROA under extreme market conditions, including high inflation, risk change, and amount of time.

Readers of this blog are familiar with my quip “Don’t take you boss to lunch; take him/her to the daily stand-up meeting.” I would suggest you give The Business Value of Agile Software Methods to your boss at the end of his/her first stand-up meeting. This recommendation is nicely seconded by the following excerpt from Sanjiv Augustine‘s review of the book:

… those looking to build a bullet proof case for agile methods based on solid data and comprehensive research and analysis will find this an invaluable work.

 

Disclosure: Colleague David F. Rico has kindly sent me a free copy of The Business Value of Agile Software Methods.

Advertisements

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.

Can You Afford the Software You are Developing?

with 15 comments

A reader of The Agile Executive brought up some questions about product retirement in the context of  project teams that use Agile methods. For example: Should a product backed by a hyper-productive Agile project team be retired at the same point that an aging Waterfall product typically would?

The question is important. Customers can get very upset over the retirement of a product, particularly a mission-critical product. Even if the vendor offers a new product that replaces the one to be retired, the operational disruption associated with migrating to the new product is often troublesome. On the other hand, the cost of maintaining software, let alone keeping it current, could be and is often high for the enterprise software vendor.

The answer to the product retirement question ties Agile methods and practices to the fabric and economics of software engineering.  A good way to address the subject is to ask the following two questions:

  • Can you afford the software you are developing now?
  • Would you be able to continue to adequately invest in the software as it evolves down the road?

Rules of Thumb for Affordability

Affordability is, of course, in the eyes of the beholder. Your CFO might see it in quite differently than your CMO. To bring a discussion between the two, or any other forum of CXOs, to a common denominator, you need to get a handle on two numbers:

  • Development cost (including product management and test costs) per story card
  • Development cost as a percentage of product life-cycle cost

Development costs and life-cycle costs vary greatly from one company to another as well as within your company. For example:

  • Off-shore costs can be quite different from on-shore costs
  • The costs of maintaining high quality code are drastically different from those for average quality code. (See Estimating Software Costs by Capers Jones for a detailed analysis of the subject).
  • Productivity of an Agile team can easily eclipse that of a Waterfall team.

Laborious and time consuming that collecting good cost data across development methods, projects, sites and continents might be, you are essentially flying blindly with respect to affordability unless you have very specific cost data.

Until you gather this data, here are two rules of thumb that can be used to get a rough sense of  affordability:

  • A typical figure for development and test cost per story card for enterprise software project teams is thousands and thousands of dollars. It can exceed $10,000.  This (order of magnitude)  figure is for a contemporary software development and test organization in the US that is “reasonably” balanced between on-shore and off-shore development
  • Development cost is typically less than 50% of the total software life-cycle costs. Again, the assumption of reasonable balance between on-shore and off-shore applies

These rules of thumb should be used prudently. For example, Mens and Demeyer report cases in which software development costs constituted a mere 10% of the total life-cycle cost.

What is your Software Evolution Strategy?

In Program Evolution: Processes of Software Change, authors Lehman and Belady summarized years of research on the subject they and various collaborators carried out. Their bottom line is deceptively simple: software is live and always evolving. Furthermore, software decays.

Jim Highsmith uses the following great graph to demonstrate the effect of accrued technical debt on cost of change and responsiveness to customers:

in-can-you-afford-the-software-you-are-developing

Jim points out that no good option exists once the software has decayed to the point of excessive technical debt. Furthermore, once you are in the far right of curve estimation is next to impossible and afforability calculations become pretty useless. You might think about technical debt like debt on a credit card – you become a slave to servicing the debt instead of paying off the principal.

Affordability Revisited

Between the initial development cost and the cost of evolving and maintaining decaying software, many software development projects find themselves in dire need of higher productivity. Hence, a more precise statement of affordability is as follows:

  • Can you afford the software you are developing given your productivity during and after development of the first release?

The productivity results reported for companies successfully using Agile methods such as  BMC SoftwareSirsiDynix and Xebia indicate productivity gains of at least 2X, and often higher, compared to industry average. Everything else being equal you would be able to retire a product backed by a good Agile team later than a product backed by a Waterfall team.

Many Agile teams tend to be inclined to refactor the code on an on-going basis. For example, Salesforce devotes about 20% of development resources to refactoring. As a result, software decay is slower for such teams. They reach the point of no good options in Jim Highsmith’s graph later than teams who do not refactor the code day in and day out.

Refactoring is like flossing your teeth regularly. The dental tape disconnects your bank account from the dentist’s…

Written by israelgat

February 1, 2009 at 9:46 pm

Agile Considerations for CXOs

with one comment

“I don’t care about Agile; I care about money!” These words, said to me not too long ago by an executive with whom I was discussing the roll-out of Agile in his division, are the impetus for this post. Whether you are or are not in R&D, Agile can have a significant impact on you and on your company, including the bottom line.

To keep things simple, listed below are a few “front lobe” considerations for CXOs – CEOs, CFOs, CIOs, CMOs, COOs and CTOs. The listed considerations are neither “good” nor “bad” – they are what they are. They are rendered here for the thinking when an Agile topic comes up in the domain(s) you are responsible for.

Some of the considerations for CXO’s are linked to posts, articles or books that already address the subject to some degree.  As additional related posts will get rolled out on this blog, they will be linked to the bullets below. In other words, the Agile Considerations for CXOs post will evolve, serving as a quick index for an eclectic list of Agile CXO considerations.

CEO

CFO

CIO

CMO

COO

CTO

Written by israelgat

January 23, 2009 at 4:28 pm

Posted in The Agile Leader

Tagged with , , , , , ,