The Agile Executive

Making Agile Work

Posts Tagged ‘The Agile Champion

Wrestling with Scaling Software Agility

with 2 comments

Software Development Times has just published Guest View: Wrestling with Scaling Software Agility by Ryan Martens and me. This Guest View is a little unique in that Ryan and I actually try to wrestle each other to the ground… Here is why we try to do so:

Agile champions spend a lot of time trying to communicate the agile premise to the executives in their organization. The difference in context between the champion and the executive often makes it a difficult conversation. A Scrum Master versed in behavior-driven design is not always able to relate to the frustrations of a sales executive who gets free advice on how to sell from everyone and his grandmother.

Conversely, a CFO does not necessarily understand why unit test coverage on the company’s legacy code is still inadequate after a full year of investment in agile methods that embrace refactoring as a core practice.

To bridge the chasm through this article, we resort to role-playing. Ryan Martens plays the Agile Champion; Israel Gat plays the Skeptical Executive. Metaphorically speaking, each one tries to wrestle the other to the ground.

Before you get into this Guest View, I would like to reinforce an important disclaimer:

A note of caution before Ryan and Israel make irreparable damage to their long-standing relationship: The two actually understand each other extremely well and rarely are they of different opinions on the fundamentals of agile in real life…

Enjoy the article!

It Won’t Work Here

with 3 comments

Two major obstacles to vetting Agile topics effectively with executives were identified in the post entitled The Business Value of Agile Software Methods:

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

As indicated in the post, the data provided in the study How Agile Projects Measure Up, and What This Means to You and the book The business Value of Agile Software Methods address the first obstacle. This follow-on post is about the second of the two obstacles – the resistance to Agile transformation in the face of hard data on its benefits to other companies.

Resistance in the form of “it won’t work here” is typically anchored in one or more of the following five beliefs:

  1. Uniqueness: “Some very unique elements exist in our company. These elements render industry data inapplicable.”
  2. Secret sauce: “Something very special element existed in the companies reporting great success with Agile. Our company does not possess nor have access to the ‘secret sauce’ that enabled success elsewhere.”
  3. Cultural change: “For the Agile initiative to succeed, our corporate culture needs to change. The required cultural change takes a lot of time and involves a great deal of pain. All in all, the risk of rolling Agile is unacceptably high.”
  4. Affordability: “The company is strapped to the degree that investment in another software method is a luxury it can’t afford.”
  5. Software is not core to us: “We are not a software company, nor is software engineering our core competency. Software is merely one of the many elements we use in our business.”

Various other reasons for not going Agile in the context of a specific company are, of course, cited at some frequency. The five reasons listed above seem to be encountered most often by Agile champions.

Use the following counter-arguments to turn around these beliefs:

  1. Uniqueness: Very rare occurence. Companies use similar business designs, apply fairly standard operating procedures, utilize common technology, are subject to the same regulatory constraints that their competitors are, have offshore sites in places like India, etc. Discussion of your company vis-a-vis its direct competitor usually suffices to overcome the uniqueness claim. 
  2. Secret sauce: The ‘secret sauce’ is neither secret nor difficult to concoct. For example, the secret sauce used by BMC Software in its successful Agile initiative  had four simple ingredient: intentionality, know-how, flexibility and patience. Based on insights by colleague and friend Alan Atlas, I have recently added mutuality as the fifth ingredient. Your own secret sauce might be somewhat different, but I very much doubt that an extravagantly exotic sauce will be needed.
  3. Cultural change: Myth has it that Agile would only work in the Collaborative culture. Reality is it will work in any of the four core cultures identified by Schneider: Control, Competence, Cultivation or Collaboration. See Four Principles, Four Cultures, One Mirror for an approach to building Agile on the strength of whatever culture prevails in your company/organization.
  4. Affordability: The question to ask is whether you can afford not to improve your software. Tools are readily available to quantify your company’s technical debt. Monetize the technical debt and include it as a liability line item in a pro forma balance sheet. Doing so is likely to shift the discussion from affordability to how to create elbow room for handling the technical debt.
  5. Software is not core to us: Indeed, it might not be but it is likely to become so in just about any industry. Use an analogy like the record industry vis-a-vis the publishing industry. The record industry has been decimated by software over the past decade. Chances are a similar decimation is likely to occur in publishing unless the industry transforms itself. (Some of the decimation that already took place in publishing has become quite visible recently. For example, last week Bloomberg LP announced completion of the acquisition of BusinessWeek for a paltry $5M).

You will need to be realistically patient with respect to the time it takes for the considerations listed above to sink in. It could easily take six months just to forge a consensus on the subject in the executive team. It might then take another six month to operationalize the consensus. Chances are there is an elephant hidden somewhere in the “room” if you don’t carry the day with within a one year period of diligently vetting Agile with your executives.

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.

Software Capitalization in Atlanta

with 12 comments

Yesterday’s Agile Success Tour event in Atlanta was characterized by quite a strong interest of various participants in software capitalization. While the topic came up in previous success tour events, it was more pronounced in Atlanta. A subtle shift seems to be taking place: from technical aspects of rolling out Agile to business aspects the Agile champion needs to be aware of and prepared to address.

In the course of exploring software capitalization, participants in the Atlanta event brought up related questions about “the business of Agile.” For example:

  • Cost accounting for Agile
  • Return on the Agile investment
  • Agile Portfolio Management
  • Governance of the Agile project/initiative

Some of the participants were quite thoughtful about the dividing line between project-level Agile implementation and Enterprise-level implementation. They grasp that scaling Agile changes the nature of the questions one wrestles with. A few of them are actually considering  top-down approaches to implementing Agile. They do not necessrily subscribe to rolling Agile in a bottom-up manner. They devote quality time to wrestling with Agile scaling issues prior to starting the first Agile project.

I am hesitant to draw general conclusions based on a single event in a particular city. For example, I wonder whether the emphasis on capitalization might be related to the concentration of Supply Chain Management firms in Atlanta.

As the Success Tour “train” continues its journey (next stop: Washington, DC on July 23) we will soon have additional data points. Stay tuned…

Written by israelgat

June 26, 2009 at 8:59 am