An Alternative Recipe for Success

Posted on September 05, 2008 by admin

My long time colleague and collaborator Daniel Vacanti does not blog. He occasionally writes stuff down and some of that might even get published one day, but he doesn't blog. So I'm going to blog for him today...

Dan has his own alternative to my Recipe for Success. I thought it might be interesting to list Dan's four hot points and then add some commentary.

  1. Break work down in to small fine-grained similarly sized elements
  2. Prioritize
  3. Emphasize quality throughout the lifecycle
  4. Make frequent incremental releases to production

Number 1 requires that each work item is independently testable and preferably independently deployable

Number 4 requires the use of latent code patterns (assuming a single code line is being maintained in a continuous integration fashion) to prevent code that isn't ready for release from escaping in to the wild accidentally. It also requires that latency is added to the test suite as a standard part of testing prior to release. Test the functionality being released and test the latency of the functionality that is complete but not being released.[Why does this happen? Well completed functionality may belong to a different project with a different release schedule but may be living in the same code base and environment. This is more likely to occur in an enterprise environment than a product or service company.]

Comparison and Commentary

Breaking work down to small fine-grained similarly sized elements has been a core part of Feature-Driven Development (FDD) since the days when it was still known as the The Coad Method (circa 1995). I made this a key tenet of the message in my book. So why did I drop it from the Recipe for Success? The recipe was originally called "low hanging fruit" and was supposed to highlight 4 things that a new manager could do to quickly generate improvement in a dysfunctional team or project. I've been under pressure (from commentators on this blog) to add a fifth element to my recipe, stating that reducing variability in the process is also important. The notion that we break work down to small fine-grained similarly sized elements is precisely the same idea. It's a low variability play.

I didn't include reducing variation in the Recipe because in my opinion it is hard to do and meets with a huge resistance. It asks people to heavily change their behavior in such a way that they don't comprehend the benefit. My belief is that while a team gets on with the 4 steps in my recipe, they will eventually realize that they have to reduce variability. In other words, reduction of variability is a higher maturity activity. No coincidence, in my opinion, that the same idea appears at CMMI level 4. A High Maturity level in CMMI.

Dan's view can be made to work through strong management and enforcement through positional power. The team can acquiesce or move elsewhere. While this can have tactical advantages, I'm on record several times since August 2006 stating why I don't believe in using position power like this. Acquiescence is not conducive to institutionalization and long term adoption of an approach. Hence, I believe that you fix other things first and let variability reduce over time.

Dan includes prioritization and he puts it at number 2 while I had it at number 4. Again, my reason for this is that it is hard and it requires the collaboration of people from other departments outside engineering. Of the low hanging fruit, it is the highest placed and hardest to obtain. Hence, while Dan and I are in agreement, I feel that some basic organizational maturity is required before prioritization can be done successfully.

We're in complete agreement over quality. As Robert C. Martin said in his after dinner speech at Agile 2008, "The jury is in on this one!"

Finally, Dan suggests that frequent incremental releases to production are key. And yes they are! So why doesn't it appear in my recipe? Well I like Dan making it explicit. The notion that your reduce (or limit) work-in-progress appears at number 2 in my list. You can't achieve this without being capable of making frequent incremental releases to production. However, as I said, I like that Dan makes it explicit. It was explicit in the Principles Behind the Manifesto and it still should be.

So Dan's recipe and mine are not so different. The order and emphasis is a little different. Dan wants to focus on reducing variability. If it were in my recipe, it would be number 5. We agree on quality, small amounts of work-in-progress released to production often and prioritization. The one thing Dan misses from my recipe is balancing demand against throughput. This is the mechanism I use to achieve sustainable pace and to implement a pull system which provides a nice mechanism for simple prioritization. Prioritizing becomes easier when you have demand balanced against throughput of work items.

Combing Ideas

So if we combine Dan's recipe with mine, we'd get something like this...

  1. Focus on Quality Throughout the Lifecycle
  2. Reduce (or limit) Work-in-Progress and Release it to Production Frequently
  3. Balance Demand against Throughput
  4. Prioritize
  5. Reduce Variability in the Process by analyzing work items in to small, fine-grained, similarly sized elements that are independently testable and deployable

:-D It won't fit on a T-Shirt quite so readily ;-)