Indeed, that gives us a formalised approach.

It still requires the discipline to put an experiment that has worked into the backlog in order to repay the debt. This is not immune to the pressures I outlined in the article above.

Kent Beck talked of how he went about writing JUnitMax, a commercial IDE plugin that continuously ran unit tests in the background. He didn’t write any tests for it in the first month because he wanted to get feedback from people as quickly as possible [1]. He, of course, had the discipline to go back to it later. He was also ‘the business’ and ‘the developer’ and had all the understanding necessary to generally make the right choice… sustainable or disposable.

When we were working on http://papyr.me, which is now on hold indefinitely [2], James Martin started out in much the same way as Kent Beck did. Everything we were doing was an experiment. He soon encountered a situation where progress on evolving an experiment became very difficult and this meant slowing down in order to speed up again by writing tests and refactoring because it was no longer safe to progress that experiment.

The problem that arises is when you want to add an experimental feature where the feedback needs you to evolve it again and again and again. Suddenly realise that it works the way your customers want it to. Should we then write tests and refactor it? Will the demand for the next experiment to evolve allow us to do this? This can be solved using continuous-rewriting [3] but there may come a point where having unit tests and well factored code will make each evolution faster and faster. So, having some guidance around when to have disposable experiments and when to have evolving experiments (where we write tests and refactor) would be useful for many. For me, if the experiment has resulted in feedback such that I’m evolving it, it should go through the sustainable ‘backlog’ route in the forked Kanban approach. If I have no basis for an idea then that would go down the disposable experiment route.

There is also the challenge of untangling experimental code from the core code. If, however, you have evolved a sustainable approach to feature toggling then this is much easier to do and will improve the speed at which you can migrate experimental code to become part of the product’s core or ditch the code altogether.

This all ignores the value of trying to express our understanding as tests which in itself can evolve our ideas or quickly highlight the gaps in our thinking.

The Forked Kanban approach is a nice way to visualise and distinguish between user stories that are a certain refinement to an existing product or a potentially disposable experiment. In XP this was done with ‘spike’ stories [4]. The only difference being that the code for a spike was often thrown away or retained temporarily for only for reference purposes. In Kent Beck’s story, he was essentially ‘spiking’ but actually released the code.

In a world where I have feature toggling I’d treat each user story as an experiment. I’d be more inclined to not have a fork and just place the experimental lane to the left so that there is a single, linear path. I might choose different wording…

| ideas / needs | developing | learning (active experiment) | removing / improving | review / accept |

I’d also want this to be supported by a continuous delivery pipeline.

I’d then make a judgement call on where I needed tests and where I should be refactoring in the earlier stages and, for any item that we decide to improve, agree higher expectations on tests and internal code quality.

In short, I can see the value of the forked Kanban approach. I think it doesn’t necessarily solve some of the problems I’ve outlined in the article but it does help the team see which things probably need a sustainable approach vs those things that can be treated as potentially disposable. Either way, to be most successful, it requires a fair amount of maturity in both the people and the tech.

How do you see the forked Kanban approach? (Given that a lot of time has passed since your comment)

[1] Kent Beck’s JUnitMax story: http://www.infoq.com/news/2009/06/test-or-not

[2] papyr.me – no more: http://on.papyr.me/post/32407029242/the-end

[3] Continuous Rewriting: http://www.citconf.com/wiki/index.php?title=Continuous_rewriting

[4] Spike solution: http://www.extremeprogramming.org/rules/spike.html