So, following the previous two days posts about driving variation out of bottlenecks and the relationship between Deming and Goldratt's approaches, let us now consider an example from an FDD project. Let's imagine that the bottleneck is software development, i.e. design and build in FDD-speak.

Our goal is to maximize the throughput of FDD Features [Coad 95 & 97 - Object Models] and to do this we must maximize the rate of Feature completion. How could we maximize the rate of Feature completion? We must seek to reduce the time between completion of Chief Programmer Work Packages (batches of Features) and increase the average Features per day or week. There are several things we could do...

(1) Improved Feature Analysis

By getting better at The Coad Method, we can improve our ability to analyze Features. Properly analyzed Features exhibit lower variability and map better to the object model and the design of the code. With better mapping to code, there is lower variability in the size of Features and the time they take to design and build. This improves the predictability for the lead time in a chief programmer work package and allows the batch size to be set appropriately.

(2) Better Time Management

We can teach developers to better manage their time, or introduce rules to let them focus quality time on productive design and coding, such as "no email before noon". This will reduce the lead time for chief programmer work packages and increase productivity. Better time management will lead to more reliable effort expended and reduce variability of throughput.

(3) Single Project Tasking

We can insure that developers single-task on one project and preferrably on a single chief programmer work package within that project. This helps them to optimize time management and focus on minimizing lead time for that work package.

(4) Quality Assurance Measures

We can enforce design and code reviews and unit testing techniques. In fact, 100% coverage for reviews and unit tests is mandated in the FDD presecription. By reducing rework caused by poor initial quality, this reduces variation in throughput. In addition, the prescribed design techniques using Coad Method object modeling and UML sequence diagrams for each Feature design reduce the variability in design techniques and increase the reliability of the solution.

These first four pay the highest dividends as they directly address the main variable - rate of Feature production. It's no accident then that the Coad Method and its evolution Feature Driven Development focused on (1), (2) and (4) and that the SEI's PSP/TSP methods focus on (2), (3) and (4).

(5) Limiting Work-In-Process Inventory

We could use a Kanban-style system to limit the size of work-in-process, preventing new Features from being started without completion of others, even if those others are blocked with issues logged. Note, this would provide the equivalent of "pulling the chain" or "stopping the line" in a Lean/Toyota-style manufacturing line. The Kanban system would limit WIP and force quick root cause analysis and resolution of issues. Limiting WIP has been shown to be directly related to lead time. My own work published in several papers last year showed that I have empirically observed that Little's Law holds for software engineering.

The SEI has objective data that shows that lead time correlates to software quality - in terms of inserted defects. My empirical observation with FDD projects would reinforce this. Small batches with short lead times correlate to higher initial quality.

Hence, limiting WIP has a secondary effect on variation in the constraint - it reduces rework caused by poor initial quality. We can see from this that a Kanban system for software engineering has some value but is definitely secondary to improved techniques in requirements analysis, time management, initial quality assurance and pride-of-workmanship and dedicated single project resourcing. For this reason, introducing a Kanban-style system in Visual Studio Team System is not a priority for me.