In a software development project, it’s important to find a suitable process for the project. A good process helps developers, managers, customers and users. A great process should improve the day-to-day life for everyone involved and help avoid generating problems or health issues.
In this article, I’m mainly focusing on fairly long agile projects that continue over multiple years, though these principles or opinions may apply to shorter projects as well.
Roles in the team
A software project team typically consists of a mix of software developers, UX designers, graphic designers and a product owner. The roles can be roughly split in two: development and product management. Product management steers the development team towards building the “right stuff” at the correct time and attempts to ensure the continued relevance of the product. The development team, on the other hand, decides how to build the “right stuff” and how to deliver it. In addition to this, the development team is responsible for ensuring the software is usable and for validating the overall quality of the product.
In short:
- Product management: What should we build? When should we build it?
- Development: How should we build it? How should we deliver it?
Sprints enforce deadline-thinking for short cycles
During recent years, agile development has been rising in popularity. It also made Scrum famous as a process method, so much so that some use it as a synonym for agile development.
One of the key elements in Scrum is sprints. A sprint is a time-boxed iteration of development (usually lasting from one to three weeks), during which the team focuses on a set of tasks planned at the start of the sprint. At the sprint planning, the team takes the highest priority items from the backlog (work queue mostly managed by product management), plans them, and makes a forecast out of the amount of work they think they can deliver. At the end of the sprint, there’s usually a review meeting about what was done. These are very deadline-enforcing systems.
This forecasting in sprints generates multiple problems. In order to forecast the amount of work that can be completed, the team now needs to assess, for instance, the following factors:
- How much effort goes into each task?
- Is someone going to be on a personal leave during this time?
- Is everyone 100 percent committed to project-related work or are there some other responsibilities on the side? Training? This week or always?
- How many sick days are there going to be in the sprint?
- How many bugs is the team going to come across during the sprint? How difficult will they be to solve?
- Is someone leaving or joining the team?
- Are there any company events during the sprint?
- Are national holidays going to affect the sprint?
- Are there any hardware issues going to come up?
While these assessments can be made easier with statistics: “Generally, we get this much work done per sprint”, and so forth. The bottom line is this: There’s a wide range of variables that cause the output to vary over different sprints.
The semantic idea of the word “sprint” is ill-advised for a long project. It suggests a mentality of a 100-meter sprint running to do whatever it takes to get to the finish line as fast as possible. A long software project is more accurately compared to a 50-kilometer run that is won with a steady pace, and during which overexertion at any midpoint ruins the whole run or sends you to a hospital. In long projects, people might not even know where the finish line is.
In practice, people end up confusing sprints to deadlines. Especially when there are systems in Scrum that enforce deadline-thinking, like sprint forecasts (old word commitment), sprint review, time-boxing and even the word sprint. In essence, sprints generate deadlines into people’s everyday work regardless of the length of the project.
Deadlines in human health
Deadlines can have multiple effects on humans. Especially when they are closing in. Some of them include health risks such as increased stress, loss of brain cells, lessening creativity, digestion issues, headaches, etc. When deadlines are closing in, the human body may eventually feel threat to its survival and trigger the fight or flight response. (Source: Psychology Today, The Dark Side of Deadlines)
Other effects include motivational enticement. There are studies that show deadlines can have a positive effect on work motivation. I would argue that there are other more worthwhile and less damaging motivational enticements in existence as well. Just to list a few to get you started:
- Creating an awesome product
- Delivering good quality
- Improving people’s lives
- Helping people with their problems
- Making people happy
Deadlines can even undermine the motivation generated by other motivational enticements. (Source: Psychology Today, How deadlines can be murder on motivation)
Additionally, the stress caused by deadlines “sets up a vicious feedback loop and keeps a person dependent on deadlines like a caffeine junkie reaching for their morning cup of joe.” For some people, meeting a deadline gives such an adrenaline rush that next time they may put off a task until they get physical symptoms of the fight or flight response. (Source: Psychology Today, The Dark Side of Deadlines)
Deadlines in software projects
How many times have you heard these explanations before?
- We had to skip tests…
- We had to add technical debt…
- We could not fix the code…
- We had to do it quickly…
- We couldn’t design it properly…
- We had to take a shortcut…
Too often these sentences end with …because we didn’t have enough time. Why didn’t people have time? There’s probably multiple reasons, but in the end, it often comes back to deadlines, right?
People will try to cut corners, produce lower quality and take risks while disregarding their own health to meet deadlines. (Source: ISHN, Deadlines can erode safety and promote risk-taking)
The deadline is closing in and we’re late, now what?
As mentioned earlier, the variables often lead to unpredictability and the project ends up missing the deadline. So what can be done now?
- Cut corners (lowers quality)
- Work overtime
- Skip or forbid team other responsibilities like training
- Forbid personal leave
- Reduce the number of features
- Refine the feature scope
- Hire more team members
- Move the deadline
Cutting corners usually ends up damaging product quality and generating loads of technical debt. This type of debt has a very high interest rate, and the project will have to pay it sooner or later. The worst case scenario is that it causes bugs in the production environment, which can be extremely costly.
Making people work overtime or denying leave (essentially meaning rest), on the other hand, might lead to a range of health issues and other problems in life management.
Denying or skipping other responsibilities, such as employee training, is another form, a more slowly moving type of technical debt: It will eventually result in people with outdated skills and a project that will not benefit from new skills.
In simple terms:
The tools the development team has for fighting the deadline are unsustainable:
- Cutting corners (essentially lowering quality)
- Working overtime
- Skipping training or other responsibilities
Product management controls the only sustainable options:
- Reducing the number of features
- Refining the feature scope
- Hiring more team members
- Moving the deadline
The above categorization means that management could resort to the unsustainable options as well, if required. I believe that it is far better if management makes that choice knowingly rather than have individuals within the team make this choice on their own. These individual responses to deadlines are exactly at the core of the issue: they generate invisible problems that jump at you unpredictably.
Well, what choice do we have?
Instead of Scrum, there’s another similar process called Kanban (Lean development) that does not have the concept of sprints and time-boxing, because in Kanban, they are considered a waste.
In Kanban, there’s only the “stuff” to be done, and the development team should do it in the order prioritized by product management. It’s a very continuous process that fits naturally into long development projects. There is no need to use time on discussing forecasts, commitments, dates, deadlines or anything related to sprints. More importantly, the system does not enforce deadline-thinking or generate deadline-like systems so the stress of having deadlines is removed. Rather, when a task gets done, the development team takes the next task from the top of the backlog and so on.
The Kanban (Lean) process removes a number of unnatural things that Scrum (sprints), in turn, entails. For instance:
- What happens when a sprint is completed early?
- What happens when a sprint is not completed in time?
- What happens when bugs emerge during a sprint?
- What if we can’t plan enough at a sprint planning?
- What if we plan too much at sprint planning?
- What if we want to release before the end of the sprint?
- What happens if product management really wants to re-prioritize during a sprint?
- What happens if everything is not ready for development at the start of the sprint?
- What happens when specifications change during the sprint?
These questions can be answered with more processes or steps and guidance. In Kanban however, many of the questions are not even applicable because they are not necessary in order to get the project done — it’s just noise.
Conclusion
Deadlines have a lot of negative impacts on human health, but some say they are a must-have for work motivation and for project organization. I argue that there are other motivational enticements and other ways to organize projects than deadlines and sprints. This takes me to my main argument, which is that the negative impacts of deadlines and sprints outweigh the positive impacts.
Scrum as a popular agile framework enforce deadline-thinking in our day-to-day life in form of sprints. Teams end up working on sprints, with no sustainable tools to manage them. Some say a sprint forecast is not necessary, and a sprint should not be thought as a deadline. I’m inclined to agree, but then again, I ask you this: Why have sprints in the first place?
Sprints and time-boxing add a lot of artificial noise to a project. That noise has few major undesirable side-effects, the biggest ones being the possible health issues and unsustainable teams and projects. In the end, there are other ways to work (like Kanban) that do not have this noise and give more flexibility in return, too. Also while comparing Scrum and Kanban, they both can have the same predictability of the future after few months of working.
If the stakeholders or product owners are not able to pull the plug on deadlines, product management might be left to play with them on some level. Development teams should not be dealing with deadlines, since they don’t possess the tools to manage them. Rather, the team should focus on the delivery of the tasks and make sure they are delivered in the order that product management sees fit. One could think of it as a layer of protection for the development team. In this case, a team might need to give out estimates on how long each task takes, but that’s still very different from committing to a deadline.
EDIT: Changed wording from ‘commitment’ into ‘forecast’ as it’s more up to date. Also clarified some of the key points. (26.03.2019)
