Why Scrum doesn’t work for you
Yes, we have been following Scrum for some time now and yes, it’s a viral term that many have come to dislike due to the tremendous hype. Although it has been proven to be successful for many organisations, it’s only a means to an end and definitely not a universal truth for everyone. In fact, one specific weak link can become detrimental for the product’s success — the Product Owner.
The importance of the Product Owner
Roughly speaking, in any given Scrum team it’s the developers’ job to do the work and it’s the Product Owner’s job to ensure the rest of the team is focusing on the right work. That means the PO is responsible for increasing the ROI made in that team by an organisation. Some of the daily tasks of a Product Owner include:
- Syncing information between the Developers, Marketing and Management — involves a somewhat deep understanding of each field.
- Understanding the customer’s needs and issues . The PO has to become an expert in the problem being solved by the product — involves close contact with the target audience.
- Syncing information with the Sales and Support teams — again, contributes to the understanding of the problem.
- Making sure that development is progressing within the set budget and all deadlines are being kept.
- Creating user stories, translating those into tickets (tasks) and prioritising them based on importance, in order to set the product direction. The tickets should involve extensive details on every feature so the development team can understand what must be done and why. It will often involve the creation of mock-ups.
- Market research, related to the industry, in which the product will be situated, in order to understand the competitive landscape — often involves attending conferences and subject matter events.
- Working with QA to make sure the product works correctly and according to the given specification.
- Resolving any issue that will inevitably arise within the team. A Scrum team involves different people with different personalities working together, so normal, every day friction is bound to take place. It’s the PO’s job to solve those issues before they get out of hand and become an obstacle for the product delivery.
Even after the successful product delivery the Product Owner has to work closely with the Sales and Support team to make sure they know how to appropriately communicate the product values and how to handle customer issues that arise.
Wait, so why do Scrum teams fail?
Despite the huge list of responsibilities, related to the Product Owner’s work, the role’s importance is often underestimated. Even more so by the Po’s themselves. They often remain silent during team sprints, giving the spotlight to developers discussing technical issues, feeling that it is somehow more important than the overall product direction.
Surprisingly little resources are spent in building the required skills in a Product Owner, compared to the rest of the team, even though the final responsibility for an eventual product failure will lie precisely within the PO. This is why a lot of organisations deciding to adopt a Scrum approach ultimately don’t achieve the results they were expecting or even fail altogether.
The most important step you can take to prevent such a grim scenario is to work towards increasing the PO engagement within the team. The rest of the Scrum team has to better understand the vision of the product, to know which opportunities exist for cutting corners and where resources shouldn’t be spared. Further, the PO has to be as detailed as possible about every task at hand. The team shouldn’t be forced to make assumptions without the PO concerning product functionality or the result may end up nothing like intended. Each uncertainty has to be covered on the spot, before the sprint review.
Much of the unclarity can be alleviated through a properly kept backlog. Here comes another issue, though — being overly detailed with ticket description can leave little to no creative freedom for developers, thereby making their job boring or even reducing chances for innovative approaches. It’s a subtle balance, really.
The Product Owner is arguably the most important role in any given software development project and while the role’s majority of functions may seem like soft skills, it’s far from granted that the PO will automatically adopt the position’s requirements once the company decides to go for Scrum. The transition to Scrum must focus largely, even perhaps revolve around building up a solid PO figure that will lead the development direction into a successful product.
You can check out the original post on our homepage.
