Fantasy: the self-organizing team
I wrote about this phenomenon in a different context about a week ago, but it’s come up again. Twice is a coincidence, three times is a pattern, right?
I was talking to a client the other day about a thousand things, in the space of half an hour. There were a few things that stung badly, but one of them was to the effect that I wasn’t managing the developers very well.
It’s true…
…that I rarely tell the other guys what to do. I don’t particularly evaluate their work, not in a keeping-score sense anyway. I don’t set up rewards or incentives. I don’t make a Gantt chart. Nobody gets called into my office.
From the outside of things, actually, you wouldn’t even know I was in charge.
Backing up for a moment
At that time, the team was just me and two part-time contributors: one Rails specialist and one User Experience expert who is also pretty good with Rails. They’re highly skilled and have Agile Mind. The UX guy even introduced me to AgileZen, a nice little web application that simulates a real KanBan board.
So… yeah. What’s to manage? There’s a board, you can see it, it has story cards… it’s easy to see blocks and backlogs… you might ask a question once in a while.
If a queue looks light you can either prompt someone to take on more cards (if that makes sense), adjust the queue size (if that makes more sense), or encourage people to work different queues from their usual.
The thing is
In this environment it rarely takes more than a nudge. Strike that, it rarely takes even that. This team really truly does self-organize. At this point they need to continue communicating among themselves and maybe remind me to push my own work to github more frequently.
Does that look like I’m not managing?
Probably.
Would it help if I started handing cards directly to the part-timers and asking for status every day?
It sure would! It would help me feel super-duper important! It would reassure the client that I’m in control! It would reinforce my position!
On the other hand, it wouldn’t get any more work done. It would probably get a lot less done, since sharp developers have a really good sense for what should be worked on next.
I’m sure you’ve seen it
This always happens. The Gantt chart says today you work on Task A, but your brain just isn’t ready to do Task A. You’re in a Task B kind of mood, and you woke up with a really simple algorithm for implementing it.
Classic management says write it down, put it aside, and get cracking on Task A. Agile says pull the Task B card, create some tests for it, write the code, make it build and test out, then mark the card as Ready.
Guess who gets Task B done first?
Guess who will probably actually get Task A done first?
Guess whose hands on the wheel are going to be more effective? Not mine!
KanBan has priorities
You arrange your Story Cards into queues, which are vertical. You move cards from the leftmost (backlog) queue, through whatever steps your process requires, and finally into the rightmost (archive) queue. Cards within a queue carry a priority number.
You don’t push cards to the right when you’re done with them. Nope. You pull cards from the left when you need something to work on!
Sometimes a card has to go backwards because redesign is needed after some code gets added. Sometimes you skip a higher-priority card to pull a lower-priority one because you had an idea, or because it fits the time you have available, or a resource you need to do the higher-priority card is unavailable.
Those are not management decisions. Those are team member decisions.
So in a really well-functioning KanBan system, what the heck does the manager do? By traditional measures, not that much. It’s less Vince Lombardi and more Mary Poppins: giving smart people a goal and letting them figure out how to get there a little bit at a time.
August 2, 2010 @ 3:19 pm
Hey Mark,
Wow, that’s pretty interesting. Guess sometimes better organizing technology can work a little too well?
How’d the explanation go over?
Judy
August 2, 2010 @ 5:19 pm
“Never apologize, never explain.”
I just pointed them at this post. 🙂
Well, okay, after making a very clear statement on the matter at our collaboration site. So clear that when I showed it to The Smartest Guy I Know his first question was, “So do you have the next gig lined up?”
As you know, sometimes I’m so into the nuance that it’s easy to lose track of my main point. So I made sure to use the word “bullshit” three times. (It’s something my mother taught me.)
August 10, 2010 @ 3:00 am
Hi Mark, I’ve seen this attitude quite too often. It’s really counter-intuitive for traditionally trained managers that a team can (and should) organize itself. But the more responsibility a team takes on their own shoulders, the better and faster everything goes. We really have to spread the word more and more 😉
August 30, 2010 @ 3:46 pm
The other really nice thing about the self-organizing team is that it conveys information a lot faster than… just about anything else. If you have to check in with management or a team leader before making decisions, that’s another bottleneck in the process. Likewise if management gets involved with telling individuals what to do on a day-by-day basis.
Lately I’ve been telling people it’s less like (American) football and more like basketball. In basketball you definitely have prearranged plays and well-practiced team techniques, but the game just keeps going without very many breaks. Your players need to take a lot of responsibility for knowing what to do and where they should be. In American football (I know you’re in Germany) it’s all prearranged plays and you even stop the game at every down for a meeting to hear management’s plan for the next play. American football players memorize the plays and perform their roles; they only improvise when something goes badly wrong and the original plan can’t be followed.
That’s not to recommend one specific Agile methodology. It just suggests a spirit of informed and coordinated improvisation as opposed to always asking someone to make group decisions.
September 7, 2010 @ 2:19 pm
I was thinking more about this recently and noticed the connection between “self-organizing team” and “team that can see more than a week or two ahead.”
It’s really hard to self-organize when you get large, externally driven scope changes or when for any other reason your team planning horizon is very short. Communication requires time and space; otherwise it’s like trying to have a deep conversation that keeps getting interrupted. Doesn’t work.