Licensed to Coach

Last week, unexpectedly, I became a Licensed Scrum Master. I knew I was attending a course run by Scrum Inc with a group of my colleagues, but I had no idea that there was a short online multiple choice exam and a certification for me at the end.

It's easy to be sceptical and sniffy about the industry around Scrum, but I try to go into training events in a positive frame of mind, looking to participate, open to having my views changed. I'm not sure that there was a seismic perspective shift for me on this occasion, but I still thought it'd be interesting to run a personal retrospective.

Some background first: I've never worked on a Scrum team, although I manage testers on them. I'm very interested in ways that software can be developed and tested, and one of my favourite books in that space is  Extreme Programming Adventures in C# by Ron Jeffries, a great practical example of iteration, reflection, and honesty.

A disclaimer too: without much visibility of the remit of the training, and knowing that the level of Scrum experience of the attendees ranged from 10 years to none in the group I was in, my comments here are knowingly, selfishly, biased to my own preferences.

Good

• Participants were split into "Scrum teams" for the class, with Product Owner and Scrum Master roles being nominated. This was neat, both to build up some team spirit and reflect some of the material being taught.
• The Scrum Inc people I dealt with were good: knowledgeable, open, seeking feedback and acting on it. 
• From what they said and the evidence I saw, Scrum Inc eat their own dog food. In particular, both trainers were able to give nice examples of their own teams' values, off the cuff.
• The course material reiterated that Scrum exposes problems for the team and organisation rather than providing some kind of magic wand to remove them.
• Teaching sessions were organised as "sprints": a Kanban board for sections of the course, with a burndown chart showing progress, velocity and so on. I thought this was a gimmick to begin with but came to think I'd have liked to have seen it extended.
• The content included extremely light touches on lots of interesting (non-Scrum) stuff such as Shuhari, Weinberg's Systems Thinking (although only for a comment on context-switching costs), Simon Sinek's Golden Circle, Value Stream Mapping and The Theory of Constraints. Perhaps it'd have been nice to have a categorised list of further reading in the course notes.

Bad

• Statistics motivating the use of Scrum (or sometimes simply "Agile") were glossed over too quickly and with too little definition for my taste. See also  The Leprechauns of Software Engineering.
• The practical exercises weren't geared to explore the course content in much depth. This is understandable; time is limited. But I found it unsatisfactory and the type of exercises — sometimes with a competitive element — were distractions from the key points.
• The why (Scrum's pillars and values) got lost in the what (the mechanics of the ceremonies and the artifacts). I fear that this risks promoting a kind of cargo cult Scrum.
• Similarly, the how (what the Scrum Guide mandates for Scrum) wasn't heavily distinguished from another what (potentially useful practice to implement Scrum) either. Story points, burndown charts, and Kanban boards might be helpful, but they're not fundamental. It's possible to do Scrum without them.
• I would have liked to have seen more on the roles. The Scrum Master should coach the development team, the Product Owner, and the company, but we didn't get to that beyond a bullet point.
• What the business commits to the team was also thinly covered. The focus of the training material was heavily biased to what the team does and what it commits to deliver to the business.

Change

• Relate all teaching directly back to the Scrum pillars (transparency, inspection, adaptation) and values (commitment, courage, focus, openness, respect) and explain how the activities serve them.
• Cover the human side of this kind of work. An enormous factor in the success of a team will be the interpersonal relationships. There definitely isn't time to coach the participants in (say) assertiveness and feedback, but some acknowledgement of their importance would make the content stronger.
• Replace the piecemeal exercises with a themed set that runs for the duration of the course, based on some kind of development project. Use it to explore the ceremonies, roles, and artifacts more thoroughly. Admittedly, this would still be artificial but the context built up over successive exercises can mitigate that to some extent.
• Provide more coaching in the roles. It was great to have Scrum teams for the duration of the training, but the PO was reduced to housekeeping in several of the exercises.
• Provide more demonstrations of actual practices, such as the burndown charts for sessions. I'd have liked to have seen the trainers explicitly facilitate a course retrospective, for example, to show how experienced practitioners go about their work.

The picture at the top is how the Scrum team I was in approached the challenge of explaining Scrum in 60 seconds using a deck of cards showing the roles, events, and artifacts. Shorn of the details of particular practices, the core iteration and reflection is clear to see. So clear, in fact, that we explained it in less than 30 seconds.

And that's one of the things I'll take away: for sure, Scrum comes with a lot of baggage (not least that it's often seen as unthinking management's silver bullet) but at heart, as the Scrum Guide says, it is transparent and iterative and (my emphasis) ...

... not a process, technique, or definitive method. Rather it is a framework [that] makes clear the relative efficiency of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.

But for it to have a reasonable chance of succeeding I think all concerned are going to need to understand and buy into that.