19 June 2009
Velocity (plus, plus) – Beefing up the Agile dashboard
First of all, how in the world did I temporarily forget how to spell out the ‘+’ symbol? It ‘looked’ correct with two s’s; sad, really. Earlier, I hinted at some other measures to add as _support_ to the Agile toolkit . To be clear, the raw measure that matters the most when it comes to understanding which features and whether our joint ALTERthought-client teams are delivering against plan is velocity. Period. That being said, while velocity is a good indicator of the effectiveness of the particular team/project/organization, in and of itself it does not convey rich information about the internal workings of your team and software development processes. So, velocity must be coaxed, teased, and massaged to uncover facts about the software development effort that helps satisfy a key tenet of Agile: to continuously improve. In fact, at times, velocity may be a sort of lagging indicator of what may be transpiring with regard to the process and organizational dynamics (factors the tremendously impact project success). Take the following burn chart for instance. its clear that velocity is degrading, but do we have any empirical evidence as to what may be contributing? Outside of the team believing or coming to a consensus that perhaps there was continuous, gross underestimation of the features in the sprint plan, the answer in most shops is likely ‘no.’
So, outside of the important, qualitative retrospective, what quantitative facts can we produce and track to _support_ (not intrude upon) the Agile process, analysis of velocity? In essence, why is our red line not burning down toward zero as it was previously? Some have said, appropriately, that management has a tendency to over-measure and introduce burdensome processes. Processes that are counterproductive to the Agile philosophy. However, if shops view additional project data as ’supportive’ or ‘explanatory’ of velocity and trends in velocity, the focus continues to remain on what matters — shipping software and continuous improvement.
In fact, many shops are not too far removed from being able to report quickly and capture unobtrusively key data we feel play a significant role in analyzing velocity and –ultimately– working product. The following bubble graphs displays _some_ of these metrics that are likely at your fingertips now or available, hopefully, without an act of congress.
In posts to follow, we’ll dive into these metrics further, but the overarching thing to remember is that these metrics – taken together – are, after a fashion, leading indicators into the most dominant factor on whether software project succeed or fail: the organizational environment. Simply put: your ream’s maturity, flexibility, and collaboration dynamics.
Some of these key supporting metrics are:
- User story: analyzing for excessive churn, maturity, gaps in requirements
- Defect: analyzing for defect trends, severity, etc
- Issue: evaluating the blocking-and-tackling of things that need to be addressed for progress to continue
- Unit test: inspecting the code base and assessing the freshness, completeness, breadth and depth of unit tests
- Code complexity: assessing the code base and ensuring that it is not unecessarily complex
- Time/effort: the least important of the bunch, but instructive at a coarse-grained level (gathered as unobtrusively to team members as possible). The ability to do this in fine-grained fashion without driving your developers and team members batty and creating unnecessary apprehension we’ll also discuss in coming posts.
As much as is feasible and appropriate, an important success factor for using _all_ of these metrics is your ability to tie them to specific features/clusters of features; for that, excellent abstraction, analytical, and organizational abilities are indispensable.
More to come …
UPDATES:
- More on issue metrics
Technorati Tags: agile, velocity, burn charts, agile manifesto, technology management, agile retrospective, agile reflection, continuous improvement
[...] Continuing our series on beefing up the Agile dashboard with ‘leading indicator’ type metrics, let’s discuss issue metrics. First, let’s get on the same page on the definition of an issue. What’s the difference between and Issue and a Risk? An Issue is something that is currently impacting or is going to impact your project period. A risk is something that has yet to materialize, but has a probability of materializing in the future. So, what is the significance of analyzing issue metrics in an Agile setting? Well, issue management is a prime indicator of the maturity of an organization and its processes. this category (and others we’ll cover) give insight into the mechanics of how well projects are managed in a shop. It is the most significant indicator of whether a project is going to experience overruns — its the “organization’s environment.” As we’ve discussed before, understanding what’s happening with issues on your project could serve as a forewarning of impending hiccups in project velocity. Before we discuss the handful of things to quantify and track, a couple of housekeeping notes. [...]