Wednesday, January 29, 2014

Question about Retrospectives and the role of the SM

A very bright and quick class attendee wrote and 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, 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 SMs duties as mainly revolving around the Retrospective (as many 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, often much harder.)  In addition, you must help and teach the PO to be more effective;  Th typically the biggest impediment (and multifaceted).  The next highest impediments are usually technical impediments (eg, getting good Continuous Integration and automated test suite).

But, we do a lot around Retrospectives.  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!

So, you (with the Team) must take action.  In two sentences:
(a) collect data and decide the top impediment for the Team
(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 approve).

And the A3 exercises was all about starting to learn how to make the case to a manager. Which, usually, we are terrible at doing because we do not speak 'manager-speak'.  To the Team, that is a foreign language usually.

The A3 exercise also, indirectly, teaches us how to prioritize. Mainly, by benefits (eg, increased velocity) to costs.  So, a key thing is that you must help the Team prioritize the impediments in a benefits-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, not exactly about Retrospectives, but I recommend that.  Again, not exactly about Retrospectives.

I have to balance the different topics in the 2 days and I have way too much to say to make all of them 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.

One of the biggest problems with Retrospectives is that some SMs get too cute.  They have lots of new, cool, weird 'process' -- but the Team does not move much on really getting an impediment fixed.  And that is your time, as SM, to get them to help you.

How can you help?  Mainly the ways I said: (1) identify the top impediment, (2) devise solution, (3) help plan execution, (4) create bus 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" (by someone). Again, getting too fancy does not help.  Just say: 'let's devise the solution together' or something like that.  And 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 naturally flows.

It is similar to the discipline of learning the piano, which is clear to many people.  Practice, hard practice, even harder practice.  But it is not so clear for the discipline of SM.  Anyway, 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 know doubt know of Malcolm Galdwell and how he has popularized the 10,000 hours concept.  Not just repetition, but how learning hours either practicing or doing.  And to many in Scrum, sadly, they do many hours just repeating dully the same mistakes -- nothing gained on the 10,000 hours scale.

And we must also see and feel how the lean-agile-scrum 'music' (the values and priniples) plays with the practices.  And we barely even 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 also a rank beginner's course.  So, if we have beginner's we have to slow down for them.

But bear in mind  that as an SM, yo 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 advanced until they master the basics. You can observe a lot, and steal from me how to explain to others as a SM.  So, rather than the content, you 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 so degree of Scrum-Butt (or you may prefer another phrase for it).  In some way, they have mis-understood.  If you play golf, we can say even Tiger Woods let's 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. The 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 advanced material in the course, but I kind of hide it.  (I am trying to keep is 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 an reinforcement for learning more.  As you know, I think Tacit knowledge is more important than explicit knowledge, but they are both learning.  And with an in-person course or workshop, you cannot help but pick up tacit knowledge from any good Agile person. And, 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 give us more questions.  We hope these ideas help, or at least make you think and learn.

No comments: