In the last few years, there has been a rise in the use of Agile methodologies. Now, everybody wants to be Agile, and although this shift makes sense, Agile is not for all types of projects (we’ll delve into this topic further in a future article). In this article, we will focus on SCRUM and one of the roles of this framework: product owners (PO).
Just to refresh your memory, there are 3 main roles in the Agile framework:
- Scrum Master: the conductor of the orchestra. Scrum Masters know the framework and the Agile world. They remove any blockers the team may face and guide the PO in their role if necessary. Their main goal is to teach SCRUM to those they work with, aiming to create high-performance teams.
- Development Team: the builders, the ones who develop the product. They have big responsibilities, like knowing how much work they will agree to deliver each sprint; they need to be a self-managed team as well and participate in all meetings for better results.
- Product Owner: “the voice of the client”. A PO knows the product and represents the interests of a client or a group of clients. They are responsible for keeping the product backlog in order, adding the stories to it in the right way, and refining tickets with the team, among other tasks.
If you are implementing SCRUM and each role does what it’s meant to do, your probabilities for success will rise. But, after years of experience and talking with teams from around the world, we have found that one of the main reasons projects fail when using SCRUM is due to the poor execution of the product owner role.
The following is a list of scenarios and key behaviors to watch out for in your project to avoid problems for your team, the overall project, and your company.
Pushing the Team Beyond Reason
One of the most common issues that a SCRUM team may face is incorrect projections. Sometimes a PO may plan how much work a development team will deploy for a long period of time (in terms of features or with story points) but suddenly, what the team is delivering is not enough.
What happens next? The following is a scenario of a sprint planning meeting:
- PO: Alright, during this sprint we need to finish these 15 stories. I have already made all arrangements and this is going to be our next sprint.
- Development Team: ok… but if we look closer at the points, we are talking about 50 story points. This is way more than what we deliver according to our velocity!
- PO: Yeah, but since we already have a due date, we will need to include the bulk of them into this sprint. It will be the same for the following sprints.
Sound familiar? Sadly, for a lot of people, this situation is commonplace. If we take a moment to analyze this situation, there are three main issues:
- The Development Team is in charge of knowing how much they can commit to delivering in the next sprint. It’s not a bad idea for a PO to have a list of items selected as candidates for the next sprint, but eventually, you might have to carry over items from the last sprint, and the complexity of new items will require more time.
- Even if there really is a deadline, the negative side effects of this type of pressure are like a snowball rolling down a hill.
- It’s important to clarify that you may have a delivery calendar, but this needs to be refined after each sprint. Otherwise, you’re turning an Agile project into a fixed bid project using SCRUM, something that, most of the time, leads to disaster.
Unsurprisingly, the team will get tired of this pace and you will start seeing more items being carried over from previous sprints. Since the list is already defined every time, each sprint planning meeting will be even worse: extra hours of work for the development team, exhaustion, and, eventually, not meeting deadlines as well as team members leaving the company.
This Seems Pretty Easy
Even though the refinement meeting is not a formal ceremony in the Agile framework, it’s really useful to have a better context of the work ahead and it allows you to prevent really long sprint planning meetings.
But we may see scenarios like the following (using story points with Fibonacci sequences):
- PO: So guys, this is the ticket we need to estimate. It seems to me that this is a pretty easy/straightforward/small effort.
- Development Team: Well, we need to work on a new UI, connect to a new endpoint, and add some validations. QA will need to test several scenarios as well, and we might need to refactor some code...this is a 3.
- PO: Hmmm, I don’t see this as a 3. For me, it's like a 1 or 2 maximum. I know you guys can do it, I believe in you.
We’ve heard a lot of stories like this and have experienced similar scenarios ourselves. What will happen here? Exactly the same as in the previous example. The team will lose confidence when making estimations if they are always rejected and will eventually get tired. They will come to regard this type of meeting as a waste of time. Again, a small number of items will be carried over each sprint and it’s possible to think that something is wrong with the team since they are not delivering what they promise or what they showed on previous velocity reports. It’s a snowball effect everywhere.
The Dev Team is a Tool and Not My Ally
This scenario is really sad. If you really want a project to fail, just isolate your team and don’t let their voice be heard throughout development by asserting “I know what the client wants.”
Let’s be honest: sometimes the client doesn’t know what they want or then again, they do know but they are not clear if what they want can be achieved using code. In this scenario, the voice of the experts is essential - actually, it’s essential in all scenarios. And who are the experts? As Lawrence M. Miller (an expert with more than 20 years of working with Agile and Lean methodologies) says: “developers, workers, the ones that make and build the products are the World Greatest Experts.”
So, it’s necessary to take your team’s perspective and ideas into account. You can’t ignore their voice; if you do, it’s best to start writing a digest of why the project failed from the very beginning.
Other Bad Signs
The following are some other bad symptoms that may lead to disaster:
- Change after change keeps coming in every time feedback is received; each round of testing or feedback from clients becomes a ticket. The PO really needs to filter what is necessary and what can be tackled during future sprints.
- “This effort requires a backend change as well but it is not ready, so let’s make assumptions about the response”. Hearing this phrase during sprint planning is bad news since it will no doubt imply a rework in the future.
- Phrases such as: “QA needs to move on and just test the happy path.”
- Instances such as: “Hey guys, I need to add these 3 extra items to the sprint that we started 4 days ago.”
What Can We Do?
Sometimes the above scenarios happen due to bad planning or lack of information. So, the first thing you need to establish is good communication: this is the greatest tool the team can have. Even though it may seem obvious, team members need to talk to each other in order to be successful.
If you’re part of the dev team, speak up. You need to be able to express and convey your opinions/ideas, particularly in situations such as the above scenario regarding the underestimation of story points. Nobody is the enemy here: the whole team is on the same side. If you feel you’re being ignored, there is someone who is there specifically to help you: the SCRUM Master. The latter is in charge of helping you with any blockers you may have, and sometimes these blockers have a name and height.
If you are a SCRUM Master and the scenarios we’ve covered in this article keep popping up, well, you’re doing it wrong. Your main task is to guide the team (including the PO). If any of the above situations keep happening and you do not prevent them, then there are two framework roles with issues here. Help the PO, explain the reasons why they’re not doing things right, and teach them how to achieve better results.
If you are a PO and you’re reading this, we suggest you do some introspection and think about your current project, its status, and your relationship with your team. Even if this article does not apply to your case, as a PO it’s always good to have a list of things to avoid.
