In our company, we are following the principles of Agile development. Our Agile Coaches are committed to finding the best software development methodology for each team. We have teams doing Scrum and teams doing Kanban, and teams doing something in-between. In this article, I will not make another comparison between Scrum and Kanban, as there are a lot of good articles on this subject. Instead, I will describe a case study of a team that migrated from Scrum to Kanban in search of the best fit.
The team in this case study is small: 5 software engineers and 1 support engineer. Their project is already in production. They have to address maintenance tasks and implement new features. The team used to follow Scrum on a two-week cycle. I became Scrum Master of this team this year, and as we completed some Scrum cycles, I began to sense that they could be much more effective. It seemed that using Scrum in a project full of maintenance tasks and bug fixing wasn't working out.
The Product Owner had mandatory maintenance tasks that interrupted sprint work. Normally, I wouldn't allow the interruptions, but in some cases — such as software in production — maintenance is necessary. On top of the mandatory tasks there were on average 5 bugs per sprint. The continuous existence of bugs was making it really hard to estimate the length of the sprint. It was too uncertain; they had tried to plan sprints with fewer points, and plan sprints exclusively for bug fixing. They had tried a lot inside of the Scrum sprint cycle structure. They had more than two years of Scrum. I was coming to the conclusion that if we couldn't make an effective sprint plan, maybe Scrum wasn't the best methodology to follow.
I knew that changing a team's methodology is always a difficult task, because people naturally resist change. At that time, I really believed that Scrum wasn't adequate for the team and I thought we should try some form of Kanban. So, I began to design a variant that didn't change the current methodology too much. The goal was to later iterate the methodology to reach the best customization, because, in my opinion, if we tweak the methodologies in the right way we can get better results than if we blindly follow the rules. So, I proposed a Kanban variant, and I discussed the possible change of methodology with the team and the Product Owner. The proposal consisted of the main concepts of Kanban, with these modifications:
KDailies: We have stand-up dailies in front of the Kanban board, which include the Product Owner. The team discusses the cards each member is working on, and each team member states some kind of commitment as to when the card will be ready. After the team members talk, the product owner presents the new cards, and we make the grooming for them. KDailies don't have a time limit, but they tend to be short and precise because of the stand-up restriction. If the Product Owner has too many new cards, they will have to be distributed by future dailies.
KRetrospectives: The retrospectives are one of the best weapons an Agile Coach has to get feedback from a team. So, we have retrospectives like in Scrum, and we make sure to discuss every concern about the methodology that we are using. In my opinion, as an Agile Coach, we should include the team when analyzing the methodology, and we should obtain feedback about every aspect. The KRetrospectives are scheduled monthly.
After I presented this Kanban idea and discussed every aspect with the team and the Product Owner, one of the team's questions was: how we will review our work, can we keep the Scrum reviews? My original idea was that we didn't have demos at all, due to the time waste they tend to consume. The work approval should be made ad hoc by the Product Owner, with help from the team member that implemented the feature, if needed. The team didn't like this idea, having grown attached to the concept of the demo. After we discussed the advantages and disadvantages of Scrum reviews, we reached a consensus in the form of KOverviews, which are non-periodic overviews of the latest features in the project, without a mandatory schedule.
The Product Owner was concerned about the loss of sprints, as he needed the changelog reports, and was worried with the possibility that the team's productivity might decrease without the sprint time pressure. Ultimately, the Product Owner had to find a way to manage the changelogs within the new "Kanban cycle", and we addressed the lack of time pressure inherent to the Kanban process by putting due dates in cards, as described in the KDailies.
So, we have defined a board that is appropriate to the team work flow, we have defined the WIP limits for every column, and we began our Kanban with the commitment that I will iterate the process as the team needs.
After 3 months, the team is more motivated and more productive, and they don't miss anything about Scrum, including the demos. The brave Product Owner that had to adapt his work to the new process is still not completely convinced. I know he misses the pressure of scrum cycles.
The KRetrospectives have had results like alterations in Kanban board columns and WIP limit fine-tuning. We're still struggling with two big challenges:
- maintaining the column card limit, due to the dependence on Product Owner reviews and deployment difficulties;
- and some lack of team commitment with the cards' due dates.
Right now, we're heading to a better methodology that fits our team, and our project. Maybe one day day we will go back to using Scrum. No one knows. But there's one thing I'm sure:
We will always value individuals and interactions more than processes and tools.
