The Three Phases of Scrum Teams

Be prepared for a long journey until Scrum teams can become value-driven units

I often encounter people complaining about Scrum. They claim that the framework isn’t helpful and gets in the way of software or product development. Curiously, when I ask them how long they have worked with Scrum, they become flustered. Some people even say, “Why does it matter? Scrum is simple, and we should be able to master it in a couple of months.” Well, I wholly disagree.

You cannot ask a baby to run a marathon. First, the baby learns to crawl, walk, stumble into everything, and start running. Between each phase, the baby falls, gets hurt, stands up, and tries again. Scrum is the same. It takes years, not months, to master.

So far, I’ve worked with dozens of Scrum teams, and I realized each team goes through three phases before they master the scrum framework. Let me share what I observed and how to understand what it takes to move from a water-scrum-fall to a value-driven team.

Faster Waterfall

Most teams I know are used to working with a waterfall framework. Like an assembly line, everyone is accountable for a single part of the product. In software development, it would go something like this:

1. Project Managers work with stakeholders to define the scope, time, and budget
2. Business Analysts write requirements and get them approved by business stakeholders
3. Designers create pixel-perfect UI designs based on the previously defined requirements 
4. Software Engineers implement the solution based on the requirements and designs
5. Quality Assurance Engineers test the application to ensure requirements and design are respected, and quality standards are met
6. After all of these steps, the product is finally ready to go live

That’s how I worked from 2008 until 2012. And despite all the effort to deliver something valuable, customers were often disappointed with our results. It didn’t solve their problems. In 2012, I had my first contact with Scrum, and what we did was this:

• Project Managers converted to Scrum Masters
• Business Analysts converted to Product Owners
• Software Engineers, UX, UI, and QA, converted to Scrum Developers

We had the roles from Scrum and started using the framework. The challenge is that we didn’t know how to work differently. We just got together and did more or less of the same thing we were doing, but more transparently, and we could see our bottlenecks. I call the first phase a faster waterfall, or you can call it Water-scrum-fall. During this phase, you can observe the following traits:

• Lack of accountability: Everyone is still responsible for one specific aspect of the product, and nobody has end-to-end responsibility
• Tasks-driven: The team works to break down projects into smaller tasks and organize their work to meet deadlines. Tasks are technical and can only be done by specific team members
• Unempowered team: The team doesn’t want to make decisions; they want to receive directions and requirements from higher-level management

Despite the waterfall attitude I’ve just described, the team gets used to the core parts of Scrum. They learn how to be transparent and share problems and obstacles. Also, they help each other improve their work by continuously inspecting and adapting. Slowly, the team starts moving from dependent teams to self-organized ones.

Feature Factory

After months of working as a Waterscrumfall team, they have figured out how to become self-managing teams. Siloes slowly start to dismantle, and the Scrum team can deliver features from end to end, Sprint after Sprint. The team is still output-oriented, but they work differently than before.

In feature factory teams, you can observe the following:

• Commitment to output: Sprint Goals refer to the delivery of a certain number of features by the end of the Sprint
• Velocity: Increasing velocity defines how successful the team is
• Feature Accountability: The Scrum team is accountable for the whole. Unlike waterfall, the team doesn’t have siloes anymore; they learned how to collaborate and create features from beginning to end
• Stories: Product Owners write user stories and refine them with the team. The team self-organizes and creates features for the refined stories
• Self-managing: Feature factory teams don’t expect people to decide how to deliver features and which requirements to follow. They are self-managing and can figure out how to create output without external help

When Scrum teams get into feature factory mode, they become proud of their velocity and capacity of shipping features at the speed of light. The more they deliver, the more stakeholders applaud. But with time, they realize something is missing, and that’s when the giant wakes up and starts challenging the way they work.

The feature factory is an anti-pattern because the team focuses on producing output while ignoring its outcome. Yet, I perceive this phase as a natural step before the team develops a value-driven mindset.

“You never question the truth of something until you have to explain it to a skeptic.” - Donald Miller

Value-Driven

When Scrum teams master creating features and become self-managing units, they soon realize they are trapped. They start challenging the reason they receive prescriptive roadmaps, why people outside the team define what they need to do, and which problems they are supposed to solve.

Value-driven teams want to create value beyond features and solve problems that users care about. But they may have their hands tied as they receive solutions to implement without knowing which problems to solve. Getting to a value-driven team is demanding, and it will require a lot of courage to challenge the status quo.

It’s important to understand that the transformation needs to happen  throughout the entire organization, not just within Scrum teams. Teams will be trusted to make decisions on how to create value instead of how to deliver features. Such change may take years instead of months.

Empowerment isn’t a given, and it won’t drop down from the sky. Scrum teams must earn it by developing trust with the organization’s leadership.

Value-driven teams are trouble makers, so don’t mess around with them. Not everyone will like them initially because they ask too many questions before getting their hands dirty. Yet, in time, stakeholders will be glad such questions were asked because they potentially avoided wasted time and resources and enabled teams to focus on creating value over fulfilling wishes.

Final Thoughts

There are no shortcuts to mastering Scrum. You’ve got to be willing to go on a transformational journey. 

It will take a while for teams to become value-driven units, and the journey will be a mixture of excitement, learning, and painful failures. You will get hurt, scar, thicken your skin and sharpen your mindset. Give yourself time, and accept you won’t have all the answers, but knowing the questions are often more relevant. 

Embrace the unknown, and keep moving forward.

Use the Japanese martial art concept in your favor: Shurari, three steps to mastery:

• Shu: Obey. Let the traditional wisdom drive you until you learn and understand it
• Ra: Detach. Detachment from traditional wisdom. Break commonly known rules and learn from experience
• Ri: Separate. It’s time to separate and create new rules. Based on what you learned, develop new ways and transcend

“It’s not hard to make decisions when you know what your values are.” - Roy Disney