In Scrum, work is delivered to customers through a series of sprints in which project work is time boxed to a fixed number of days or weeks, usually 30 days. In lean software development, the goal is to deliver as soon as possible, permitting early feedback for the next iteration.
Both techniques stress the importance of workflow in which software work product does not accumulate in development awaiting release at some future date. Both permit new or refined requirements and feedback from QA and customers to be acted on with as little delay as possible based on priority.
A few years ago I heard a lecture where the speaker talked briefly about a family of concepts from industrial engineering called theory of constraints. In the factory, they use an operations model based on three components: drum, buffer, and rope. The drum synchronizes work product as it flows through the system. Buffers that protect the system by holding output from one stage as it waits to be consumed by the next. The rope pulls product from one work station to the next.
Historically, are these ideas part of the heritage of Scrum and Lean, or are they on a separate track?
It we wanted to think about Scrum and Lean in terms of drum-buffer-rope, what are the parts?
- Drum = {daily scrum meeting, monthly release)?
- Buffer = {burn down list, source control system)?
- Rope = { daily meeting, constant integration server, monthly releases}?
Industrial engineers define work flow in terms of different kinds of factories.
- I-Factories: straight pipeline. One input, one output.
- A-Factories: many inputs and one output.
- V-Factories: one input, many output products.
- T-Plants: many inputs, many outputs.
If it applies, what kind of factory is most like Scrum or Lean and why?
2
Agile is really just a set of principles (see here). Scrum is just one tool to try to adhere to those principles.
Another agile/lean tool which does rely heavily on theory of constraints in Kanban. Where one of the key points is to limit work in progress (WIP) in order to improve output (See here).
Its worth noting though that Kanban is only agile if you choose to use it that way, as its much less prescriptive of process then scrum is, and in theory could be implemented in a waterfall SDLC.
1
Lean, Kanban and Theory of Constraints originated on the industrial engineering world, but have been adapted to software engineering. For example, Kanban origin can be traced directly to Toyota. So I would simply call the relationship “Antecessors”
Most Agile methods in software have some roots in Lean, but there are a few based on TOC and Kanban too.
A few of us software engineers read “The Goal” back in the 90s, before Agile was a thing, and looked for ways to apply the principles. Personally, I had a hard time “seeing” it, and improved my development process to be quite Agile (in terms of results, and meeting the Agile manifesto even before 2001 when it was written); but I had trouble describing what was my bottleneck. I read later “Critical Chain”, but still was stuck on translating TOC to software.
Years later, I read “Agile Management”, which does a great job on explaining Scrum, XP and FDD (the latter a clear translation of TOC into software). Since then, I can see a connection, once you have a clear metric of delivery, and can apply TOC principles to Scrum practice.
But the current expert to follow on TOC for software is Clarke Ching, check his books “Rolling Rocks Downhill” and “The Bottleneck Rules”