The Three Phases Scrum Teams Go Through to Become Outstanding
Be ready for a long journey until Scrum teams can become value-driven.
Be ready for a long journey until Scrum teams can become value-driven.
Originally published in GoRetro
I often encounter people complaining about Scrum. They claim 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 get confused. Some people even say, “Why does that matter? Scrum is simple, and we should be able to master it in a couple of months.” Well, I disagree entirely with that.
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 to master it, not months.
So far, I’ve worked with dozens of Scrum teams, and I realized each team goes through three phases before they master the framework. Let me share what I observed and how to understand what it takes to move from a watterscrumfall 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 be like this:
Project Managers work with stakeholders to define the scope, time, and budget.
Business Analysts write requirements and get them approved by business stakeholders.
Designers create pixel-perfect UI designs based on the requirements previously defined.
Software Engineers implement the solution based on requirements and designs received.
Quality Assurance Engineers test the application to ensure requirements and design are respected and quality standards are met.
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 the following:
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 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 Waterscrumfall. 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 is responsible from end to end.
Tasks-driven: The team works to decompose 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: During this phase, the team doesn’t want to make decisions but 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 still has an output focus, but they work differently than previously.
In feature factory teams, you can observe the following:
Commitment to Output: Sprint Goals refer to delivering 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 how to solve stories instead of breaking them into technical tasks.
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 factories, 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 within time, they realize something is missing, and that’s when the giant wakes up and starts challenging how 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 why 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 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 happens in 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 fall from the sky. Scrum teams must earn it by developing trust with the organization’s leadership.
Value-driven teams are troublemakers, don’t mess around with them. Not everyone will like them initially because they ask too many questions before getting hands-on. Yet, within time, stakeholders will be glad such questions were asked because they potentially avoided waste and enabled teams to focus on creating value over fulfilling wishes.
With value-driven teams, you can expect to observe the following:
Focus on solving problems: Every day, they strive to create solutions that solve real end-users problems and drive business outcomes. They don’t fall in love with solutions but with problem-solving.
Questions over answers: Curiosity drives their actions. They ask four or five times more questions than give answers. First, they want to understand, then talk about potential solutions.
Argue intensively and commit: You may get shocked by observing value-driven teams exchanging. They are intense and get excited quite fast. They are never afraid of challenging each other because they want to use their time to create value faster. Yet, they argue and commit and then bond with each other to deliver meaningful solutions.
Learn from real customers: They do their best to continuously learn from their customers and uncover hidden opportunities. They do not assume to know it all. On the contrary, they have a beginner’s mindset and strive to gain evidence from experiments.
Final Thoughts
There’s no shortcut to mastering Scrum. You’ve got to be willing to go on a transformational journey.
It will take a while until teams become value-driven units, and the journey will be a mixture of excitement, learning, and painful failures. You will get hurt, create scars, 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. Shu-Ha-Ri, three steps to mastery:
Shu: Obey. Let the traditional wisdom drive you until you learn and understand it.
Ha: 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
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊