A theme that seems to be popping up in my conversations with individuals participating in “agile” projects is that it is begining to feal like you are in a constant “death march”. Business continues to press for “more productivity” and has to respond to a constantly changing and competitive marketplace. In traditional waterfall projects many are used to the last couple months becoming the death march. Long hours, lots of stress, a changing triage bar for defects, all hands on deck as you surge to get the product done “on time”. This may mean you have 10 months of a “normal” life and then two months of hell.
But as companies move toward Agile, every two weeks may be a new release. That is a possibility for 26 sprints per year. If two of the working days of your 10 day sprint are a death march, that is 52 days per year vs. 40 days in the “annual” program. A more than 25% increase in death march days. The Agile Manifesto states:
“…Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely…”
The question is what is sustainable. I am hearing stories that don’t sound like only the last 2 days of a sprint are a death march. Every day feels like a death march. This isn’t a new topic, I have included links below to some posts on the topic. Organizations, actually teams, need to determine what is sustainable for the team. WIP limits need to be understood. A freeway filled to 100% capacity is a parking lot. Don’t let a shift to agile mean a shift to constant running. Global business and mobile devices only make this a more challenging battle.
Is your organization marching up hill or has it found discipline to not only be sustainable but found that you are more productive not just in time to value but driving customer sat and improving quality? What did it take for your team to succeed?
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Agile looks like confusing for many people. Many of the processes in agile are similar to SDLC…But it depends how you take it…
If working in an agile team feels like a “death march”, that is something that the team (together with the stakeholders) can address. For instance in a retrospective, where team members can state how they feel that things are going. If pressure is something that is really hampering the team – as can be the case as you describe – then the team should take action. E.g. by deciding to commit to a lower number of user stories / story points.
A retrospective can also be used to find the root causes why teams feel that they are under constant pressure. Do they get enough freedom to do the work the way they think it can be done? Are they allowed to make occasional mistakes and learn from them? Is it one or two person who are under pressure, or is it everybody in the team? What’s the team morale, do they feel happy when they go work, and when they go home? Find the causes, and address them in a next iteration.
“If you want to deliver more, you should not work harder, but smarter” is a basic thing that didn’t change when agile was invented. But the feedback and learning cycle that agile methods like Scrum have can help you to improve. It still needs an investment in time and energy, but when done it can help you to stop walking deatch marches, and work in a sustainable pace.
what if your scrum master is a fascist? more scrum b.s. works perfectly in theory but the practice rarely lines up so nicely. Hucksters and shills the vast majority of ya.
I would expect that if your “scrum master is a fascist” that this isn’t a problem of scrum, they will behave the same way irrespective of the chosen process. All processes work well in theory and yes, in many places things don’t like up nicely, that doesn’t make it invalid or merely hucksterism.
However, yes if the ideal is commit to fewer story points but you can’t because it is dictated to you, well that isn’t agile either. I think the challenge here is partial adoption of agile practices and a lack of commitment from management.
The title is incorrectly worded. it should be
“Is your organization driving Agile to a continual death march?”
Agile, as described in the manifesto, and the professed values, would never lead to a death march. as many others have said here, it’s the organization culture that never changed, that causes death marches to persist.
I too have witnessed this on numerous Agile projects.
I think the notion that a project can continue to deliver with linear velocity is erroneous. Jacobson’s observations on entropy within software dictate that as a software systems gets larger/more complex more effort must be expended to exploit the value of that software, i.e. it does less work over time. This is similar to the second law of thermodynamics.
This means every Agile project will experience falling velocity. That is to say the effort X to exploit value Z from the software at time T1 will increase to X+Y at some later point T2. This is regardless of the skill of those involved!
This probably means that Agile teams that are attempting to deliver X points month on month are destined to become larger or to constantly re-estimate their backlog.
I think the rate at which entropy increases in the software is proportional to 1) the size of the team 2) the focus of delivering value. This means larger teams suffer a greater rate of falling velocity.
I think this feeling of steadily atrophying software is what some describe as “the death march”.
Very informative post i think you have great knowledge about agile. OnTime Scrum is a famous tool for agile scrum. It is a project management and bug tracking tool for Scrum teams. It allows us to create a custom dashboard which in addition to displaying the previously mentioned burndown charts and allows us to see at a glance current team velocity, required velocity to complete everything by the end of the Sprint, projected completion date and work remaining.
I do trust all of the ideas you have introduced for your post.
They’re very convincing and will definitely work.
Nonetheless, the posts are too short for beginners.
May you please extend them a little from next time?
Thanks for the post.
Seen some very hellish Agile working environments. Brutally fast paced.
I will list a summary:
– Stressful, intensive interpersonally demanding working methods bordering on exhausting. No fun, just work work work.
– People used to waterfall not working in an Agile way and not understanding it.
– Failure in marrying business project methodology and lifecycle with agile software development teams methods leading to polarisation of working ways.
In my view if a project at concept is about delivering something in an Agile way, it needs to bring in Agile specialists i.e. Agile specialist team at all levels.
You’re so awesome! I do not think I have read through a single thing like this before.
So wonderful to discover somebody with unique thoughts on this topic.
Seriously.. many thanks for starting this up.
This web site is something that is needed on the web, someone with
a little originality!
This is how we work with Agile: https://zaven.co/agile-lifecycle-management.html
The article was written in 2013 but it still very much valid in 2021.
Working in Agile is like running on a tread mill constantly. Agile is disrupting the mental health of employees. People don’t realize it very soon or are afraid to speak and even if you speak, you will be seen as someone who can’t cope up with the pressure and also as someone who is not aligned with the organizational goals. It is the killer of creativity, increases duplication and repetition of project related activities very frequently every two or three weeks and the most important thing is Agile creates an imbalance in the work life balance of employees.
Perhaps there is a need for industry leaders to make a fine balance between competitive edge in the market and the impact on personal and professional lives of millions of employees worldwide.
To be completely honest, I’ve been working with some Agile methodologies for many years and I think such frameworks really make our work so much easier and more productive.
For me, Agile seems good not only in theory, but in practice as well. But I would like to stress one thing: Kanban is sooo much better than Scrum!