Albert Einstein once said, "Not everything that can be
counted counts, and not everything that counts can be counted." Ain’t that the truth?
When looking at agile projects, there are a few very obvious
ways to track team progress. You can
look at sprint and release burndowns, velocity charts, cumulative flows,
etc. However, what the business needs to
ask itself is what it really wants from agile metrics, and it needs to be
prepared to get what it asks for.
There are many examples in which companies have set certain
metrics that gleaned disastrous results.
There is one example in particular that seems to resonate the most,
though. A company once set the metric
that the developers that found the most defects during code reviews would get
extra “incentives”. You can imagine what
happened. These developers wrote bad
code, found bad code, and then collected the incentives. The phrase “I’m gonna code myself a minivan”
has its origins in this example.
We can all agree that this was NOT the company’s
intention. Not in the slightest. Yet, the company got what it asked for,
yes? So the company needs to ask the
hard hitting question as to what it wants to measure and what it will
mean. Here’s a breakdown as to which
metrics are for team use and which are for business use.
Velocity
Measuring the velocity of a sprint should be a metric to
help the team. Why? Because velocity is all about estimating, and
the team needs to become great at estimating.
Once a team has a few sprints under their belt, they can better estimate
for the business how long certain projects will take. Why would it be a bad idea for the business
to harp on this metric? Because the team
will worry about how much they get
done (quantity) and not what they get
done (quality/priorities).
Burndowns (Sprint and Release)
Again, this is another metric for the team. This helps them gauge how well their tasks
are progressing in relation to overall remaining work. I think this is for both the team and the
business, but again the business must be careful how it uses this data. Every team is different. Some teams hit the ground running and deliver
daily. Other teams take a little while
to get traction, but they still meet their goals and deliver on time. If you must draw a line, then do so between
Sprint Burndowns and Release Burndowns.
The Sprint burndowns are more for the team to help them adjust on a
micro level. Release Burndowns are for
the company so it can adjust on a macro level. Again, if the business focuses on this
metric, the teams will worry more about quantity rather than quality.
Cumulative Flow
This chart is a more visual way to show what the team has
finished in comparison to what is still left to do. This is valuable for the team, but on a macro
level, this is very valuable for the business when looking at product
dependencies and delivery dates.
Value Delivered
This isn’t as obvious as the cold hard numbers you can
collect from velocity or burndown charts.
This one is a bit more subjective since the business needs to rank
stories based on business value. However
when implemented effectively, this metric can provide a ton of value for the
business. This metric promotes value,
not quantity, and in the end, customers want value.
Time to Customer
Another valuable metric for the business is measuring the
time it takes to deliver a product to the customer. If a business can track how long it takes
teams to deliver value, then it can better predict product launches and
business costs. This could get out of
hand if the business pushes getting as much done as possible in any given
timeframe. Quality can seriously take a
hit if value isn’t also encouraged.
These are just a few ways to measure work in an agile
environment. There are many more that
deserve a lot more discussion. In the
meantime, what do you think is valuable and how would you use it to
satisfy business needs?
No comments:
Post a Comment