Principle 8 from the Agile Manifesto
Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
What is Burnout?
According to Psychology Today burnout is defined as:
Burnout is a state of emotional, mental, and often physical exhaustion brought on by prolonged or repeated stress. Though it’s most often caused by problems at work, it can also appear in other areas of life.
According to a recent Gallup study of nearly 7,500 full-time employees found that 23% of employees reported feeling burned out at work very often or always. An additional 44% reported feeling burned out sometimes.
Burnout is attributed to long hours, little downtime, and continual peer, customer, and superior surveillance. Source
Signs of Burnout
- Chronic fatigue
- Physical symptoms like headaches and stomach aches
- Detachment from co-workers and customers
- Extreme dissatisfaction with your work
Causes of Burnout
- Negative work culture
- Lack of work-life balance
- Lack of control over the direction of your career
Why does burnout exist within an organisation?
- Lack of prioritisation so everything is done at once
- Lack of a coherent strategy and direction
- Not distinguishing between what is urgent and what is important
- Poor management
- Putting short term profit above people
- Treating staff as a factor of production rather than a human being
What are the implications of burnout to an organisation?
Work-related stress costs British businesses over £26 billion a year in absences, sick leave and disability benefits.
We can look at the impact of burnouts at three levels:
- Individual cases
- Team level
- Organisational level
Work-related burnout can be devastating to the individual. It can take time to recover and it can leave long term mental and physical damage. For some, it may even mean changing careers or being away from work for long periods.
If a team or department exists within a high-stress environment then the following issues may be seen:
- Drop-in productivity
- High staff absenteeism
- Demoralised teams
- Increased staff turnover
- More mistakes are made
Burnout leads to low staff morale, turnover of staff, lower product quality and ultimately impacts the bottom line. This also can negatively impact the company culture, increase the workload for all staff and could lead to legal cases as well as negative press.
Time, product features and quality
Before we look at sustained development it is important, we consider the idea of delivery.
In every project there are three factors:
- The deadline to deliver the project
- The product features that the project will deliver
- The quality of the features that are built
If the deadline is fixed and it is not possible to deliver all the features in time then we may be faced with two possible scenarios:
- Apply pressure on the team to deliver regardless of the impact it has on the team
- Compromise quality which impacts the user and builds tech debt for the technical team
Commonly the team would be expected to work longer hours to deliver. Working longer hours and trying to squeeze everything in can impact impact quality. Compromises are made to meet the deadlines, QA may not have sufficient time to full test and any feedback may not get actioned by the development team.
From an Agile perspective quality (the definition of done) is not compromised rather we limit the number of features that can be delivered in the timeframe given. The product roadmap then maps out the order of the features that will be developed.
What is Sustained Development?
Sustained development is one of the principles from the Agile Manifesto. According to the Agile methodology, the pace of development is set by the development team and not by managers or external parties. The team understand their capacity so they can scale up and scale down according to their circumstance. Therefore the pace of development can be continued indefinitely because it adjusts to the particular needs at the time.
Pace of development
One of the aspects of sustained development is the ability to say no. The team has a capacity and anything above and beyond that capacity may not be done straight away. This introduces the idea of opportunity cost. Opportunity cost is the loss of other alternatives when one alternative is chosen. If you work on one story then the cost is the lost opportunity to work on another story.
One of the features of Scrum is the team is self-organising. The development team will decide what it will work on per Sprint. The product manager can set the priorities in the product backlog and explain their rationale but ultimately the developers decide what will enter the Sprint backlog. The Sprint backlog determines the pace of the development which is agreed upon by the development team.
If the developers are on annual leave or ill, they can adjust the number of stories they commit to in that Sprint. If the dev team are trying to implement a story in new technology in the Sprint planning session can award the story a higher Fibonacci story point because of the uncertainty of a new language. This helps to protect the well-being of the team. The opposite is also true, as the team become experienced they are able to complete my stories per Sprint.
If during the Sprint an urgent and important story is presented to the development team, the product manager and the development team will negotiate what needs to be removed from the Sprint to focus on the urgent story. This also helps to protect the well-being of the team and ensures that only the stories with the most value are developed first.
The final example in this section is the idea of velocity and story points. Stories points are not compared between teams and it is something that is consumed within the team. What one team may classify as 5 points another may see it is as a 13-point story. It is the team that defines the amount required to deliver a story and it is not imposed upon them by an external party. They may seek external expert advice but it is the team who ultimately decide. This helps to reduce unnecessary expectation to deliver because each team is different.
Why are development teams motivated to deliver?
While the cat’s away the mice will play. (proverb)
If a manager is not supervising a team, it could be argued that the team will ultimately become demotivated and lose focus and not deliver.
Within an Agile culture, we look for leaders rather than have people supervisor what other’s do. The product manager job is to motivate the team through the product vision. A team that believes in the product vision is more likely to consistently deliver than a team that is faced with a long list of to-do without any context. The product vision creates a shared value that people aspire to.
What is the benefit of sustained development?
To illustrate the benefits of sustained development we can look at three audiences within the organisation.:
At a company level one of the key benefits to sustained development is a more stable workforce. Having a culture where crunch time is expected may in the short to middle term increase the output by staff as they are working longer hours. In the long run, such a culture leads to burnout with higher staff turnover and staff sickness. In such scenarios, it becomes rather then fully focus on growth the organisation there is a continuous demand to backfill positions.
One of the best ways to recruit new staff is how current and staff who have left the organisation feel about the organisation. A simple search on Glassdoor on a company’s name can easily attract or repel potential employees.
A company ability to be agile and pivot quickly in an ever-changing environment is vital. Sustained development is a part of Agile methodology which lends itself perfectly to support MVPs, lean and methodology like Evidence-Based Management.
A team that is based upon sustained development understands that there is an opportunity cost for any work that is carried out. There needs to be a ruthless focus on the most important because there is limit of what can enter a Sprint.
Under high-pressure environments, the focus for the team is the here and now. With sustained development time can be allocated to work on future projects because not everything is about completing the backlog. Having time to focus on future projects gives autonomy to the individual to directly influence the direction of the business, and gives variety.
As a final example is the idea of removing impediments. An impediment is something that will slow down or stop a developer delivering a story. It could be technical or non-technical, it could be an internal or external factor to the team. Impediments can causes stress to the team members and one of the objectives of the daily stand ups is to highlight impediments. The Scrum master will identify, track and help remove impediments. It is common that the impediment may be removed by the team, but sometimes it is beyond the team. The Scrum master will then work with other teams or external parties to remove the impediments.
In this section, we will look at two examples. Sustained development on the wellbeing of the individual and how it can help to create a growth mindset.
- Managing wellbeing – a team or an organisation that adopts sustained development as part of an Agile framework looks to give autonomy to the employee, a feedback loop as well as a more balanced workload. These features help to reduce the possibility of burnout.
- Growing as an individual – in a safe environment where the workload is manageable and everything is not required yesterday gives space to the individual to experiment, learn and take on more responsibilities.
Practical ways to avoid burnout using sustained development
This section will look at practical ways to avoid burnout.
- Avoid making commitments that do not come from the development team. This avoids putting unnecessary strain on the team.
- When Sprint planning allocates 10-20% for non-committed time to unknown impromptu meetings etc.
- Have meetings in blocks rather than spread out through the day. Developers as well as those who create content require uninterrupted focused time. Having meetings spread out may not give the necessary to get into the flow.
- Make sure there are clear targets for each sprint.
- End a sprint on a Friday morning. Have the sprint review and retrospective in the morning and have sprint planning on the following Monday. This leaves Friday afternoon for the team to work on something else.
- On the Sprint planning meeting ensure the developers are given time to walk through each story so reasonable know what can be completed. The team should be comfortable saying no.
- Schedule and ensure time is set aside for the team to improve their technical skills.
- After every three Sprints have a week where developers can work on side projects that provide business value.
- Ensure the feedback from the retrospective is acted upon to improve the lives of the team.
- If not every Sprint, every other Sprint or after a few Sprints the Sprint backlog should contain stories for technical debt and quality of life (QOL)
- The focus must be placed on impediments that stop or slow down delivery.
- Keep the Sprints fun. It helps to bring people together and helps destress potential stressful situations.
Health Check Model
One way to check the well-being of the development team is to do what is called a health check of the team. An example of a health check can be found on the Spotify engineering blog.
Image used from Pixabay