How to implement Lean Kanban software development

By Adam Scott
Technology engineering

‎

There are plenty of reasons why you might be looking to implement Lean Kanban in your organisation. Maybe you’ve been inspired by Kanban in Action (a very accessible read), or even my own introduction to Lean Kanban software development, and you now want to put the theory into action. Maybe your boss wants to see ongoing improvements in your processes. 

Whatever your reasons, this post introduces two ways of getting started with Lean Kanban. First up, let’s start with STATIK, the most common way to get started with Kanban.

Introducing the STATIK approach to Lean Kanban

STATIK is an acronym for a ‘systems thinking approach to introducing Kanban' into an organisation. If you’re wondering what systems thinking means, this is basically a holistic approach to analysis that focuses on the way a system's constituent parts relate to each other, and how systems work over time and within the context of larger systems. 

This works by viewing the team doing the work as a ‘system’, and by treating the work they do as a ‘service’ for other teams or systems. So, before you can get going with a STATIK approach to Lean Kanban, you need to identify the ‘services’ you’ll be analysing. 

Then, for each ‘service’ in your organisation, you’ll need to follow the below steps sequentially. These are the eight steps that make up STATIK, and I’ve paraphrased them here to help make them a little easier to understand: 

  1. Understand what makes the service ‘fit for purpose’.
  2. Identify areas for improvement.
  3. Analyse the types of work, where work comes from, and any patterns of demand.
  4. Analyse the people in the team and their skills. 
  5. Map out how the different types of work are treated by the team.
  6. Identify how to handle the different types of work by defining classes of service.
  7. Design the Kanban system.
  8. Share the design with everyone affected by it, and implement it collaboratively.

What are the benefits of a STATIK approach to introducing Kanban?

STATIK starts with what your organisation is already doing now, and so unsurprisingly it’s the most common way to introduce Kanban.

With STATIK, no roles or processes need to change right away, so there’s no shock to the system, and resistance to change is significantly reduced as a barrier.

Processes will change over time as a result of continuous improvements, and roles may need to change as a result of changes to the process.

For these reasons, it’s seen as a softer-touch, more people-centred approach where the speed of progress made on an organisation’s Kanban journey is determined by the people making that journey.  

It’s worth noting that although Kanban started by not defining roles, a couple of new roles are emerging in relation to the strategy of treating the team as providing a service. 

The best way to learn more about this approach is by doing it, preferably with an Agile coach as an integral part of the team.

When do I use STATIK for Kanban?

As we’ve discussed, STATIK is a ‘softer’ approach to getting started with Lean Kanban as it implements change in a gradual way. As such, it’s an approach that makes sense for an organisation where one or more of the following are true for the ‘service’ in question:

  • The people using and providing the service are happy with the current process (at least to some degree), so although the process could be improved, it’s a good place from which to start.
  • One or more of the people involved are strongly resistant to change.
  • A cautious approach is prevalent.
  • Too many radical process changes have already been tried and have failed.
  • There’s internal consensus that the benefits of STATIK outweigh the benefits of a more radical approach.

At Inviqa we are seeing far fewer of the above concerns as we learn from each project. When I first get involved on a project at Inviqa, as a PM and / or Agile coach, I do an Agile induction to explain to the team (and client) the relative merits of adopting a team Kanban approach. I then let them decide if that’s the way they want to go.

For the team, key factors in choosing to go with Lean Kanban are usually the drastic reduction in meetings, and the increased autonomy over design, thanks to the just-in-time backlog. Clients typically love the increased flexibility over the end product, the shorter feedback loops, and the improved value for money.

Every project where I’ve presented this choice has chosen to try Kanban, and none has gone back on this decision. That’s why we’re developing a fast-track approach to introducing Lean Kanban in-house as an alternative to STATIK.

Using a Fast Track approach to implement Lean Kanban

Fast Track is a direct implementation of Lean Kanban where the old process is completely replaced with a new process.

With Fast Track, you don't forget STATIK altogether; you apply some of its steps having made the move to the new process. You’ll still look for areas to improve, for example, but the difference is that you’re not starting with what you do now; you’re starting with a process focused on flow and all that this entails.

Where the decision has been made to let go of the current process and dive straight into a Lean Kanban approach, it’s critical not to throw the proverbial baby out with the bathwater. Look for the good bits in what you were doing previously and make sure you still have them covered.

Each team I’ve worked with on a Fast Track approach has applied Kanban principles and practices differently, and so there’s no one-size-fits-all approach. That said, below is an overview of what to expect with a Fast Track approach to Lean Kanban adoption:

Review progress

Rather than investing a significant amount of time on a slick, polished demo aimed at the product owner, and usually delivered by just one member of the team, with Fast Track, teams review progress by encouraging the team members to talk through their achievements for the last week. If they have something to show on screen, that’s great, but if they don’t, that’s great too.

Risks

One of the sections in the weekly checkpoint is used to discuss the project risk log. If there are no new risks to raise on the project, and the existing project risks haven’t changed their status, this section can be pretty quick. But the benefit of having it is that it does make risk management significantly more proactive than reactive, which is a big plus for everyone. This also encourages the whole team to consider and raise risks together. This can help it become a collaborative team responsibility, rather than the maintenance of the risk log being centralised to one role e.g. project manager (PM) or business analyst (BA). 

Retrospectives

All too often when teams adopt Kanban they see that some of the meetings they used to have are now not defined as required, so they stop doing them at all. A good example of this is retrospectives. But you shouldn’t ditch retros just because they’re not defined as part of Kanban; keep them as a productive way to continuously improve. 

For Kanban projects at Inviqa we have retros weekly so it’s easier to remember what happened, which also makes them shorter on average.

Time-boxing conversations, and allowing the team to prepare the points they want to discuss in the retrospective prior to the meeting, can also help here. Lean Coffeeis an excellent and appropriate approach to running these sessions.

Refresh backlog

Similarly, you still need to build a backlog. The ways we’ve found to reduce the time spent building the backlog at Inviqa include:

During the refresh backlog session we work as a group to identify, understand, and prioritise the tasks required. Directly after the weekly checkpoint we then work individually or in smaller groups to expand on the tasks.

Release planning

The new addition to the weekly checkpoint is to discuss the release planning (head to my previous post here for an overview of weekly checkpoints). For teams managing multiple streams who are releasing to production on a regular basis, it’s helpful to discuss what needs to go in the next releases and plan user acceptance testing (UAT). It can just be a quick conversation, but helps everyone to focus on flow.

Weekly checkpoint

The 5 ‘R’s (review progress, risks, retro, refresh backlog, and release planning) make up the weekly checkpoint. They detail what needs to be covered, but not necessarily how; that’s up to each team. For example, when refreshing the backlog some teams have found it useful to use a diagram to drive that process. So far several different diagrams have been used (story map, feature map, key deliverables map) depending on what the team thinks works best.

Daily sync

The daily sync happens on the days that the weekly checkpoint doesn’t. Teams walk the board in priority order (top to bottom by swimlane, right to left within a swimlane). This makes the meeting quicker and more focused.

Meetings and ceremonies

At Inviqa we’ve ‘boiled down’ the ceremonies we were using and now just have the weekly checkpoint and daily sync on a regular basis. We add more ad hoc as and when we need them. We find them much leaner and more pragmatic than what we were using before. However, they’re included here only as an example; your starting point will most likely be different, so your solution is likely to be as well. It’s a case of applying Kanban principles and practices, rather than finding a model to copy.

Steady pace of implementation

Don’t be in too much of a hurry to follow every Kanban practice and principle straight away. One thing I do is to help the team to get tickets flowing across the board more smoothly before helping them to introduce WIP limits. Another tactic is to encourage rotation of the facilitation of the daily sync, and then, once that’s going successfully, each of the 5 ‘R’s in turn.

Pairing reduces WIP

Productive pairing has both participants proactively engaged in collaborating to the best of their combined abilities. It’s generally accepted now that productive pairing has many benefits including improved quality, reduced bugs and rework, increased knowledge sharing, and reduced on-the-job training costs to name but a few. Bigger than all of these for me is the positive impact on throughput that pairing productively has by reducing the average work in process (WIP). 

I encourage productive pairing not just within the same discipline, but across disciplines too, e.g. QAs pairing with developers. Moreover, I try to build an environment where tripling and mob programming are seen as good things too. They help to reduce the WIP even more markedly.

Relating user stories to tasks

If you’re using Goldilocks estimation the team will have chosen an optimal size for which to aim. That size is usually smaller than that of traditional user stories or features. On some projects the product owner may still be thinking in terms of user stories. On others the features may have already been defined. Either way, at Inviqa we’ve found that creating automated tests at user-story level, with scenarios to cover the Goldilocks tasks, works well to address this.

We’re also finding that the best way to learn more about the fast-track approach is by doing it, preferably with an Agile coach as an integral part of the team.

Training

Training is key regardless of whether you decide to adopt STATIK or to go with fast-tracking your implementation of Lean Kanban. 

That’s alI, folks! 

I hope you’ve enjoyed this introduction to implementing Lean Kanban and now have a better understanding of which option might suit you best.