The Agile Executive

Making Agile Work

Archive for May 2010

The ‘Secret Sauce’ of The Path to Agility

with 2 comments

Yesterday’s Path to Agility conference in Columbus, OH was characterized by extraordinary energy. To start with, four hundreds participants in a regional conference is quite remarkable. Four hundreds participants with ‘infinite’ amount of energy all day long is quite extraordinary.

What is the ‘secret sauce’? According to Bart Murphy, Vice President of Solutions Delivery at QuickSolutions, the ‘trick’ is concentration of energy that usually gets spread over three or four days of a conference into a single day. A large number of interactions in a short time span create intensity and passion that are contagious. The energy flows from one person to another, from one group of people to another, creating an amplification effect that engulfs all participants.

You really had to be there to fully appreciate how powerful the experience was. You might not live close to Columbus, OH, but you owe to yourself to consider attending The Path to Agility 2011. And, don’t miss it for the world if Bart & Co. decide to apply their secret sauce to an Agile event close to where you live.

Thank you Bart, Jennifer,  Matt and the other organizers and volunteers at COHAA – it has been a unique experience!

Advertisements

Written by israelgat

May 28, 2010 at 8:32 am

How Many Metrics do You Need to Effectively Govern the Software Process?

with 4 comments

A Simple Metrics-Driven Software Governance Framework Based on Jim Highsmith’s Agile Triangle Framework

In my recent Cutter Blog post entitled Three Governance Metrics I recommended using just three metrics:

  • Value
  • Cost
  • Technical debt

The heart pf this recommendation is that all three can be expressed in dollar terms as depicted in the figure above. An apples-to-apples comparison is made through the common denominator – $$. For example, something is likely to be either technically, methodically or governance-wise wrong if the technical debt figure exceeds the cost figure for a prolonged period of time. One can actually characterize such a situation as accruing debt faster than building equity.

I am often asked about adding metrics to this simple governance framework. For example, should not productivity be included in the framework?

‘Less is more’ is my usual response to such questions. IMHO value, cost and technical debt address the most important high level governance considerations:

  • Value –> Why are we doing the project?
  • Cost –> Can we afford the project?
  • Technical debt –> Is the execution risk acceptable?

Please pay special attention to the unit of measure of any metric you might add  to this simple governance framework. As long as the metric is a dollar-based metric, the cohesion of the governance framework can be maintained. However, metrics which are not expressed in dollars will probably superimpose other frameworks on top of the simple governance framework. For example, you introduce a programming framework if you add a productivity metric which is measured in function points per man month. Sponsors who govern using value, cost, technical debt and productivity will need to mentally alternate between the simple governance framework and the programming framework whenever they try to combine the productivity metric with any of the other three metrics.

Toward An Event Driven Scrum Process

with 10 comments

Recent posts in this blog and elsewhere recommended using technical debt (TD) criteria as an integral part of the build process. One could fail the build under conditions such as:

  • TD(current build) > TD(previous build)
  • TD per line of code > $1
  • TD as % of cost  > 50%
  • Many others…

If you follow this recommendation while integrating continuously, chances are some fixing might need to be done multiple times a day. This being the case, the relationship between the daily stand-up meeting and the build fail event needs to be examined. If the team anyway re-groups whenever the build fails, what is the value add of the daily stand-up meeting?

Figure 1 below, taken from Agile Software Development with Scrum, examines the feedback loop of Scrum from a process control perspective. It shows the daily stand-up meeting providing the process control function.

Figure 1: Process Control View of Scrum

Figure 2 below shows the feedback loop being driven by the build process instead of by the daily stand-up meeting. From a process control standpoint it is essentially identical to Figure 1. Control through the regularly scheduled daily stand-up meeting has simply been replaced by event-driven control. The team re-groups whenever the build fails.

Figure 2: Build Driven Process Control

Some groups, e.g. the Scrum/Kanban teams under Erik Huddleston and Stephen Chin at Inovis have been practicing Event Driven Scrum for some time now. A lot more data is needed in order to validate the premise that Event Driven Scrum is indeed an improvement over vanilla Scrum. Until the necessary data is collected and examined, two intuitive observations are worth mentioning:

  1. Event Driven Scrum preserves the nature of Scrum as an empirical process.
  2. A control unit that is triggered by events (build fail) is in the very spirit of adaptive Agile methods.

Cutter’s Technical Debt Assessment and Valuation Service

with 3 comments

 

 

Source: Cutter Technical Debt and Valuation Service

The Cutter Consortium has announced the availability of the Technical Debt Assessment and Valuation Service. The service combines static code analytics with dynamic program analytics to give the client “x-rays” of the software being examined at any desired granularity – from the whole project portfolio to a single instruction. It breaks down technical debt into the areas of coverage, complexity, duplication, violations and comments. Clients get an aggregate dollar figure for “paying back” debt that they can then plug into their financial models to objectively analyze their critical software assets. Based on these metrics, they can make the best decisions about their ongoing strategy for the software development effort under scrutiny.

This new service is an important addition to the enlightened software governance framework that Jim Highsmith, Michael Mah and I have been thinking about and contributing to for sometime now (see Beyond Scope, Schedule and Cost: Measuring Agile Performance and Quantifying the Start Afresh Option). The heart of both the technical debt service and the enlightened governance framework is captured by the following words from the press release:

Executives in charge of software governance have long dealt with two kinds of dollar figures: One, the cost of producing and maintaining the software; and two, the value of the software, which is usually expressed in terms of the net present value associated with the expected value stream the product will generate. Now we can deal with technical debt in the same quantitative manner, regardless of the software methods a company uses.

When expressed in terms of dollars, technical debt ties neatly into value vis-à-vis cost considerations. For a “well behaved” software project, three factors — value, cost, and technical debt — have to satisfy the equation Value >> Cost > Technical Debt. Monitoring the balance between value, cost, and technical debt on an ongoing basis is an effective way for organizations to stay on top of their real progress, and for stakeholders and investors to ensure their investment is sound.

By boiling down technical debt to dollars and tying it to cost and value, the service enables a metrics-driven governance framework for the use of five major constituencies, as follows:

Technical debt assessments and valuation can specifically help CIOs ensure alignment of software development with IT Operations; give CTOs early warning signs of impending project trouble; assure those involved in due diligence for M&A activity that the code being acquired will adapt to meet future needs; enables CEOs to effectively govern the software development process; and, it provides critical information as to whether software under consideration constitutes an asset or a liability for venture capitalists who need to make informed investment decisions.

It should finally be pointed out that the technical debt assessment service and the governance framework it enables are applicable to any software method. They can be used to:

  • Govern a heterogeneous environment in which multiple software methods are used
  • Make apples-to-apples comparisons between disparate software projects
  • Assess project performance vis-a-vis industry norms

Forthcoming Cutter Executive Reports, Executive Updates and Email Advisors on the technical debt service are restricted to Cutter clients. As appropriate, I will publish the latest and greatest news on the subject in the Cutter Blog (which is an open forum I highly recommend).

Acknowledgements: I would like to wholeheartedly thank the following colleagues for inspiring, enlightening and supporting me during the preparation of the service:

  • Karen Coburn
  • Jennifer Flaxman
  • Jonathon Golden
  • John Heintz
  • Jim Highsmith
  • Ken Collier
  • Kim Leonard
  • Kara Letourneau
  • Michal Mah
  • Anne Mullaney
  • Chris Sterling
  • Cindy Swain
  • Sarah Wiesbrock

Open-Sourcing the Inovis End-to-End Kanban System

leave a comment »



Source: Gat, Huddleson, Bodwell and Chin, “Reformulating the Product Delivery Process

Colleague and “partner in crime” Stephen Chin has published a post on the Inovis End-to-End Kanban System (aka Apropos) we presented at the LSSC10 conference on April 23.  As readers of this blog might recall, the system tracks features through their full life-cycle from proposal to validation, ensuring actionable feedback cycles. By so doing it firmly anchors the software method in the overall business context with special attention to operational aspects such as deployment, monitoring and support.

Stephen outlines details of the forthcoming open-sourcing of Apropos as follows:

The plan for this tool is to do the initial launch of a BSD-licensed open-source version on May 22nd.  This will include support for the Rally Community Edition, which is free for up to 10 users.  In future releases we plan to support other Agile Lifecycle Management tools, both commercial and open-source, but will need assistance from the community to do this.

If you are interested in helping out with this project, please contact me.  I will have limited bandwidth until after the initial launch, but after that would love to scale up this project with interested parties.

I really can’t wait till the 22nd. IMHO Apropos has the potential to become the leading Kanban system by the community for the community.

The Concise Executive Guide to Agile

with 3 comments

a

a

The IEEE Computer Society Press published today a ReadyNote[1] that I authored entitled The Concise Executive Guide to Agile. It is available through the IEEE Computer Society Store. A Kindle version will be published in June.

I had two main objectives in writing the guide:

  1. Provide the know-how for approaching Agile in a concise manner that requires minimal investment of time and effort by the reader. The ReadyNote does so by summarizing most Agile topics in a page or two. Detailed coverage of a topic is left for follow-on reading in the selected references that accompany each topic and in the Further Reading appendix.
  2. Be accessible to any executive  — R&D, Marketing, Sales, Program Management, Professional Services, Customer Support, Finance, or IT.  The only assumption I make is that the reader has a conceptual grasp of software and software engineering as well as an interest in learning about Agile. No deep knowledge, let alone technical knowledge, about software engineering is required for comprehending the guide.

There is no fluff in the guide. Every paragraph has been written to satisfy the “And therefore what?!” criterion. It is my intent to drive a point home and make it clear to the reader what he/she could do with the information in as few words as possible.

A simple acid test for the guide is your successful assimilation of it in entirety during a flight in the continental US. Something has not quite worked if you need to fly all the way from the US to Europe or vice versa in order to comprehend the guide…

I would like to express my sincere thanks to Michael Cote, Michael Mah, Hubert Smits and to the fourth reviewer (whose identity I don’t know) for their many helpful insights and suggestions. I am also deeply indebted to Linda Shafer and Kate Guillemette of the IEEE Computer Society who got me to write the guide and supported the writing and editing process along the way.

Enjoy reading!

Footnotes:

  1. “ReadyNotes are short e-books that are tightly focused on specific topics” [IEEE Computer Society Press].