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.

Scum Master

• 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

Product Owner

• 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

Developers

• 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!

Key Metrics

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?

Closing Thoughts

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.

References:

KainNexus blog https://www.planettogether.com/blog/the-four-principles-of-kanban

The Kanban Method, The Kanban University, https://edu.kanban.university/kanban-method, David J Anderson

Kanbanize, https://kanbanize.com/kanban-resources/kanban-analytics

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

Scrum with Kanban: How to Improve Your Sprints

Kanban for Skeptics

Making Your Culture Work with Agile, Kanban & Software Craftsmanship

Open Source Kanban Tools

More Agile and Project Management Knowledge

Scrum Expert

Project Management Planet

---

Click here to view the complete list of Methods & Tools articles

This article was published in October 2021