3 Signs Your Sustainable Pace is Killing Your Developers

Work at a sustainable pace and your team will be happy and never burn out.

That’s the idea, anyway. It’s one of the twelve principles of the Agile manifesto.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

What that means, however, is your team must find a working pace (40 hours per week or so) that is sustainable and healthy for the long term. Agile software development depends on team members who are in the “zone”—creative and energized throughout an entire project or initiative.

Figuring out sustainable pace for your team is the first step. You’ll need to work out how many tasks from the backlog your team can complete comfortably during a sprint, and how that work gets distributed. It takes some trial and error. And while a sustainable pace is certainly a goal worth striving for, phrases like “principles” and “manifesto” suggest lofty ideals. How can you ensure that the sustainable pace you’ve set for your team is realistic and doesn’t create more stress than necessary, wearing everyone down?

It’s possible to do everything “right”—work within sprints, use visual work management tools, manage dependencies, write user stories, do everything else Agile methodology suggests—yet still find your team running into problems. For instance, in the video game industry, a sustainable working pace often goes out the window during a prolonged period called “crunch” when a game is nearly ready and must be pushed over the finish line. With a deadline looming, there’s too much coding and testing and not enough time to do it during normal work hours. Teams pull heroics. They work long nights and weekends to finish the game and ship it on time. It’s a generally accepted part of the video game world, even as it ends careers. Sometimes it works, and the game gets out the door on time. But it often results in a team crash, leaving those involved exhausted, demoralized, and underappreciated.

That isn’t the only way it happens, though. You may need to look at how your team is splitting user stories or if capacity planning is done correctly. Even if your team isn’t going through similar periods of extreme overtime work at the end of every sprint, it’s still possible to exhaust your team under the guise of maintaining a consistent work pace.

Here are three signs that your “sustainable pace” is putting a strain on your development team.

1. You’re working in sprints, but your team is still stressed

Working in sprints is a widely used Agile method that helps teams work quickly and effectively to deliver working software more often. A two-week sprint, for example, should make it easy to incorporate feedback and change direction while still producing a minimum viable product. With planning prior to the start of a sprint and review at the end, there should be time for your team to talk through how much work you can reasonably expect to complete, and how much is actually accomplished. Then for the next sprint, the workloads are re-figured and, all along, kept manageable.

But if you’re planning too much work every sprint, pressure remains on your team to work overtime. This defeats the purpose of the sprint.

Author Mike Cohn suggests that someone, like a Scrum Master, keeps a watchful eye on the team’s sprint plans and pulls estimates back when they become too optimistic. “Even if a team manages to complete the work as planned during the sprint, that team runs the risk of entering the next sprint both tired and also overly optimistic about the amount of work it can complete,” Cohn says. He adds:

“Such a team might then once again commit to slightly more work than it can comfortably complete. Eventually, the team will burn out trying to work at a pace that is unsustainable. Another great way for a Scrum Master to guard against burnout is by giving a team time to work on things of their own choosing.”

Cohn’s fix for this problem is to build in a one week sprint for self-defined work following every sixth two-week sprint. This way, your team members have something to work on that gives them time to recharge, keeping them happier and the quality of their work higher.

Another common problem in sprint planning occurs when a team accepts the tasks for a sprint, but the product owner is the one estimating how long they will take. That should be the team’s job, and if the product owner is taking over, then there’s going to be a disconnect between what’s planned and what gets done. The product owner is there to help set priorities and work items, but the team members best know how much time a particular task will take, as well as what they can accomplish in a given sprint.

The key with sprints is to not lose sight of the fact that, even though your team is working on a two-week deadline, there will be another one coming up right behind it.

2. No one is saying “no”

Prioritizing work and only committing to a manageable workload is part of maintaining a sustainable pace over time. After your product owner, along with key stakeholders, prioritizes the strategic goals, it’s up to team members to accept the tasks that they feel they can complete during a sprint. Members of your team should be comfortable saying “no” to requests that do not fit the mold. If they aren’t, it’s a sign that they aren’t prioritizing effectively, or that stakeholders and your development team aren’t having the necessary two-way conversations that make prioritizing essential tasks possible. In that case, everyone could be headed down the road to burnout.

Create a visual backlog of upcoming work, and then prioritize it to help your team members keep an eye on what needs to get done when. Working only on the most important items in the backlog will help your team sustain the right level of energy without going overboard.

One way to decide what needs the most attention is to use an even/over statement. By putting two tasks next to each other and prioritizing one “even with” or “over” the other is a good way to figure out which is the most important for your team and business. It’s also an easy way to rationalize working on one task and turning down another. In that way, something that may not fit into the current sprint can be moved to the next one, keeping your team from loading too much into a too short time frame.

3. Your definition of project success may need to change

It’s possible that your team is burning out working on projects because they shouldn’t really think of them as “projects” in the first place. Projects are considered done when they’re delivered in working order, on time, and on budget. If your team is focused on hitting that goal, they might miss the larger picture regarding the project’s overall value and put more pressure on themselves in the long run.

Agile coach Magnus Dahlgren argues that by focusing too much on finishing a “project,” your final product actually suffers:

“We normally define project success as delivering a set of features on time and budget. However, by doing so, we don’t necessarily get the benefits we were after. In fact, the risk is that we reduce our chances of getting them.”

When working in a sprint, it’s easy to get caught up in reaching a specific outcome by a specific end date. And while that sounds like success in a vacuum, Dahlgren doesn’t think it leads to success in the overall picture. If the quality isn’t high enough because work was done too fast or without enough feedback from team members and stakeholders, then it isn’t really worth declaring a success anyway. By focusing more on continuous improvement, your team will be happier with their results and create a better final product.

Sustainable pace is still important

Keeping a sustainable pace at work is key to keeping team members happy and engaged while producing their best work. Regularly check in on team mood with something like a Niko Niko chart. And remember, team happiness is a moving target. Monitoring pace and workload and making necessary changes with every sprint is the way to ensure everyone stays on top of their game.

A sustainable pace is achieved through proper planning, commitment to goals at all levels in the organization and collaboration and communication up, down, and across the company. Focusing on the value delivered rather than the framework in which your work is done will help to keep your team happy and working well together.

Want to learn more about Agile and how to help your team? Check out these articles!

• Learn more about SAFe methodology and whether you’re ready to undergo a SAFe transformation
• Learn how to convince your boss to purchase that work management tool you’ve been eyeing to keep your team on track
• Find out how to build a successful Agile team