How It Began
A year ago, I started to lead a team as Scrum Master for the first time, and to be honest, it was barely holding it together. Deadlines were slipping. Endless meetings and all of them felt like time-wasters. What about collaboration? Minimal at best. The phrase “we’ve always done it this way” or “we’ve handled with experience” echoed louder than any call for change. Morale was low, ownership was missing, and any mention of “agile” was met with rolled eyes or blank stares.
Back then, I didn’t have a magic fix but I knew we couldn’t keep going the way we were. What followed was a long, sometimes, messy, but ultimately rewarding journey of transformation. Not overnight. Not without setbacks. But step by step, the team went from disconnected and reactive to engaged, aligned, and truly agile, not just in process but in mindset as well.
In this post, I want to share that journey as a practical guide for what worked, what didn’t, and what truly made the difference in turning a low-performance, unagile team into one I’m proud to say from some perspectives, it’s a high-performing, adaptable force.
Chapter One
Before we could fix anything, we had to understand why things were broken. So at first, I just wanted to join on daily standup to observe and try to understand what the team was working on. Jumping directly to the solution like bringing in a new tool or running a quick agile workshop is just a band-aid. The real issues were much deeper than that. So I just focused on listening and observation.
In informal chats and sync-up meetings, patterns started to emerge. Some team members didn’t know what is their work or how it connected to the bigger picture and delivering output for the project. Others felt like their voices didn’t count, decisions were handed down without discussion. Some had simply burned out from constantly shifting priorities and unclear expectations.
And beneath it all? A quiet fear of failure. Of speaking up. Of changes.
We wrote everything down in retrospective session. We did it internally first. No blaming, no judging, just honest reflection. At that time we weren’t dealing with laziness or lack of talent. I guided the team to focus on dealing with misalignment, mistrust, and a system that didn’t support growth.
That’s when it clicked: before any agile practices could become as our habit, we had to reset the environment the team was working on. We needed clarity, safety, and purpose, and only then we could move forward.
Chapter Two
Once we understood what was holding the team back, the next step wasn’t to download the Scrum Guide. It was a good time to have a conversation, especially about mindset.
I talked, and I provided training sessions for the team through multiple restrospectives. There was no slide, no buzzword. Just a simple question: What is the better way we could do together?
At first, it was quiet. Then slowly, answers started to come:
“Knowing what’s expected of me.”
“Being able to ask for help without feeling judged.”
“Having a say in how we work.”
And just like that, we had a foundation.
This wasn’t about agile for the sake of agile. It was about building a team culture where people felt safe, trusted, and empowered to do their best work. We talked about values like transparency, focus, adaptability, and respect—not in a theoretical way, but in the context of our own challenges. What would it look like to be transparent when priorities change? How could we become more adaptable without chaos?
Instead of saying, “Here’s how agile works” we asked, “What’s getting in our way—and how might we work differently?”
The shift was subtle but powerful. Agile stopped being a set of rules we had to follow and started becoming a mindset we chose to adapt. That was the turning point.
Chapter Three
Once the team began opening up, it became clear what had been missing all along: trust.
Not the surface-level, “we’re polite in meetings” kind of trust—but the deeper kind. The kind where people feel safe enough to say “I’m stuck” “I disagree” or “I messed up”.
In the past, mistakes were quietly swept under the rug. People hesitated to ask questions because they didn’t want to look unprepared. Feedback rarely flowed upward. And so, collaboration stayed shallow, and problems festered.
To change that, we had to model vulnerability from the top.
I started sharing more openly—admitting when I didn’t have all the answers, asking for feedback on how I was showing up as a leader. In retrospectives, we made space for real talk—not just “what went well” but “what felt frustrating” and “what are we avoiding?”
It was awkward at first. Some people held back, unsure if it was really safe to speak freely. But over time, those moments of honesty started to multiply. Someone admitted they felt overwhelmed. Another shared they didn’t fully understand the user story they were working on. And instead of criticism, they should have the support as they need.
We celebrated those moments, not just project wins. Because that’s when real growth began.
Psychological safety isn’t built with a workshop. It’s built one conversation at a time. And as the trust grew, so did the team’s willingness to collaborate experiment, and take ownership.
Chapter Four
Once the team felt safer and more connected, the hunger to actually get better started showing up.
People started asking questions like:
“How do other teams manage changing priorities?”
“What’s the best way to break down a big task?”
“Is there a better way to track what we’re working on?”
That’s when we knew they were ready—not for a lecture, but for learning.
I never recommend throwing a bunch of processes for the team. Instead, we introduced tools and practices gradually, and always in context. When people struggled to stay aligned, we introduced the daily stand-up—but kept it lightweight, focusing on conversations, not status reports.
One of the biggest wins? Pairing people up. Not just for coding or testing, but even for planning or backlog refinement. The knowledge transfer that happened informally in those sessions outpaced anything a course could deliver.
We weren’t aiming for textbook agile—we were building our own version of agility, shaped by the team’s needs and supported by the right tools, at the right time.
And because the team had a voice in shaping how we worked, they owned it. It wasn’t something being “done to them”—it was something they were growing into.
Chapter Five
Now that the team was learning and experimenting, we hit another realization: progress without direction is just motion. I let the team members communicate directly with customer and challenge them about the requirement and how we should do it. I remember we used to have a lot of sessions to clarify every single details and co-create our vision on building product.
What came out wasn’t just goals—it was alignment. Suddenly, people weren’t just delivering features; they were supposed to solve problems. And then they started challenging backlog items that didn’t connect to that bigger picture. They asked better questions. Priorities became clearer. Energy became focused. So instead of “Here’s what you need to do” the message became “Here’s what we’re trying to achieve. Let’s figure out how to get there together.”
And just like that, ownership kicked in. People weren’t waiting for instructions anymore, they were driving the work.
Chapter Six
With clarity in place and momentum building, the next step was to shift from working in parallel to working together.
Before, collaboration was limited. Developers coded in silos, testers came in later, and PO was often the last to know when something changed. Handoffs were frequent, and accountability was blurry. If something broke, fingers started pointing instead of hands reaching out.
So we made a conscious shift—from roles to responsibility.
One of the first thing we tried was swarming. When a high-priority bug came in, we gathered around it as a group—devs, QA and customer—we are one and tried to solve it together. No delays, no “that’s not my task.”, just one team, one goal. And the results were electric.
We started pairing more—on tricky features, planning sessions, and even documentation. People began to step out of their lanes, not because they were told to, but because they wanted to help each other to complete their work.
We also made ownership explicit. Rather than assigning tasks, I let team members pull them. And when someone picked up a story, they owned it from the very first to end. Not in isolation, but with full support from the team.
We celebrated those moments—when someone raised their hand to lead a spike, or when a developer jumped in to help QA test a release. Over time, that ownership mindset became part of who we were.
It wasn’t about being perfect. It was about being accountable—and being there for each other.
Final Chapter
By now, I think the team had come a long way—but if there’s one truth, it will be the work is never done.
Improvement isn’t a one-time initiative. It’s a habit. A rhythm. A mindset we had to keep nurturing.
So we leaned into retrospectives—not as a checkbox meeting, but as our team’s heartbeat. Sometimes they were structured with templates. Other times they were casual like a conversation. We asked some questions like “What slowed us down this sprint?” or “what small changes would make a big difference next time?”. And after that, we acted. Even if it was just one tweak at a time. Better backlog grooming, more focused stand-ups, less WIP, a new board layout, … We treated every small improvement like a new experiment.
We also started tracking a few light metrics—not to judge, but to learn. Things like cycle time, team happiness, how we were getting interrupted. These weren’t KPI weapons, they are mirrors. And sometimes they sparked as the best conversation tools. Nonetheless, we still hit bumps. Not every change worked, others didn’t bring much benefit to the team. Some weeks felt like a step backward. But now we have the mindset and the tools to learn and adapt. And that was our real win.
