Is the team productive?

Posted May 11, 2020

“The team should be able to deliver more than this by now… Why aren’t they more productive? Let’s add more backlog items to the sprint backlog to make sure everyone is working with something and is kept busy!”

Do you recognize this reasoning? Maybe you have said something similar yourself? Maybe you have been working as a developer in a team where the product owner, or even the Scrum Master, had a similar approach? How did that make you feel?

In this post I will share some thoughts about how this, surprisingly common, approach to improve team productivity may result in the exact opposite.

Great products are built with an outcome-oriented mindset

There are different reasons to develop a product to begin with. E.g. to make a business more efficient, to enable new ways of socializing, to entertain. The list goes on… What’s common for all reasons is this: To solve a defined need for the users of the product.

For a product to be successful in a competitive market it has to solve the problem(s) that the users are facing - And it has to do it the best way possible! The problem has to be solved in a way that meets, or exceeds, all expectations.

Consider if you were a producer of vacuum cleaners. Is it a success if you sell 100 000 vacuum cleaners? That data alone can’t really tell you that. But if you got the information that most customers complain about the vacuum cleaner being so inefficient that it takes them twice the time to clean their floors compared with their old one; Which producer do you think will remain attractive and get a good reputation? Which producer do you think can charge the most for their vacuum cleaner while still keeping the sales figures up? Is this a success? 100 000 or 1000 vacuum cleaners sold doesn’t make a difference if you can’t effectively solve the customer needs and stay competitive over time. This highlights the difference between an output- and an outcome-oriented mindset!

Output is about what is produced and the organizational tasks around it. Outcomes describes the effects and behavioral changes that the product brings to its users and the world around them. Meaning - The incentive to buy and use the product to begin with. What is most important; To produce a vacuum cleaner, or to produce a vacuum cleaner that people want to buy and use?

To repeatedly force more items into the sprint backlog to keep everyone busy is a possible sign of an output-oriented mindset that is centered around completing as many backlog items in the shortest time possible. It has become more important to deliver a lot of things fast, rather than the right things. This will be reflected in the results of the product, how your users perceive it, and finally the profitability.

When working in an agile way the goal is not to deliver more stuff. It’s about delivering the right stuff! And only the stuff that is valuable to the stakeholders. Delivery of things that doesn’t meet the stakeholder’s needs is commonly referred to as waste, because it’s wasted time, wasted energy and wasted money.

Defining a good goal for the sprint will help you stay in an outcome-oriented mindset centered around what the sprint aims to achieve for the stakeholders of the product. Meeting those needs as efficient and early as possible is a sign of a productive team. Completing many backlog items are not.

How does this affect the team?

When the team work to solve a user need the team gets engaged in how the product will be used. They do everything they can to understand how the product will fit in the life of the users. The team will feel ownership and responsibility to maximize the value of what they deliver and to delight the product’s users. This will be the main goal and focus, sprint after sprint! This will be very rewarding for everyone involved!

If the product development is driven with an output-oriented mindset the focus of the development team changes drastically. If more backlog items than what the team forecasts is manageable are forced into the sprint, while at the same time questioning the team’s productivity, the new goal for the team will be to finish everything in sprint. That is an output-oriented goal.

This will cause the team to feel stressed, sprint after sprint, to make sure everything gets done. The work they perform will be seen more as a pile of items that needs to be moved from one column to the next on the sprint board. They will not have the time to get engaged in the product and how well it meets the user’s needs, only in what is produced and how fast they can do it.

After a while the team will start to take shortcuts to meet the goal of being perceived as more efficient by the organization. It may look like it works for a while, but eventually the quality will start to drop, and technical debt starts building up, step by step.

If the pressure keeps increasing the team will eventually not be able to meet their only defined goal (to finish everything in sprint). When the team has “failed” for a couple of sprints will the team start to ignore goals. Achieving goals are no longer seen as realistic or important. The team will no longer feel ownership of goals since they are not created in collaboration. This is a state of true productivity loss and disengagement!

Forcing more backlog items than the team feel they can manage in a sprint is a vicious spiral. For great products to be developed we need an engaged, outcome-oriented, team! When backlog items are forced into sprint and / or the team’s productivity is questioned - Consider this:

What is worrying the person that is questioning the team’s productivity? Has something been noticed that has caused this worry that needs to be addressed?
What are the incentives of the person that is questioning? Is the person under pressure by stakeholders or the organization? What help do they need?
Is there a lack of collaboration that causes a gap between the imagined effort and the actual effort required to do the work properly? Is there a way to better the collaboration for an increased understanding?
Does everyone understand empiricism and how to apply it?

But how to know if the team is productive?

A productive team does what it takes to successfully solve the defined need for the users of the product. The value the team produces each sprint is therefore the right indicator of a productive team.

Velocity may be interesting to look at from a planning perspective, but it doesn’t say anything about how productive a team is. Neither does team utilization and sprint completion (ratio of sprints where all items where completed and not). These metrics are all output-oriented.

Outcome is typically harder to measure than output and therefore many organizations are not doing it as often as they should to really benefit from it. The trends in these metrics in combination can be interesting to take a closer look at to find out if the team is productive:

Thumbs up from stakeholders - The identified stakeholders are pleased with what the team delivers at the end of the sprint.
Customer / User satisfaction ratings - User satisfaction is increasing or remaining high.
Feature usage index - The new features that the team is producing gets a high usage rate. The features do meet a real user need.
User reported defects - There is a decrease in user reported defects. This is a sign of increasing product quality and good test practices.
Employee satisfaction - The employees that are part of the product development are happy. A happy employee is often an engaged employee!
Lead time and release cycle - The time it takes from idea until a user can start benefit from a feature. If this time is decreasing or remains short that is a sign of a mature development- and release process and a low level of technical debt.

Hope you enjoyed this post on team productivity! Please reach out to me if you have any feedback or comments!