Balancing Life and Work
One of the promises of Agile is a better work-life balance. But even with Agile this is not always the case. Sometimes projects are called “Agile projects” but are run just like a RUP or Waterfall-managed project. There can be “death marches” at the end of the project and work-life balance goes out the window. Other times there can be extreme peaks and valleys. These are not unique to using Agile by any means, but the question is, How can we use the Agile methodology more effectively to truly have a better work-life balance?
Real-Life Stories
I was on a newly formed Scrum team and saw first-hand how the use of velocity really led to a better work-life balance. This Scrum team, like other new Scrum teams I had been on, started off kind of rough. We did not initially meet our Sprint commitments and had trouble estimating User Stories. Over time our velocity improved and eventually became pretty predictable. But then something unfortunate happened: program management decided that the project deadlines were not going to be met, so they started to mandate Sprint commitments for teams. They knew for some teams this might mean closing 25% or even 50% more points in a Sprint. So, in order to accomplish this there was also mandatory overtime. At first we were told we just had to work four weekends in a row. Then it became six weekends. Then it became open-ended. Developers were working 13 hours a day plus weekends. All the talk of work-life balance completely went out the window.
Having enjoyed the early success on our Scrum team of using the team’s velocity to not overload the team, adjusting to this new way of working was painful. It is not that as developers we don’t have to work some long hours—that is fine (from time to time). But when it becomes the norm, it burns people out and can really kill team morale.
Thoughts
One of the ways we can achieve a better work-life balance using Agile is through the use of velocity. Velocity is a tool for capacity planning and ideally can be used to make sure the team does not overcommit to work. It’s not unusual for developers to overcommit (yes, we like to please managers and will sometimes say we can do in one day what takes three). The use of relative sizing (discussed in more detail in Chapter 13) along with a team’s velocity can help ensure that a team does not take on more work than it has historically been able to complete in a Sprint. If used correctly, and the team is the one making the Sprint commitment, then this can lead to a better work-life balance.
Of course, like anything else, the idea of using velocity as a planning tool can be gamed. So it is important that managers keep the team honest. The team will probably have a lower velocity when it is first formed, but every Sprint the velocity should get better—until it hits a plateau. Once that happens it will become harder to increase velocity, but it can be achieved by squeezing out waste from your processes. Of course, the velocity can take a hit for various reasons (unforeseen impediments, when team members leave, onboarding new team members, etc.). Also, make sure to do capacity planning during your Sprint Planning. This is not a technique that all Scrum Masters follow, but I’ve seen it work well. It means that before you make your Sprint commitment, take into account things like planned vacations, appointments, meetings, and so on. For example, if several people have vacation days during a Sprint, of course your Sprint commitment will be lower than your historical velocity, and that should be expected. As long as the Sprint commitment is lower for legitimate reasons, the team should not feel bad.
The bottom line is that if used properly, the tools we have with Agile can lead to a much better work-life balance for everyone on an Agile team.
Extreme peaks and valleys also disrupt work-life balance. I’ve seen this, to one degree or another, since I first started as a developer. I saw it earlier on when using Waterfall and then RUP. But when I started using Agile I saw fewer of these peaks and valleys. However, on one Scrum team I saw really bad peaks and valleys. A lot of these peaks and valleys came as a result of the way this organization did its funding. On this Scrum team we would work on a project for a while. When the project ended we would then have no work. The manager would tell us to find “filler work.” We would go weeks, or in one case over a month, without pulling things from the Product Backlog. Because of this, we had velocity per se. We randomly worked on things in the Sprint. Then a new project would get approved and all of sudden we were given a lot of work with a tight deadline. So we would go from not having any work to now working long hours.
There was no cadence on this team. We had no historical velocity we could trust. Even if the team wanted to commit to points based on historical velocity we couldn’t because there simply were not enough stories in the Product Backlog.
Thoughts
There was obviously a much bigger issue in the story. But in this particular organization, I talked to developers on other teams who were experiencing the same issues. However, even with the unique funding model of this organization, I think things could have been done differently to provide a better work-life balance.
One issue is whether Agile teams are 100% dedicated to projects or dedicated 100% to sustainment. If a team is 100% funded by project work, then it is likely there will be these kinds of peaks and valleys. Having a team split between project and sustainment work can be one solution. For example, we have a Product Backlog, and use Epics to divide project work and sustainment work (i.e., defect fixes and improvements). Then the team pulls from these two Epics (or maybe uses components or whatever makes sense in its environment) and commits to points based on its historical velocity. This does not have to be a 50/50 mixture. Maybe at times it is 80% project work and 20% sustainment and then 100% sustainment when there is no project work. This is just one possible solution, but the point is to find a way to have a good work-life balance and for the team to have a steady cadence.
Story 3: Great Work-Life Balance
While on a Scrum team that had been together for about eight months, I saw one of the best examples of work-life balance on an Agile project that I had ever seen. We were a cross-functional team (development, QA, business analysis) and we had several processes in place after eight months. Then we were told the project would be shelved and that we were moving onto a new high-priority project that had extremely tight deadlines. We switched from Scrum to Kanban (using Scrum meetings and a Work-In-Progress (WIP) limit and we had Service Level Agreements (SLA) based on point values). During Sprint Planning the team was really given full control of the Sprint commitment. We looked at our velocity from the last Sprint and our historical velocities and then planned out our Sprint. We were encouraged to keep improving and to commit to more points than the previous Sprint, but were not forced to do it.
The other thing that was key in terms of a work-life balance was the support of management. Both the technical manager and the project manager were very insistent that people go home at a decent time every day. This was because this particular organization had a history of projects with “death marches.” Leadership knew that death marches killed morale and they were determined that this Agile project would be run differently.
Thoughts
The project described in Story 3 became the gold standard for an Agile project within this particular organization. In large part this was due to the lack of stress and great work-life balance that everyone on the team felt. Even with launching on time and on budget, we had, maybe, two weekends of extra hours over seven months. We launched with very few high-priority defects (definitely no functional defects).
The key was letting the team decide what to commit to each Sprint. The team knew the amount of work for the project was not changing (i.e., everything that could be descoped was already removed), but team members were allowed to decide how much they could take on each Sprint. This led to transparency with the business, which meant no surprises. It was then up to management to decide how to handle any gaps between projected velocity and the deadline.
The other key to this Agile’s project success was management’s support. Hearing from a technical manager that it’s OK to leave at 5 p.m. and to not burn yourself out was refreshing. On so many software delivery projects (Agile or otherwise) it is all about getting something out the door, no matter the human cost (I talk about such a project and the detrimental effects it had on developers in Chapter 7). In a strange way, lack of pressure actually made everyone on the project work harder and do better work.