Theory of Constraints and Agile - book review

As with many people who like to read, my backlog of books grows faster than my reading of those book.  There are just too many interesting things - and I don't devote full days to reading (there's an idea!). 

The latest from the backlog is David Anderson's 2004 look at Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results.  I heard about this book through the TOC community when it first came out, but I wasn't doing much with software engineering at the time. Now that I've joined the cult-of-Kanban, which has some of its founding in his earlier work, I thought I would take a look.

One of the key quotes for me (and highlighted enough times that the Kindle notes it as a popular highlight) was in chapter 6 on the changes from "traditional" to Agile project management.

The project manager's new work is to assist the flow of value and the continuous generation of Throughput by maintaining the Issue Log and running down issues before the delay delivery date.

The best thing about this book from my perspective was the application of Theory of Constraints thinking to the problems people see in software engineering. Given the audience for this book, there was some necessary TOC background information that I found useful to read as it was written from a different perspective than many of the TOC books. What is the meaning of a constraint? What kinds of constraints might there be in software engineering? How can a manager think about Throughput, Operating Expense and Inventory (T, OE, and I) in a software development environment? These things don't commonly get measured, but there are stand-ins that can be of benefit. 

Anderson goes through many different software development methodologies and fits the TOC concepts into those of the methodology. I found it interesting that Anderson called out the differences in where the constraint resides - not all the methodologies agree, as they were developed for different reasons.  As a natural result, the actions taken within the methodologies represent different decisions around exploiting and subordinating the constraint. Equally, the definition of T, OE and I are somewhat different, as each methodology has a different set of measures. This was fascinating to read from the perspective of learning more about the development methodologies. It also felt somewhat repetitive after the first few of these chapters, so I admit to skimming many of the chapters in the middle portion of the book that go into the details of the methodologies and how they fit with TOC.

Chapters 12 and 13 had some interesting discussion of what managers should focus on creating and how important measures can become. The key for Anderson was around reducing lead time, rather than specifically focusing on increasing throughput of finished work. The flow of work should be guided by the flow at the constraint.  If you have excess capacity, find ways to do the things you do FASTER, so that you can react. This is at the heart of Agile.

I also found it interesting to see how the various influences mentioned in the book have a thread into the more recent work around Kanban in software engineering. I saw plenty of Reinertsen and Wheeler and plenty of references to the people who develop Agile and Scrum and the development methodologies. There was talk about chaos and complexity, but it was a little early to bring in the Cynefin framework that has been taken up by the Kanban / Agile community recently.  And it seems that Anderson's more recent work has taken the approach of helping create flow at the work front level - he hasn't been writing as much about portfolio - level management or even management of entire projects worth of work.  This book reflects the earlier approach of thinking in projects.

This book is a good set of reference material, both for thinking about Theory of Constraints in the context of software engineering, as well as for the thinking about how to make the translation between TOC and the various software development approaches.  There are plenty of people who are thinking about these topics still today - I see a few people from the Lean Agile mailing list talking about these things on a regular basis.

Some of my notes and highlights from the book, if you are curious for detail.  The other option, of course, is to buy the book.: 

• Love the Return on Investment in software calculation (Chapter 2): ROI = [T (unknown) - OE (pretty hard to guess)] / I (didn't bother to measure)
• "Establishing trust is the most important goal for any development manager." (Chapter 4)
• "Metrics should ideally be self-generating and should provide leading or predictive indication of the system performance rather than lagging or reactive performance [Reinertsen 1997, pp. 197–217]." at the lead in to Chapter 5.
• "Traditional software development metrics of lines of code written or time expended do not meet any of the ideal characteristics for system control metrics." (Chapter 5)
• I didn't know this: "Donald Reinertsen introduced the idea of using cumulative flow diagrams for design activities in Managing the Design Factory, p. 50." (Chapter 5)
• "All of this creates the rather uncomfortable conclusion that traditional project management is obsolete in the world of Agile software development. (Chapter 6)
• "There are no Throughput dollars associated with a useless and obviated requirement." (Chapter 18)
• "Perhaps the most important business benefit from Agile methods is the tendency toward a culture of continuous improvement. (Chapter 18)
• There was a great story about the impact of too much WIP in a section called "Idleness, Efficiency, and Growing Inventory Levels" in Chapter 19.
• Interesting idea about showing buffer status on a card wall in figure 22-7.  The challenge with doing this on paper is in synchronizing with the buffer system, which is why I suspect most people haven't done this integration. 
• A familiar statement about task estimates (in this case talking about "level of effort" estimates): "However, industry metrics suggest there is, at best, a 50% likelihood of hitting this estimate, even allowing for the fact that the estimate is accurate and the variance in an FDD system is low. (Chapter 23)
• Killer comment! Applies just about everywhere. "It is impossible to be Agile without some slack." (Chapter 23)
• Great discussion of "Morning Roll Call" or the morning stand up meeting. Anderson says it was initially for recovery, but that it was also helpful for education and self-help. (Chapter 23)
• "I would like to suggest a more expansive expression of agility. Not just that Agile methods are able to cope with change, but that they are particularly good at coping with a particular type of change—expedited requests." (Chapter 34)