- You shouldn’t assume the network is reliable. Erlang doesn’t have any special measure for that except detecting that something went wrong for you (although that’s not too bad as a feature)
- The network might be slow, from time to time. Erlang gives asynchronous mechanisms and knows about it, but you have to be careful so your application doesn’t go against this and ruin it.
- Bandwidth isn’t infinite. Small, descriptive messages help respect this.
- The network isn’t secure, and Erlang doesn’t have anything to offer by default for this.
- The topology of the network can change. No explicit assumption is made by Erlang, but you might make some about where things are and how they’re named.
- You (or your organization) only rarely fully control the structure of things. Parts of your system may be outdated, use different versions, be restarted or down when you don’t expect it.
- Transporting data has a costs. Again, small, short messages help.
- The network is heterogeneous. Not everything is the same, and data exchange should rely on well-documented formats.
The primary work unit for the team is the “minimum marketable feature”, or MMF. (…) As Arlo [Belshee] puts it, MMFs are “the smallest features we can sell.”
The team [only] works on the top MMF in the backlog queue until it’s done. They use simultaneous phases (…) MMFs are either in production (“done”), at the top of the backlog queue (“in progress”) or waiting.
The use of simultaneous phases is probably the biggest difference between Arlo’s approach and David Anderson’s. David Anderson doesn’t use simultaneous phases, so his MMF-equivalents have to travel through multiple stages. This mean that his team work on multiple MMFs at a time, which leads to a need for complex configuration management, and I’m sure it lengthens his cycle time.
There’s no estimating of tasks or MMFs in this approach. Instead, you use what Arlo calls “Disney Line Planning”: “Your wait from this point will be XXX days.” (…) Since MMFs can vary in size, this is a rough projection, not a commitment.
(…) the sign is not the most important part of the Kanban System. What Toyota was really trying to accomplish was “one-piece flow”. One-piece flow means manufacturing items one at a time rather than in batches.
That’s why I prefer Arlo’s approach to David Anderson’s. By using the Extreme Programming approach of simultaneous phases, everyone on the team works on one MMF and gets it done, then they work on the next. Work-in-progress inventory is reduced to the absolute, bare minimum: just one MMF. By doing this, we create flexibility, improve productivity, eliminate waste, increase throughput, and do all of the wonderful things that one-piece flow gets you.
In the field, I’ve seen Kanban work best in chaotic environments where upcoming features don’t have much in common. I don’t think it’s a coincidence that the initial examples of Kanban come from those sorts of environments. David Anderson’s team was responding to change requests. Arlo Belshee’s team worked in a start-up, where frequent, entrepreneurial shifts in direction are commonplace. One team I worked with used a Kanban system to respond to post-release change requests, but plans to switch back to iterations once they start planning their next release.
So, should your team use iterations or a Kanban system?
Here’s my criteria:
- If your team is new to Agile planning, use iterations.
- If you’re producing a new product or a significant new release of an existing product, use iterations.
- If you’re in an environment where the feature backlog is constantly in flux or hard to predict, particularly if you can release the software on a whim, try the Kanban system. Entrepreneurial environments, maintenance of mature products, and recent releases are all examples of environments with unpredictable backlogs. The Kanban system will convert that chaos into a smooth, constant flow.
TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System…
The challenge is to develop a learning organization that will find ways to reduce the number of kanban and thereby reduce and finally eliminate the inventory buffer.
Remember: the kanban is an organized system of inventory buffers and, according to Ohno, inventory is waste, whether it is in a push system or a pull system.
So kanban is something you strive to get rid of, not to be proud of.
is more important than capturing conversations
is more importante than automating conversations