The Truth About Developing Self-Organizing and Self-Managing Teams

Written by JT Moore on August 26th, 2010

It’s day one of your new role as ScrumMaster, you remember from Certified ScrumMaster (CSM) training that the Development team is supposed to be self-organizing and self-managing. You think to yourself, “Wow, what a great concept, I can concentrate on clearing impediments and my team will be on autopilot. I might just have enough time to catch-up on cleaning out my inbox. Now that it is time to put that Scrum training to work and kickoff the first Sprint.  I guess I better send out an e-mail.”

To: All Development Team members

From: Your new ScrumMaster

Subject: Sprint one

Body: I know that you all must be as excited as I am about starting Sprint one. You guys know what to do so go and make it happen. If you have any impediments let me know and I will take care of them. Good luck team! – Sincerely, your new ScrumMaster

Wouldn’t it be great if it were this easy? Unfortunately, many newly minted ScrumMasters don’t fully appreciate the hard work it takes to build self-managing and self-organizing teams. They take a fire-and-forget it approach. Then, when the development team fails to achieve their first Sprint goal they immediately jump to the conclusion that the team is incompetent or that Scrum itself doesn’t work.

Building a self-managing and self-organizing development team is hard work; it tests the metal of even the best ScrumMasters.  Let’s take a look at how one Lean technique, Kanban, can help you avoid a mistake such as the one illustrated above.

In the book “Implementing Lean Software Development” Mary and Tom Poppendieck define Kanban as, “Kan is the word for card in Japanese, and ban is the word for signal. So a Kanban is a signal card.” They give an analogy of an airline ticket. Have you ever noticed how it is your ticket (or card) that signals which gate to go to and ultimately which plane you get on to reach your destination?  Kanban is the process of using a signal card to reach one’s ultimate goals.

A practical application of Kanban for Scrum would be setting up a Scrum board or information radiator as Alistair Cockburn calls it, near the team. On this Scrum board would be all of the tasks necessary to develop the Sprint Backlog items, laid out in priority order. As the Development team needs work they would pull the next signal card (a.k.a. development task) from the Scrum board, repeating this process until all of the tasks are complete.

By facilitating the creation of a Scrum board, or Kanban system, the ScrumMaster is gently guiding the team to what is the most important task to do next. The best part of this system is that the team creates the tasks, prioritizes them, and then completes them all without the need for the ScrumMaster to tell the team what to do.  In this case the ScrumMaster is applying the Lean concept of Kanban by utilizing their environment as a tool to help facilitate self-organization and self-management.

This post was contributed by Brian M. Rabon, an ASPE-SDLC instructor who is a CSM, CSP, MSEE and PMP. Brian is also the president of The Briantrust Consulting Group, you can read his blog, find him on Facebook, and connect with him on Linkedin or Twitter.  Brian is a regular contributor to the ASPE-SDLC Blog and a thought leader in the fields of Agile and Traditional Project Management as it applies to Software Development.

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

Comments are closed.