The Dawn of a New Day in Software Development…
By Steve Hebert:
I have to say that I am excited about the prospect of Kanban in software development lately. I am so excited that I am moving back into the blogging space looking at this topic along with actual coding topics that I personally enjoy writing. With Kanban and the related shifts that are pending, the opportunity to change how we look at Lean Software Development in general and Agile practices in particular is very real and tangible. First, I'll take a cursory look at how Kanban and related systems are different from current methods, discuss how the supporting systems are fundamentally different and then discuss how Agile methods fit into the bigger picture.
First and foremost, Kanban is a pull-based planning method which is fundamental for lean because we now get away from pushing work through the development channel. Instead, work is done by pulling tasks through the development channel – developers work from a common work list, picking tasks as they complete work and driving the entire chain by this simple action. The notion of driving the chain by a common day-to-day task is what makes this so different and powerful at the same time.
To compare current methodologies, virtually all common software project planning methods including scrum are push-based planning methods. Being push-based is what drives scrum to be a somewhat arbitrarily time-boxed mechanism. From a Pull- perspective, time-boxing that is not an external business dependency lends itself to being a sub-optimization which leads to waste in terms of starting and stopping, mismatched time-frames due to estimation problems and a significant planning overhead on each iteration. Removing such a mechanism allows the process be adjustable ‘on-the-fly' and an adequate system gives all parties an accurate view into the state of process. In comparison, the end of an iteration in scrum is overloaded with four primary functions: review of completed work, planning for the next iteration, communication of that work plan and ultimately a heart-beating of the overall process. Pull-based lean systems view those four tasks as discrete entities that may be done with independent work flows – combining two or more of those at one time are ultimately driven by the business and project needs as opposed to the dictates of the mechanism.
Let's take one simple aspect of development and look at how it changes under a pull mechanism – specifications. As has long been understood since the days of XP and Agile, specifications are analogous to inventory – the longer they sit around, the more they depreciate in value. Therefore, calling out detailed specifications too early in the process is very costly. Likewise, calling out specifications too late in the process is very costly as people are sitting around waiting on them. Calling them out at the right time – neither too early nor a minute too soon is called ‘the last responsible moment.' How the team is made aware of when to call out a specification is one function of what is called ‘signaling' in a pull based system. Approaches to proper signaling include buffer management from a Theory of Constraints perspective. In other words – if you have ever called out dependency characteristics in a project plan, pull-based methods make them a living part of the system as opposed to an artifact that starts aging the moment you save it.
In addition to things like signaling mechanisms, pull-based systems give us the opportunity to introduce other Lean concepts like Theory of Constraints as mentioned earlier into the mix. While a key principle of Lean is cycling fast to the customer with minimal inventory, ToC states that any given system has a natural occurring constraint. One leaning in the ToC crowd is to view Development and QA as one – as a backlog of non-QA'd work is a massive cost-multiplier. Keep in mind that QA and Development in this context may not be how your organization views these disciplines. This is a topic for another day that deserves its own post.
So how do all these pieces fit together? If we move to the notion of cycling quickly to our customer, pull systems require that a high quality bar be continuously met and that workflow in a software development task are visible at all times. Without these capabilities, a fast cycling software project will collapse under its own weight – shortcuts taken on day 1 snowball into non-refactorable messes on day [n]. Therefore we can see the value that Agile practices bring to the table with things like effective stand-ups, well-directed TDD efforts and even integrated code review tools.
There are a ton of topics to discuss in this space that the community is just starting to hit upon – and to think that I haven't even mentioned Tom DeMarco's brilliant mea culpa yet. It feels to me like the stars are aligning for something very different in our profession if we avoid the marginalization of Lean practices in the software engineering space. Plenty of blogging lies ahead.
— Steve Hebert