BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Measuring in Agile Teams

Measuring in Agile Teams

This item in japanese

Bookmarks

At the Agile Tour London 2015 Doug Talbot gave a talk titled "Do you know how fast you’re going?". InfoQ interviewed him about difficulties with estimation and planning, the measurements that agile teams use, objectively measuring productivity, his view on the #NoEstimates movement, and asked him for ideas that can help teams to make measurement more meaningfully.

InfoQ: In your opinion what makes it so difficult to estimate and plan in software development?

Talbot: There are so many studies now showing that we are all subject to significant cognitive biases when trying to predict the future, even when this is focussed on our area of expertise. In fact in some cases we are worse because it is our area of expertise. A quick hunt on the planning fallacy will turn up countless studies on this. We even struggle to consider our own true expertise level, often referred to as the Dunning-Kruger effect but this is not the only example. The summary from me would be that: 1. We are not trained in understanding bias; 2. We don’t often use good data; 3. We are almost always under pressure when estimating either from ourselves or customers.

InfoQ: What do you suggest that teams can do if they want to improve their estimation skills?

Talbot: Stop estimating, use data to predict based on good maths. If you really can’t avoid it because you have no baseline data then get trained in recognising bias. Lot’s of studies support this as the primary way to give us a chance of estimating.

InfoQ: Can you explore some of the measurements that agile teams are using, and elaborate if these measurements are useful?

Talbot: Most teams are using a very basic set of what I would call efficiency measures. Things like velocity, lead time, WIP, CFDs etc. Some teams are also now moving into effectiveness measures where they try to understand the value they are delivering to their businesses. Lean Startup movement has popularised the MVP thinking and challenging our delivery features for true value even before we build them. The third wave of measures seems to be those about the human dynamics of the organisation. I’m seeing more and more of Spotify’s "health checks" and Patrick Lecioni’s 5 dysfunction tests being used with agile teams.

All these measures are great for understanding if we as individuals, teams or organisations are getting better or faster but only in relation to ourselves. My contention is that these don’t help us to know if we are underperforming, above average or awesome on the world stage. To summarise 80% of developers think they are above average … prove it!

InfoQ: Is it possible for team to objectively measure their productivity?

Talbot: Obviously if they can see their effect on their business within the context of an entire market place, this might be possible. E.g. our shoe sales web site is selling more than that other shoe sales web sites. But for most teams this is incredibly hard. They might be building back-end systems or a small part of a large whole. I hope that we can mature as an industry and consider how to provide some intra industry bench marks, but there are many obstacles to figure our way around. Competition is a big one.

InfoQ: Can you share your view on the #NoEstimates movement?

Talbot: I’m sure you can guess from the answers above but I’m a pragmatist and believe there are situations we can’t escape where we must do our best to estimate. Obviously the industry has very little perspective on the issues with traditional Project Management and the associated planning and estimating. #NoEstimates should be a catalyst for opening some eyes.

InfoQ: Do you have ideas that can help teams to make measurement more meaningfully?

Talbot: Obviously start measuring! Then consider efficiency, effectiveness (value) and people (team health) measurements. These will all improve life as long as we don’t make them hard to do. Don’t go overboard! Then consider joining in with some of us who care about sharing information so we can really understand how fast we are and for the growth of the whole industry.

Rate this Article

Adoption
Style

BT