My son is a linguist-in-training; he tells me that “semantics” is the study of the meaning of words. I guess that’s why I find it funny when someone says, “You’re just arguing semantics”. Really? If you are not arguing about ideas and what they mean, then what else would you argue?
When you work in an industry where ideas are evolving and changing, it’s interesting to watch how existing or new words get introduced to describe these new ideas. We have all seen that this can happen for a variety of reasons – sometimes the ideas are truly new and more useful than the old ones and therefore you need a new lexicon to describe them. Other times it is just rebranding or co-opting of existing ideas for the purpose of trying to create distinction and demand in the marketplace.
Oliver Kelley Farm - Anoka, MN
I’ve been watching this happen as the notions of Lean and Kanban first introduced in the context of manufacturing are now getting reapplied to the domain of software development. Given my focus on operations management in MBA school, I feel like I got a decent grasp of these concepts and how they are applied, and I can understand the allure of the analogy. The principles of Lean cross over very well to software development and I’ve been making comparisons for some time now and I would describe Agile as an appropriate application of Lean principles to software development.
BUT (you knew that was coming, didn’t you), given my understanding of what Kanban is in the manufacturing realm, I find that term not only dangerous to apply to our domain, but in a sense it’s just plain wrong.
There is an idea behind Kanban that is very powerful if not disruptive, in operational systems. It’s a simple pull-replenishment system in which the request for one unit of output sets up a chain reaction that triggers pulling your needed sub-components from nearby until that stock location needs replenishment. The “kanban” was the card used to trigger the replenishment through a very simple signalling system.
Behind that simple idea is a very powerful implication – if your source for replenishment can give you a fast response time and never run out, then you can run your manufacturing system with much less planning and much less work in process and inventory while actually increasing throughput in the system.
You can realize that same goal in a software development organization – Agile is about identifying and eliminating process bottlenecks and accomplishing that same kind of reduction in work in process in your development organization. You build only what your customers really need by reacting quickly to their demand signals. The analogy this far is great, but this is where they start to lose me.
As mentioned earlier, Kanban is a means for signalling that a downstream dependent process step needs something, and the idea is that when this signal arrives it would get produced or replenished “just in time”. It establishes a continuous flow of subcomponents into final products. Software development does contain dependent process steps, and I can see the attraction to the idea that the movement of work through concept, design, coding, and testing should just flow freely upstream until the team has everything it needs to do the work.
BUT (here’s where I explain my concern) the challenge is that shipping software always requires the convergence of many parallel paths to a moment in time. There is always a need for “ship mode”, always a need for a collective push that leads to the pinnacle of the project. I know that in principle that happens at the end of every Sprint, but in practice there are usually special activities associated with shipping a product, the least of which is coordinating marketing, etc around the launch of that product to the market.
Now, I can imagine that there may be organizations where the either the gradual release of features makes sense (especially if they are internal) or that are willing to commit to delivering features that are off by default until they get revealed later by turning them on. I can also imagine a world where our product truly is DONE in every sense of the word every two weeks, but the closest we ever got is a three week delay to launch.
My second concern is that time-boxing is not only an important feature, it is the most important feature of Agile methodologies. Software projects are a gas – they always expand to fill (and slightly exceed) the available volume. Any idea can be improved, and refactoring can go on forever unless something like a deadline brings it to a stop. I know every engineer on the planet is convinced that this is the reason that they never get to build the perfect product, but time is not really the enemy. The real issue is economics – time is money, and there is limited money available for any software product. Sprints help snap us out of our collective concentration and to realize – oh yeah, we’re supposed to have something done now. We always have many paths to an acceptable solution – sprints help make sure we chose an economical one.
Finally, as much as I respect the industrial revolution, developing software remains a creative, human enterprise. A healthy team ebbs and flows, and no one can maintain a constant and unending flow of work. We need to form a collective vision, refine the ideas needed to deliver it, bear through the crisis point, and celebrate our success when it is done. High functioning teams are driven by this rhythm and it is part of what helps them remain together long enough to achieve that exceptional performance. Software development can learn from manufacturing, but it will never be manufacturing.
