What is the Slow death march?
It’s likely that you have heard before about the slow death march applied to the software development, actually I’m sure that if you have a few years experience you would have been involved in a few projects where you have seen this happening.
This phenomenon responds to those dynamics where a team somehow knows they will fail to complete the project successfully, but no one does anything to prevent it.
When the team starts marching in this way, it is essential to detect it as soon as possible and to act immediately as the longer this dynamic is in the team, the harder will be to remove it.
Signs that the team has started marching.
There are many signs that may help you detect if your team is falling into this dynamic, but the main indicator is team motivation, the problem with motivation is that hard to tell when the motivation is going down until is very late. A few indicators could be.
- The team is starting to miss deadlines with apparently no reason. Could be an early sign that they are loosing motivation, concerns should be raised from the second deadline missed.
- Communication is not as fluent as is used to be. In a healthy team communication happens in an informal way almost continuously, if you detect that your team is starting to communicate less, probably is because motivation is going down.
- The team is been under high pressure for too long with no reward. This is one of the big motivation killers.
- Decisions have been imposed by management and the team doesn’t agree with them.
Motivation and broken windows.
In the book “The Pragmatic Programmer: From Journeyman to Master” Andrew Hunt and David Thomas explained the broken window effect:
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
If the motivation is low, people is not going to care about broken windows, if that happens, is likely that the team will find itself sooner than later in the slow death march.
Who is responsible for it?
Probably developers will think that the responsible for this dynamic is management, but that’s false, the responsible are all the parts involved in the project, including all the individuals of the teams, that’s you and me. If you are in a team that is starting to loose motivation, ask yourself:
- Am I helping the team to work better? Sometimes we are so focused on our own opinions that we forget that we are actually getting in the way of our team to get things done.
- Am I doing what the team is expecting me to do? A motivation killer is the lack of confidence among the developers of the same team, every meeting you have, do you find yourself answering “why have you been doing that for the previous days”? If so, you have a communication problem and the motivation of the team is going to be affected.
- How can I help? One of the easiest formulas to help building a great team is to offer yourself to help someone.
A great article related with this subject is “Dealing with Bad Apples” by Jeff Attwod via codinghorror.com
Oh my god! I’m slowly marching to death! What can I do?
That’s an easy one, simply do something for the project, anything! That can sound a bit ridiculous, but is true, team members in these dynamics usually spend most of the day in the Internet or simply starring the screen, the best remedy is to start doing something and to encourage other people to do the same.
This article may help you to focus on your tasks and not loosing motivation: 5 Tips for creating good code every day; or how to become a good software developer
- 7 non technical tips to deliver great software
- My 7 principles to design the architecture for a software project.
- How to write a good test case: 5 tips to write better test cases
- Waterfall vs. Agile: QA and Management
- How to determine the cost and schedule of a software project? The mythical BPUF (Big planning upfront)