Credits: Pixabay

Migrating from the Scrum framework to ScrumBan

I have been an Agilist for almost 5 years, but, throughout my career, I have had the experience of managing projects for more than 12 years, which allowed me to acquire enough satisfactory experience so that, instead of focusing on following the Scrum Guide, analyze the scenario in which I work at the moment, identify their problems and, finally, suggest changes in processes based on other frameworks, methods and methodologies, which may resolve these issues, generating value for that particular reality.

After having worked as a Project Manager, Scrum Master and Product Owner in several sectors such as Animal Health, Telecommunications, Technology, Logistics, Expatriation, Financial Institutions, among others, from June 2020 to March 2021 I worked as an Agilist in a prestigious and international Program for a customer, which is a network of American-Canadian gas stations and convenience stores.

Since the beginning we were running the Scrum framework, with which the team was already familiar and we had the following scenario:

• Development Team working on two products at the same time;
• A clear sprint goal to be achieved every 2 weeks;
• Dev Team working more closely together on the same item to deliver that goal;
• The scope of the demands were rarely changed;
• The Dev Team to Know their velocity was essential for planning the next iteration (Sprint);
• The stakeholders seeing more value in delivering the objective (sprint goal) initially defined;
• Time was adapted and seeing value in Scrum events.

What motivated us to change the processes, aiming to adapt them to a new reality:

After 10 sprints running with the Scrum framework, based on constant feedback from the Development Team, I could see that there were changes in our scenario, which, possibly, would also require changes in our processes. Our new reality became this:

- The sprint started to fail, as there was a need to meet more than one goal containing several objectives, simultaneously, and these used to change, quick often, throughout the iteration;

- The need arose for each Dev to work, individually, on each demand that arrived, in order to account for all of them, which arrived in greater quantity;

- Stakeholders began to change their demands with great frequency, so they began to see more value in the agility of the Dev Team, that is, in adapting quickly to these changes;

- Dev’s team needed to know when to drag an item on the Jira board to the next stage of the value delivery cycle, that is, they wanted to know what would be considered ready to start the next stage;

- The Development Team was missing more information to consider an item ready to start, having to dedicate a lot of time in refinement;

• Time was wasting time estimating the effort of items, and at any time, more priority items could arrive, having to be accommodated in the sprint anyway.

How the Process Happened:

So, as an Agilist and, therefore, part of the Scrum Team, I decided to select some points of this new scenario, by making them more transparent and summarized and took them to be discussed, as points to improve, in the Sprint Retrospective Meeting; which were:

• We were not able to follow the planning of the Sprint Planning meeting (we have not been achieving the Sprint goal with a certain frequency);
• Priorities were changing frequently and often had nothing to do with the sprint goal (goal being obsolete);
• Our team was working on more than one product at the same time, which was making it difficult to establish the objective and understand the prioritization;
• We needed to be more flexible to meet the most diverse customer demands (as they were seeing more value in our agility, the ability to adapt quickly to changes).

After a productive discussion among the team members on the above points, when defining the action plan, the Development Team voiced the need for processes to be changed, in order to adapt them to the new scenario, so that it could continue working with motivation, purpose and productivity, delivering value.

Thus, the action point that the Scrum Team jointly defined was: “Vanessa will provide the team with a meeting to talk about the suggestions that the team will bring about the new processes.” I could have opened the discussion with a brainstorming, encouraging the team to bring suggestions, however, to not make this meeting long and boring, on the same day as Retro, I opened a board in the FunRetro tool (currently EasyRetro) and asked the team to already start including their suggestions, days before the discussion. Thus, on the day of our chat, the idea was to go through each suggestion, asking the owner to clarify what he or he was talking about, giving transparency, making a vote, electing the most important of them and putting an immediate action plan for them, which would result in the redefinition of processes. I realized that these new processes, by having elements of the Scrum framework and the Kanban method, could be translated into a hybrid method that would combine characteristics of the Scrum framework with aspects of the Kanban method, which we would call “ScrumBan”. This would work as follows:

• Replacement of the Scrum board by the Kanban board so that the team works in a more “task-oriented” way, in order to meet the constant changes in demand;
• Use the WIP limitation, so that a Dev works on only one item at a time;
• Scrum events maintained, as the team believed that it generated value and that there was no need to replace them with Kanban’s and also because other four international teams were also part of these events along with Brazil’s team;
• No more defining a sprint goal and for the Product Owner would always ensure to make clear and up-to-date for the team the priorities;
• Modify the flow of value delivery, in the Jira tool, in order to make the current reality transparent, including better detailing the columns within the flow;
• At the Sprint Planning Meeting or the Refinement meeting, no longer estimate work item effort;
• Implementation of Explicit Policies, that is, agreements that would make possible between members of the Scrum Team, which covered, among others, the following aspects:
• 1) The stories / bugs will contain a specific structure so that the Dev Team is provided with the necessary information to start acting;
• 2) “Priority” field from the issues will be used: instead of using Classes of Service, for now, the team preferred that our board be configured based on 4 priority levels: critical, medium, minor, trivial;
• 3) Product Owner is the one who defines and redefines priorities (in the past the priorities used to come through different sources, such as stakeholders, architects, project manager, technical leaders);
• 4) Dev Team to focus on following up on the items that are closest to being ready (“stop starting”, start finishing”);
• 5) When changing the priority of a story, the Product Owner notifies the Scrum Master, in a specific channel of the Slack tool, and the Scrum Master will update the priorities of the respective subtasks, which would be technical tasks, written by the Development Team, in order to achieve the objective of the respective story.

Results:

The increase in the motivation of the Development Team was evident and was reflected through the increase in the average score of the Dev Team in the Team Health Check, which I used to apply every two weeks to them.

In addition, in the following Sprints Retrospective Meetings, positive topics began to appear, such as comments that reinforce the effectiveness of the move to ScrumBan, as well as a notable increase in team motivation, for example:

• Sprint 11:
• “The team has always endeavored to meet the frequent changes in demands”.
• Sprint 12:
• “The team collaborated a lot, by bringing suggestions for improvements to the process change meeting”;
• “Moving from Scrum to Scrumban”;
• “Very useful discussion about the improvement of processes, as well as the team’s good attitude towards this need”;
• “Team committed to the quality of delivery”;
• “A very useful discussion about improving processes, as well as the team’s good attitude towards this need”.
• Sprint 13:
• “Discussions related to the implementation of ScrumBan and the adaptability of the team to adjust the board in the last two weeks”;
• “The team adjusted very well to Kanban and gave excellent suggestions on changes to the board”;
• “The team was very supportive and offered help whenever needed.”
• Sprint 14:
• “Our Scrum Master, Vanessa, is always very helpful and quick when it comes to our needs regarding the Kanban Board”;
• “Change in the development framework”.

Conclusion:

I like to reinforce that no framework, method or methodology is a “silver bullet”. It is essential that the Agilist observe, in depth, the scenario in which he is inserted and constantly review whether the processes previously implemented by him, continue to make sense or not.

It is also essential that the Scrum Master, through the observation of the current context, chooses to focus, with perspicacity, on the instance of his/her role most appropriate for that particular moment, such as the agent of change, used by me in this case.

Another tip is, when noticing that there are dysfunctions that the team has not identified occurring repeatedly, the Agilist to act quickly, taking them as points to improve at the Sprint Retrospective Meeting, which is the formal opportunity to discuss processes as well.

No less important is the Agilist not to cling to frameworks, but to understand the current problems and needs of the team, encouraging them to reflect and make suggestions, which helps them to have a feeling of belonging and motivation and only then go in search aspects of the most varied methods or methodologies that will collaborate to solve the dysfunctions, that is, that generate value.

Finally, Agilists need to be great listeners and observers and true pickers of feedback from the team! After all, as good facilitators, we always need to inspect — in order to check if the processes have been working well or not — and adapt — in a way that our processes are always adherent to our current reality, collaborating directly for an effective increment delivery and maintaining health and team happiness and making our customers happy.