Search

Wednesday, April 30, 2014

Drowning in Scrum

This might have been the actual pier
When I was three years old, my father tried to teach me how to swim using the same method his father had used: He threw me into a local lake off the end of a long pier and expected me to learn.  Sadly, that day I wasn’t going to learn to swim before drowning and he had to rescue me.  I’m told that I avoided the water for the next few years.

I didn’t use this approach with my own sons.  Instead my wife and I brought them to a swimming instructor, who started them off in shallow water, learning to put their face in and blow out bubbles.  Later lessons grew skills, while managing fear.  I wanted my sons to have a healthy respect for the dangers of water, but I didn’t want them paralyzed with fear and not experience the joys of surfing, diving or just cooling off on a hot summer's day.

Unfortunately, I didn’t apply this approach with my first Scrum team.  I applied dad’s approach of tossing them off the pier.  This involved handing them copies of a book and telling them to “follow the rules”.  Fortunately, the team didn’t “drown”, but they were terrified of all this “agile stuff”.  They clung to the rules, deathly afraid of what book I might read next.  They learned the equivalent of  “treading water” and that was all.

I’m a slow learner, but I eventually correct my bigger mistakes.  For the next team adopting Scrum, I behaved less like my father and more like the swimming instructor.  I had them attend some training to get the big picture, learn the vocabulary and to acquire a vision of what we hoped to achieve using Scrum.   We (management) worked on basic, “safe” practices, such as having leads sit with junior developers to help them estimate a sprint.  The team didn’t commit to a certain number of features for their first sprint, but accomplished what they could.  We measured those features that met a reasonable definition of done and used that metric as a basis for planning future sprints.  In carefully facilitated retrospectives, we listened to their feedback about what worked and what didn’t and agreed on some easy-to-achieve actions.  Slowly, we backed off our involvement and let them assume more responsibilities.

The results for this team were far different than those of the first.  The second team felt empowered with a sense of ownership and were less fearful of change.  This team frequently changed their environment and practices.  They even made demands on management, such as having someone from QA join their team.  The only intervention we found necessary was when, in deciding to tear down cubicles, they exposed live electrical wires and were about to fix the problem directly!

There are too many leaders that don’t understand how to approach fundamental change.  It has to be done with safety and respect.  I count myself as one of those who has hopefully mended his ways.  I don’t blame others who are stuck in a command-and-control mode because, like my father and myself, they come from a long line of “doing things the way they learned how to do them”.  Breaking this cycle is hard, but rewarding.

2 comments:

nictuku said...

+1 to iteratively and incrementally teach scrum. It's funny how this simple agile precept is forgotten by trainers and coaches.

nictuku said...

It's sad to see how many people think of Scrum a a set of practices and ignore its basis.
"Iterative and incremental" is not only the sprint's goal. It should be our approach to constant progress, and it's the basic precept on agile learning as well.
Great snack of knowledge!