A SCRUM lesson delivered using….SCRUM

How to arrange any kind of training using SCRUM? Read below!

Last week I had the pleasure to teach Agile and SCRUM. The class was quite challenging because the attendees were all PMP certified, with a deep experience in managing ITC projects. The class was also quite heterogeneous because of the different types of projects they manage and because of the different expertises.

In a class like that, teaching agile could be tricky because the experience and the approach of the attendees is such that topics like Planning, estimating, risk management are paramount and you will be challenged for sure when explaining how agile embodies those topics.

This is the reason why in courses like that one, I make huge use of games, exercises and confrontation sessions (a little bit of coaching never hurts) in order to facilitate the learning process of the participants letting them to consolidate the knowledge just aquired.

Knowledge is only a rumor until it’s in the muscle (Papua New Guinea proverb)

One another trick I use when teaching SCRUM is to arrange the lesson using SCRUM itself.

First of all, I arrange a fantastic taskboard with three columns: Backlog, Running, Done.

The backlog column contains the topics I’m going to cover, as post-its. In every post-it I write the name of the topic and on the left or right corner I write also an estimation in story points.
This estimation is a blend of these factors: number of slides covering the topic, importance of the topic, difficulty of the topic and finally how much space I should left, to let the attendees to reason, talk, discuss, confront about that.

Then arrives the calculation of the total story points I muyst deliver in that session, summarizing the points of each topic.

Good, now it’s time to draw the burndown chart.

I decided that the duration of my hypotethical day is one hour.
The burndown chart is a standard one: on the Y axis I report the total story points just calculated; the X axis, however, is divided into the N days available (the number of hours available for that teaching session).

The preparation is finished, now it’s time to work, explaining the contents of the lesson.
Every time I start a new topic, the relative post-it is moved from the Backlog column to the Running column. On the other way round every time a topic is completed it goes from the Running to the Done column.

Every hour I check the status of the work delivered (topics covered), how much work is again in the backlog, the time remaining and I say to myself and to the class what we are going to do in next hour and if we are on track or not. Think of this as what a team does every morning conducting the SCRUM Daily Meeting.
Then, the burndown chart is updated with the story points left.

I found this approach very usefull.
Visualizing what topics are still in the backlog, helps you to remain focused and to decide to slow down or accelerate.
Visualizing the burndown chart reinforces what just said in the point above.

The class sees how many topic must still be covered (taskboard), it sees what this does mean in relation with the time available (burndown chart).
This actually, allow the class to automatically regulate the way the attendees ask for questions, the need of any break, the way how they discuss: they obviously want to cover all the topics, maximizing the value and reducing any waste of time.

I think, however, that the most important point here is to let the class see how SCRUM works.

This helps the attendees in the process of digesting the SCRUM knowledge, transforming it from a only rumor in their brain into an abilities they can train and use soon.

What I hear, I forget.
What I see, I remember.
What I do, I understand.
(Confucio)

Tags: burndown chart, collaborative games, Confucio, daily meeting, learning process, rapid learning, scrum, SCRUM courses, task board