To make our products great, we can use the build-measure-learn cycle to drive continuous improvement with a lean startup approach. An approach to making our teams great is the plan-do-check-act cycle. Both "measure" and "check" imply the use of data to inform our decisions. To counter the common retrospective anti-patterns we see around actions that never get done, we can take these principles and ensure we are really adapting and not just inspecting. When running improvement experiments to improve the way the team works it is crucial to use some form of data to verify that the change has moved you toward your target condition. To do this effectively, we need to go beyond output focused measures and focus on metrics that tell us about the outcomes we are trying to reach. We can’t, and shouldn’t, measure everything, so I will explore what to measure, and discuss some common ways of capturing, visualising and using the data for team effectiveness. These aren’t metrics for managers and they aren’t metrics to compare teams.


Outline/Structure of the Talk

Presentation with slides containing real world examples


[5 min]

- Introduction, including experience applying concepts in real teams


[15 min]

- Continuous improvement anti-patterns

- What we can learn from prior art (lean, toyota kata, PDCA)


[15 min]

- How we approach product development and how we can apply this to our teams

- What do we want to learn about our teams and how do metrics support this


[15 min]

- How can we measure that we are: a) building the right thing, b) building the thing right, and c) building in a sustainable way


[5 min]

- Summary

Learning Outcome

- How does the build-measure-learn cycle apply to teams

- Why using data to back improvement initiatives is important


- What anti-patterns do we see in the absence of data to guide us


- How do we get data with difficult to measure or subjective requirements


- How do we stop the abuse of team metrics

Target Audience

Anyone working within product development or delivery teams

schedule Submitted 2 years ago

Public Feedback

comment Suggest improvements to the Speaker