How would you present Scrum (agile) and Kanban (lean) as building from a common principle? What is the common core of these methods? These questions were the topic of recent discussions with colleagues agile coaches Joakim Sundén and Marcus Hammarberg. Based on our reflections, I would like to propose – yet another – definition of agile/lean software development. Yes, a lot has already be written on that subject, yet I find it hard to get a simple and concise proposition that can quickly outline the relevance and significance of agile/lean methods to IT managers.
So, here is one minimalistic definition that cut straight to the core:
The goal of an agile or lean method is to minimize lead-times.
That’s it. Feel the whole power of the agile/lean space folded in a short sentence! Now that we have reached the core, let’s elaborate on how it ties to Scrum, Kanban and other methods.
First, why focusing on minimizing lead-time? Why not maximize throughput or quality? Focusing on lead-time will force you to continuously minimize the time it takes for a product, or service, to travel within the organization from idea to production (or cash as the Poppendieck coined it). It forces you to trim the whole organization to work effectively together and focus all energies on what is really important for success right now. Incidentally, it requires limiting the amount of work in progress in the organization and in each team so that the ongoing work can flow as quickly as possible. In other words, minimizing lead-times creates flexibility – some would say agility – that companies, private as well as public, depend upon to stay competitive (public organizations are expected to perform as well as private ones lets they be outsourced).
So, how would an agile/lean method minimize lead-time? An agile/lean method minimizes lead times by identifying and addressing problems as soon as possible. By not letting problems go unchecked, you gain the time it would take for you to fix those problems at a later stage, when they have become obvious and require a lot of effort.
Now, it is immediately apparent that a lot of communication is needed to identify and resolve those problems. As our focus is minimizing lead times, we want this communication to be as effective as possible, meaning that face-to-face, daily meetings with all involved parties are necessary. We want these meetings to be short, facilitated by big visual maps and charts giving the current status.
Ok, but what kind of problems are we discussing here? There are mainly two categories of problems when developing software: first the problems related to the product or service being developed (does it answer the needs of the customer/user? Are we building the right thing?), second the problems related to the way the product or service is being built (are we building it right?).
Identifying the first type – problems related to “building the right thing” – requires frequent feedback from the customer and users; demos or reviews established at a regular cadence is a good model. Addressing these problems require to be able to often change the scope of what is being worked on, allowing rework of certain parts of the product based on the given feedback; hence working iteratively and incrementally.
This constant feedback allows gaining time-to-market (thus lead-time) by producing the right product as soon as possible; even if the customer wasn’t aware of the exact qualities the product should have from the start. Moreover, by always focusing on producing the features with the highest value first, one can save time by “cutting the tail”; reaching a point during production where the most value-adding features are implemented so that one has a viable product and production can be stopped regardless on how many other features are left in the backlog.
Identifying the second type – problems related to “building it right” – is somewhat harder as it requires introspection, looking into ones own methodology. Identifying such problems is not easy – one gets easily used to the way things are usually done – so that is something that needs to be trained (using regular retrospective meetings, kaizen events, A3 reports, etc.). Yet, here is where most of the lead-time gains can be made.
As we have seen, to gain lead-time we want to discover all the bad news as early as possible. So, we want to build, integrate, function test, performance test, system test as soon as possible, and as often as possible. This may require extending the definition of done per team or to have several teams working concurrently on different aspects of the same product (for example, one team may be responsible for continuous integration, functional and performance tests of the work produced by several development teams). While doing so, we want to remove anything that is impeding our progress; the largest impediments often being an integrated part of the organization (the system).
So, expanding from the tightly packed proposed definition of agile/lean software development, we have just described a set of techniques and tools needed to minimize lead-times by addressing problems as soon as possible. Scrum and Kanban are examples of methods or frameworks that package such techniques and tools. Of course, you will need to use one or the other, or a combination of both, to succeed minimizing lead-times in your organization.
Minimizing lead-times is an endless endeavor: as soon as you have a part of the organization under control you will feel impelled to extend your agile/lean bubble up and down the value flow. Sooner or later, chasing lead-times will require the cooperation of everyone in the organization, all guided by a simple and tangible metric. Once you are there, well, you will have an organization that is finally ready to do some good work and you will realize that this was just the beginning.
