The Big Picture of Scrum

I’ll be the first to admit, I have a love/hate relationship with Scrum.

Scrum is a great project management framework. At only 19 pages long, the official Scrum Guide is an excellent starting point for teams that are working on projects of all sizes. It is clear, concise, and doesn’t require a Black Belt or (contrary to the belief of some) a certificate to get started.

This being said, Product Managers – when it comes to Scrum — use it, but stop spending large amounts of time trying to perfect it.

This is not to say that Scrum is not important. What it is saying is that project management is a small part of the role of a Product Manager, and Scrum is one of many solid project management frameworks. Spending excessive time focusing on improving Scrum has:

• At best – a greatly diminishing return on investment of your time
• At worst – a net-negative impact on your team, as other critical areas of the job are being ignored, bottlenecks form, and customer feedback dries up

Product Management and Scrum

Product Management is responsible for the big picture of the product, and because of this, it’s a big job. It requires taking an idea, whether that be the product as a whole or a single feature, from inception through launch, and then supporting it as it grows. As seen in the diagram below, there are many tasks involved with this process.

Scrum focuses on the detail-level of a product, and is naturally a time-intensive process – daily ceremonies, constant user story writing, backlog grooming, the list goes on. The result is a large baseline of time spent on project management.

It’s important to remember that Product Managers are equally responsible for the high-level direction. To do this successfully, Product Managers must be able to think contextually, meaning they can shift their viewpoint of the product between a high-level and detailed point of view based on the task at hand.

Spending a disproportionate amount of time focusing on the details can cause a Product Manager to get lost in the weeds. They become distracted, and lose focus on what’s important in the long run: the vision, strategy, and financial health of the product.

Perfecting Scrum is Hurting the PM’s Value

Between the overwhelmingly high number of articles (this one included), and the many available Scrum certifications, there is an unproportionately high focus on Scrum in the software industry. For a new Product Manager, the focus on Scrum inflates its perceived value.

Scrum is ultimately a project management tool, and the focus on Scrum perpetuates a project mindset. A project mindset, if not kept in check, can lead to an internal focus (backlog, what’s being built) with success being tied to output.

Although Scrum is an agile project management framework, in the big picture, project management is an efficiency tool. Efficiency is an internally focused metric — it’s best measured by velocity and volume. But the goal isn’t just to ship features fast, it’s to solve users problems and ship value.

In an internally focused team, the goal is to get as many features out the door as possible. Testing and validation are limited to whether the new feature works or not. Although ensuring that new features work is very important, it’s more important to validate that the feature properly solves the customer problem. This can only be done through an external focus on user feedback and user testing.

Efficiency can’t measure value. As user stories and feature requests pile up, it’s natural to want to chew through as many as you can. But the goal is to build the right things, not everything. Focusing on the customer allows you to chose the right things.

The central benefit of having a Product Manager is to bring the outside in, and help the team understand the needs of the customers. The main goal is to create context, and answer why something is being built. Creating a product backlog and user stories is the end result of a much larger process.

Overall, creating context is making sure the team understands how user stories fit into the big picture. This can be done through involving the team in customer meetings, or through user story mapping. Outcomes over output.

Product Management Focus

The more time a Product Manager spends perfecting their user stories, or researching how to improve the teams velocity (is this even possible?), or if the team should use rock-sizes or the Fibonacci sequence to do estimation (should a team even estimate?), the less time they have to spend on other important stuff.

If the diagram earlier didn’t emphasize the scope of the Product Management role, the diagram below should paint a good picture of the tasks as a whole; along with the proportion of project versus non-project orientated tasks.

With project management being such a small part of the role, it is important not to get carried away focusing on it. The return on investment on your time will be negligible. It’s a situation where good enough is most likely good enough.

All tasks are subject to the law of diminishing returns, and the 80/20 rule - 80% of results come from 20% of efforts. The more we focus on a single item, the less return on investment we get from it. In addition, an over-focus on one task means that other tasks remain stagnant. It’s important to keep the ball rolling on all aspects of the job, as this reduces the chance of product stagnation.

With Process, Often Less is More

The more process in place, the more rigidity, the less flexible a tool becomes. True agile tools should be light and easily adapted (or even outright discarded) when a better tool or process is discovered.

Every business and product operates in a unique and complex environment. It’s impossible to generally optimize complex tools (such as scrum) beyond the core principles. They need to be locally optimized. A single tool or template does not fit every environment.

The best process improvements are often discovered organically by the working team, through trial and error. Many of the Scrum “best practices” that are recommended online worked for a single team, but it doesn’t mean it will work for yours. In fact, it could slow you down.

Humans have a bias where we tend to look to fix situations deemed as broken by adding a solution, rather than by subtracting barriers. This is called intervention bias.

When a framework or process is adopted and it seems inefficient, we look to add additional steps in an effort to speed up. In reality, our first step should be determining which steps of the current process are causing issues, and stripping them out.

The more complexity a tool has, the harder it is to bend the tool to fit the team. The team has to bend to fit the tool, even if the result is being less efficient.

Scrum and Agile are Not Synonyms

Adopting Scrum will not make you instantly agile. This is because for a team to be truly agile, it can not be limited to the development team. In order for a business to effectively be agile, every business unit must buy into core principles.

Within a business, there are many dependencies. Certain tasks require input from multiple business units. Agility depends on consistent communication between business units, and the elimination of bottlenecks. If bottlenecks form, it doesn’t matter what project management tool is being used, the business as a whole hits a roadblock.

Most major roadblocks to allowing a team to act with agility come at the broader organizational level, which is often outside the direct control of the team. An important aspect of Product Management is to be able to build relationships and influence the organization to remove these bottlenecks.

Scrum allows for the business units and development teams to work together and operate in an agile manner. At the end of each sprint, the team has an opportunity to reflect on what they learned, and then adapt. This being said, when project management fits into the big picture of the business, the biggest value that it provides is efficiency.

Being 100% agile is inefficient. Important tasks are constantly being brought up. If there is no level of control, the team will constantly be jumping between tasks. Multi-tasking, or task-switching, has been shown to reduce efficiency by 40%.

Learning (customer feedback) + adaptability (working on what is important) + efficiency (planning and execution) = valuable outcomes

For a development team to be able to deliver there needs to be a balance between agility and efficiency. Scrum allows the development team to deliver as it limits work in progress, allows for focus on tasks, and provides a clear window of certainty as to what is the highest development priorities are.

Keep Your Eyes on the Prize

By disproportionately focusing on Scrum, or any other project management aspects of the job, Product Managers can fall victim to:

• Ignoring tasks that are far more important to the team, such as gathering customer feedback, or making sure the product is successful in market.
• Focusing on output over outcomes. In turn, creating feature factories.
• The false belief that the team is agile when they are really just using Scrum.

All this being said, Product Managers should be looking for ways to reduce their time spent on Scrum tasks.

There are no silver bullets when it comes to improving Scrum. The best improvements are through trial and error. This means small tweaks, time, and patience. This patience and time give plenty of opportunities to keep the ball rolling on other aspects of the job.

Thanks for reading!

If you liked this article check out a few of my others, and feel free to connect with me on Twitter.