Have you ever found yourself working on a project and feel that maybe a different strategy can help you to be more flexible in the face of the continuous business changes? Usually, teams face the decision to implement an agile framework and the most common is Scrum. But that’s not always the most suitable way to achieve our goals. I will explain an example where Kanban helped my team to improve stakeholder satisfaction and at the same time organize ourselves better as a team.
Is Scrum working here?
One year ago, our team had the objective to implement software changes for different business areas of a retail company. Initially, we decided to implement the Scrum framework. A two-week sprint cadence would allow us to concentrate on the sprint goal and receive business feedback in the sprint reviews.
Our idea was to have the most important user stories for the business at the top of the backlog. Sometimes, we faced the decision to replace a user story that was already in progress in the sprint for another one that had suddenly appeared on the business radar. The problem was that this situation became very frequent and these emerging requirements were difficult to add during the sprint.
Teams who have implemented Scrum know that there is some flexibility. It’s possible to replace items in the sprint backlog if the priorities for the product change suddenly during the sprint execution. The point was that this was the rule rather than the exception. So how can we manage a workflow that helps us react better to these unpredictable changes? And the underlying question: are these real changes to the business priorities? Or are we not considering some stakeholder insights when defining our sprint goals?
Inspect and adapt the process
Firstly, the Product Owner confirmed that these sudden changes were really part of the business context. Several business areas were represented by different stakeholders who requested our services. The prioritization based on the urgency and importance of their requests was volatile and difficult to predict.
As a result, we decided to adapt our process with the objective to make shorter plans and be able to react faster to possible changes. The Kanban method appeared the most suitable way to implement our workflow and the Product Owner supported this decision. But we had some concerns, some related to our team and another related to the stakeholders.
- Internalize Kanban with the team
The team had identified in previous retrospectives that a different strategy would help us, so we were open to changes. The point was that not everyone had previous experience working with Kanban so it can be confusing to change the processes. Maybe, the traditional way to introduce Kanban in a team is that the leaders explain the concepts and define the initial rules – but we tried something different. We played a game called “Pizza Kanban” which is an adapted exercise from this dynamic to teach basic concepts. The idea was to iteratively discover as a team the best possible distribution to generate a continuous flow cooking as many pizzas as possible. We experienced the different situations that occur when a team implements a “Pull” system and this game helped us to understand the values, principles, and practices of Kanban. The most important lesson learned of this game was to “stop starting and start finishing”.
As a result, we defined the limits for work in progress and created an initial idea of when a work item is ready and done. Of course, it was easier for us because we had been working before with Scrum and we maintained roles and responsibilities. Also, we continued doing daily meetings and retrospectives (every 2 weeks).
Image source: www.agile42.com
- Involve stakeholders with the Kanban method
The project was in progress so there was a risk of failure with the delivery date of the user stories that were in progress. We used the STATIK (Systems Thinking Approach to Implementing Kanban) process to identify the actual demand, capacity and pain points. We detected that priorities were not correctly defined as a result of miscommunication with some stakeholders. We also observed that if we re-organized our prioritization activities then we could set a more appropriate expectation with these stakeholders about when a work item could be finished.
We decided to introduce a replenishment meeting each 2 weeks with all the stakeholders and to encourage their participation. This event would let them communicate their needs and the reasons for each new request in front of their pairs. The idea was that the Product Owner would facilitate the conversation and hear from all of them. We could then decide, following a healthy discussion, which of these requests would be first tackled by our team.
- Prioritize using Classes of Service
The stakeholders’ participation was important, but the method to prioritize their requests was an even greater factor in being totally transparent in deciding which user story will be worked first. We wanted to be fair and use a smart criteria when accommodating our backlog so that users don’t feel uncomfortable. We decided to experiment using Classes of Service (CoS) which is a versatile tool for coping with uncertain and unpredictable situations. It would allow us to manage dependencies according to the cost of delay (CoD) for work items, which is the economic impact of failing to deliver the service on time.
We analyzed which type of requests we received in the past. They were different because sometimes a business area only wanted a nice-to-have feature in a process. Other times, they needed critical functionality which would cause several losses if we delayed the implementation. That’s how we decided when an element would be considered as Expedite, Fixed Time, Standard and Intangible.
Inspect again – We are doing better!
After several months of applying these changes we received good feedback from the different business areas and we also learned different things:
- Limit the Work in Progress (WIP): It helped us to improve collaboration and implement a Pull system. The typical moment when one of the stories gets complicated drives a team conversation to look for a way to finalize this story instead of starting a new one. It was surprising to see one developer, who has great business knowledge, spend an entire week helping testers to accomplish the definition of done for a couple of user stories before starting development on a new one. A Cumulative Flow Diagram was used to inspect periodically if these limits were helping to improve our flow of work.
- Visualize the workflow: We were really transparent on the Kanban board. When a user story is blocked it remains on the board occupying an available space. This obligated us to conduct a conversation with other IT areas to obtain help and unblock the item. Also, this enables us to provide visibility to the stakeholders of how the progress was and share with them if we need a business response to unlock an item – bearing in mind that this wait time will prevent other business areas from being attended.
- Agreement in the meaning of urgent: Having a replenishment meeting with all the stakeholders every two weeks was a perfect opportunity to socialize with them which work items were completed and delivered by our team and to understand their needs and expectations. It was surprising that in the past some of them had tried to prioritize their requests as urgent because they wanted to make sure it would be ready for a specific date. Little by little, the team gained stakeholder’s confidence thanks to the continuous deployment of functionalities that we did. Also, we managed metrics to know if there were business areas that were not being served for a long time to help them justify their requirements using the Classes of Service tool.
Conclusion
This article does not pretend to state that Kanban is better than Scrum or vice versa. There doesn’t exist either a static recipe to determine when one or the other is more suitable. The idea is that we should always keep in mind that choosing a framework or method to implement in a project is only the first step. Then, we should ask ourselves periodically as a team what is going well and what is not. We have to be open to adapt our processes according to environmental changes and the context of the situation.
