Catching the big one.

The release date is approaching and some important features are still missing. It might be that we are losing a customer because of that. There are basically two paths to take. First one is to start cut corners, do some hacking, maybe not test that thoroughly etc. In other words we take technical debt to try to reach our goal. For the short term point of view, this sounds attractive.

The second choice is not to take technical dept and leave some functionality out from the release and negotiate with the customer(s). For the long term this is usually the better choice. If the product is something for which the life time is long, even decades, we are doing less work, because we don't need to pay back technical debt and intresses. This is might be because we are not catching one particular customer, put there is plenty of fish in the sea and competitive benefits comes in t
he long run.   

Where the heck are we?

Your nightly build is red. There are some test cases failing and you know that this should be the moment when you need to stop and investigate. Your Product Owner runs in the team room and start to rant about features which must be in before the release at the end of the week. He is questioning are those faults so bad that we really need to consume time to fix them, because we have promised some cool stuff to our customer.

Roadsign to Lost farm near Bellabeg. (Stanley Howe) / CC BY-SA 2.0

What to do? Every time we have failing test case(s) in our build(s) it means that our location is unknown, failing test case says that behavior of our product is not what we have expected it to be and before those case(s) are green again, everything what you create are just hypothesis.

Abnormal situation is work need to be done, and it's work that does not get any better with age, actually quite the opposite. It's work which generates more work. On the other hand, if we use stop the belt and fix the problem immediately it causes idling to the rest of system and the bigger the system is, the bigger the effect of idling is. So what do? I think that abnormality should always be removed as soon as it is noticed. We should always have the best understanding where we are and get back on the map quickly.

What Key Performance Indicators (KPI) should Agile Team(s) use?

It would be nice to measure how we are doing and also check, has our newly implemented improvements hit the spot. Metrics are always nice, but (un)fortunately only few of them are usable. Here is a list of those KPIs what I think should be used.

Velocity
How many Story Points(SP) has team consumed during previous iterations and use this information to forecast. Keep your Story Points uncorrupted and here you have good and handy tool. If you are wondering what is SP, you should read Mike Cohn's excellent book Agile Estimating And Planning.

Cycle Time
Cycle Time (or Lead Time), means a time from when a customer request comes into a process to a time when it has actually delivered to a customer. Good way to measure the whole process, not only R&D efficiency. With this, you can check how good your flow is.

Boomerangs
Boomerangs are things, which are coming back to the process after they have declared as done and delivered. Because those things are defects like bugs and misunderstandings in customer requirements, this is a measurement for quality and communication. You can read more about this from Gojko Adzic's blog.

Customer Satisfaction
It's good to check, time to time, what people who are paying our salary think about us :)