[1] http://danielwildt.wordpress.com/2011/05/18/spike-solutions-why-the-world-would-be-better-if-development-teams-use-this-as-a-default/

Thanks,
@dwildt

I would recommend that instead of adding additional states to your Kanban boards, you should simply define for a task the level of it’s completeness, or delivery model. Meaning, some features, tasks would be delivered half-baked just for the sake of the experiment, while others with a more solid knowledge will be delivered differently. I find this perspective very hard to manage across team, however, if you get it to work, you’ll start to see some great results.

Cheers,
Guy

Nice article.

Arlo,

I totally get where you are coming from.

For me, the goal of the startup is to create something of value as quickly as possible and with minimal cost / waste. In pursuit of this, visualization gives a startup team clarity and immediate direction. Options are made apparent and acted upon with maximum buy-in.

In a startup, the kanban can be the focal point to allow rapid ideation, prototyping and release. It can also be used to experiment, kill bad ideas, and evolve rapidly.

All kanban instances are temporal. They live, they provide value, they die off. Pre-alpha, alpha, beta, and beyond, the visual controls will change radically.

I think this is exactly what both of you are saying, in fact. So, in my mind, you are both in agreement.

Jim

I usually explain the last bucket as “validated” meaning, “knowing whether or not the story was a good idea in the first place.” If you capacity-constrain that bucket, you provide a strong incentive to bake-in validation activities (like A/B testing) into the story.

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.

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.”

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.

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.