Grading “Iterations” in a Lean environment

When we moved from Agile to Lean, one of the items that was ditched was the concept of the iteration (with all the overhead of Planning, Retrospectives, etc) in favor of a fixed size Demo point.  So every 10 features we deliver get Demo’d and that’s our reset point, whether is be 1 week or 1 month.  Part of what I’ve been doing over the last 2 months is capturing all the metrics of when work on a feature card is started and stopped (“Work”) in each phase.  Any gaps between stopping one phase and being started on in the next is considered “Lag”.

Based on our teams SLA for each phase I’ve also calulated what our opimal capacity should be;  the ideal rate that we should see the demo phase fill up.  This is done by taking the total of SLA’s accross the Kanban (in this case 14 days), adding the size of the demo phase (less the size of our “Contraining” phase)  multipled by the SLA of our “Constraining” phase divided by the size of our “Contraining” phase.  Should look something like:

R = T + ( (D – Sc) * (Tc / Sc) )

When we moved from Agile to Lean, one of the items that was ditched was the concept of the iteration (with all the overhead of Planning, Retrospectives, etc) in favor of a fixed size Demo point.  So every 10 features we deliver get Demo’d and that’s our reset point, whether is be 1 week or 1 month.  Part of what I’ve been doing over the last 2 motnhs is capturing all the metrics of when work on a feature card is started and stopped (“Work”) in each phase.  Any gaps between stopping one phase and being started on in the next is considered “Lag”.

Based on our teams SLA for each phase I’ve also calulated what our opimal capacity should be;  the ideal rate that we should see the demo phase fill up.  This is done by taking the total of SLA’s accross the Kanban (in this case 14 days), adding the size of the demo phase (less the size of our “Contraining” phase)  multipled by the SLA of our “Constraining” phase divided by the size of our “Contraining” phase.  Should look something like:

R = T + ( (D – Sc) * (Tc / Sc) )

From here I’m able to calcualte our team performance accross three dimentions: Capacity, Accuracy, and Efficiency.

We can compare our Actual rate of delivery to the ideal to get a grade on capacity (score goes down the farther away from target we go, whether under or over).

We can compare the total time a card spends on the Kanban to the SLA to get a grade on Accuracy (score goes down the farther away from target we go, whether under or over).

We can evaluate the percetage of Lag time to Total time to get a grade on efficiency.

We can take the average of these values to get an Overall Grade.  If any of those dimentions are not on target, the overall score will be affected and it will be a clear indicator that something isn’t right and needs to be evaluate.

The reason for the three dimentions is because they reinforce each other.  The team can’t sacrifice capacity to improve Accuracy and Efficiency.  The team can’t overestimate to acheive Accuracy without sacrificing Efficiency and operating Over Capacity.  The team can’t focus only on efficiency without impacting Capacity.  Everything is forced to be in balance and constantly driving towards better and better numbers.

Only by high performance across all three will the team acheive a high grade.  And with a standardized template and rating mechanism, the team will understand more as issues arise how inaction will be reflected in the overall score.  This helps us avoid the Flacid Kanban as everyone becomes more aware and cognizent of what the Kanban is saying.

You Kanban will tell you when trouble is lurking around the horizon if you stop to listen to it.