As a first step towards dealing with an over-loaded development team, we showed an organization how to visualize their work by representing work items with Post-its on the wall, flowing from to-do, to in progress, testing and done. The organization quickly catched the idea, and soon priorities were respected, deliveries became more predictable, and developers had a process to improve.
Which is what they did, and after some time we saw a new work pattern emerge:
- A product owner identifies a need and wants a designer to work on the details
- The designer grabs the task and sketches out a solution
- Developer tasks can now be defined, and they go into a special planning column, which gradually started to increase in size
Things are finally happening
Although tasks are completed at this point, the need is still not solved. Nevertheless, the message becomes: “Hold on tight everyone, things are finally happening now,” and while waiting for it, the product owner may start working on even more needs, which creates even more work for the designers, and subsequently even more tasks for the developers.
Which is what they did.
One idle product owner is more scary than ten overworked developers.
There’s just one problem: The developers still don’t have the capacity to deliver everything they’re expected to deliver. They are still over-loaded, but nobody sees the bottleneck for creative, well-intentioned process improvements: Pure designer tasks, extra categories, special columns and so on.
Show don’t tell
People had become so used to telling each other about their overloaded developers, many had simply accepted it. (Btw: They had heard the theory about limiting work in progress, but didn’t quite see how that would help – they were after all only beginners with Kanban and had enough challenges already.)
They were trying to improve their way out of symptoms of false premises for their work. In other words, great circumstances for a show – don’t tell maneuver:
We proposed simplifying the process by sticking to one type of task (that both designers and developers would have to work on), and a simple YES or NO response from the developers to any incoming task.
Put the discussion where the problem belongs
“That would make our product owners realize there’s no point reporting tasks to our designers, because most of it would stop later on anyway, ” they responded.
“So what would happen then?” We asked.
“Well, the product owners wouldn’t have much to do, and neither would the designers. We would make them more or less idle.”
“And then what would happen?” We asked.
“Pretty soon everybody in the organization would realize most of their stuff isn’t worked on. They would see product owners with nothing to do. There would be huge protests!”
“And then what would happen?” we asked.
“Someone in upper management would have to come in and deal with this!”
Which is what they did.
