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:

The Lean Startup Loop

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:

kanban-startupFor 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!


  1. Agile Focus » Blog Archive » Responsible technical debt: not an oxymoron:

    [...] Reading « 9 Signs of Bad Team Spaces The Lean Startup Kanban board [...]

  2. William Pietri:

    One person asks on Twitter whether this additional Kanban complexity is worth it. As I said at the beginning, I am just starting to try this, so honestly, I don’t know yet.

    But in my view, one of the great things about the Kanban board is that it makes existing but invisible states visible. I think that is powerful in two ways. One, it can impose some WIP limits, keeping complexity manageable. Two, it requires people to be explicit about state transitions, so that things can’t sneak from, say, “working on it” to “verified complete”. Or, worse, from “working on it” to “abandoned in the middle and forgotten”, a common state in chaotic companies.

    The shops I have visited who are doing well with experimental features are careful to limit the lifespan of experiments, and many of them already have something akin to the “active experiments” column. I added the fifth column to be explicit about our obligation to clean up the mess from experiments. Technical debt can be a silent project killer, and I want to be sure that temporary code doesn’t turn permanent accidentally.

    If it turns out that column is superfluous, I’ll certainly remove it. But I’m betting otherwise for now.

  3. Lean Startup Kanban Boards « LeanKit Blog:

    [...] a blog post today on, William Pietri outlines his approach to tracking experimental work through the value stream of a Lean Startup. Being a “Lean Startup” ourselves (though we don’t really think of ourselves as a [...]

  4. SKMurphy » Startup Lessons Learned Conference Coverage Roundup:

    [...] William Pietri “Responsible Technical Debt: Not An Oxymoron” (Part 2: “Lean Startup Kanban Board“) [...]

  5. Arlo Belshee:

    I recommend against adding complexity to deal with a problem of feedback loops that are too long. This is always the temptation with process: refine it, add detail, and X (precision, predictability, cycle times, learning, etc) will improve.

    Instead, simplify.

    I got here from a comment where you assumed that I don’t play in the startups area, because Naked Planning may fit with stable requirements and funding, but not in the world of startups.

    Ironically, the people in stable situations assume that I must be from the world of startups, because Naked Planning clearly assumes constant change and experimentation, and in stable arenas they need to do a lot of planning and predict what will happen.

    Of course, I have played in both spaces, but mostly in startups (I’ve founded 2 software startups, and worked in 2 more). That’s why Naked Planning is so focused on tight-cycle experimentation.

    The naked approach to including experimentation is simple. Who says that you need to wait to ship an MMF until its done? Who says that you have to deploy to everyone at once? Who says that the only way for an MMF to be done is for it to become a feature of the software? Who says the code has to be high quality? The only requirement is that everyone agrees that we have delivered all the value on this that we want to, and we have incurred only the debt we want to. The MMF stays open until then, and then it makes space for the next learning opportunity.

  6. Arlo Belshee:

    Instead of side-tracking your experiments and managing multiple queues, just use the Detective’s Blackboard to track everything you discover as you work an MMF – just as would a team working on a more “stable” system. The whole point is to experiment, tight-cycle the learning, and do what’s right for the value stream (often, but not always, the customer).

    Even “stable” projects are nearly entirely discovery. Anyone who tells you their project is implementing something they understand is working on a doomed project. If the result is known, then a competitor is already doing it, and you’ve no advantage to implement that piece. Just partner with them and move on to some area that is unknown.

    So, the Naked approach works for all the projects worth doing – anywhere the requirements must be discovered as you go along. The approach is so simple that it cannot be readily explained, nor easily done. It is just this:

    1. Focus. If you don’t stand against something, you don’t stand for anything. So say no a lot.
    2. Don’t lie to yourself. Complexity is a great way to lie. So are guesses that are communicated.
    3. Get feedback fast.
    4. Always have a plan; never stick to it.
    5. Decide. Options are good; unmade decision are not open options – they cut off options. Keeping multiple options open requires seeing them and deciding, now, when you will choose which to excercise, and on what basis.

    Everything else is just an implementation detail. And all implementations are complexity, which, by rule two, we strive to eliminate. To enhance Kanban, find a way to strip a part out of it; don’t find something to add.

    As Ohno said “Kanban is not something to be proud of. Kanban is something to be gotten rid of.”

  7. William Pietri:

    Hi, Arlo. Thanks for coming by.

    The reason I assumed you were not using this approach in a startup context is that startups, being very capital-constrained in the early days, are extremely sensitive to cost. In that context, estimation is not necessarily waste. From the product management perspective, having some idea of the cost is valuable. From the end-user or investor perspective, estimation is of course waste, but it can be a small waste that prevents a larger waste of working on lower-ROI choices.

    I share your bias for simplification, and I encourage you to document your “Detective’s Blackboard” notion so I can see how it works. It sounds interesting. I also am in favor of the 5 points you name, and pursue them relentlessly.

    However, in this case I have not yet found a simpler system that solves the problem that I consider key: properly managing technical debt in a way that the natural behaviors of team members doesn’t result in out-of-control code bases. XP handles this well enough for relatively stable systems: one just never takes on technical debt. In startups, this leads to waste: some code doesn’t live long enough to make XP’s practices worth it. Ergo the split between two flows: sustained and short-lived.

Clicky Web Analytics