Ten Lessons Learned from Professional Scrum Master Training

There’s a lot I want to relate about my recent Professional Scrum Master training that was delivered by Ken Schwaber– perhaps more than can reasonably fit in a blog post.  Initially, I thought this would be a refresher course for me – I’ve been an advocate for Scrum since 2002, so I knew the fundamentals.  However, to my surprise there were a lot of nuances that I hadn’t considered and some glaring gaps in my own knowledge.  For example, I have come to understand that I’ve actually been too involved with my teams, inadvertently creating a dependency on myself. I have to learn to step back and let them do their own thing more.

Below are ten lessons that seem to have “prioritized” their way to the top of my mind’s Product Backlog as I’ve thought over my experiences in the classroom.

1. Define what “done” means for your organization, team and project:  This trips up a lot of teams, including many of my own.  As a company and as a team you need a standard that clearly spells out when you are “done” implementing a feature.  Without this, teams are unable to estimate their work and say with any certainty what they can commit to completing for Sprint Review.  If you’re chucking quality under the bus every sprint, say so in your definition of “done”.  Put it on a poster in the team room in big letters to remind yourself that because you’re not doing it now, you will be doing it later.
   
2. People, not Resources:  This became a bit of a running joke over the two days of the course given how many times people would ask about how resources should be managed, resourcing issues, etc.  Ken would not-too-subtly remind us that we’re talking about people with a joke that we should go home and tell our significant others that they’re the most important resource to us in the world.  The point is that to refer to people as a resource is to try and homogenize them: They aren’t interchangeable parts.
   
3. Trust teams.  They’re adults, not children:  Non-agile software management rules attempt to corral, herd and then dictate to highly-paid, intelligent people what they should do to solve a problem – like they’re kids.  We need to trust teams to find solutions to hard problems, because they’re made up of (we hope) adults.  Let’s treat them as such.
   
4. Always make risks transparent. Always.  We blew what should have been a simple exercise on Day 2 of training that distilled down to not making our customer aware of risks in delivering a mission-critical application inside of four months.  We all chose trying to provide certainty where there were actually a lot of hidden assumptions. To illustrate our error, Ken related the story of going to a doctor to get guided through a surgical procedure.  The doctor would explain the procedure and the risks, options and alternatives allowing the patient to make an informed decision about whether the risk was worth it.  We should do the same for our customers – the risk is theirs to take, not ours.
   
5. The Product Owner is more involved than you think:  They just come in for the first part of Sprint Planning and Sprint Review, right?  Actually, they should be involved in all parts of the project except for Daily Scrum.  Sprint Planning? Yes.  Decomposing backlog items into tasks?  Yes.  Sprint Review?  Yes.  Sprint Retrospective?  Of course!  A more involved customer is a happier customer.  Conversely, Scrum may not be a good approach for customers who are disengaged.
   
6. Don’t ignore or dismiss team formation:  Set aside at least a day for a new team to get acquainted, set up their environments, pick a team name, establish rules for development and interpersonal etiquette and understand what it means to be “done”.
   
7. Scrum is a shovel that uncovers problems in an organization.  And then some:  It’s been said that because Scrum makes everything transparent, it causes pain when it surfaces everything you’re not doing well.  The good news is that allows your teams figure out how to address the pain and resolve it.  The bad news is that you can expect Scrum to uncover bigger problems down the road.  By itself, Scrum offers no solutions – only teams can do this.
   
8. Sprint Review is not the place for applause:  While many teams may take some joy in getting an increment in front of their customer for Sprint Review, this isn’t the time or place for adulation and “corporate applause”.  Sprint Review is an important part of new product development and planning, allowing both customer and team to inspect and adapt their work.  Treat it as such and go out for beers afterward.
   
9. Empirical process frameworks, like Scrum, require courage:  Kent Beck established “courage” as one of his fundamental principles behind his eXtreme Programming engineering framework.  The same holds true for Scrum.  Think carefully on this – it has more levels than an M.C. Escher drawing.
   
10. Teach teams to resolve conflict:  Teams working in an iterative/incremental way with Scrum will inevitably come into conflict.  Rather than avoid conflict at all costs, teams need to learn how to resolve their conflicts.  It’s not bad to have a passionate fight about something.  It is bad to take it to a point where feelings are hurt or a physical fight is about to break out.  Get them professional training to learn how to take the temperature down and resolve their issues.  This doesn’t mean a group hug or other kumbaya moments – it’s serious, bare knuckles, coming to better understanding with others.