To paraphrase Elisabeth Hendrickson’s “agile acid test”, modern software development is about delivering small chunks of value to customers frequently, at a sustainable pace. That “sustainable pace” encompasses all the good development practices that allow teams to perform well consistently. Practices like test-driven development, pair and ensemble programming, continuous integration, acceptance test-driven development – just a few of the practices seen as part of “agile” since the days of eXtreme Programming.
Some organizations have embraced agile practices and enjoyed a sustainable pace for more than two decades. And yet, we still see many software organizations fail to understand that working at a sustainable pace is key to delivering valuable changes to customers frequently and predictably.
The slippery slope
Recently, Janet was working with an organization whose master backlog was long, and the clients all wanted their features to be built – you’ve got it, by yesterday.
Everyone in this organization means well. The product people were trying to prioritize. But there was still more coming into the teams than they could handle without sacrificing quality. One of the team’s choices were to work longer hours to meet their “commitments”. (It’s worth noting that Scrum leaders abandoned the idea of “commitment” in favor of “forecasting” years ago).
Our question is to you is – how long do you think this team can keep going? How long can they maintain the long hours, the stress levels?
There is no easy answer to this quandary. Company leaders want their development organization to crank out features so the business can grow. They often pressure teams to meet unrealistic deadlines. Sometimes the teams put this pressure on themselves, keen to prove their value and make business stakeholders happy. Teams often think they have no choice but to keep working that hard.
Step back
Is your team falling into the trap of working extra hours, and skimping on good practices to “save” time, only to face more impossible deadlines while accumulating technical debt? It’s a good idea to take a step back and look at your process and observe what is happening.
People on overworked and stressed-out teams may feel powerless to push back on unrealistic demands. Yet, often we have more influence than we think we do. For example, the team could simply agree that they will not work more than 40 hours (or whatever your standard work week is). This can highlight how much the team has been overworked. Often, organization management does not realize how much extra teams are having to work to get things done.
In one team Janet consulted with, management told the teams to put 40 hours into the timesheet no matter what they worked. They were trying to simplify it for the teams but didn’t realize they were hiding a problem.
Finding a path to sustainable pace
If you find yourself in a similar situation, look for ways to make the overtime visible. You could talk to the “powers that be” and suggest an experiment to capture “real” hours worked and make it very visible to everyone. Maybe you could visualize it on a chart, like those thermometers that capture how much money is raised towards a goal, showing how many hours the team has put in each week.
Retrospectives and other working sessions could be an opportunity to design experiments to try and address non-sustainable pace. One approach that has worked for our teams includes learning to slice stories into small, consistently-sized increments – where each story can be finished, including testing, in two days. That way, if a story “blows up” and takes twice as much time as expected, it’s still not a lot of time. Along with this, the teams agree to be disciplined in limiting work in progress to, say, two or three stories at a time. This helps the team achieve a predictable, consistent cadence, which makes the business stakeholders happy.
If you’re a manager whose team is often working nights and weekends, find ways to educate the business stakeholders that their software organization is in a death spiral that will end with projects grinding to a halt. Show them how technical debt and opportunity cost are hurting the bottom line. Budget time for the team to learn and adopt good development practices that will allow them to avoid waste and re-work and deliver small changes at a frequent cadence.
Nurture a learning culture
Lisa worked on a team that had been failing to release anything to production for month. The company leadership hired an expert agile coach and allowed the team time to determine the best way forward to learn the skills they needed. As they learned basics like continuous integration and test-driven development, they only delivered small changes every two weeks – but they did deliver something! Allowed to invest the time in continuous learning and using each retrospective to plan the next step forward, they soon became a high-performing team. The business could depend on their cadence of releasing new changes and had a highly competitive product to sell.
If you’re part of a team that is headed for trouble trying to keep up with an impossible workload, talk about it in your next retrospective. As with any obstacle, brainstorm small experiments to try as “baby steps” to allow for more a more sustainable approach. See if your team can start avoiding overtime and watch for the benefits of following a sustainable pace. Organizations cannot afford the effect of not having sustainable pace which is burnout and turnover – a very expensive result for everyone.