Forcing Scrum does not make sense. Ironically, a team that, after more than a year of working together, stopped saying they were doing Scrum actually got much closer to the framework. How?
What the team looked like when I joined
The team consists of 12 managers, each of whom leads anywhere from a few to over a dozen people. The thirteenth person in the team is their superior - the director.
They meet to discuss and collaborate on topics that would be assigned to them anyway. When they tried to adapt Scrum to their team - or rather adapt the team to Scrum - their manager became the Product Owner.
They have Scrum events. Daily meetings and planning help them communicate faster and clarify the scope of work and collaboration.
Retrospectives are often skipped. They do not see any value in them. They believe no outcomes come from them.
There is a review, sometimes even without stakeholders. In such cases, they report completed or incomplete tasks to their manager, while the remaining 11 people mostly hear the same things they already heard during the daily.
They have sprints and a sprint backlog. In the "product" backlog, topics for future sprints sometimes appear, but rather on the basis that nothing more can be done in the current sprint, so tasks get moved to the next one.
And most importantly - the team’s biggest sin - they do not have a product. They work on ongoing operational tasks.
The managers in the team are related to the production of a physical product. These include logistics, warehouse, planning, technologists, assembly, mechanical department and others.
They introduced Scrum because it was the only structured way of working they knew apart from having no rules at all. The company was undergoing an agile transformation. Agile ways of working were introduced, starting with departments involved in product development, such as embedded software teams.
As a result, company leadership strongly promoted the Scrum framework. Unfortunately, this led to a slight distortion where everyone wanted to have a "Scrum team."
How I got involved with the team
As a Scrum Master in the company, I was asked to provide guidance on what they could do to give structure to their collaboration while also bringing benefits. I was supposed to give feedback on what they could do better to make Scrum work for them.
This is important because this was not another team I could fully dedicate my time to. Working with them was not supposed to impact my work with other teams where I was a Scrum Master.
I participated in one sprint to collect data on how they work, what does not serve them well, and which practices they use. I gathered my observations over two weeks. It was mainly during this period that I learned how the team functions and what is happening there.
After that, we had a retrospective. My first feedback to the team was: "This is not Scrum."
It was a cold shower for them. Some had already sensed for a while that something was off, but they did not know exactly what.
Goal
During the retrospective, we came to the conclusion that Scrum is not a holy grail they must achieve and implement. What they really want is to function better as a team.
The most important goals we set were:
increase engagement within the team
create a structure that helps maintain a working rhythm
build a collaborative team
enable continuous information sharing between team members
Actions taken
The first step I took was to show them alternatives to Scrum. I organized an almost 3-hour workshop.
I started with a theoretical part, presenting Scrum, Kanban, Scrumban - which I would not present today as a separate framework - and a fourth idea, a task force with its own set of rules. While the first three approaches are widely known, the fourth showed that not everyone has to work within an already defined method - they can define their own working rules.
When presenting the idea of creating their own rules, I pointed out which areas should be defined first so that collaboration works and does not become chaos:
how will you communicate - for example face-to-face or Teams chat
how will you inspect your work - for example Daily or review
how and when will you improve as a team - for example keeping retrospectives or asking questions during daily like "what can we improve?" or "what was a problem in the last 24 hours?"
Next, I divided the team into four groups. Each group had to discuss one of the working approaches in terms of:
implementation pros
implementation cons
questions they have about the method
anything else that comes to mind and does not fit into the previous categories
After 5 minutes, only one person - the group leader - stayed in each group, while the others rotated between groups so that as many people as possible could discuss each option. Leaders could also be changed in each round.
After four rotations, we moved to presenting the results of all groups.
The conclusion of the workshop was that the group was moving toward defining their own rules, based on known frameworks and ways of working.
However, until the new rules were defined, they continued working as they had so far, introducing changes gradually. The main moment to discuss improvements was to be the retrospective. I also committed to bringing flipcharts with workshop outputs to each retrospective.
The next retrospective was about reviewing the downsides the team saw in how they practiced Scrum. The key issue was the lack of a shared team goal.
After a longer discussion about feasibility and value for the company, they decided to take on one shared goal for everyone, discussed in detail during planning. This happened and became the first step toward change.
During the next two-week sprint, the team focused on that shared goal.
At the same time, we made a small adjustment to how the Daily works so that it would no longer take 30-40 minutes and would not repeat the same information every day.
An important change was that information about completing a task was shared only once during Daily, instead of being repeated every day until the end of the sprint.
The most important part of working with the team was making them understand the purpose of Scrum events - the "why" behind them.
The team became more open to experiments and, after a few weeks, they were no longer afraid of them. Every retrospective ends with an experiment and, most importantly, retrospectives are no longer skipped.
This team has just started its journey, but I am convinced they will adapt their way of working to themselves. They document their rules in a shared knowledge base. They know these rules will constantly evolve because they operate in a changing environment.