The Standish Group’s Chaos report, first released in 1994, was a ‘burning platform’ for software development practitioners the world over. Software Development projects, predominantly managed using methodologies that were optimised for more predictable problems, were consistently demonstrating unacceptable failure rates and delivering unused features.
It was patently clear that something had to change and in the ensuing years a number of methods such as Scrum, XP, Crystal, DSDM, BDD and FDD emerged resulting in the creation of the Agile Manifesto in 2001.
A brief history of product development
In 1970 Winston Royce wrote his famous paper “Managing the Development of Large Software Systems” that gave birth to the ‘Waterfall method’, an imperfect child that Royce himself never wanted. Directly below his famous diagram were the words “I believe in this concept, but the implementation above is risky and invites failure”. In true human fashion, we looked at the picture but not the words, and pressed on.
The waterfall method, while flawed, managed to deliver some pretty amazing things. We owe a lot of our critical finance and telecoms systems to SDLC projects delivered by true heroes; some of the core systems I’ve worked on are older than me (and arguably more complex). However, the world has changed.
In the 70s and 80s we were developing software to automate or augment internal business processes. We used rich client applications and part of every project was a detailed training plan to help our internal users to adopt the new technology. In the 1990s the internet came along and changed everything.
Suddenly we were developing software for customers that we may never talk to. Our software had to work, and it had to work in a way that was intuitive and immediately accessible.
Just as we were scrambling to find ways to insert ideas like User Centric Design into our traditional processes, the world changed again. App stores, Facebook and Twitter gave garage companies the ability to reach millions of customers, literally within months.
Startups began disrupting large incumbents and scaling began to be seen as a burden rather than an advantage in some industries. The ability not only to release products quickly, but also to learn and adapt from customer feedback, became paramount.
Since then, agile methods have grown in popularity and as an industry we have started to see the benefits of working in smaller batches and using methods that are more responsive to change. However, it is fair to say that adapting agile methods to work effectively in large, complex IT environments is a work in progress.
Transforming product development with Kanban
If you’re doing product development with small teams and can identify a product owner who has been delegated authority, then a method like Scrum is probably a great fit for your team.
But outside of that context, e.g. if you have a large, complex delivery factory with lots of moving parts, it is prudent to ensure that you’re taking a scientific approach and that you have empirical evidence that the changes you are making are actually driving improvement.
This doesn’t imply that Scrum or nexus or SAFe or LeSS won’t work, rather that you need to be able to prove that they actually do. Agile methods have been proven in a limited set of contexts through empirical evidence rather than hard facts.
Kanban wraps around your current processes and, with the right discipline, can provide an evidence base from which to drive process optimisation. The place where you end up might look like agile, but equally it might look like something completely different.
Introduction to Kanban methodology
Kanban has its origins in Lean and was adapted for software development by David J Anderson in 2004. David tells the story of when he attended the Imperial Palace Gardens in Tokyo and was given a token at the gate, which he had to return when he completed his visit.
He enquired as to the reason behind the tokens and discovered that they were used to limit the number of visitors at any one time – i.e. there was a finite number of tokens which matched the visitor limit for the park. Kanban cards (as distinct from Kanban boards) are used in the Toyota Production System to ensure that upstream activity is matched to downstream capacity, maximizing flow.
Kanban is not really a member of the ‘agile’ family at all, rather it is an evolutionary approach to managing knowledge work that borrows heavily from Lean principles (particularly the work of Don Reinhertsen). It is an approach that relies heavily on metrics and is based on the assumption that every context is different and hence the optimal approach will be unique.
Can Kanban and agile methods co-exist? Sure, providing that you are comfortable with evolving your chosen agile method to make it optimal for your organisational context.
Is Kanban limited to software development? Not at all. Kanban can work from strategy through to execution, from development through to lifecycle management.
You can create a Kanban system for an individual (Personal Kanban), for an existing team that is struggling with its workload, for a specific phase of a product development lifecycle or for an entire product development function.
Kanban as part of the product development system
Kanban systems can be independent, or they can be part of a system of systems. Kanban also supports Portfolio Management, Project and Capacity Planning, and Enterprise Services.
Unlike other methods Kanban creates impetus for evolutionary change rather than imposing revolutionary change on the team. We capture metrics that demonstrate things like:
- How long does it take for a piece of work to move through our delivery process?
- What percentage of time is a piece of work being ‘worked on’ rather than sitting around waiting for someone to pick it up?
- How much work is in process at any one time (and hence how much context switching cost are we wearing)?
- What is the likelihood that we will deliver a certain feature by a certain date?
We then provide the team with tools that they need to optimise those metrics, while also keeping an eye on the other things that we have traditionally measured well (cost, quality, etc.). Have a look at Marcio Sete’s series of blogs “Project Management Anonymous” for a demonstration of a kanban system in the wild (see ‘Further reading’ below).
Marcio Sete and I recently visited Bangalore, India, to obtain Kanban Trainer Certification from David J Anderson and the Lean Kanban University (LKU). We had a great trip, successfully navigating Indian street cuisine without the forewarned consequences, attending Ganesh Chartuthi – a celebration of the elephant headed son of Shiva, meeting a bunch of interesting people from all over the globe, and learning a great deal about Kanban in the process.
Further Reading:
Project Manager Anonymous: Collaborate to win
