The development team’s capabilities for battling deadlines are fairly restricted, yet they end up committing to them in day-to-day life…
Article word count: 1818
HN Discussion:
https://news.ycombinator.com/item?id=19346958Posted by
ingve (karma: 99528)
Post stats: Points: 126 - Comments: 47 - 2019-03-09T16:45:28Z #HackerNews #and #are #bad #deadlines #for #sprints #you
Article content: 
[1]Go to the profile of Antti
The development team’s capabilities for battling deadlines are fairly restricted
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.
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?
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 commits to an amount of work they think they can deliver. At the end of the sprint, there’s usually a review meeting about what was done.
This system generates multiple short deadlines for the project. In essence, sprints force deadlines into people’s everyday work regardless of the length of the project.
This commitment to sprints generates multiple problems. In order to commit to the amount of work, 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. Sometimes you hit the goal and sometimes you don’t. But you do have a goal, a deadline.
Some think that sprint commitment is not necessary (disregarding SCRUM process to some extent) and that sprint should not be thought as a deadline. I like the idea in theory, but in practice, people end up confusing sprints to deadlines regardless of the intention. Especially when sprint commitment is supposed to be an instrumental part of the SCRUM process by default.
Even 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. Sprint seems more like a marketing term that shouldn’t be used as a term for a method of working in the first place.
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: [2]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: [3]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: [4]Psychology Today, The Dark Side of Deadlines)
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: [5]ISHN, Deadlines can erode safety and promote risk-taking)
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.
The development team’s capabilities for battling deadlines are fairly restricted
In simple terms:
The tools the development team has for combatting 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.
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 commitments, dates, deadlines or anything related to sprints. More importantly, the system does not generate deadlines or 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, 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?
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 for us to get the project done — it’s just noise.
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 brings us a bunch of deadlines to our day-to-day life in form of sprints. Teams end up committing into sprint content, with no sustainable tools to manage it. Some say sprint commitment 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 it 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 life-threatening 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.
If the stakeholders and product owners are not ready 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.
References
Visible links
1.
https://medium.com/@niant?source=post_header_lockup 2.
https://www.psychologytoday.com/us/blog/counseling-keys/201506/the-dark-side-deadlines 3.
https://www.psychologytoday.com/us/blog/making-change/201003/how-deadlines-can-be-murder-motivation 4.
https://www.psychologytoday.com/us/blog/counseling-keys/201506/the-dark-side-deadlines 5.
https://www.ishn.com/articles/103452-deadlines-can-erode-safety-and-promote-risk-taking HackerNewsBot debug: Calculated post rank: 99 - Loop: 253 - Rank min: 80 - Author rank: 128
