Kanban Cards are a bunch of directions, but you need a MAP
I wrote this up as an attempt to make it easier to describe the problems with never-ended Kanban boards. Would love some feedback to see what everyone thinks
Everyone driving the car
the point of doing a "project" is that the company wants to make it to a "destination". Imagine that your whole team is in a car and the programmers are in the driver's seat.
At first, everyone would just yell out where to go, backseat driver style, but this just stressed out the driver and they wouldn't know who to listen to and subsequently made no progress.
Taking Turns
They solve this arguments by taking turns picking where to go. Each person picks a close-by destination, write it on a sticky-note and place it in a queue. The driver goes to them in order.
For instance:
- Ron: "Go to Walmart on main so I can get an apple"
- Jess: "Go to the park on 27nd street, there's some low hanging fruit"
- Ron: "Go back to Walmart on Main because I need another shrubbery"
- Jerry: "Go to the car shop on 89th street, we need some fresh tires to avoid roll resistance"
- Jess: "Drive to this gas station for some fuel, there's one right here"
Fair, but not effective
This helps with the driver getting stressed out but also has some problems. Firstly, it's very unfocused. Everyone gets a turn to pick where to go, which is "fair" but isn't very effective.
All the different sticky-notes, while detailed, don't get them anywhere in particular when you added them up. The list is so verbose also so it took a very long time to read.
Secondly, there's no real check on each of these instruction cards to see if all of them are truly necessary. Anyone can just throw a card into the list that wants to. Sorting and throwing out bad ideas would help, but this is very time-intensive due to the sheer number of sticky-notes and the fast rate at which they are added.
A map that everyone shares
A better system is to have a map that everyone shares. Not only that but lay out a clear guideline on where exactly you want to go:
"We want to discover Atlantis 🤯*"*
Wow! Sounds exciting, but nobody knows where Atlantis is. This would easily turn into a wild goose chase that could take years with no progress, there's just too much risk and too much ambiguity. Maybe pick something a bit more reasonable.
"We want to go to the Grand Canyon and go poll vaulting"
Much better! This is very good because as the driver thinks of where to go and deals with unexpected traffic problems he can make efficient adjustments. It's also nice because it becomes a clear way to measure if you're going in the right direction or not. While it might be tempting to take this and convert it back into the sticky note system this causes everyone to turn off their brains and blindly follow the instructions and it's unclear if each sticky note is contributing to the main goal or a distraction from it.
Deadlines
Another great thing to add to your travel plan is an arrival time. For example:
"We want to go the Grand Canyon and go pole vaulting by September 5th (3 days away)"
While it may be tempting to again try to just add up all sub-destinations and expected stops to figure out how long it will take to get there, it doesn't work because if you ask, "what's all the stops along the way everyone wants to make?" people will all contribute their 10 tickets and you'll end up with a month-long road trip which is far more than you bargained for.
Counterintuitive as it may seem but adding a deadline before you plan all your stops (so long as it's unrealisticly short) actually helps a lot because it makes everyone in the car think twice before requesting any more stops along the way.
Making this more concrete
The problem with Kanban boards is they don't show you where you're going, only a bunch of "driving directions". They don't have a concept of a project because they make the assumption that you've already broken down the project (put your project description through a shredder) and that all the tickets that are in the sprint are cohesive and not just a bunch of competing priorities.
However, this is a bad assumption. Organizations are made up of lots of people, and as such, each department (support, developers, marketing, the executives, etc...) usually gets a relatively equal say in what tasks get prioritized. As such this means the development team gets pulled in many directions and often makes very slow progress because of it.
See also:
- fixed time, variable scope
- Agile deathmarch
- Pitches
- timebox
- Time is money
- Agile is about productivity, Basecamp is about effectiveness
Untitled recording.webm 🔖
this file hasn't been written, it's a stub
Backlinks: