Burn-out is now a medical diagnosis recognized by the World Health Organization. The International Classification of Diseases, or the ICD-11, which guides medical providers in diagnosing diseases states that doctors can diagnose someone with burnout if the person has:
a) feelings of energy depletion or exhaustion
b) increased mental distance from the job, or feelings of negativism or cynicism related to the job
c) reduced professional efficacy
The World Health Organization notes that the diagnosis is limited to occupational context and shouldn’t be applied to other life situations. Burn-out isn't the symptom for stress. Instead, it's the result of workplace stress that has not been successfully managed. The good news is that Agile can help prevent situations where burn-out can become prevalent and you might already be “managing” burn-out if you are correctly implementing an Agile framework such as Scrum.
The Agile Manifesto states that sponsors, developers, and users should be able to maintain a sustainable pace indefinitely. Scrum puts these principles into practice in several ways, including team estimation, the use of a Product Backlog and Sprint Backlog, as well as the use of Sprints and the product increment. Be sure to adhere to the following Scrum practices and you’ll be well on your way to not only practicing proper Scrum but also combating burn-out in the workplace.
Estimate the Work - The Development Team should always estimate their own work. This ensures that the work effort has been sized appropriately by the people who will be performing it. It addresses the tendency for stakeholders to underestimate the work size and complexity in order to meet unrealistic and shorter timelines than the work calls for. A poorly estimated work item will cause the Scrum team to work long hours to meet the committed timeline.
Respect the Product Backlog - The Development Team is expected to work only from the product backlog. No one should tell the Development Team to work from any other source of work. This guarantees that the developers focus on the most important work and avoid managing conflicting priorities or multi-tasking. It is difficult to maintain a sustainable pace when different priorities are consistently interrupting your focus. In addition, multi-tasking has several negative effects. According to Psychology Today, recent estimates are that you can lose up to 40% of your productivity if you multi-task and might also increase fatigue, exhaustion and agitation.
Pull, Don’t Push - Agile uses a pull system. We never push work to the developers. The Development Team decides how much work to pull into the Sprint. They do this during the “what” topic portion of Sprint Planning, where the Development Team is entitled to choose their product backlog items and to co-create the full Scrum Team to craft the Sprint Goal. This ensures that the team commits to an achievable workload that is sensitive to their capacity while meeting an agreed Sprint Goal.
Work Iteratively – Iterative development uses short, self-contained cycles that build on the previous ones. In Scrum, each cycle is known as a Sprint. A Sprint should last no more than four weeks. By maintaining consistent Sprint lengths, Scrum teams maintain a sustainable pace that start and end at a predictable time. If work cannot be completed during a Sprint, it is simply prioritized in the backlog by the Product Owner so that the Development Team includes it in the next Sprint. This reduces the need to add urgent work on top of already committed work, which overwhelms the developers’ schedule and creates burn-out.
Enforce Incrementally “Done” – The output of every Sprint is a potentially shippable product increment that adheres to the Definition of Done. A product increment is made up of the previous increment plus the work completed during the last Sprint. This is an important distinction because it forces us to always have a single product increment at all times. By maintaining a single product increment, we are forced to have “done” work that increases the product’s capability at the end of every Sprint. It also ensures that we won’t have to revisit work once it has been accepted as “done.” Undone work will likely be sent back to be completed or reworked at a time when the team has moved on to other priorities. This breaks the sustainable pace that the teams are expected to maintain and can contribute to burn-out.
Reflect periodically – The Sprint retrospective offers an opportunity to discuss and improve how the team works during the Sprint. It inspects the people, relationships, tools, and the process. This is a perfect opportunity for the team to evaluate, brainstorm and agree on action items that can reduce factors that can cause the team to burn out. Pluses and Deltas, Idea storming and Silent writing are a few of the techniques the Scrum team can use to address these issues. The retrospective event also marks the end of the Sprint and it is a perfect time to celebrate the latest incremental win.
Remember that the next Sprint starts tomorrow. There are no breaks needed in between Sprints. This is, after all, interactive and iterative development. It, of course, assumes that you are following a comfortable and sustainable pace by making use of these practices. If we are using Agile, we should be able to avoid the pitfalls of team burn out.
Comments