Skip to main content

Call to Action!

November 25, 2019

Original article in French here 😊

How the information radiator can help the call to action?
How to make decisions based on explicit indicators?

Traffic Light

CONTEXT

 

The Development Team scrupulously followed the "suggestions" of the Scrum Master.

The Development Team has set up a whole information radiator, with for example a burndown chart, a cumulated flow diagram, a niko-niko, a graph displaying the trend of the number of incidents, a calendar with the next birthdays ...

 

SYMPTOMS

 

You observe, day after day, week after week, that the different graphs fluctuate but that the development team does not react to these fluctuations, whatever the extent of these variations.
 

After finally understanding that the Scrum Master refused to play the role of a mere secretary, the team scrupulously updates the radioator. But the team does not take into account what is constantly under the eyes, these curves that deviate slowly but surely in dangerous areas.

 

CAUSES

In the best case, the team is so focused on their work that it loses all perspective and requires help to alternate moments of action and moments of reflection.
 

In other cases, it is possible for the team to post "things" to please the Scrum Master, but not to help in their decision-making. The development team is not yet in full possession of it work process.

The fact remains that the team drifts slowly and accumulates each day a "small" drift acceptable, negligible to the scale on which the team is focused. It does not become aware of the sum of the gaps that has become intolerable and that only a more global vision can have a little more perspective.

 

POSSIBLE REMEDIES

Introduce some "Visible Status": decide when the indicator of acceptable ranges (green light), and unacceptable ranges (orange or red lights), as well as the possible measures in the event of exit from the zone (measurement default: put the pen / take out the head of the handlebars and make a decision all together)

As soon as the measure or graph overflows in the red zone, the team will have an explicit signal that an intolerable course has been crossed and that it is necessary to act IMMEDIATELY!

The graph then displays not only raw and neutral data, but becomes a real call to action.

For example, what is the point of collecting the team's mood with a niko-niko day after day if no action is taken while the entire team shows morale at a very low level for a long time?

But then what is a low team morale? What is a long term? What will be the explicit threshold trigger for an action?
 

In this case, the team may decide that the variations are normal and tolerable if each member of the team votes at least 3/5 and if a team member takes a score of 2/5 for two days in a row. Beyond (a vote of 2/5 for 3 days), an action must be implemented on the spot. This can be a team discussion similar to a retrospective targeted on the alarm signal, potentially led by the Scrum Master, or even an escalation to management if the problem unfortunately exceeds the team's self-organization capabilities or its power of action.
 

Another example that we all too often encounter in our accompaniments is that of the development team which scrupulously notes its work remaining daily on the burndown chart Sprint, but does not adapt its strategy after several days of stagnation. The reasons can be multiple and the solutions are therefore dependent on the context. The drift can come from a lack of focus and collaboration between team members; a lack of competence of the crew members on certain works which are found blocked; discovery of works that obscure the completed work; Influenza epidemic ... Whatever the reasons, Sprint Goal is at risk, it's time to take action!

 

https://i0.wp.com/www.collectivegenius.fr/wp-content/uploads/2019/11/image-2.png?w=700&ssl=1

Burndown Chart drifting

https://i0.wp.com/www.collectivegenius.fr/wp-content/uploads/2019/11/image-1.png?w=700&ssl=1

Burndown Chart caught up with visible status

This is the very principle of Kanban, in which we do not just move items in columns, but where we explicitly display a threshold (maximum or minimum) not to exceed.
Overflow, if it occurs, triggers an emergency procedure that has already been established.

 

CONCLUSION

Since the approach works well to control the amount of work in progress, let's apply the same approach to the other relevant metrics!
And you now? In your current team, what does your visual management tell you? What can you add?

Original article in French here 😊


What did you think about this post?