A Controversial Opinion

It’s time for a controversial opinion. Some of you who read this will know that I’m prone to random thought bubbles, less of you will know that my preferred method of dealing with a thought bubble is to inflate it until it pops, this is one of those thought bubbles. I’m not actively trying to start a flame war, but if one begins, I’ll be sure to sit back, relax and watch the carnage. Okay, so maybe secretly I would like to see some passion displayed. Are you ready for it:

AGILE CAUSES DEVELOPER BURNOUT!

In my early days as a developer the concept of “agile” didn’t exist. Waterfall was the tried and tested method and worked just fine. Business analysts would estimate the scale and scope of a project; it would get thrown over the fence to developers who would deliver it late and over budget; everyone was happy.

As a developer I was happy as I knew from day one that the project was not realistic, so I felt no pressure to deliver on time. When the project manager came asking about progress the lack of delivery was the business analysts fault for not estimating it correctly.

The business analyst was happy as he could blame scope creep and inefficient developers.

The customer wasn’t happy, but they paid the bills, so that kept the accounts team and senior management happy.

It was a winning formula.

Then, along came agile. Projects were designed (not planned) with scope creep in mind. Customers knew they would get what they needed, not what the originally asked for. Project manager became scrum masters and sought to remove impediments from the development team. Business analysts became product owners and got to see jobs to completion.

But where does this leave the developer? The developer has gone from being a highly skilled pawn, to a master of their domain. They estimate the size and complexity of tasks; they are taught to be customer focussed; the communication requirements have increased; their day-to-day delivery rate is monitored; and they still have to be experts at coding.

I can only speak from personal experience, but as a developer I feel the pressure and responsibility of the role has greatly increased. As developers have gained responsibility our customer focus has increased; this has led to us applying greater pressure to fulfil the customers wants and needs, often at our own expense.

As a developer I am involved in estimating each task I undertake; if I have underestimated the task or overestimated my abilities, I feel responsible for resolving the situation to maintain customer satisfaction. If this requires working harder, or working longer, then I will do it because I have been entrusted with ownership of the task. On the other hand, if I overestimate the task or underestimate my abilities, then when I complete the task early my customer focus and ownership of the product means I will pull additional work forward.

I understand that most agile implementations have measures that are supposed to prevent this, but no organisation or product owner will turn down the chance for something to be delivered sooner than expected. Additionally, most of the metrics that are supposedly used to maintain a sustainable pace are used as drivers for individuals to improve and require the addition of tasks to an iteration to maintain usefulness.

If a developer takes ownership of a task and strives to complete it, even when it has been poorly estimated, they will not get the rest periods they need. If a developer is customer focussed, then early completion of a task provides room for other tasks to be bought forward. This sets the developer up for a burnout event.

The next step is to work out ways to mitigate this.

In my opinion the best solution is to provide education and training to developers about the balance of customer focus and personal needs. I often hear talk about the work/home life balance; but I have never seen, let alone been offered, any training about how to achieve this balance. It seems the expectation is that we can find this balance our self; unfortunately to truly find this balance requires either luck or a burnout event.

Another solution would be for product owners and scrum masters or delivery leads to take some ownership of their team’s mental health and refuse requests to add tasks to an iteration. As part of this these leaders would require a good knowledge of their team, skills in recognising someone who needs a lightened workload or break, a team focus that will allow them to put the team first and the ability to help developers determine the best way to de-stress and relax.

There are also options around ensuring that appropriate downtime is scheduled; overtime is prohibited (and this is actively enforced); professional and/or personal development is scheduled as iteration tasks; timesheets, attendance records and task logging is removed; or cultural changes that allow developers to feel comfortable not actively engaging in delivery related tasks.

If there is one thing I would like leaders to take away from this article, it’s that a customer focussed developer will burnout under their own pressure, as a leader it is your job to reduce the chance of this happening.

For developers, the one item you should take from this is that in order to be truly customer focussed you need to put yourself first; if you burnout, the impact to the customer will be much greater than you reducing your throughput a little and caring for your own mental health.