Reblog

Naked Planning

Most important learning this week is Arlo Belshee - Naked Planning from the Agile Toolkit series. It’s a fact: this guy officially does crazy stuff! And there are only two ways to follow his work: conferences or podcasts. Considering the podcasts are recorded during the conference that means you can hear from him once every two years or so. I remember his past revolutions like “promiscuous pairing” and the “least qualified implementor” but the current one is about “naked planning”.
Main facts: the user story length is bigger around 5-15 days or work and the perceived execution time from when it enters the queue (basically the board with all the other MMF) is up to 45-60 days. The user story is prioritized by value not by cost (that means no estimates). It’s called “minimal marketable feature” (MMF) and it’s different from a user story because it must be releasable in isolation. Releases happen as soon as the MMF is ready (no release planning). There is an iteration but is just a container for retrospectives with no planning game. When the MMF is in progress, the team discuss the design potentially splitting in sub-tasks or doing whatever is needed to complete the MMF, again with no estimates.
Another opinion expressed by Arlo in the podcast (not connected with naked planning) is that the maintenance cost of acceptance tests is too high. His suggestion is to use acceptances to drive unit testing and then throw them away. Pretty wild uh?
I had some thinking about this approach. Naked Planning is based on strong assumptions. The customer must be able to understand and to produce minimal marketable features. The customer must also be trained to take business decisions independently from the cost of implementing the MMF. As a developer I like the fact that I fight against complexity and time to maintain an estimate and I learn how to estimate better the next time. Micro-estimates like pomodoros are my daily game which is what makes me an happy programmer. How a developer feel considering the next 15 days working on the same feature? Arlo is not talking about what happens in the team when the MMF is in progress, but I suspect the pair creates and implicitly think of estimates.

Master Craftsman Teams - Uncle Bob… Here’s a flame-like post by Uncle Bob for the richness of ideas it contains. Perplexity: skipping higher CS education for a serious apprenticeship? Could be. But somehow higher education is important beside the actual subject of training. So why not learning physics, maths, chemistry or other high abstraction disciplines with the specific goal to move to computer science right after? I know a lot of successful examples of cross-discipline CS professionals and the success seems to depend on their ability to think “differently” than the subject of their studies. I think what Uncle Bob describes is doable but probably what is missing are those Master Programmers described in the post. There are just a few of them in my opinion, I don’t know if this is enough. Anyway, I aspire to be a Master Programmer one day. I changed my Linkedin tag line accordingly. :)

Ken Schwaber on Scrum at Google… Here’s the classic video about Scrum by Ken Schwaber. Three years have passed already but the talk is just actual as it used to be. I’m wondering how Scrum adoption at Google is doing after several years. Anyway, I liked the how Ken rendered the accumulation of technical debt using burn-down charts. First management asks to increase velocity to produce more value. The team reacts reducing quality and achieving the velocity increase. But the following sprints velocity decreases for the accumulation of technical debt although the team is always trading quality for speed. What they experience is a false perception of instant velocity while they fail to see the decrease of long-term velocity which is so much harder to fix. Amazing that Ken can explain whatever idea with a burn-chart :)

I Love Pair-Programming - Absolutely No Machete Juggling… At first I judged this experience report to be too naive. It’s instead a valuable article about the conversion of a cowboy coder into a quality-aware agile practices enthusiast. There are catch phrases and definitions to remember, like the experience of coding at the speed of light or the fact that “programmer man” is instead “technical debt man”. I don’t know if I ever was a programmer man: I probably suffered of the opposite problem of lacking of pragmatism and focus.

Legacy Code - David Heinemeier Hansson… I want to remember this podcast not for the content but for the speech capabilities of DHH. The content is actually very simple and can be summarized as: “legacy software is a personal opinion”. On top of this interesting concept DHH was able to create an entire speech. I’m amazed by the approach: a very simple catch phrase or concept and then, like in a mind-map, a set of corollary and consequences and for each one an simple explanation. I’ll be happy to be able to repeat the same approach in my talks: find out what the content is all about in just one sentence and draw from that sentence all the consequences. Is not necessary for the main topic to be a complex theory, just something simple that can potentially have many consequences and what are the most important of them. Just a dream… I don’t have of course the same eloquence.