Firefighting Puts Scrum Teams and Value In Opposite Directions
When all that matters is fixing urgent issues, no time is left to do what could lead to outstanding results.
When all that matters is fixing urgent issues, no time is left to do what could lead to outstanding results.
More! Give me more!
Business pushes teams to deliver more output. All they want is to keep the engine running as fast as possible. Developers become feature machines, and their mission is to maximize the output at all costs. Nothing is more important than increasing the output!
Such unprecedented pressure only leads to more and more disappointments. Scrum Teams may deliver more features, yet they increase the tech debt by reducing the quality. Bugs arise more often than ever. Eventually, the Scrum Team becomes a firefighting team. Day-in, day-out, all they do is fix the bugs caused by the features stakeholders wanted, and nobody needed.
When teams fall into the firefighter mode, no time is left to do what matters most; solving end-users REAL problems.
I’m tired of pointless discussions about more features. I’m done with pleasing stakeholders. It’s time to stop firefighting and start doing what Scrum Teams should do; deliver value sooner!
“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.”
― Marty Cagan
Allow me to share some insights on how to escape from the firefight trap. I often get myself trapped in this situation; I’d like to walk you through what I learned about it.
Why Do Scrum Teams Become Firefighting Teams?
From my experience, I’ve never seen a company with enough development capacity to fulfill all the business’ wishes. Stakeholders always want more than Scrum Teams can deliver. Therefore, how Product Owners deal with this situation is decisive on the future of the Scrum Teams.
Product Owners face a constant conflict: business wishes vs. development capacity. I see some possibilities to address this issue:
A little bit of everything: the team’s capacity is transparent to stakeholders, yet they are reluctant to reduce the pressure. Therefore, Product Owners try to do a little bit for everyone. You can identify this scenario with extensive backlogs. This strategy tries to please everybody and ends up pleasing nobody.
Do nothing: Product Owners can also ignore this conflict and take the passenger seat. Stakeholders decide what goes into the Product Backlog, while Product Owners behave like waiters; they take orders and send them to the team. This scenario leads to confusion. Nobody knows what to reach, and yet they receive unbearable pressure to deliver more. You perceive this scenario with the constant change of directions.
Focus on the value: Successful Product Owners master the art of saying no. They ensure Scrum Teams can focus on the outcome instead of the output. What doesn’t help deliver value sooner doesn’t go to the Product Backlog. There are no promises like, “I will put it in the backlog and address it in the future.” You can identify this scenario once backlogs are lean and provide a clear direction.
Addressing conflicts is tough. Not everyone is either willing to do it or ready for it. When Product Owners avoid conflicts, confusion and poor results are the ultimate outcomes.
In the short term, it’s easier to please all stakeholders. However, to please everyone, the team has to cut corners, inevitably compromising the quality. In the long-term, the code-base becomes unsustainable, and the bugs pile will be ever-growing.
Scrum Teams will have little or no chances of success if they are trapped in firefighting mode. To deliver value, Scrum Teams need to see farther than what’s in front of their noses.
Delivering Value Instead of Firefighting
Resistance is the biggest challenge I face as a Product Owner. Sadly, many companies still treat product and tech teams as support areas to the business. Stakeholders want to use tech teams to fulfill their needs. Such companies are missing the point; technology is the business.
It’s gone the time where technology was a means to an end; now, technology is the end. Until companies understand that, they increase their chances of being disrupted by their competitors.
Without solid product management, Scrum Teams will fall into firefighting mode. Product Owners have to be bold to help teams avoid this pitfall. Here are some attitudes I learned during my journey:
Say NO: don’t be afraid of pissing some people off. Your job as a Product Owner is not to keep your stakeholders happy but to ensure the team delivers value fast. For me, saying yes is the same as getting a new responsibility, and saying no is a decision. Once you master the art of saying no (understanding when and how to reject something), you can ensure clarity and let teams focus on what matters most.
Ask questions nobody is asking: it’s shocking how fast people jump into execution. Some bugs seem critical, but they happen to less than 1% of users. Some features seem promising, and yet there’s no evidence end-users need them. Sometimes all we need is someone asking tough questions, e.g., “What happens if we don’t do that?”, “Which evidence do you have end-users have this problem?”, “How many users are facing this issue?”
Understand the why before talking about solutions: discussing how to implement a solution is one of the easiest things on Earth. However, understanding which problem the solution solves and why that matters is the difference between great teams from ordinary ones. Great teams solve significant problems, while ordinary teams implement pointless solutions.
“But one of the most important lessons in our industry is to fall in love with the problem, not the solution.”
― Marty Cagan
Without a Clear Priority, Scrum Teams Have No Chances of Success
Building successful products is hard. Although Agile aims to shorten the delivery cycle, shortcuts will lead to bad results, e.g., building solutions with invalid assumptions. Patience and focus are what lead to success. That’s why we cannot skip key steps while building products. It’s pointless to agree on which features to implement without clarifying the product strategy. First things first.
First comes a product strategy. Maybe you could start by answering these questions: Why does the product exist? Which problem does it solve? What’s the product vision? Once you get them answered, then you can talk about which features could contribute to your strategy. However, if you don’t answer such questions, whatever you prioritize will lead to confusion.
A Product Strategy doesn’t need to be complex. It needs to help you make decisions on what matters most.
In my opinion, the difference between solid Product Owners and regular ones is that strong ones won’t settle until they get critical questions answered. In contrast, regular Product Owners will jump to execution even without a clear strategy.
To conclude this post, I take Melissa Perri’s definition of a good Product Strategy. Without that, everything can arguably be a priority.
Product Strategy is a system of achievable goals and visions that work together to align the team around desirable outcomes for both the business and your customers.
