It is no secret that, often, the weakest link in the Scrum chain is the product owner. He or she represents “the business," but having this role efficiently filled is often the exception to the rule.
That's old news. For decades it has been a huge challenge to persuade “the business”—i.e., the management layer—to get more deeply involved in its projects. This is surprising for three reasons:
- More and more work is carried out in a project-like manner.
- Poor project performance reflects directly on the company’s bottom line.
- Research shows that active executive sponsorship is the key driver to project success.
The figures speak for themselves. The illustration below, from PMI’s Pulse of the Profession 2016, shows that various project targets are considerably more likely to be achieved when executive sponsorship is part of project management.
Nevertheless, only three in five projects have engaged executive sponsors. The findings also show that, if you were to do one single thing to improve project results, you should educate managers to fulfill the role of project sponsor.
Business sponsorship in scrum
The above facts can be directly transferred to Scrum, where the product owner can, more or less, be translated to the traditional project sponsor, but on top of that is responsible for a number of project management-like activities such as:
- Tracking the total work remaining after each sprint
- Assessing progress
- Planning releases
- Owning the budget
However, on Scrum projects you often find that the only thing the product owner keeps top of mind is the product backlog. At least the product owner knows that this is the role's responsibility, but what about the other activities noted above?
Sadly, you very often meet product owners who are not aware of the activities within their area of responsibility. To gain the full benefits of Scrum, I firmly believe you should work as described in the Scrum Guide, written by Ken Schwaber and Jeff Sutherland.
The bottom line is that, if you do not have an active business sponsor, your project is more than twice as likely to fail. If the product owner role is not adequately filled, you are not doing Scrum in the first place, and you are not likely to gain the benefits from being truly agile. The result will almost certainly be less successful projects measured against the responsibilities mentioned above.
The agile shift
Changing from a waterfall mindset to agile represents a paradigm shift. Scrum looks deceivingly simple, but if you dig below the surface, you soon realize that the dynamics are completely different compared to traditional methods.
- Scrum is a team-centric system, moving from pushing tasks to project teams to letting the team members pull tasks when they are ready.
- Supply and demand is balanced, and trust is a key word.
- Scrum development teams pick the work for each sprint based on their capacity, and they control and measure their own work during sprints.
This is not easily accepted in organizations where, for decades, steering committees have been the escalation point and strategic project decisions-makers and project managers have been responsible for project outcomes. Old habits are hard to break, and both parties may not be very tempted to give up authority.
Why agile needs business leadership
Thus, moving from waterfall to Scrum very often means that you meet every morning, you are standing up, and the team reports to the Scrum master, which merely is a new title replacing the old role of project manager.
You may appoint a product owner, but this person may not know what the role entails. You sometimes find the product owner role spread across several persons (I have experienced as many as three), and you may also see that responsibilities are delegated to others when the product owner does not have enough time to spend with the scrum team or participate in sprint events.
You may work in sprints, but you don’t have clear sprint goals. So the scrum board ends up being a task board, nothing more. You work with a new vocabulary and a new set of roles, while sticking to old project habits. You are not playing by the agile rules, but rather you are doing waterfall in disguise.
It takes strong leadership and strong business support to move from a traditional project system and mindset to Scrum. It requires training of many parts of the organization, and it requires patience and persistence.
Don't underestimate the force of resistance to change
Even if you know that your project performance is not where it should be—that is, even if you know that organizational agility has proved to generate better project results, and even if you accept that you should improve—it’s just so easy and comfortable to keep on doing what you always did. Even if you have decided to work with Scrum.
Don’t fall into the trap of believing that scrum is so simple that a couple of days of training with a few Scrum masters will make any significant difference in an organization where everybody else has no idea about how they should support the Scrum teams.
If you do not accept the fact that projects are quite complex systems and, besides all the technical stuff, they involve a number of people from different parts of the organization (maybe subcontractors, vendors, etc. who interface in a number of ways), you may make the mistake of treating projects as trivial endeavors. You may not see the shift to Scrum as a big deal, and you may not pay enough attention to this essential human factor: Most humans don’t like change.
Agile reveals the problems more quickly
Agile does not change the complexity, the budget, the risks, etc. associated with projects. It just provides a different way to control them. Agile does not fix any malfunctions in your project system, but it makes them become more visible, and you can decide to act on what you see.
Using Scrum as intended will, over time, result in changes to the project DNA, but the benefits of those changes will come more quickly if the move to agile is done organization-wide. Typically, the move to agile starts bottom-up, but if you want to gain optimal benefit, true business involvement at the top is key.
Therefore, business people’s view of their role in agile projects must change.
How to convince business people to get more deeply involved in agile projects
I have often asked myself how to crack the code and convince business people to wholeheartedly take on the product owner role. I have tried several different things, but what works best is letting the results speak for themselves.
If implementing Scrum is not a business decision made for the right reasons, with a budget attached, but is instead reluctantly accepted, I can suggest the following:
1. Volunteer for a project under time and/or budget constraints with high management attention.
2. Promise delivery predictability using Scrum under the following conditions:
- You get a dedicated team of motivated, mature professionals with the right skills.
- You are assigned a dedicated product owner with a strong business mandate.
- You agree that no one can break the scrum team as long as the project runs.
3. Follow the Scrum rules and other good agile practices:
- You do not cut corners, for example in your estimation efforts.
- You measure rigorously, so you can always explain how you are performing.
- You keep your product backlog in good shape and up to date.
- You update release plans, budgets, etc. to maintain full overview.
- You stop starting and start finishing to optimize flow.
Show how Scrum works
You might argue that anyone can show predictability and deliver under the above circumstances, and you could be right. But what I have proved on real projects is that Scrum works if you get the right level of business involvement and commitment and play by the rules.
So why not use that recipe on all your projects? Share your experiences here in getting management involved with your agile projects.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
