Resource Management Strategies for Scrum Teams

Article Agile

How to drive performance when there is more work than available Scrum team(s) member(s), and optimize results when those teams lack cross-functionality.

As an Agile Coach, when I engage a new client, it is always a pleasant surprise when project workload aligns with the number of self-organized, cross-functional teams. These clients understand what their vision is, and how to go about thoughtfully implementing it. But what happens when there is more work than teams can support? What happens when teams are not cross-functional? And what are some possible mitigation strategies when these things happen?

In my experience, multiple things happen with teams when there is more work than the current teams can comfortably support. First, let me define what I mean by “comfortably support.” This is a concept in which Agile teams (Scrum, Kanban, Lean, etc.) can adequately plan their work with time built-in to experiment with novel solutions, as well as learn new technologies that they may implement in the future. They are also able to juggle all the day-to-day activities that require their attention like periodic compliance training, or even division-wide quarterly meetings that can sometimes take a full day to attend. 

So, what happens with teams that are stretched thin and not only unable to ‘see the light at the end of the tunnel,’ but also keep having additional work piled onto their growing workload? In my experience, any of the following may occur:

  • Teams disengage from the work and do just enough to get by.
  • Teams struggle to keep up and burn out.
  • Teams pull heroic acts by working nights and weekends to attempt to stem the inflow of work.
  • Teams cut corners on the quality of work to increase speed, but ultimately create more work by creating production defects.
  • Teams are not cross-functional and only focus on one area of the codebase.
  • Teams experience skills gaps due to organization funding restrictions, hindering them from being fully cross-functional.

This is far from an exhaustive list but includes just a few examples I have helped teams resolve. Each and every team, and circumstance are unique, and what has worked for some may not work for all. 

Separately, what happens when teams are not cross-functional? This is often a major challenge for teams and organizations overall. When teams are not cross-functional, they cannot complete a piece of functionality end-to-end. Instead, they must rely on other teams to finish the work which creates bottlenecks for those that have to work together on functionality, as well as slows down delivery to production. A common example is:

  1. Team A creates a portion of functionality, then passes it on to Team B to add logging to it.
  2. Team B then has to understand what Team A built, meet with them to understand the logging needs, and then fulfill those needs.
  3. Once Team B completes their understanding of the logging needs, they then go back to Team A to see if they did things as expected.
  4. If not, Team B will correct their misunderstanding and show Team A again.
  5. Team B may be able to start this rework immediately, or it may have to go into their backlog for work at a later time, which could further delay production deployment of Team A’s functionality (this also has increased potential for integration defects that cause additional delays) 

While these are all unique issues, with distinct root causes, options for alleviating them are universal. The first is a technique called ‘PI Planning Session’ or ‘Big Room Planning,’ where all necessary development and business teams come together to discuss what is to be worked on for the upcoming quarter. Requirements are discussed and refined, dependencies are elucidated and planned for, all while crafting epics for the planned work that is currently underway. 

The second option is to hire additional people that may or may not have subject matter expertise but have the necessary technical skills to perform the work. While hiring additional people may be a relatively quick and easy ‘fix,’ you will need to have meaningful data to back up the need for additional headcount, as well as an estimate of how many are required. 

Both of these options may work on their own, however it is recommended to implement a combination for optimal efficiency and effectiveness. Other potential strategies that may be combined include:

  • Top of the house vision and prioritization of initiatives the enterprise will focus on. This provides a cohesive vision for the entire organization to work toward, instead of each group operating independently.
  • ‘Work in progress’ limits need to be set at the top of the house so that teams are fully dedicated to achieving the same cohesive goals. This will allow teams to work towards the same results rather than on competing goals.
  • Start finishing things and stop starting new things before you complete what is currently in progress. Don’t be afraid to stop in-flight work if the vision changes, and what is in-flight no longer makes sense to continue developing.
  • Instead of big bang budgeting for the year, try ‘rolling quarterly budgets’ to help shorten feedback cycles. For further thoughts on this topic, keep an eye out for Natalie Vinitsky’s “Why is Finance so Important during Agile Transformation” blog.

Digital transformations are unique and challenging, but we do see similar issues across clients and industries. The challenge is determining how we can best help, and where to begin. These strategies have worked time and time again when it comes to issues with teams and workload, and the excitement lies in identifying the perfect combination for each client.