You don’t have to be Scrum Masters
One of the things we often hear, you see it all the time on Twitter, is that Kanban might be a good project management technique, but it should only be tried with advanced teams. That you should perfect Scrum first and then move on to Kanban. We couldn’t disagree more.
First, while several of us at LeanKit are CSMs and we think Scrum has its place in the Lean/Agile toolkit, we don’t believe “pure” Scrum works for the whole IT organization. If you are doing mostly greenfield software development then pulling together a dedicated, cross-functional team for a project and using iterations to give them space to focus is great. But. Even most software development teams always deal with a mixture of project work, minor enhancements, and operational support. Break-fixes don’t wait for the next iteration. Having a way to gracefully handle planned work and inevitable interruptions is crucial to Agile success. And for networking, security, server services, CS, etc. the idea of fixing scope for 2-4 weeks and being guided by a single all-knowing product owner is simply unworkable. Their world is defined by interruptions and demand from every direction. So, to say everyone should make it through Scrum first to get to Kanban is absurd.
Second, and more important than our theoretical opinion, is that we’ve seen Kanban be successfully implemented many times by teams that are not only new to Agile but are also quite ordinary – not experts in any process. We think that’s because Kanban doesn’t demand that you throw out your old process and make a radical change to something new. It just gives you a method for getting better visibility into what’s happening so you can gradually and carefully adjust your process for better results based on data rather than guesses. As has been said many times, Kanban is less a specific method for managing projects than a tool for improving whatever method you currently follow.
Our favorite example is one we’ll keep anonymous, although I suspect they’ll recognize themselves. If they do, I hope they understand this story is told with a great deal of respect. Anyway, when we started working with this team they were the Bad News Bears. They had around 10 people but were responsible for maintaining something like 50 systems. Some of these systems were pretty important to the company, but they weren’t new or glamorous so the team got very little executive time or recognition. And with so many systems, prioritizing was extremely difficult so it seemed that the only attention they did get was when someone was upset because their requirement was bumped by another. They worked hard all the time but got no respect.
Other teams within the company were implementing Scrum, but it didn’t seem to fit them so they decided to try Kanban. We did a one day training for them to introduce them to the method and help them design their system to model what they were currently doing. They put their LeanKit Kanban board up on a large monitor in their work area (a practice we highly recommend) and began holding daily stand-ups around it. At first, they created cards for everything they were doing. The goal was to get visibility into what people were working on. They didn’t initially set any WIP limits. But they did create classes-of-service: normal, management urgency, and widespread break–fix.
After that first training we talked with the team’s manager about once a month to see how things were going. At our first follow-up meeting, the manager was in pretty poor spirits. The team wasn’t thrilled about having to do Kanban. They hadn’t yet seen any benefit and kind of resented the intrusion into their business. Looking at the data with the manager, we advised them to create another board for some team members whose work didn’t overlap much with the others, to work with team members to pare down the number of cards to focus more on customer results than tasks, and to start implementing WIP limits.
The manager was struggling with getting business owner attention to prioritize work. We advised that, with the exception of the urgent classes-of-service, she shouldn’t struggle to get guidance from people who were disconnected but simply prioritize them herself with a focus on front-loading work that could be done most quickly and thus generate positive momentum. Our suggestion was that they would be more interested in active prioritization if they started seeing regular delivery. Finally, we advised that the reason the team hadn’t yet seen any benefits was that the manager was still focused on (micro)-managing the tasks not improving the system. One of the benefits of Kanban is that it allows the team to manage their own daily activities while giving the manager visibility into progress and data for process improvement. She needed to keep her eye on progress problems to intervene if necessary, but focus mostly on improving things for her team. She needed to be their manager not their task list keeper. At a meeting with the team the next day, the manager got some real resistance to the changes, but she persevered and implemented them.
Our next meeting went very differently. The team was doing well. Implementing WIP limits was improving delivery speed. A review of their cumulative flow diagram (CFD) showed that the team was doing a great job of holding work in the backlog until they were truly ready to start and then quickly flowing things through the different steps to the done lane where they waited a few days for verification before being archived. Average work-in-process per team member had declined from 8 to 2.5. They were exceeding their WIP limits on a regular but not continuous basis, but only for a few hours at a time. In our view this meant the limits were perfect, just tight enough to be noticeable but not painful. They were getting into a consistent pattern for cycle time, an average of two days for break-fixes, four days for items marked urgent by management, and nine days for normal work. We suggested some tweaks but mostly reassured her that her data was indicating she was doing the right thing. By the way, all these positive changes happened despite one team member being re-assigned.
Our third follow-up meeting didn’t come for several months because of scheduling difficulties but they delay wasn’t a problem at all because, instead of a consulting session, it was practically a victory lap. The team was continuing to do well. The manager was happier and more confident than we had ever seen her. The team’s LeanKit data continued to show a consistent and positive pattern. Their backlog, which had averaged more than three month’s worth of work was down to one month’s worth. The cycle time for normal work items had increased from nine to fourteen days, but (and this may sound strange) this was a good thing. The manager had actually volunteered two of her people to work on a different project secure in the knowledge that she could measure and control the impact on delivery. Her cycle time for break-fixes and management urgent items stayed exactly the same. Only normal items got slower and only by an acceptable amount. Basically she got to be a hero to management while keeping her customers happy.
We’ve not met regularly with the manger since then but we do keep in touch and an eye on her team’s metrics. They’ve stayed consistent for about ten months now. Other managers, including on the business side, have come to her to learn about what she’s doing and many followed her lead. It’s a great story. A true story. And, we emphasize, not a story of expert Agilists, rock star developers, people highly motivated for change, or any of the other things people will say you need to be successful at Agile – or especially such an “advanced” technique as Kanban. We did train them and stay in touch, but only about 10-12 hours in total. They did this themselves.
It’s just one example of how Kanban helps regular teams to
- make a gradual transition to a better way of working
- that provides better results for their customers
- and helps them feel better about their work