The Lean Startup Kanban board
In my last post, “Responsible Technical Debt: Not an Oxymoron“, I said I’d propose a way to responsibly handle technical debt in a Lean Startup context, where a substantial number of your units of work are experimental, and unlikely to be kept as first written. That way follows. I should explain that although I haven’t seen in practice, it’s one I’ll be trying soon in my very own startup, so I’ve given it a fair bit of thought. My thanks to the many Lean Startup and Kanban people who have inspired this.
Standard Kanban boards
The core notion of a software development Kanban board is that you represent visually the state of various units of work. These units of work are pretty small, generally a few person-days. A basic one looks something like this:
Stories flow in from the backlog on the left. After they are worked on (D-E) and reviewed (F), they are released and put in the file of finished stories, rarely to be looked at again. There are generally limits, so that a team will only have a certain number of stories in each stage at one time. Because the code could be around for years, we need to make sure to write it in a sustainable way, and the Agile movement, especially the Extreme Programming end of it, has discovered and promoted a lot excellent techniques for making code that lasts.
This flow makes a lot of sense when you are using Agile techniques to solve a known problem, and have pretty high confidence that the things you build will last indefinitely.
Lean Startups are different
However, in software startups, and especially when following the Lean Startup approach, you are solving an unknown problem. The goal, especially in the early stages, isn’t to build software; it’s to discover needs and wants that people will pay you to satisfy.
The standard startup approach, typified by dot-bomb Webvan, is known in the Lean Startup community as the “field of dreams” approach. You build a complete product in the hope that when you finish, your customers will come. The Lean Startup approach instead requires that you identify your hypotheses about your customers, your market, and your products, and test those hypotheses as early as possible, partly by trying a lot of things out and seeing how they work.
Another way to look at this comes from Eric Ries:
Anything that makes that loop longer is worse. Technical debt can surely do that. But if you write something to last the ages and then remove it next week, that can also slow down your feedback loop.
My answer is to explicitly accept there will be two kinds of code in the system. There will be sustainable code, the kind that Agilists have spent the last 15 years learning how to create properly. And there will be temporary code, code that we explicitly plan to throw away. I still think the third kind of code, half-assed code, has no place in a serious software project. But there’s a risk, one many of us have lived: what if the temporary code sneaks into the permanent side, putting the project on the road to a technical debt bankruptcy?
Lean Startup Kanban boards
My solution to this is to expand the Kanban board to explicitly represent the flow of experiments. Below, experiments are represented in blue:
For the early part of their lifecycle, experiments and regular features share a pretty similar path. They hang around in a backlog until the are put on deck (C). They get worked on by the team as part of the regular flow (E), and accepted by product managers (G). But then, after release instead of being put in the released-and-forgotten box, those stories are tracked as active experiments (H-M).
When the experiment is concluded, then the feature might be accepted permanently, in which case the code will need to be cleaned up, and the rest of the system refactored to accommodate the new code. More likely, the code will be removed. Possibly because the feature turned out to be a bad idea, at least in its current form.
Or possibly it was a good idea, but not good enough in its current form to keep. Often the first approach to a feature (or to its implementation) isn’t the right one; it can be better to remove the experiment and its code in favor of an upcoming correct implementation. In which case, it will yield a number of new story cards for the backlog.
I think this approach will mitigate the biggest risk of accepting any temporary code: you forget that it’s temporary, and suddenly you’ve got technical debt in your system and no scheduled time to clean it up. There are other risks, some of which I hope to write about over the coming weeks and months.
Have thoughts on this? Have you tried something similar? I’d love to hear about it. Leave a comment!