Eight Steps Program to a Lean Mean Kanban Machine
Mark Haynes, https://dmarkhaynesconsulting.godaddysites.com/
Are you contemplating switching your Agile software development team from Scrum to Lean Kanban? The first step of recovery is to admit you have a problem.
Scrum Master: “Hi my name is Mark and I give boring Retrospectives”
Agile Coach: “Welcome to our Scrum therapy session, Mark. No one is here to judge. What seems to be the problem?”
Scrum Master: “Well we identified our issues from the last Sprint. We agree on a list of action items but most of our changes never seem to get done.”
Agile Coach: “You need to find a way to get the team to take ownership”.
Scrum Master: “Thanks a lot”.
Maybe it’s not your retro’s, maybe it’s your Framework. Is your team suffering from:
A focus on trivial changes rather than those of substance
User Stories that seem to consume the Sprint
Downtime due to Sprint scheduling constraints
User Stories clogging your IT arteries
Foundational Principle of Lean Kanban & Scrum
What exactly is involved with migrating from Scrum to a Lean Kanban, assuming an initial Scrum implementation? I have identified seven Foundational Principles common to both Scrum and Lean Kanban. This will be our starting point to identify those practices. Some will be very similar to both frameworks and need only a slight tweaking, others will requiring more extensive modification. Both Frameworks are very flexible concerning implementation. Lean Kanban is methodology agnostic and starts with the premise of working with existing practices.
1) Process Controls - Manage Workflows
If you are still using a Scrum Board then replace it with a Kanban board. If you already using a tool such as JIRA, or Azure DevOps then you already are using a Kanban board.
Modify your board to support your current development practices.
Set WIP limits to modify the amount of work performed in any column.
WIP limits act as a governor to control the flow of work through the Kanban board.
Limiting the number of pending requests makes the process more sensitive and reveals inefficiencies.
When you see a build-up of User Stories in a column it represents unprocessed inventory, which is a form of waste. The behavior being modified is the tendency of a team to take on too much work simultaneously.
2) More Process Controls - Create a Pull System
The next step is to add a replenishment mechanism to your visual inventory management process
Each activity needs a corresponding “Done” column
Finished work from every process activity (i.e. Development, or Testing) is moved to its corresponding “Done” column
A signal is created that indicateswork’s available to be “pulled” to the next activity
This creates a true Kanban board, with message cards that trigger replenishment
3) Even More Process Controls – Agile Requirements Management
Do you feel triggered yet? Now that you have come this far, let’s go a bit farther. How do you manage your requirements? Does any of the following sound familiar?
1) Product Owner pulls an all-nighter to get ready for Sprint Planning?
2) Product Backlog suffers from excessive inventory build-up, or not enough inventory.
3) User Stories are incomplete or poorly written.
Typically Scrum has only two Backlogs:
The Product Backlog, which contains every User Story, and
The Sprint Backlog, which is the Sprint’s TO DO list.
Consider what stages a User Story goes through before they are pulled, to work on.
I recommend you create a 2nd Kanban board to manage User Stories. You could do it with one but it might get unwieldy. Your goal is to create Just enough Requirements to satisfy the immediate “Pull” of the developers. Let’s consider what the life cycle of the User Story Requirements definition might be.
Elicitation – Gather a list of requirements from Stakeholders and deliver them to the Product Backlog for assessment. Conduct User Story mapping, create a Road-map and establish Project Milestones. User Stories might only contain a name and a brief description. Epics are often created at this point.
Elaboration - Epic are turned into User Stories. User Story details are fleshed out with additional details. The majority of User Story enhancement is performed at this stage. Please note that the conversational aspect of the User Story is still an ongoing activity.
Validation – Requirements are verified for completeness, testability, conflicts, and ambiguity.
Acceptance - Requirements are accepted by the stakeholders for use. In Scrum, they are ready for Sprint Planning.
4) Team Dynamics – self-organizing and collaborative
If you are Scrum and re-aligning your team to be Lean Kanban consider re-assessing the three primary roles of Scrum. The focus on team dynamics is similar. Scrum has a team orientation dynamic and Lean Kanban starts with the team and flows outward to embrace the entire organization. Although the Scrum Master and Product Owner aren’t roles specified in Lean Kanban their existence is not excluded. You may find that as with Scrum they serve a useful purpose.
Monitors the work queue for blockages, dependencies, and inefficiencies
Identifies opportunities to eliminate waste
Ensures there are adequate visual controls in place
Identifies the natural work relationships with internal and external team members and helps implement synergies and the efficient flow of work
Provides leadership to the team, often with their knowledge about implementing the framework
Views User Stories from a life cycle perspective
Ensures that each developer has just enough inventory to work upon
As with both frameworks:
A single point of contact with the business users and customers
Coordinates building project Milestones and the Road-map
Helps to assess how well the users or clients are being served by functional changes
This role doesn’t change that much
They pull only one User Story at a time
They take ownership of their work
They become the first line of support in the pursuit of quality
5) Are you Doing Useful Work?
Useful work consumes resources that create value for the customer. Useful work is customer-focused, value-based, and prioritized. Consider modifying or adding a few additional ceremonies.
Kanban Meeting - The Daily Stand-up becomes the Daily Kanban meeting. Focus on stalled work items, the day ahead, and the immediate future.
Service Delivery Review (bi-weekly) – The purpose is to understand how well the client is being served by the team’s output.
Replenishment Meeting (weekly) – Similar to Sprint Planning, in that tasks are selected for the backlog.
6) Philosophy of Continuous Improvement
At the heart of both Scrum and Lean Kanban is the Deming Cycle. The PDSA Cycle (Plan-Do-Study-Act) is a systematic process for gaining knowledge for the continual improvement of products, processes, or services. In that sense, both frameworks attempt to accomplish the same thing. A Lean Kanban focus needs to expand on the quality feedback mechanisms to improve quality, determine how well the client was served by the team’s output, improve overall operations and determine what factors put the work delivery at risk. Consider expanding the scope of current ceremonies or including several new ones:
Retrospectives (bi-weekly) – focus on reducing waste and improving quality
Operations Review (monthly) – reviews the big picture to determine how to improve efficiencies
Quality Circles - enlists employees in solving problems related to their jobs
Risk Review (monthly) – examines factors that put work delivery at risk
7) Make all policies explicit
The team needs to embrace transparency. An open work environment should be central to both Scrum and Lean Kanban. Ceremonies need to be open to an extended audience. Team agreements should be publicly displayed. If a Team Charter doesn’t exist then make sure any teaming agreement such as Definitions of Ready & Done is widely shared, especially with Stakeholders and management. Publicly display the team’s performance metrics as well.
8) Shippable Products
Does your release package have User Stories that must be released together? Has your Sprint’s User Stories morphed into batched inventory? These behaviors will bog down your board with unshipped inventory and clog up your delivery pipeline.
In Scrum, a Potentially Shippable Product Increment means that the User Stories of each Sprint can be released to production. If you have a release date, a better practice is to make sure each User Story is independently shippable and ship them.
Continuous integration (CI) and continuous delivery (CD) is a set of operating principles and practices that enable a team to deliver changes more frequently and reliably. It’s often called the CI/CD pipeline.
What’s stopping you from building a CI/CD pipeline and release User Stories each day:
Your technology stack – that’s solvable
User Stories are too big – that’s an issue that needs addressing by your Kanban or Scrum team
The architecture of your codebase doesn’t permit you to back out a single User Story from Production. You might have some refactoring to do!
Scrum is Sprint bound. Metrics focus on aggregate measures of throughput, such as Velocity and Burn-down/Burn-up charts. Lean Kanban has a focus on the continuous flow of work through a queue. Many metrics are specific to the behavior of User Stories, such as Lead time and Cycle time.
You can keep your Scrum metrics if you must but make sure you add a few of the following:
Lead Time – The lead time starts from the moment a new task is requested and ends when it’s done.
Cycle Time – The cycle begins when someone starts working on a given assignment and ends when it's finished.
Throughput – Throughput is the number of tasks finished per time unit.
Work in Progress – Work items that are in progress but not finished yet.
There are a host of metrics out there to consider. Be selective. At a minimum, you should consider those that help provide feedback for process improvements. Remember the primary purpose of Agile metrics is to improve the process not to torture your development team.
What, Me Worry!
Why don’t Scrum teams become more Lean, naturally? Building small, independent User Stories seems to be a fairly obvious practice. It reduces complexity, dependencies, wait time for unexpected problems, and uses resources more efficiently. I think it's a question of focus. Once Scrum team's become comfortable in their work habits, helping them simplify and decouple User Stories can appear to be an academic argument. Attitudes start shifting, to focus upon Sprint-specific activities and not the flow of work. When tracking aggregate measures such as Velocity or Burn-down charts there is a tendency to overlook why a specific User Story caused inefficiencies in the flow.
Put that in your Pipeline and Smoke it
The Project Management Body of Knowledge teaches us to manage schedules, effort hours, and sizing. Scrum does something similar, it focuses us on Sprint length, effort hours, and Story Points. Lean Kanban doesn’t. Think about what happens when a User Story approaches a minimal size, say one Story Point, a minimal amount of effort hours, say 4 hours and a minimal amount of scheduled activity, say ½ of a working day. They in effect all become the same thing. Why then make a distinction between them? Actually, why not just go with a CD/CI pipeline?
Are you considering implementing Scrum for the first time? Why not consider Lean Kanban instead. If your team is considering a few modifications ask how Lean Kanban can help? If you already are Lean Kanban then how well are you following the guiding principles and core practices mentioned above? My intention is not to provide the definitive description of Lean Kanban but rather touch-points you can refer to. Always go back to foundational principles.
You could very well argue that all of this can be done with Scrum. And that's true. Nothing special is being offered here. All this can be done with Waterfall or RUP as well. Maybe it’s time to become a Lean Mean Kanban machine.
The Kanban Method, The Kanban University, https://edu.kanban.university/kanban-method, David J Anderson
The Rhythm of Success: Kanban Meetings, Sonya Siderova, Nave https://getnave.com/blog/kanban-meetings/
The Seven Wastes in Manufacturing, David McBride, https://www.emsstrategies.com/dm090203article2.html
Related Kanban and Scrum articles
More Agile and Project Management Knowledge
This article was published in October 2021