今日推荐开源项目：《色彩 ColorUI》
今日推荐英文原文：《Why deadlines and sprints are bad for you》
今日推荐开源项目：《色彩 ColorUI》传送门：GitHub链接
推荐理由：一个小程序 UI 组件库，最大的特点是鲜明的颜色。这已经是这个库的 2.0 版本了，增加了更多的配色，如果你正在寻找一些具有鲜明颜色的组件的话它会是一个好的选择。不过它升上 2.0 的时日尚早，在线文档还没有编写完成，如果想要寻找文档的话只能去它提供的 demo 中学习了。
今日推荐英文原文：《Why deadlines and sprints are bad for you》作者：Antti
原文链接：https://medium.com/@niant/why-deadlines-and-sprints-are-bad-for-you-7ee87be5d0f0
推荐理由：赶 DDL 是一种动机，但是也是一种危害
Why deadlines and sprints are bad for you
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.
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 create deadlines 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 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?
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 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…
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
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
- Reducing the number of features
- Refining the feature scope
- Hiring more team members
- Moving the deadline
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 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?
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 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.
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
