Agile Techniques and Developer Stress
Homer: [to staff] Are you guys working?
Man 1: Yes, sir, Mr. Simpson.
Homer: Could you, um… work any harder than this?
Man 2: Sure thing, boss. [they do]
Homer: Hey, call me Homer.
I’m an advocate of Agile Methodologies, but it’s recently been brought to my attention that there is a potential downside. When this downside manifests, good developers can feel over worked, over pressured, and burnt out.
In this article I’ll give a brief outline of the problem in each situation, followed by how it could possibly be remedied.
The first case that was brought to my attention when I was was chatting to a new colleague of mine, I’ll call him Jimmy Lazerface (or JL for short). We were talking tech and he had been super enthusiastic about everything. Then I moved onto Agile – I was acting like a total Agile Fan Boy. I noticed he quieted up. Once I pressed him for details it turned out that the last job he’d had, indeed the place he’d worked only a few weeks earlier, had implemented their version of Agile, and he had had a bad experience. The Scrum Master/Tech Lead was giving very tight estimations on work and holding the developers to those deadlines – ensuring that the velocity stayed where he thought it should be.
I think there are a few parts to a solution here. Firstly, the developers should be involved in the estimation process, not just one person. Using a technique like Poker and T-shirt sizing, we can get a better, fairer, idea of how much work can be achieved.
Next, I think trying to maintain a velocity is a bad idea. Velocities should be used to help estimate. If there is a big drop, can it be explained in the retrospective? Or does your velocity need to be adjusted?
Finally, I think some responsibility can be put on the scrum master/tech lead for not not having some faith in his team (JL is one of the most switched on developers I’ve met, so I know he wouldn’t be slacking off).
The next example I came across of Agile being viewed in a less-than-positive-light was today. An older colleague of mine known as Professor Donaltron (or PD), was discussing the shift over the last few years to agile from a more waterfall/BDUF. He told me, That in the waterfall days, a project might last six months. The first month or so would be design, the next, say four, would be writing up functionality (i.e. actual coding) followed by a month of testing. The way he viewed this cycle was the work ramping up at the beginning, then ramping down at the end. He felt that with agile, his whole work-life was a busy period – no down time. Poor PD. It was obvious that he was feeling burnt out, and as a close colleague of mine I know he has been working really bloody hard.
Seeing as how I work with PD now, I have an insight that might point us in the direction of why he feels this way. I know PDs team do not use retrospectives or do much estimation. They are almost entirely R&D so instead they kind of pile on stories and move them across the agile board once they’re “completed” (which in itself is often hard to define. Everyday they have stand ups, where they have to explain what they did the day before. One card might could be XL (or more) and take a developer longer than a sprint to do. This whole time it could be perceived that PD is not making much progress, despite the fact that he could have put an enormous amount of effort in.
Since PDs team is R&D estimation is very difficult and rarely happens. In the same vein, it’s difficult for the Scrum Master/Stakeholder’s to understand how much progress was made.
I think in this case PD has to do a better job of communicating what he has done in the stand up. I actually advocate him adding new stories to the board (or sub tasks perhaps) so that there’s a visual representation of what he’s doing as movement across the board. This should then be discussed in the retrospective. This may sound like a break from agile, but I believe that agile implementations should be just that – agile. Teams should select the most useful parts of the methodology and apply that. In this particular R&D team, cannot apply many of the cool agile techniques we know and love, so must adpot a subset, coupled with anything that works for them. As long as there’s communication, openness and iteration, I can dig it.
My own experience of Agile has been overly positive, however upon reflection, I remembered when I was first introduced to daily stand ups. At the time I had been at this particualr company for a year or so, so my responsibilities included my project work, AND daily support-style work for stake holders. I remember that I wasn’t used to having to account for my time every day, so as a result I’d get to the daily stand up and have trouble talking about why I hadn’t made as much process as was expected.
The solution here is was, once I realised the problem, was to keep track of any bespoke support I’d done the day before and talk about it in the stand up. Then in the retrospective I would collate what I’d done and show that it was a meaningful amount of work. From here we started putting effort numbers on support work (kind of reverse estimation) so we could work out a kind of velocity separate to the usual project work. We then created a support roster to share the support work, and tried to focus on getting the “support velociy” down. It was a successful way to tackle that problem.
In conclusion, I think developer burn out is a worthwhile thing to note when employing agile techniques. Perhaps more emphasis should be placed on asking how developers feel during the retrospective? Did they work too hard? Not hard enough?