————————–
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
Subscribe via RSS | Lean Blog Main Page | Podcast | Twitter @markgraban
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
You may be interested in a new book, Measuring and Improving Performance: Information Technology Applications in Lean Systems by James William Martin.
This book details how to apply Lean principles to IT systems on a global scale. It also covers several project management methods including agile project management, agile unified process, SCRUM, and extreme programming.
Available at http://www.productivitypress.com/shopping_cart/products/product_detail.asp?sku=AU4186&isbn=9781420084184&parent_id=&pc=.
Thank you for the recommendation. I will take a look. I am also a fan of Mary Poppendieck's books, blog and work on the topic.
I, too, am excited about the using Kanban and limiting WIP in software development.
That said, I have a couple of reservations about the way this has been applied and adopted in the software development community. Note that these reservations are not about Kanban itself in software development, but about typical practices that I think are problematic, and could be improved.
First, the unit that is typically pulled is the user story. While this is arguably the right unit for development work, I think it is very wrong from the perspective of the ultimate customer. Something like scenarios in Behavior Driven Development are much more appropriate for the customer. The scenarios could then be broken down into user stories for the dev team to pull.
Prioritization should also take place first at the level of scenarios.
In my experience, most customers find user stories too fragmented and alien — scenarios are much closer to how the customers actually describe their needs and goals.
(I have a similar complaint about features and Minimum Marketable Features — while customers will often talk about wanting a particular feature, focusing on features usually results in fragmented customer processes, and frustration when customers actually try to use the software to accomplish their goals.)
The goal of software really is to support customer value streams, so the unit of value and flow should bear a close relationship to those customer value streams. Scenarios are better than user stories from this perspective. (And there might be other units of value / flow that are better still…)
Second, I think it is a serious mistake to optimize the development subprocess in the value stream. This is really a suboptimization. In fact, this too-narrow scope probably accounts for the user-story focus of most Kanban dev teams.
If we look at the entire software product value stream, from customer concept to consumption, it may turn out to be very valuable for developers to take responsibility for customer support. This would give them a much deeper understanding of the customer, and enable them to create better software. (I also believe strongly in the value of exposing people to the consequences of their design choices.) It would also enable developers to more effectively collaborate with Marketing and the Product Champion in the early stages of defining customer value.
If we consider metrics, I think the Kanban teams are typically optimizing the wrong thing, both in terms of cycle time of a subprocess and in terms of the units of value that they are flowing.
I think we should be flowing scenarios (or something like that) and optimizing the value stream from concept to consumption, specifically including throughput time and customer support, both of which are typically neglected in the discussions of Kanban software development.
In my alternative approach, the resulting kanban system would have two levels: one for scenarios, and one for user stories. There would be a third kanban stream for customer support, and I would recommend assigning members of the dev team to this role on a rotating basis. The customer "order" would be a complete scenario, and the user stories would be the components of the scenario which need to be coded and assembled.
Quality and customer satisfaction could also be better measured based on scenarios and support needs.
Regards,
Alina
Alina,
You have a number of topics that I am looking at addressing. I need to follow up with a longer reply shortly.
To your point about suboptimization in current kanban approaches I believe that characterization is fair. When you combine this with the issue of connecting developers more closely to the consumer, there are a number of ways to address this-and the notion of rapid cycling to the customer and reducing WIP along the entire chain is a key place to start.
Your idea of breaking out the specifications is excellent and speaks to the differntiating beteeen a macro planning backlog and a detailed work list (if I read you right). And the approach of focusing on MMF is one that has to be measured against the health of the product and supporting infrastructure.
I will be focusing on many of these issues in the coming weeks. I am also available on twitter as 'stevehebert'.
-steve