The Kanban and The Flow
I think most developers like to work on Greenfield projects. A lot of developers are in a position where they can do that, or so they think, because most projects turn into Brownfield before they’re finished.
I used to prefer Greenfield as well, but after a while I realized that while it’s nice to be good at Greenfield, it’s way more important to be good at Brownfield. And that includes managing Brownfield work.
This story is about managing Brownfield work.
Kanban
Most Brownfield projects are not really projects. There might be a scope, but a lot of Brownfield work is just a never ending stream of ad-hoc requests. Also, the work is very unpredictable, so any form of planning is useless. So how do you manage work without planning?
The first time I heard about Kanban, all I remembered was: three lanes, no iterations. And I’ve heard other people describe Kanban like that as well.
Then I came into a position where I had something to say about our process. We had no iterations and a lot of ad-hoc requests, as well as fire fighting. I proposed Kanban, but I wanted to do it right. And so I found out about WIP Limits.
Limit Work in Progress
What you do is, for every lane on the Kanban board, you decide on a maximum number of tickets that can be in there. The number of team members is often a good start. This maximum is not an indication, you are literally not allowed to move a ticket to a lane that has reached its limit.
At first, this didn’t make any sense. Sure, you could use this to make sure a developer finishes a ticket before starting with a new one. But what if they are genuinely blocked? Or, they’re done, but they can’t move the ticket to the Review lane, because that one’s full?
Aha! But if there are too many tickets waiting for review, and you’re not allowed to pick up a new ticket, then you have time to do a review! And this holds in general, doesn’t it? If you are blocked, and you can’t start something new, that means you have time to work on removing obstacles.
This is what they call Managing Flow.
Manage Flow
Is a car factory more productive if it produces more steering wheels, but less cars? No. It doesn’t matter how many steering wheels it produces, it’s all waste if they’re not actually on a car.
The same goes for software. Pull Requests are nice, but they are just waste unless you actually merge them. If your Pull Requests are piling up because your build takes 3 hours and fails randomly, why not take the time to fix it?
Cycle Time
But what exactly is wrong with building code in the meantime? Nothing, provided that:
- Plans don’t change
- Everything works the first time
- Delivering later has no impact
In my experience, however:
- Plans change before features are delivered
- Builds regularly fail more than once
- Some features are even cancelled because “we already did it manually”
In reality, working on multiple things at a time means more rework, context switching, dead code and other pointless activities.
The time between a feature being requested and being delivered is called cycle time. The better the flow in your process, the lower the cycle time, and the lower the amount of waste. This is why it’s important to manage flow, and this is why limiting work in progress helps you do that.
Make policies explicit
Here comes my favorite part…
If you do Scrum, but you also get bug reports that need to be picked up immediately? Do you allow the Sprint Backlog to be changed?
Your answer is probably: no. But even though it’s not allowed, it still happens. And everybody is unhappy about it. (We just don’t talk about it.)
Let’s call these bug reports “expedite”.
If you do Scrum, do you write stories for documentation? And do you assign story points?
Of course you don’t assign story points! Documentation has no value for the end-user! In fact, your Product Owner thinks documentation has no value at all… Okay, that’s mean. (But you know I’m right.)
Let’s call these tasks “intangible”. We’ll call normal tickets “tangible”.
Now, why not agree that:
- Expedite tickets always go first
- Expedite tickets don’t count against the WIP limits
- The backlog should have a mix of 4:1 ratio of tangible to intangible tickets
That wasn’t that hard, was it? If we make explicit policies that benefit stakeholders as well as balance short-term and long-term benefits, we can get along with our work, and there’s no need for all this bickering about bugs and documentation.
Slack
The thing you have to give up, of course, is planning. No iterations means no forecasts of what will be delivered. But then again, if your Sprints are disrupted by expedite work, you don’t really have forecasts either. The only way to be sure is to set aside a fixed amount of time per Sprint, but this is inefficient. Delegating the work to a dedicated maintenance team doesn’t help either, because they would need excess capacity as well.
This excess capacity is called Slack, and it’s the only way. There’s no such thing as a free lunch. There’s no buffering without RAM. There’s no dam without a lake.
If you want to be able to finish your Greenfield work on time, while also being able to process expedite work in between, then you need slack. If you add slack to your Sprints, you could at least use it to pick up the intangible work in the meantime.
And if you choose to outsource all Brownfield work to a maintenance team, you know you want that team to focus on flow, not predictability.
Managing Without Planning
Now let’s go back to our original question: how do you plan work without planning?
The answer is: you manage the flow. You make a continuous effort to remove bottlenecks and reduce cycle time.
Does that mean you know when it’s done? No. But you do know it will be done as soon as possible.