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.