(On relationships of Scrum,TOC, BPR, Systemsâ€™ Thinking, Knowledge Management, TQM, Complexity, Manufacturing, New Product Development, etc.)
Although there are great synergies between TOC and Scrum, there are also vast differences. Both provide patterns to resolve systemic problems akin to those described in Systemsâ€™ Thinking by Senge, but TOC resolves systemic problems that are more akin to process improvement ala TQM, rather than complete overhauls as in BPR, which I argue, is closer to what Scrum does â€“ it reengineers the process from scratch, by implementing high performance patterns altogether.
For the most part, TOC, and The Goal, assume a somewhat repeatable business process, where the process of removing constraints, exploiting constraints, finding new ones, etc.; is an ongoing process in a somewhat stable, repeatable process.
Scrum, on the other hand, generalizes this technique in the absence of a repeatable process, it simply removes *any* constraints constantly, with no assurance that the constraints removed will remain so the next day, and that the particular constraint optimized
â€œhas been removedâ€, and that we can move on to new ones at that point. It is usually the case, however.
Another important difference is that a Scrum team is already an organizational structure that avoids process anti-patterns like handoffs, iteration and re-work (among different organizational structures, between an â€œanalysisâ€ team and a â€œdesign teamâ€ for example, or between an organizational structure building component A, communicating with another one building component B, in a Conwayâ€™s Law configuration i.e. where Organization Follows Architecture.
In that sense, a Scrum team is a true â€œCase Teamâ€, as termed in Michael Hammerâ€™s BPR, i.e. an organization structure that is *completely responsible* for the success of a process or project, where the ScrumMaster is the â€œCase Manager* ala Hammer, that responds to the Product Owner.
From the Knowledge Management perspective, TOC optimizes the process and therefore, more knowledge of the processes themselves are more valued, while in the Scrum (Case Team) perspective, the individual contributorâ€™s knowledge is more valued.
On the other, and to make things slightly more complicated, Scrum sits atop a number of processes, that as more applications of the same kind are built, tend to be more repeatable, like configuration management, testing of certain components, vertical slice development or new applications on top of reusable architectural services.
The interesting thing to note, is that in Scrum, smaller reusable processes develop underneath as a base of knowledge but they donâ€™t drive development, while the Scrum process, acts as a â€œwork generator/work managementâ€ â€œprocess envelopeâ€ (a superprocess, or meta-process, if you prefer), that drives the work. (In Complexity terms, it is the Maxwell Demon that provides the autocatalytic cycles to drive self-organization, ala Kaufmanâ€™s â€œOrigins of Orderâ€.
Curiously, manufacturing is turning more and more to the original BPR patterns to build things. However, New Product Development always requires one meta-level more of work organization to handle the variability of â€œbuilding something new every timeâ€. In software development this difference evolves into a more continuum spectrum. The first application in a domain is New Product development, but as new ones get added, only a percentage is New Product development, the other percentage is more like manufacturing, and therefore more repeatable.
But donâ€™t worry â€“ no one needs to understand all the above gibberish for Scrum to work. On the other hand, it is nice to understand these things to properly understand Scrum in the context of other management techniques,
- Mike Beedle