Burnout is a real problem in the software industry. A survey from Blind found that almost 60% of respondents had experienced burnout. A Harvard Business School study found that workplace stress costs employees between $125 and $190 billion per year, 5-8% of national spending on healthcare. I myself burnt out a year ago, and took months off to recover.

Burnout is the result of stress over time. I believe that the way most companies make their software creates unnecessary stress. I also believe that there’s a way to structure our product process that can reduce stress and maybe even improve our output.

In software, we’re usually good at critiquing and optimizing systems from the user’s perspective, whether that’s a consumer of internal infrastructure or an end-user of a website or app. I’d like to turn that same critical eye towards product processes.

Note: The thoughts here are based on my anecdotal experience at a handful of companies, plus many friends’ anecdotes about their experiences. A lot of this is also in the context of the unprecedented COVID-19 pandemic. While I try to make my proposals here based on broad, global principles, your mileage may vary.

The problem

Before jumping into solutions, I want to dive into the problems I see with common product processes. And for that, I want to talk about Scrum.

If you’ve worked as a professional software developer recently, you’re likely familiar with the Scrum process. It’s a product development framework revolving around short sprints (usually two weeks), at the end of which you have a functional, user-testable product. It’s theoretically based on the Agile Manifesto, though it doesn’t perfectly adhere to it. It prescribes a bunch of meeting per sprint, like sprint planning, backlog grooming, sprint review, retrospective, and a daily standup. Most of these are recommended to be multiple hours. I’m going to call this by-the-book approach with all the default ceremonies “strict scrum.”

Strict Scrum cannot be for every team. And that’s why it has a built-in system to inspect and adapt. This is the most important part of the whole framework, and the part that I think is most underutilized.

The lack of adaptation of Scrum to an individual team is, in my experience, the root of most process-related stress and burnout.

So let’s talk about some tweaks that can be made to make software development less stressful for everyone involved. Each of the following suggestions will be elaborated into a full post eventually, but hopefully this will be a good overview.

Guiding principles

I’ll tie all the suggestions I make back to the following principles. We’ll focus on two from the Agile manifesto and a few focused specifically on preventing burnout.

Agile manifesto

  • Individuals and interactions over processes and tools
    • i.e. adapt the process to each team and to team members’ unique needs
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
    • i.e. iterate quickly to ensure everyone sees their impact quickly and feels effective

Avoid burnout

  • Trust team members to do their best, and avoid micromanagement
  • Protect deep work time for all parties to do their real work
  • Encourage breaks and room to breathe to keep a sustainable pace
  • Communicate effectively, minimize urgency, and make decisions quickly

Potential solutions

Using the principles above, I have a few ideas of how we could improve the common scrum process. These are summaries; I hope to expand on each of these eventually.

Longer development cycles

Many software teams work in two-week sprints. I propose making these development cycles longer, on the order of a month.

Adding more time into each development cycle should also lead to less stress overall:

  • The team can communicate more effectively when communication is less urgent and frantic.
  • Less-urgent communication and less-frequent planning meetings mean there’s more time for deep work.
  • There’s more leeway to plan around life and take breaks without derailing cycle goals.

It seems counterintuitive to have a longer development cycle when you want to iterate quickly. However:

  • Very few teams ship real, working new features to even internal users every two weeks; the process of creating new features usually ranges from a month to a few months. Allowing for more time in each cycle means teams can actually ship working code to users every cycle, without all the planning overhead.
  • Iterations happen within a cycle, too. Leaving time to iterate between just design/eng/product within a cycle means more iterations overall. Even with longer cycles, teams should be shipping to production as frequently as possible, and use a pattern like feature flags to hide work-in-progress code.

Other thoughts:

  • Teams should adapt the length to a time that fits them.
  • In order to fit tasks into a cycle, keep the scope down and aggressively fight scope creep during the cycle, rather than cut corners on quality.
  • With longer cycles, team members can take on larger chunks of work, giving them space to grow.

This synergizes (if you’ll forgive the business-speak) with some other proposals in this post. More time per cycle means there’s more room to lead with prototypes and iterate on them within a cycle. It’s helpful to plan slack time with longer cycles, allowing the team to use fluctuations in velocity to respond to urgent requests, polish existing features, plan for the next feature, or just rest and relax.

Lead with prototypes

Many teams struggle with a mini-waterfall process, where even with a strict scrum process, product and design fully define future projects before engineering is looped in to build to the spec. By the time the project is ready to be developed, product and design are already defining the next project and therefore unable to fully participate in the iteration process. This causes stress on everyone’s part and leads to lower-quality products.

We can iterate more quickly and communicate more effectively if we lead with prototypes instead. From the conception of the project, engineers create prototypes of the work-in-progress designs and product ideas. These serve as technical proof-of-concepts and can be used for internal or external user testing.

Developers can give feedback about the project while requirements are malleable, and designers and PMs stay involved throughout the iteration process to provide valuable feedback on drafts. Iteration cycles can get done faster since no one wastes their time making perfect specs for the wrong thing, and communication is easier since everyone is on the same page. Overall, the higher momentum improves morale.

This is easier to do with longer development cycles where the team has enough time to define and iterate on an idea within a single cycle. It enables teams to spend less time planning, since it brings the design and product development work inside the development cycle. And it encourages small, cross-functional teams where the designers, PMs, and engineers all work closely together.

Plan slack time

One perspective on slack time is what Martin Fowler puts forth in his great post on how slack time can help a team make velocity and timelines more predictable. You should absolutely read it, so I’ll just give the abridged version: only committing to what the team is certain to finish each cycle allows for easier planning, and the extra time can be spent on important tasks like investing in infrastructure, listening to customers, and responding to urgent requests. I’d also like to add high-level thinking and planning as another option for productively spending that time. Additionally, planning time for urgent requests means they’re less disruptive, and is a form of protecting deep work time.

The other perspective is to use slack time to improve morale and prevent the team from burning out. Having time to work on passion projects and infrastructure makes engineers happy and can help morale; planning this way also helps re-frame fluctuations as “doing more” in some weeks rather than “doing less” or missing sprint goals in others, helping perceived momentum. Using some of that extra time for taking breaks helps improve productivity (seriously, go read this) and prevent burnout.

These benefits are especially helpful with longer development cycles, where longer timeframes make it harder to defer urgent requests and unexpected work to the next cycle. Longer cycles also helps ensure that meaningful chunks of work get done, even with the lower committed capacity, rather than cutting tasks into arbitrarily small pieces.

A few other ideas

This post is already too long, so here are some of my other ideas with shorter summaries.

  • Spend less time planning: Limit time in planning meetings by making them async whenever possible and plan for defining work in the sprint. Shorter meetings make more time for deep work, and fewer planning artifacts makes it easier to iterate effectively. Leading with prototypes makes this much easier, and longer development cycles allow for more coarsely-scoped work.
  • Use less-frequent, asynchronous standups: Trust team members to be delivering on their work unless they say otherwise. Makes more time for deep work. Longer development cycles means blockers are less urgent, and allows for multiple streams of work
  • Keep the retrospective, and maybe the review: Retro is the most important part of the process, allowing you to adapt it to each team.
  • Create small, cross-functional teams: Fewer people means less time spent communicating, and having everyone know enough about their teammates’ work helps teams stay lean. Less time communicating means more time for deep work and that the team can iterate faster. The sweet spot seems to be roughly one person per platform (including design, product, and customer service, as applicable).

Conclusion

I believe that these ideas can help teams avoid burnout without sacrificing productivity. Take some time to experiment with these and other ideas, and adapt them for your team. And, as always, let me know what you think!