Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Individuals want to improve their skills, teams want to create more, and everyone wants to go faster. However, improving skills and creating more both require time: something we have a finite amount of.
In business, the solution to the time conundrum has historically been to work more hours. The idea being that if we can create a certain amount of stuff in 40 hours, we should be able to create double that in 80 hours. However, that is not the case.
When people consistently work overtime, we’re more prone to make human error, more prone to make mistakes, and more prone to not think clearly. That typically leads to poor quality software and a pace of development that leads to missed deadlines and compromises that lead to lots of technical debt over time.
Another solution teams might try to implement to overcome the time conundrum is to throw a bunch of developers, testers, and hours at a project as a deadline approaches. In my experience, teams who consistently work overtime late in projects actually increase the time it takes to deliver, and they deliver lower quality software. Typically, these teams have to spin up new people, push off other commitments, and stop communicating because everyone is heads down trying to get the work done.
A prime example of both of these issues in action is the well documented disaster of the Affordable Care Act’s Healthcare.gov initial release. Prior to release, the prime contractor CGI ramped up staff weeks before the release to try to fix the broken system and forced employees and staff members to work extreme amounts of overtime for weeks on end to try to “fix the system” before release. New engineers were often not able to onboard successfully without impacting velocity and required additional instruction from key individuals already overloaded with responsibilities. In the end, more staff and more hours didn’t result in a better quality product. In fact, it resulted in more bugs and technical debt being introduced.
The abundance of mismanaged teams providing minimal value resulted in CGI and the government throwing more people at the problem by implementing multiple siloed war rooms to address the problem. These war rooms didn’t effectively communicate with one another to solve any technical problem, in fact, they often communicated different messages on the actual readiness of the system to the government. More complexity and more staff didn’t result in solving problems, it just decreased velocity, created more meetings, and resulted in more confusion and miscommunication.
Working overtime happens, but overtime shouldn’t be a part of your company culture nor should requiring heroics. If one person on the team is pulling some heroic effort to make sure the team makes commitments on a regular basis, you have a sustainability problem.
If you’re regularly running into one or both of these situations, there’s probably one of two things happening:
A. You’re overcommitting all the time or
B. The team is accepting scope creep
If you’re experiencing problem A, you might consider slowing your velocity until you’re sustainable, then ramping that velocity back up over time as the team because better equipped to do so. It’s important, though, to make sure as you measure and track velocity that you’re thinking about short- and long-term sustainable pace.
To solve problem B, the first step is to recognize and acknowledge that scope creep is happening. If you commit to something at the beginning of a two-week sprint, and it changes before the end of the sprint, it can be challenging to accurately estimate and deliver mid-sprint changes. If you allow scope creep, you must recognize that teams can’t meet deadlines they didn’t commit to at the beginning of the sprint.
If you’re truly agile, everyone on your team—from product owner to developers to testers to operations—is working at a pace that is sustainable over time. Of course, you might have weeks where team members put in more than 40 hours, but, ultimately, you’ll want to create a team dynamic where individual work sustainably to improve productivity, increase employee engagement, and reduce the likelihood of burnout.
I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.
