In Part 1 and Part 2 of this series, we defined Scrum and Kanban, discussed how they are related to the word “agile” and compared / contrasted the two. Now, it’s time to decide which agile process to choose for your project and / or organization.
Agile is a philosophy that tends to take over and transform the organizations that embrace it. The method you choose to bring agile to life will go a long way toward determining whether that embrace is warm or at arm's length.
Adapting the Theory of Constraints for project management
It would be beneficial to deviate our discussion today away from Scrum and Kanban, and into some fundamental concepts which can directly or indirectly act as the foundation to improve processes and practices, including the aforementioned two. One of those concepts is “The Theory of Constraints” or TOC.
The TOC is a management paradigm that views systems that are straightforward to manage as limited in achieving most goals by a very small number of constraints. The assumption is that there is always at least one constraint, so the TOC uses a focusing process to identify constraints one by one, and then restructures the rest of the organization around each constraint, resolving it one by one.
The management philosophy was introduced by Eliyahu M. Goldratt in his 1984 book, The Goal. The underlying premise of the theory is that organizations can be measured and controlled by variations on three measures:
- Inventory: the money that the system has invested in purchasing things which it intends to sell;
- Operational expense: the money the system spends in order to turn inventory into throughput;
- Throughput: the rate at which the system generates money through sales.
After Goldratt adapted the concept of TOC into project management with his 1997 book the Critical Chain, he developed the application of theory for flow problems called “Drum-Buffer-Rope” (DBR). The bottleneck or constraint, acts as a “Drum” by setting the rhythm for the entire system. In Lean Manufacturing this is also called Tact Time. Whereas the “Rope” is a method by which the constraint can signal to the upstream processes (non-bottleneck processes) when to slow down, stop, or produce faster and by how much. This is called “Pull Scheduling” in Lean Manufacturing terms. In software, this can be implemented as a data structure called a Stack, with “Push” and “Pop” as the methods for pulling from the Stack.
Using a pull system at Microsoft
The details of Drum-Buffer-Rope are beyond the scope of this article, but generically speaking, Drum-Buffer-Rope is an example of a class solution known as pull systems. Kanban is an example of a pull system.
One of the purposes of pull systems is that they limit work-in-progress (WIP) to some agreed quantity, thus preventing workers from becoming overloaded. But at the “bottleneck” point all workers remain fully loaded.
David J. Anderson applied this idea to implement a solution while working at Microsoft in 2004 to improve the productivity for one of their software development processes. The pull system was implemented based on Microsoft Product Studio (a forerunner of the Team Foundation Server). In short, it was the Microsoft defect tracking system. There was no physical board available. The engineering team was offshore in Hyderabad, India. By implementing Drum-Buffer-Rope for this software development process, the productivity more than tripled and lead time shrank by 90 percent, while predictability improved by 98 percent.
But isn’t that what every manager of every organization wants?
Not exactly. First, let’s look more closely at what type of development process we’re talking about and what bottlenecks usually occur in software development.
The software engineering team at Microsoft had to perform day-to-day “track tickets” with development work coming from multiple teams (a. k. a. help desk/support model). This is probably the best candidate of all types of software development processes to try to improve on by using any pull system, because it closely resembles the assembly line paradigm.
Later, Anderson revisited the working implementation of DBR in favor of instead using Kanban, another pull system, and made a conclusion that both DBR and Kanban are equally effective.
Choosing a PMI framework that fits your organization
But what about other flavors of software development that most of us know about? Like business software development, for example? Or software development that deals with frequent changes in business requirements, changes in scope, budget, dealing with different teams and many other constraints? Would it be as efficient to implement Kanban and to expect a similar improvement in productivity, lead time, and predictability as it was done with the 2004 Microsoft pilot project?
It’s definitely possible, but not guaranteed. The reason is simple: all software development projects and their teams are different. Even organizations that may look alike are actually very different.
Teams have different:
- Skill Sets
- Levels of experience
- Levels of capability
Project have different…
- Risk profiles
Organizations have different…
- Value chains
- Target markets
A “one size fits all” development methodology simply doesn’t work. The reason being that EVERY project is different!
So which PMI framework will you choose for your next project?