"Un-assessments" using Agile Evaluation Framework - actions by the teams, for the teams
Metrics can backfire. They are useful for both self assessment and retrospectives. But experience since 2002 with 80 teams at IBM has shown it’s not just a matter of finding the right metrics. It’s important to use them properly, and avoid common pitfalls, including bloated metrics, the evil scorecard, lessons forgotten, forcing process, and inconsistent sharing. Turning assessments into “un-assessments” returns power back to the team. Instead of defining more metrics, this paper tells how not to misuse them.
In 2002 we created a survey based retrospective assessment to help teams hasten and tune their adoption af agile. So imagine my shock we teams failed to capitalize on the technique. Since then we’ve painfully learned to avoid the five deadly pitfalls common to assessment techniques: bloated metrics, the evil scorecard, lessons forgotten, forcing process, and inconsistent sharing.
Our current technique, Agile Evaluation Framework v4.2 (Agile:EF) uses three golden rules to learn, improve, and share practices: few but often, small team ownership, and action batches. These techniques can amplify the success of your reflections using Agile:EF or related approaches.
We’ll highlight data from a selection of more than 100 teams that have used the framework inside and outside IBM. They will show where teams have stumbled with agile, and their actions to address the problems uncovered. We love data. But it’s not about the data. It’s about self directed teams nailing improvement actions of their choice.
We’ll cover these topics by drawing on material taught to over 500 engineers. It will feature a short interactive exercise:
30 minutes is divided as follows:
10 minutes: Describe the technique
1) The five deadly pitfalls - what Not to do
2) Details of the Agile Evaluation Framework
3) The three golden rules - how to make reflections more efficient while tapping into the creativity of coaches and team members
15 Minutes: an exercise to illustrate pace of the technique
** 5 Minutes:** Questions and Discussion
This session can be either 30 minute experience report or a 90 minutes tutorial. I’ve proposed 30 minutes because these are the simplest metrics that could possibly work.