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.

There are other cases that are trickier, and can’t be usefully analyzed purely in design terms. You have to look at the question in business terms, because in the end the decision to refactor properly or hack egregiously is a cost-benefit question, not a technical one.

In many projects, we can ignore the business side: revenues and costs are approximately stable, cash reserves are ample, the relationship between features and revenues is unclear, and both features and products are expected to live indefinitely. Given those factors, we can generally get away with only thinking in design terms.

For startups, though, none of those is true, which means we have to be more careful about when and how we indulge our preference for beautiful code.

I’d postulate that ideally, we just throw away the module with the code for that feature, and the rest of the code stays untouched.

For that to work, we need to refactor the whole system so that most of it doesn’t need to know a bit about multi-accounts. And those changes should be high-quality. Even when we throw away the feature, we still benefit from those refactorings, because the code improved in terms of SRP, SCP and OCP. We are likely to benefit from those changes in some way for future features, possibly in surprising ways.

I conclude that the quality of the one experimental module, that we can plug in and out on a whim, then might actually be of secondary concern.

What do you say?