Hi there! My name is Olga, and I'm a Scrum Master at Elecard. I want to share the story of how we adopted Scrum — through pain, skepticism, and cakes at our retrospectives. If you're thinking about switching to an agile methodology or are already in the middle of it, our experience might be useful.
A Bit of Context
For those less familiar with the terminology, here's a quick rundown of the key concepts.
Scrum is a set of rules that helps a team build a flexible workflow. Development happens in short iterations (sprints), each iteration has a clear goal, and every team member has well-defined tasks.
Scrum Master is not a boss — think of it more as a facilitator. Someone who helps the team follow processes, removes obstacles, and runs meetings. Ideally, a Scrum Master shouldn't be a developer or a product manager — they shouldn't have a stake on either side.
Sprint is a short work cycle, typically three or four weeks long. Short enough to keep the team focused, long enough to deliver meaningful results.
Backlog is a prioritized list of tasks.
Story points are abstract units used to estimate the relative complexity of tasks.
Daily is a meeting that lasts no more than 15 minutes, held every working day. Developers discuss progress and flag any blockers.
Where It All Started
Our team consisted of 20 developers (including two tech leads) and one product manager. A big team with varied tech stacks and skill levels. And we had a whole pile of problems building up.
Communication Issues
We had one meeting per week. That was nowhere near enough. Managers often had no clear picture of who was working on what or how complex those tasks were. Cross-team communication was lacking too — some decisions could have been made at the component level instead of being escalated to the product level.
But the biggest pain point was developer distraction. Picture this: a developer — let's call him Alex — comes to work, grabs his coffee, opens a task, sits down to code, and immediately someone from marketing walks over: "Hey, we urgently need this!" Then someone from tech support. Then someone else. Alex could get interrupted 10 to 15 times a day. We'd essentially lose him for the entire day — he couldn't focus on a single task.
On top of that, we had no mechanism for surfacing problems. People just kept quiet about them. All of this meant there was no sense of team unity — and that directly affects the mindset you bring to work every day.
Organizational Issues
Back to Alex. Someone from another department gave him a task. But who's accountable for the result? The tech lead? The product manager? Alex himself? Nobody knew. There were no clear boundaries of responsibility.
With such a large team, it was hard for tech leads to track individual growth. And with just one meeting a week, we essentially had no processes or guidelines in place.
Strategic Issues
Deadlines were often set by guesswork and rarely met. The team had no understanding of how the product should evolve or what the market actually needed right now.
All of these problems kept piling up, and at some point it became clear: something had to change. Leadership and the team jointly decided to adopt Scrum. That's when I was offered the Scrum Master role — by that point, I was already certified.
The Five Stages of Accepting Scrum
1. Denial
At the start, it was completely unclear how Scrum could possibly help us. Or whether it could at all.
In textbook Scrum, a team is 7–10 people. We had 20, with different tech stacks and skill levels. No cross-functionality, so pulling tasks from a shared backlog in priority order simply wasn't feasible. Add a healthy dose of skepticism — we're all afraid of change. Nobody believed Scrum would actually work.
2. Anger
Many rituals triggered a negative response. We started with a task estimation scale of 1 to 10 — and immediately ran into trouble: the more complex the task, the harder it was to pin down a number. Is it a 7? An 8? Maybe a 9?
Meetings dragged on for half a day, sometimes the whole day. It was absolutely exhausting for the team. It wasn't easy for me either. I was used to working independently, and now I had to constantly engage with a large team, explain why each ritual existed, and answer the endless "Why do we need Dailies?" and "What's the point of estimating tasks?"
Dealing with other departments was a separate headache. I had to set boundaries and explain how to interact with our team under the new process.
3. Bargaining
This is where we started tailoring Scrum to fit our needs.
Team rules. For example, every sprint must include writing a portion of technical documentation and testing every feature.
Fibonacci numbers instead of a 1–10 scale. We switched to the sequence 1, 2, 3, 5, 8, 13, 21, 40. The bigger the task, the easier it is to tell the difference between adjacent values — making estimation much more intuitive.
Individual backlogs. Since the team isn't cross-functional, each developer got their own prioritized task list within the shared backlog.
Strict timeboxes. We set firm time limits for every meeting. If the team runs over, I gently but firmly wrap things up.
4. Depression
This is the stage where every Scrum Master asks themselves: "Did we make the right call adopting Scrum?"
I beat myself up for a long time over not doing it "by the book." The team was probably thinking: "Maybe we should just go back to the way things were?"
5. Acceptance
At some point, I had an important realization: you don't need to do it "the right way" — you need to do it the way that's right for your team.
By the end of the third sprint, we had a solid methodology in place. We'd settled into the new rhythm, agreed on how to interact with other departments, and the team started coming to meetings better prepared.
What Our Process Looks Like Now
Our sprints are three weeks long, and here's how they're structured:
Planning. All tasks are prioritized by the product manager — everything goes through them. If an urgent task comes in, it also goes through the PM: the developer picks it up and moves the lowest-priority item from their backlog to the next sprint.
Task estimation. We do this twice per sprint — at the beginning and at the end (a re-estimation pass). We use planning poker: everyone opens a free online tool, we discuss each task, and the team votes. If estimates differ by more than one step, I ask the people with the extreme scores to explain their reasoning, then we re-vote until we reach consensus or land on adjacent values and take the average.
Kanban board. Three columns: new tasks → in testing → ready for release.
Daily. Every day, 15–20 minutes. The team shares what they've done and flags any problems.
Demo. At the end of the sprint, the team presents what they've built — bugs fixed, features added.
Retrospective. My favorite ritual. I share how many story points the team closed during the sprint. The developer with the most points wins the Traveling Dragon Trophy 🐉.
We also have a great tradition of bringing something sweet to the retro — cake or pastries. When people are chewing, they filter less of what they say, and the feedback ends up being more honest. I once brought a cake to a retrospective, and the next time I didn't. In the "what went wrong" column, everyone wrote: "No cake." So now cake is a mandatory part of the process 😄.
Where We Ended Up
Here's what changed:
✅ Communication improved — both within the team and across teams. People started speaking up and sharing more.
✅ Clear boundaries of responsibility emerged. The product manager owns product development, the team owns implementation. Nobody goes directly to Alex anymore.
✅ Story points brought transparency. We can now see who's doing what and how complex their tasks are. This actually allowed us to revisit salaries for some team members.
✅ Planning became predictable. We have an average team velocity, which lets us plan product development ahead.
✅ The team sees the big picture. At the start of the year, the product manager presented the product road map — everyone now understands where we're headed and what our customers need.
✅ The atmosphere improved. The team even started their own daily tradition — at 4 PM, they all go do pull-ups together. A small thing, but it says a lot.
✅ Turnover dropped. The team became stable.
To back this up with data: I ran an anonymous survey within the team — not a single person said they wanted to go back to the old way. Nearly everyone noted that the product quality had improved.
The Key Takeaway
Don't be afraid to adapt the methodology to your reality. Textbook Scrum didn't work for us — and that's okay. What matters is embracing the core principles: transparency, regular feedback, consistent rituals — and then shaping everything else around your team.
Oh, and don't forget the cake at your retrospective. Trust me — it works.
Top comments (0)