Throughout my career, I’ve encountered many teams that struggle to deliver products with adequate quality and efficiency. They’re overworked, missing targets, and customers are frustrated. The Product Managers on those teams were struggling – and they either didn’t know Kanban or if they did, weren’t apply it correctly.
Kanban offers guidelines and principles for how to manage the flow of work. Unlike the more prescriptive Scrum process, Kanban is applied based on your specific situation and helps alleviate bottlenecks and waste. You take the principles of Kanban and just do what works. You apply as you go.
My first experience with Kanban was 6+ years ago and I’ve been using it ever since. I’ve worked with over a dozen product teams & applied a hybrid of methods, and without a doubt, teams who employ Kanban principles deliver more efficiently and have less stress.
These teams work better together because they focus on their flow.
Do What Works. Apply as You Go.
Some background: Kanban translates to signboard/board in Japanese. The Kanban Method originated in the 1940s-50s when Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Toyota innovated in so many ways – with Just In Time manufacturing, the Toyota Production System, Kaizen, Kanban, and countless other practices that in due time made their way to the West. Japanese management training for the longest time regularly included the management principles and learnings from Toyota. Eventually, around the 80s this was brought to the West and evolved into what we know as Lean, Six Sigma (for manufacturing) and eventually, Kanban was adapted for technology companies by David J. Anderson in the early 2000s.
You can run another process (like scrum), and also apply the principles of Kanban at the same time.
Unlike Scrum’s iterative sprint-based approach, Kanban is about managing a continuous flow through your system. A simple flow could be three steps (new, doing, done) or more complex depending on what makes sense given the context of your service model. For example, your process might look like this:
Backlog > Triage > Selected > Dev > QA > Deploy > Done
Kanban’s goal for the team is to optimize the flow of work through the system to best support the goals of the business. Since I already knew Scrum, running Kanban and mixing the two has enabled me to apply more of a hybrid approach – since oftentimes at this point I could look to either method to choose a path forward that made good business sense.
What Kanban Brings.
- Increase measurable efficiency and productivity (increased throughput)
- Respond faster and more directly meet business demands
- Reduced overburden; executing at a sustainable pace
- Better team morale
- Better quality product and code; reduce defects and rework
- Establish a culture of continuous improvement
Some easy places to start.
If you manage a consistent flow of work from customers (enhancements, new requests, bugs), Kanban can be much easier to practice than Scrum. In Scrum, you may find yourself doing some of the following:
- Abandoning or breaking a sprint halfway through due to recently surfaced higher priority requests.
- Delaying high priority items for weeks/months, because it doesn’t fit your current iteration.
New and existing products can run Kanban – but those that are already live (most of us) often lend quite well to Kanban. Demand and priority of issues can fluctuate over time, and managing these prioritizes very closely at the time of entry into your system is advantageous over Scrum’s batched multi-week iterations (which you’d just have to break anyway).
The best way to start is slowly. Adapt and improve a current process by incorporating the five core principles below incrementally, as described in David J Anderson’s book Kanban: Successful Evolutionary Change for Your Technology Business.
Create an Emergent Set of Lean Behaviors with Kanban’s 5 Principles
Principle 1: Visualize Workflow. Your workflow should be visible to the team (hence ‘kanban board’). All of today’s modern ticketing systems support digital boards (Trello, JIRA, TFS, etc). Define your workflow and represent it on the board, and begin pulling tickets into progress.
Principle 2: Limit Your Work in Progress (WIP). Limiting work in progress reduces context switching, communication breakdowns, re-work, duplicate effort, meetings, and missed deadlines (efficiency++). Tickets can continue to be pulled in progress, but only the number of tickets equivalent to the agreed capacity of a system should be put in circulation. Once the agreed-upon capacity is reached, no additional tickets can be pulled to in progress until capacity becomes available.
Principle 3: Measure and Manage Your Flow. Metrics to consider tracking include Lead Time & Cycle Time, Work In Progress, Blockers, Throughput, Escape Defects, Aged Tickets, and times tickets are sent back to Development from Testing. Start basic – perhaps with a few key metrics and iterate. Start by understanding how well your team is performing by establishing a performance baseline and creating a low-effort process to track & report this regularly.
Principle 4: Make Process Policies Explicit. With your team, set standards to define and make clear what the expectations are for delivering work. Putting agreed standards in writing allows growing teams to ensure everyone is following the same process and following best practices. Apply change management practices and give team members a seat at the table.
Principle 5: Continuous Improvement. Use models to recognize improvement opportunities. After setting baseline standards, define a process to maintain said standards, identify improvements, and iterate. Kanban is about evolutionary change. As such, continuous improvement doesn’t mean you have to stop work completely or even slow down – it’s about making small iterative changes to make you, your team, and your organization better. Action Item: Read up on the Theory of Constraints & Kaizen.
Succeed with Kanban.
Kanban, nor any other Agile process for that matter, will guarantee success. Delivery is only part of what makes a successful product leader.
“There is nothing quite so useless as doing with great efficiency something that should not be done at all.” – Peter Drucker
Every team, product, and organization is different. The way we employ agile/management principles to our delivery process can and should be adjusted to fit each context.
The ability to drive efficient and effective Product Delivery is a required skill for successful Product Managers. Once you determine your vision, strategy, and decide what to build – learn to improve your execution with Kanban.