Our book about Valuable Agile Retrospectives has been published!
Agile promotes that teams work in a sustainable pace, delivering value to their customers. When teams are working under too much pressure, technical debt will increase and velocity of teams will go down. Agile retrospectives can help you to discover the causes of pressure, and to take actions to reach a sustainable pace with your teams.
A sustainable pace is a workload that a team can handle for a longer period, without compromising the quality of the product. It is based on a velocity that is doable for the team and doesn’t lead to stress or illness of the team members.
When the workload of the team becomes too high, chances are big that team members will make more mistakes with increased technical debt as an result. Team pressure drives code quality down and increases maintenance. Due to the technical debt, the velocity of the team will decrease so they will actually be delivering less value to their customers while putting in more hours. Clearly a waste of valuable time, money, and energy of your people.
Finding out what causes team pressure
Some pressure is acceptable, but if you have the feeling that you are always working under pressure, that the pressure is hampering your teams to deliver value to your customers, then that is something that should be addressed. You can do that for instance with agile retrospectives where team members can state how they feel that things are going, and use questions to discover what can be done to reduce the pressure.
A retrospective can be used to find the root causes why team members feel that they are under constant pressure. You can do a five times why exercise to investigate the deeper causes:
- Do teams get enough freedom to do the work in the way they think it should be done?
- Are team members 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?
- How is the morale of your teams?
- Do team members feel happy when they come to work, and when they go home?
Using the retrospective you can find the causes of pressure, and take actions to address those in a next iteration.
Reaching sustainable pace
If too much pressure due to a large workload is really hampering the team then the team should take action. Possible actions that they can do are:
- Commit to a lower number of user stories in the planning game. Build in slack.
- Investigate which improvements they can do to increase the team velocity.
- Establish stable teams, which are capable of delivering quality and maintaining high productivity.
- Prevent multitasking / task switching as much as possible.
- Monitor work in progress, use Lean and Kanban to steer on flow i.s.o. working more hours.
- Plan time for team members to relax and blow of steam after having had a busy period.
- Focus upon happiness in your teams, make sure that team members have fun while doing their work.
Collaborate with your stakeholders
It may be good to involve your stakeholders to find workable solutions to reduce the pressure and find a sustainable pace that delivers value to them. Building trust is important: The stakeholders should trust the teams by assuming that they will do the best they can, and the teams should earn this trust by continuously delivering valuable products. In the longer run both the teams and the stakeholders benefit from a sustainable pace.
“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. The feedback and learning cycles from agile methods like Scrum can help you to improve. You need to invest time and energy, but when properly done it helps you to stop death marches, and to work in a sustainable pace.
Thanks for posting. Agree with all you say. Interested in your take on what happens if teams ignore/forget sustainable pace. Here is my example. A really good agile team has delivered 25 points a week (not scrum but Lean/Kanban or continuous flow) for a year (obviously sustainable). A deadline is looming and the team, in an effort to please their customer, jumps through hoops and burns the midnight oil and for a full month, delivering 34 points a week for 4 straight weeks. Do you incorporate these 4 weeks into their average velocity going forward? or do you throw them out.?
Steve, thanks for the example, nice one!
My thoughts on this: First I’m surprised that their velocity has not increased during a year. I would expect good teams to improve continuously, which would also result in higher velocity.
Second, I’m worried that the team may have increased their technical debt in their last month. Which will result in velocity going down, until the technical debt has been reduced.
Finally my experience is that a team work more hours and deliver more output for a couple of weeks, but not for a longer period. So there a big chance that last months pace is not sustainable.
I would do a retrospective to learn from this month. Is there any damage done that the team needs to deal with? Any improvements that they have done last month which should be continued? Anything that has surprised them or still puzzles them? Let’s turn this month into a sustainable learning opportunity!
Not sure pressure causes technical debt. It could be that developers choose to cut corners as a response to pressure. With self-discipline, developers can maintain good practices that control technical debt, and allow a different factor to give way under the pressure.
Agree there might be no direct link between pressure and technical debt, but it tends to happen often. Pressure tends to lead to habits, default behavior of people. If self-discipline is their default then quality doesn’t have to get hurt.
Question back: How do developers develop self-discipline?