From Storming to Performing

Alongside my role as Senior Product Designer, I spent over a year acting as the part-time Scrum Master for my squad: five developers, an Engineering Team Lead, a Product Owner and me as the Product Designer.

When I stepped into this role, management had lost confidence in us. Delivery was unpredictable and we weren't consistently creating meaningful value. The team wanted to move from Scrum to Kanban, but a new workflow alone couldn't solve what was really getting in our way.

We had talented people, but we weren't yet working as a team. Long-standing members were protecting the old culture while newer members brought different ideas. Psychological safety was low, feedback was rare, responsibilities were unclear, decisions were slow and ownership sat largely with the Product Owner.

So I started with the foundation. My role became less about facilitating ceremonies and more about changing the conditions in which the team worked.

Before we could ask for better delivery, we needed to feel safe enough to be honest with one another. That was simple to describe, but much harder to create.

We began learning and practising Nonviolent Communication through the structure:

Observation → Feeling → Need → Request

A shared structure made feedback easier to practise.

After a full training day, we used structured Hot Seat sessions to practise giving and receiving feedback. I then turned it into a team challenge: everyone had to request and give feedback to every other team member, with a small prize for the first person to complete the full loop.

The game made an uncomfortable behaviour feel more approachable, but repetition was what changed us. Feedback became more natural, disagreements surfaced earlier and we began moving from artificial harmony towards productive conflict.

Once people felt safer speaking up, we could see the next problem more clearly: we weren't always sure who was responsible for what.

Responsibilities between Product, Design and Engineering often overlapped. The assumptions this created caused friction, especially between my Product Designer role and the Product Owner role.

I facilitated a Roles & Responsibilities workshop. Everyone wrote down what they believed their own role involved and what they expected from the others. By comparing those assumptions openly, we agreed on clearer ownership across the team.

Making expectations visible helped us agree on clearer ownership.

The tension between Product and Design eased, and the team moved further into Norming. With clearer ownership, we were ready to look at another source of uncertainty: how we planned and delivered work.

We still struggled to predict delivery, and the team had little confidence in its estimates. Rather than impose another process, I brought the question back to evidence.

In retrospectives, we reviewed completed projects: what we had expected, how long the work had actually taken and why. Using those real examples, the team created shared definitions for Small, Medium and Large pieces of work.

Estimation became more accurate and delivery more predictable. Just as importantly, accountability stopped being something the Product Owner had to enforce and became something the team could own together.

That growing sense of ownership made it possible to tackle the final habit holding us back: waiting for perfect agreement before moving.

Our decisions were slow and consensus-driven, and we often over-polished ideas before testing them. To break that pattern, I introduced Consent Decision Making, built around one principle:

A shared decision-making process helped us move forward without waiting for perfect agreement.

This helped us decide faster and become more comfortable experimenting, learning and adapting. In parallel, the Product Owner strengthened the product vision and strategy, giving the team a clearer North Star to move towards.

With trust, clarity and shared ownership in place, the team's behaviour changed. Feedback became routine, responsibilities were clearer, decisions were faster and delivery became more predictable.

Management regained confidence in us, and we were finally ready to move from Scrum to Kanban—the change the team had wanted from the beginning.

But Kanban itself wasn't the solution. The real work had been creating a team mature enough to make any way of working effective.

Eventually, my Scrum Master role was no longer needed. The team could sustain these behaviours without active intervention, which was the clearest sign that the culture change had stuck.

This experience reinforced that team performance problems are rarely solved by adding more process. Our real obstacles were trust, clarity, ownership and decision-making—and those had to be worked through together.

My role wasn't to provide every answer. It was to create the conditions in which the team could solve problems together.

I also learned how important leadership partnership is. The Engineering Team Lead and I worked closely throughout the transformation; culture change cannot be driven effectively by one person alone.

Holding both Designer and Scrum Master roles also taught me to be explicit about which hat I was wearing:

“As a Designer, I recommend…”
versus
“As a Scrum Master, I propose…”

That distinction let me contribute strongly while protecting the neutrality needed to facilitate the team. Ultimately, the experience taught me how to influence without formal authority, facilitate difficult conversations and help a team become less dependent on its leaders.