Retrospectives and the role of the SM

A very bright and quick class attendee asked: Why don’t you talk in the class more about Retrospectives? And why so much about the PO? Why do you focus on the basics so much?  I want more advanced materials.

***
First, I actually think we do these things, as explained below. We do talk about Retrospectives, and we do have some advanced materials, even in the CSM course.

Here is basically what I said to her, somewhat edited (I wanted to make it better).

First, it is not correct to think of the SM’s duties as mainly revolving around the Retrospective (as some do).  Although the Retrospective is an important meeting, you as SM must teach the whole company how to adopt agile and scrum.  (Or adopt it more fully.)  In addition, you must help and teach the PO to be more effective; typically the biggest impediment (and a multifaceted one).  The next impediment is usually technical (eg, getting good Continuous Integration and an well-running automated test suite).

We do a lot around Retrospectives in the course.  The whole exercise at the end of the first day (where we emulate doing a Business Case in the Retrospective) is essential.  I expect you as SM to use that A3 approach to drive higher velocity.  (I recommend you google the A3 approach and learn more about it.  Jeff Sutherland and Mary Poppendieck talk about it, as well as many others.)

The first problem with many Retrospectives is, as Angel said, all talk and no action.  Classic! By this I mean, Teams often use the Retrospective to only bitch and moan about the same old problems. And they take no action against them.

So, you (with the Team) must take action.  In two steps:
(a) collect data and decide the top impediment for the Team – quickly
(b) start to take action

I suggested action in one of 3 ways – with the Team in the Retrospective:
(a) devise a solution (Ken Schwaber loves to say it that way)
(b) plan the execution (not a detailed MS Project plan, but ‘who will do it and how?’)
(c) pull together a Business Case to get a manager to say ‘yes’ (to $, to give you people, to just permit the change).

The A3 exercise was all about starting to learn how to make the case to a manager. Usually, we are terrible at doing this; we do not know ‘manager-speak’ yet.  To the Team, that is a foreign language usually.

The A3 exercise also indirectly teaches us how to prioritize. Mainly, by a benefits (eg, increased velocity) to costs comparison.  So, a key thing is that you must help the Team prioritize the impediments in a benefits-to-costs way. And do other parts of the thinking, as implied in the A3 approach.

To learn more about Retrospectives per se, you might read Esther Derby and Diane Larsen’s book, Agile Retrospectives.  Esther Derby and Don Gray are giving a course in Atlanta soon, not exactly about Retrospectives, but I recommend that.

I have to balance different topics in the 2 days and I have much to say to make all of the attendees a ‘good enough’ SM.  It is always fine if an attendee says: ‘I want to talk about the Agile Retrospective more.’ Or asks a question.

Again, your biggest impediment is likely to be a ‘not good enough’ PO or a business side that does not give you enough PO time or BSH (business stakeholder) time.  As SM, you should spend lots of time making the PO (or the Business side) better.

More generally, as SM it is key to your job at first (and often for a long time) to remind the people how each Scrum role is played, and how they play together.  So, an SM must understand each role in depth.

One of the biggest problems with Retrospectives is that some SMs get too cute.  They have lots of new, cool,  ‘process’ for doing the Retrospective — but the Team does not move much on getting an impediment fixed.  That is your time, as SM, to get them to help you.

How can you help them have a better Retrospective?  Mainly the ways I said:
(1) identify the top impediment,
(2) devise solution,
(3) help plan execution,
(4) create business case.

Also, the Team needs you in the Retrospective to report back on progress (or not) on the last big impediment, and usually, to tell them “we got it done.” Again, getting too fancy does not help.  Just say: ‘let’s devise the solution together’ or something like that.  Let them self-org. (Sometimes you have to ‘make’ them self-org if they look helpless to do so.)

An SM’s job requires patience.  It requires the willingness to practice, practice, practice the basics yourself, and the willingness to let others do the same.

Yogi Berra said: Think!  How am I gonna think and hit at the same time?

In other words, you and the Team must endeavor to get the practices and the values and principles of lean-agile-scrum so deeply embedded in muscle memory, that you don’t even think about it.  It flows naturally.

It is similar to the discipline of learning the piano, which is clear to many people.  Practice,  practice hard, even harder.  It is not so clear for the discipline of the SM.  Watching others make mistakes is very trying for the impatient SM, who by now can easily do it herself.  I would be very surprised if a relatively new SM did not need to practice many of the basics a lot longer, to get them into muscle memory.  You no doubt have heard of Malcolm Galdwell and how he has popularized the 10,000 hours concept, not just repetition, but hours either practicing or doing.  To many in Scrum, sadly, they do many hours just repeating the same mistakes — nothing gained on the 10,000 hours scale.

Also we must see and feel how the lean-agile-scrum ‘music’ (the values and principles) plays with the practice.  We barely started to touch on the underlying principles.

It is true that some experienced people come to the CSM course, and want to go in-depth into one or two areas. But the CSM course is a beginner’s course.  So, if we have beginners we have to slow down for them.

For all of us, but especially for beginners, KISS is so important. Keep It Stupid Simple.

Bear in mind that as an SM, you must learn yourself to teach beginners.  For more advanced people I often say: Think about how you would explain Scrum to a beginner.  KISS.  Watch how I teach, how I emphasize simple things, and make them focus on only the basics.  They cannot advance until they master the basics. You can observe a lot, and steal from me how to explain to others as a SM.  Rather than just content, focus also on the methods.

Now, even the advanced people need to re-learn the basics.  This is because, 100% of the time, they are doing some degree of Scrum-Butt (or you may prefer another phrase for it).  In some way, they have misunderstood.  If you play golf, we can say even Tiger Woods lets some bad habits get back into his swing.  You get the idea. KISS.

Also, simple as it is, it is too complex for them to really do.  Or they can’t explain the basics well enough to get people to do them.  It is not the trainer, not Scrum, but simply human nature. Two big things: we forget and we fall into bad habits.  Again, you have plenty to do to get them all to follow Scrum (as you now know it to be).  See the Scrum-Butts list I gave you.

There is lots of advanced material in the course, but I kind of hide it.  (I am trying to keep it KISS for the beginners.)

For those who are intermediate to advanced, I have a Scrum 201 course.  And, other CSTs have their intermediate courses.  The new CSP path gives you reinforcement for learning more.  As you know, I think tacit knowledge is more important than explicit knowledge, but they are both learning.  With an in-person course or workshop, you cannot help but pick up tacit knowledge from any good Agile person. Sooner or later, you must have coaching from the best coach you can find.  Every professional sports team does, if they want to be successful.

Please tell me your further questions.  I hope these ideas help, or at least make you think and therefore learn.

 

« « Planning Poker Tools || Agile Reading for Executives » »