Archive for May 2010
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.
A Simple Metrics-Driven Software Governance Framework Based on Jim Highsmith’s Agile Triangle Framework
- 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.
- 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:
- Event Driven Scrum preserves the nature of Scrum as an empirical process.
- A control unit that is triggered by events (build fail) is in the very spirit of adaptive Agile methods.
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 IEEE Computer Society Press published today a ReadyNote 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:
- 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.
- 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.
- “ReadyNotes are short e-books that are tightly focused on specific topics” [IEEE Computer Society Press].