The Kanban board has become the staple of progress tracking in software development. There’s a “To Do” column, various stages of “In progress” and finally a “Done” list.
We think of this as a discrete set of steps. A ticket moves from one column to the next. There are no “in-between” states.
If you’ve ever worked in a software development team, you might agree that it’s hardly ever as clear cut. In theory, a ticket goes from step 1 to step 2 and can never move back. With all our talks of “Lean” and “agility”, our progress model seems to resemble … a waterfall. In reality that’s not how it works. The tickets move through a continuum rather than a step-by-step state machine. If we look at it that way, we can see some interesting overlaps.
Urgent Tickets
Tickets in the To-Do column have to wait until they are moved to the Doing column. Unless we need it NOW NOW NOW. Whether there is an urgent security patch or the CEO discovered a typo in his name, we drop everything and push to prod as soon as possible. These tasks are often not even placed on the board. There is no ticket. Just do it now!
Release Purgatory
A developer has committed their code and while we all dream of continuous integration, the code is not live. It’s not exposed to real users. For most of us, there are extra steps. Maybe we’ll have to wait for an Acceptance Testing session. Maybe we require a sign-off before pushing to prod. Whatever the reason is, these tickets are neither In Progress or Done. Nobody is working on them and anybody downstream can reopen them with feedback.
Rework
So you marked those 18 user forms as “Done”? Well, get ready to open them up again, because we’re going to add multilingual support. Sure, they are different tickets, but the feature was never Done. It’s why project managers hate rework: the progress they’ve reported in no longer valid.
The Product
In the middle of our continuum, there is The Product. It’s all the work needed to keep our thing afloat. It’s ever-growing and we can’t always define tickets. It’s scaling up the servers. It’s redesigning the overall architecture. It’s responding to customer requests. It’s fixing bugs.
The more time passes, the more we’ll work on The Product. That’s why progress seems fast in the beginning. That’s why it grinds to a crawl after a few months.
Business/IT vs Product teams
The existence of The Product explains why self-organizing Product Teams are so much more efficient than Scrum / feature teams. For the latter, the Business fills up the “To Do” column. They often have no incentive to care about the rest. They’ll keep tickets in Purgatory because other things are more important to them at the moment. When they finally review those after a few weeks, their comments will create Rework. When the pressure is high, it rains Urgent Tickets.
Now, look at what Product Teams go through.
Sure, they’ll spend an ever-increasing amount of time on The Product, but they get to decide their own inputs, outputs and priorities. While it’s still not a discrete step-by-step waterfall, they do have their three-step flow:
Doing: new features and improvement they are currently working on
The Product: customer support, keeping the system up and running, maintenance
Done: the system as it is currently being used by actual users.
This way of looking at the big picture is far from complete. I’m sure there are a lot of grey areas and flaws in this design. But it’s closer to reality than the waterfall.
And it impacts our teams.