“Scrum is leading us into temptation to work until we burn out.”
Michael Hofmann @ SGBER (2014)
I’m a ScrumMaster in a reasonably successful feature team at a large European bank, in London.
First of all don’t get me wrong – the title is deliberately dramatic and attention grabbing, but I am a firm advocate of Scrum and agile methodologies in general. I’ve worked on waterfall projects and is was not a pleasant experience – I have no desire to return to those dark days. I do however, believe that Scrum is far from perfect and offers its own unique challenges.
My problem is stress and the constant pressure caused by maintaining and sustaining a certain velocity (i.e. high pace), while at the same time ensuring that quality doesn’t suffer. I want the team to actually enjoy themselves at work and I often find the frantic pace just doesn’t allow this. Now, I know what you’re thinking – a teams velocity is supposed to be sustainable; that is clearly stated in the manifesto.
“Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”
Agile Manifesto – Principles
The competing factor though is continuous improvement – this philosophy is instilled in all good agile teams and so there is a natural tendency to want to see your velocity increase.
I have another problem with velocity and it’s the implication or assumption that it is carefully measured. If you measure something you are creating targets, whether you mean to or not. Should it be measured at all? I stopped measuring velocity a long time ago and we abandoned the burndown altogether; I haven’t detected any particular problems and morale has improved as a result. Anecdotally, I’ve seen no reduction in velocity or capacity.
Then you have the problem of how it is measured and reported (and then ultimately compared and used as a stick to beat a team with). Equally, if you don’t measure velocity, you have the problem that stakeholders and product owners will calculate it themselves, ambiguously and without assigning an actual measure or real value, based purely on their perception of your output. This is why if you run a successful Scrum team it often feels like you are digging your own grave – the joy of having a successful sprint and delivering against your plan is swiftly replaced by the overwhelming dread that you’ve got to do it all over again next week (and improve on it). You are left with the demoralising effect of feeling like you’ve somehow gotten worse or that you are going backwards. Either way, it’s stressful and not much fun.
There is a lot of supporting evidence in favour of an agile approach vs waterfall, with respect to the teams mental health – but this is largely based on the assumption that stress is reduced and far less than that found during a typical waterfall crunch period. Is it really? Does slightly reducing the stress levels but spreading them out so that it occurs in each sprint really improve things? At least after a couple of weeks of waterfall crunch you had the chance to rest and recuperate; with Scrum there is no end in sight.
I’ve also found that generally a Scrum team has a far more rushed attitude to delivery. This is a common criticism of Scrum and I’m not going to cover the issue in any detail here. You could call this ‘focus’ or the result of increased energy, motivation or enthusiasm, but the result isn’t healthy, for the product itself or the team members. Again, this is often the result of the drive towards continuous improvement. What if some things just take time and careful consideration?
“Move slow and craft things.”
Now, I realise that there isn’t anything in the agile manifesto about increasing velocity or rushing through things, but the reality is that the principles and the attitude that is instilled into the team does affect a number of people in this way. Certain personality types seem less affected than others and some people are more willing to miss their estimates and instead just do the job properly, but that is rare in my experience. It’s not just the burndown; it’s Scrum in general – people can find the process and the methodologies addictive and the never ending backlog of work just doesn’t fit well with certain personalities.
Closing a JIRA or moving a sticky note to a ‘done’ column is an intrinsically rewarding and motivating process. I don’t think that is an accident; I think there are elements of gamification within Scrum by design. Is this the right approach – we know that this encourages people to call a piece of work complete when perhaps that isn’t quite accurate. If all of your colleagues have moved some tickets or closed some items at your daily standup, there is some pressure on you to do the same, that is human nature. Again, there are many other articles covering the importance of the Definition of Done, or of the effects of peer pressure within an agile team.
I’m not the first person to make the connection between Scrum and exploitation…
“The daily Scrum meeting (stand-up) is another tool designed to maximise exploitation of developers as a capacity constrained resource by keeping them busy and keeping development moving forward.”
David J. Anderson
To summarise, I think the agile approach fundamentally changes an individuals approach to work – largely in a positive way, but with some negative connotations for stress and an individuals attitude towards completeness and thoroughness.
What can you do about it?
Have some time off between sprints, perhaps a free day, so you don’t feel that you are jumping straight back into the fire! This would give everyone some time to play, learn, reflect etc. I’ve seen similar implementations where people have tried to introduce Google 20% time outside of the Scrum process, for example.
It is worth investing in a proper model of your system, ideally visualised and well presented. This model can help to articulate the business value of design, infrastructure or architecture work.
A good ScrumMaster, team lead or project manager will spend a lot of their time helping to ease the pressure on team members and insulate the team from frequently changing and increasing demands. It’s a fine balance, you need to be delivering ‘value’, but you also want to allow the team to fail occasionally to facilitate learning through experimentation.
My advice – drop the burndown, stop measuring velocity and appreciate that there is a real limit to team performance and efficiency; the continuous improvement curve can’t be linear!
As always, I’m keen to hear your thoughts and experiences.
How To Not Destroy your Agile Team with Metrics