Before moving to Agile I worked with Waterfall for around 10 years. Throughout those years I could see people working day and night in development phase. Sometimes teams used to work from 9AM-8PM rhythm non-stop even without knowing why are they doing so.
Whenever product was shipped to customer or whenever any critical production problem occurred, it was quite usual and at the same time pitiful to see team staying entire night to fix the issue.
I heard the word burnout many times. I could see the signs of fatigue on the faces of some people but apart from that I never could understood what burnout actually means.
So here is a story.
One fine day, customer asks a team (working with Waterfall so far) to start working with Agile methodology.
Team starts working using Scrum. Though they followed all practices and ceremonies of Scrum and XP, one thing still didn’t change – the very familiar environment of demanding customer, strict deadlines and pressure from project manager to push team even harder.
Though it may look surprising to you guys, it looked very familiar to the team coming from Waterfall background.
Apart from some similarities with Waterfall, many things were very different. The sprints were continuous, one after another. One ends with a demo and another one begins the very next day. Till the very last day of Sprint, people used to be busy in doing the fine-tuning and related things.
Even after all these efforts, customer didn’t look very happy with team’s productivity. Customer was getting pressure from stakeholders to finish the project early which had nothing to do with existing team. So, that explains team’s so called inefficiency.
Team coming from Waterfall environment generally responds pressure with working extra hard and that’s what team actually did.
Extra hard work got into a vicious loop which didn’t seem to end and before team could even realize anything, they could feel the very signs of burnout. Getting into depression, not able to do any work, discussions bothering you a lot and you go to the workplace where you never want to really go.
Below mentioned presentation which I did at Agile-2009 conference talks about yet another but a bit similar case-study in which team had a burnout. Take a look:
So that was all about story. Let’s see why people in Waterfall are always in hurry to finish application without looking at quality aspects much.
Quite Less Development Time in Waterfall
Waterfall means a long time spend on requirement analysis and design. So in entire 6 months of SDLC, around 3-4 months go to other phases (requirements, testing and design) and only 1 part of the whole SDLC becomes the part of development.
As you can see, very less time to do any effective development with all quality stuff intact. That eventually translates into low quality, software with a lots of bugs, high maintenance cost, redundant requirements etc.
Among all these problems, there used to be a silver light for the developers. Even though they used to work day and night in the development cycle, that time was not too long. In between they get relatively much less pressurized environment of working out other phases of methodology.
Let’s look into the reasons why team got into burnout mode while moving to Agile from Waterfall.
Why Agile Adoption Caused Burnout?
At one end Waterfall churns out a lot of waste in which sometimes you have no clue who is doing what, on the other hand in Scrum, you just don’t stop. Scrum comprises short iterations of 1-2 weeks. At the end of each Sprint team has to create production quality software along with all facets of Waterfall phases running along at the same time.
So in our story what really caused the burnout and how it could be stopped? Let’s see.
- Team coming from Waterfall and in turn hierarchical background could not really say NO when management continued putting pressure on team for delivering faster.
- Pressure in Scrum has much more far-fetching impact (burnout) than in Waterfall.
- Before moving to Agile it’s important to focus on having training on Agile values and mindset for management, customer and team as Agile implementation is not yet another PMI or CMM implementation.
- Team must believe in the golden rule – “under-commit but over-deliver instead of over-commit but under-deliver”
- Team and not management should have complete say in estimation (the amount of effort required)
- Management should have helped customer to identify only high priority user stories for each and every sprint. Otherwise, people put the same effort for low or no business-value user-stories
Makes some sense? I would be happy to hear your comments.
gordon mclean says
I agree that you do need to be very careful with burnout of staff. This is from personal experience where a team member ended up being off sick for several weeks.
I think that the problem in that situation was the lack of defined phases where the person was able to have a break. All the person could see was work and no end. This was missed by the management team (of which I was a mamber of).
Mugen says
I feel this is one of the most important points. I haven’t seen this happening even once in 4 years experience. I doubt it happens anywhere in a country like India.
“Team and not management should have complete say in estimation (the amount of effort required)”