Working at a Sustainable Pace is one of the principles of the Agile Manifesto that is often hard to achieve.
The Agile Leaders discussion group has recently been addressing the topic of Sustainable Pace.
The discussion centred around identifying what a sustainable pace IS and how to achieve sustainable pace consistently.
Bob Sarni opened the discussion by quoting the principle: "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
He states:
In my experience working with many organizations and teams, sustainable pace seems to be one of the major issues facing teams and organizations. There are many factors into maintaining a sustainable pace - product road-maps and commitments, vision, velocity/flow/ cadence, work/life balance, visibility, corporate culture, personal issues, trust, multitasking, etc.
Sustainable pace at a team level can be even more challenging because each person on the team has their own sustainable pace that contributes to the overall pace.
Manoj Vadakkan identified the problem of not working at a sustainable pace as being linked to organisations adopting Agile practices without an understanding of the underlying values and principles that
The major problem I see with Scrum adoption is that it is being adopted as an iterative process with no foundations on the principles and values. Would you agree that the issue with Sustainable pace is one of the issues that we see when our process is not based the values?
I am afraid, in general, we are not saying enough that - this (Scrum) will not work without the foundations of the Agile values and Principles.
Other contributors agreed that without the Agile values as a starting point then an Agile/Scrum transition is not sustainable, with teams and individuals at risk of burnout. Scott Duncan described his experiences with larger organizations:
1) What they current expect people to "sustain" is what I have heard called the "professional week," i.e., 50 hours or an assumed 2 hours per day "overtime" for which exempt people are not compensated;
2) Estimation approaches based on hours that assume at least 40 productive hours per week (even if the week is only expected to be 40 hours) which take individual feature/requirement estimates in hours and then "fill up" the total team/staff/project hours by taking on features/requirements that add up to the number of people on the team/project times 40 times the development time period in weeks;
3) No real concern for what is sustainable in the face of the belief that true professional will "do what it takes to get the job done";
4) Starting out "the job" with plans that assume all time is already accounted for so any unplanned events (e.g., changes, design "discoveries") already assume overtime as the approach to absorbing them.
Manoj Vadakkan referenced an post of his on the Scrum Alliance website in which he concludes:
Sure, the customer may not care if your employees are working long hours every day but have you talked to them about the quality of the code as a result? Try telling them the downside and they may start to care. In the long run, the customer will be the one to pay when they want to change the code for next release. Do you still think sustainable pace is a nice to have? Maybe we should check with our customer. Maybe they would agree that quality is nice to have too or maybe not. One thing is for sure, we shouldn’t make the decision for them
Karen Greaves offered some concrete advice based around her own experiences:
Currently the way I work with this in my organization is:
1) remove any link between hours at desk and productivity or value delivered. Never measure hours worked as a manager. I.e. No time sheets, no fixed working hours, not even a suggestion that you are "required" to work 8 hours a day. Rather set expectations about what people are supposed to deliver.
2) focus rather on getting things done than being busy. If you are having a pointless day go home. If you are on fire and getting things done - keep going. To paraphrase Kent Beck "every hour at the office that you don't want to be there is overtime"
3) never ever ask people to work weekends
4) focus on providing an engaging goal to motivate people to achieve it because they want to rather than a made up unachievable deadline.
5) build slack in. Have days or periods when people specifically aren't supposed to do their regular work. We do Fedex days, lab days and have regular Friday learning sessions.
So far it's working well for my teams, and although it's hard for business to swallow, sticking to my guns on this seems to have paid off. When I started this job over a year ago the team worked weekends and late nights regularly. In the last year, we have delivered every release before 6pm on release day and not worked a single weekend. Quality has improved, staff satisfaction has improved, staff retention has improved. Productivity has been up and down but can be directly correlated with the clarity of the goal/plan for the release.
Outside of the Agile Leaders group a number of commentators have discussed Sustainable Pace.
Bob Hartman (“Agilebob”) posted “New to agile? Work at a sustainable pace” in which he points out the likely results of not working at a sustainable pace:
1. Defects will increase. Tired teams let more defects through.
2. Work output will decrease. Tired teams do less work in more time!
3. Morale will drastically decrease. This may lead to employee turnover at a most unfortunate time in the project.
4. The blame game will become common. (Not our fault you didn’t say X. I said X. Did not. Did so…)
5. The team starts to abandon good practices for those that “seem” faster. Sorry, but test-driven development (TDD) is actually faster than just writing the code and throwing it over the wall to QA!
He gives some firm advice to leaders on Agile teams:
Project managers and Scrum Masters need to watch the mental and physical health of the team. Be the conscience of the team when it comes to maintaining a sustainable pace. Re-read that last sentence and ask yourself when the last time a project manager asked a team to reduce their hours because it wasn’t healthy!
What does Sustainable Pace mean in your team, and how do you ensure it stays that way?