I don’t find anything to object to in the article, but I feel that a stronger argument can be made for Kanban than the supposed freedom from iterations.
Time-boxes Aren’t Scrum’s Impediments
The freedom-from-iterations argument sounds like treating a symptom. The iteration length should not be an obstacle to more frequent releases if those are important to users or customers. Demos at the end of a time-box (say, on Business Day 10 of a two-week sprint) are not the right time (too late) for a product owner to become aware of a completed feature and they are not for sort of acceptance tests to decide what’s shippable and what’s not. Suppose a feature is ready by Day 6, the product owner is aware and approves it. It’s the right feature, built right and it’s shippable. If it’s really important to ship it to the users the same day, the ops people can do it. They are part of the team, sit nearby and not in a different building, right? When Scrum is without “buts” (“we do Scrumbut, our PO is never around”), time-boxing shouldn’t hold it back. Scrum has a built-in retrospective process to get rid of “buts” holding teams back.
“We are constrained by Scrum’s time-boxed iterations, so we need to try the iteration-less Kanban process” is a weak argument. Kanban is a meta-method for improving other processes and its main strength is that it can bring many teams closer to their problems and understanding the science of their operations.
This is a class of problems faced by many software organizations. Take a feature that your paying customer wants, don’t take your eyes off it, and follow it from concept to cash (or from hypothesis to happiness, if you will). Now consider all your features. That’s your flow. That’s how software work behaves. (Some people don’t see it that way. They prefer to look at the org chart. But that doesn’t change the reality.)
Today’s reality for many in the software industry is that our work doesn’t flow very well. There are pools, back currents and even dams (often built by us because of our lack of understanding of flow). What we need to do is to understand how work flows in our context, study the flow and make improvements. This is exactly where the Kanban method comes in with its “improve collaboratively using models and the scientific method.”
What models and methods, you may ask. A short, incomplete answer is: Goldratt (qualitative), Reinertsen (quantitative) and Mary and Tom Poppendiecks’ lean principles as super-useful approximations. Consider the Theory of Constraints. When Goldratt’s Jonah asks Alex about quality control in his plant, he thinks about exploiting a bottleneck by inspecting parts before the NCX-10 gets them. That’s “building quality in.” Specification by example is an attempt to apply similar logic to software development. Check out Donald Reinertsen’s Principles of Product Development Flow. You can find many things in this book, among them charts quantifying what we approximate by using the principle of “deferring commitment.”
Distance Between Teams and Their Flow Problems
Consider one team. They didn’t do XP 10 years ago. They’re mainstream, maybe late adopters. You may have met a team like this one recently. They seem to be doing this:
If you were an XP pioneer or an early Agile adopter, there is something important in this picture that is not actually shown in it: the customer, standing pretty close to it on both sides. Your XP or Scrum framework may not say much about the economics of your product development flow, but the way you work and retrospect are aligned with the desired economic results reasonably well. This is not the case for the mainstream or late-adopting team in our example. But let’s zoom out and see what they’re actually doing:
This is a fairly typical case: a two-week iteration cycle, a quarterly release cadence, and the total cycle time through the whole value stream of more than one year. What is needed here is a dose of lean thinking. Kanban can deliver it and help this team get underway on their lean journey, understanding and studying their flow and finding solutions to their problems. And they may even decide to keep their iterations, or as we call them in Kanban, input, release, and retrospective cadences.
I totally agree that we shouldn’t throw the Scrum baby out with the bathwater. Dropping iterations is not a good reason to do so.