Archive for April 15th, 2009
The House Jim Built
Colleague Jim Highsmith uses an interesting metaphor in a Cutter Advisory published a few days ago:
Visualize a house structure with a roof, a foundation, and three pillars… The roof is business goals — the rationale for implementing agile methods and scaling to larger agile projects. The foundation is agile values or principles — principles that need careful interpretation as to how to apply them to larger teams. And finally, the three pillars: organization, product backlog, and process/practice.
The simplicity of the metaphor makes it quite effective in communicating what Agile is in a concise manner. The need to do a better job conveying the concepts (as distinct from the practices) of Agile was highlighted during Rally’s recent event in Los Angeles. Numerous participants in the event felt they have not managed to get the Agile premise across to their executives.
Jim’s metaphor is nicely supplemented by the following short characterization of Scrum by Cutter Consultant David Spann in a recent Report:
Scrum, as a management methodology, is elegant in its design, requiring only three roles (i.e., product owner, ScrumMaster, and self-organized team), three ceremonies (sprint/iteration planning, daily Scrum/debrief, and sprint review meetings), and three artifacts (product and sprint backlogs and the burndown chart) — just-enough practical advice so agile teams do not overcomplicate the development lifecycle with too much ceremony and documentation.
Between Jim and David, you should have no problem carrying the day in discussing Agile methods with an uninitiated executive.
[David’s Report is available in entirety here. You will need to subscribe to the Cutter service in order to get a copy of Jim’s Advisory. The excerpt cited above, taken from the public summary of the Advisory, is largely self-contained and should suffice for delivering the core message].
When an Agile Project does not Seem to be Working
Colleague and friend Paul Beavers suggested writing a post on this topic. To quote Paul:
… it is clear the [Agile] methodology often gets blamed for poor quality and poor general execution. The root cause of these problems is not methodology but more the mere implementation of it. It would be valuable to read ideas on how to recognize things are not performing and how to keep leading an organization through the tough times.
Recognizing when things are not working
The post Early Warning Signs highlighted various specific indicators one could use to foresee problems. Examining the same subject from a somewhat different perspective, Jean wrote about Twelve Top Agile Adoption Failure Modes. Christophe Louvion has recently conducted a session on the topic 101 Things Leaders do that Kill Team Productivity. It should be fairly easy to sense that something is not right by consulting theses three sources in conjunction with your own intuition.
A good practice to follow is establishing a base line with respect to the state of your software engineering practices before starting an Agile implementation. Collect and record the data for a metric or two. For example, number of bugs per thousand lines of code is a useful metric for quite a few purposes. When you suspect the Agile implementation might not be working, compare the historical data you collected with current data. You will be able to assess your progress (or lack thereof) on a relative scale instead of an absolute one.
What to do about it
IMHO self-awareness is more than 50% of the solution. It comes in two “flavors”:
- If the things that do not work are under your control, start addressing them with realistic expectations in mind. For example, it might take a few months to get an inadequate build process to the point is satisfies the requirements of your Agile process.
- When the things that do not work are beyond your control, your task is to make the right folks fully aware of the obstacles. It is a minute of truth for you as an Agile champion: you might need to convey some hard facts to various senior folks in your eco system. It is not too hard to do if you are wholeheartedly convinced Agile is the right thing to do. It is next to impossible to do if you are ambivalent about Agile.
One other thing to do is assess whether Agile is indeed a good fit for your business imperatives and corporate culture. Chances are you had already made this assessment prior to starting Agile. Reassess in view of the actual experience of the Agile initiative.
The Agile Executive 