Regain team motivation by using slack time | David Tzemach
Like in real life, you can’t always sprint if you're not a robot; you need to rest between sprints. What’s relevant to the best athletes is also applicable to scrum software development. In scrum, the team works in short intensive iterations of 1-4 weeks, which is quite different from what we used to see in traditional software methodologies that are more similar to running a marathon.
Scrum sprints are intensive because their primary purpose is to provide value to the customer waiting at the end. At the start of the sprint, the team creates the sprint backlog that reflects their commitments (here is some pressure…) and needs to work in a speedy and changing environment. A team member who needs to work in such an intensive environment usually does not have time to relax and put off their tasks (the customer is waiting). So, in the end, there is no time for resting, which is highly important.
“Slack time” provides the rest time the team needs to regain their strength. But that's not all: it also helps increase team motivation and morale (essential factors for creating self-organized teams). At the end of each sprint, the team conducts a review meeting, where the team presents the sprint deliverables and a retrospective to discuss what the team wants to improve/keep in the next sprint. After these meetings, both the team and the product owner will be full of information, tasks, and ideas to implement in the upcoming sprints.
The common practice in the industry is that the scrum team starts the planning meeting right after the retrospective is over to start the next sprint on the first day of the following week. And now for a simple question: do you think the team can effectively prepare for the next sprint with all the data they generated during those meetings (which is still related to the previous sprint)?
The answer is straightforward: if the team immediately starts planning the next sprint, I can assure you that the chances are that the majority will not be focused enough to conduct the meeting as they could have had they had the time to stop and think about all information and lessons learned. The PO will not have time to prepare the backlog (based on the feedback received during the retro/review meetings), and so on. LET’S GIVE THE TEAM SOME SLACK The solution to the problem I just described is introducing some slack before the team starts a new sprint. We want to make sure the team has time to rest and think after the sprint retrospective and before the next sprint planning meeting. I learned over the years that you cannot always succeed with this approach, but at the very least, you need to try to give the team some slack before jumping into the planning meeting. Sometimes, I change the meetings’ timeframes by sending home all team members once they complete the retrospective of the current sprint and schedule the planning meeting for the next day or the beginning of next week. Example: Without using slack time: Friday 10:00-11:00: Sprint review (Sprint 1) Friday 11:00-12:00: Sprint retro (Sprint 1) Friday 13:00-17:00: Sprint planning (Sprint 2) With slack time (option 1): Friday 10:00-11:00: Sprint review (Sprint 1) Friday 11:00-12:00: Sprint retro (Sprint 1) Friday noon: slack time. Monday 09:00-13:00: Sprint planning (Sprint 2) With slack time (option 2): Thursday 08:00-09:00: Sprint review (Sprint 1) Thursday 10:00-11:00: Sprint retro (Sprint 1) Thursday 11:00: slack time. Friday: Learning time Monday 08:00-12:00: Sprint Review (Sprint2) Note that in option 2, I added another day (Friday) that the team can use for learning or, in some other cases, to do whatever they think is best for them (in most cases, they will invest the time to create a better working environment that will be worth the effort in the long term). IF YOU DECIDE TO USE LEARNING DAYS, SOME TIPS CAN HELP:
Learning days should be added per month and not after each sprint so that we will add one learning day at the end of the second sprint in the case of two-week sprints.
Although this time is dedicated to the team, you still need to see whether it adds real value. There is no reason to use these days without adding real value to the team, process or the business.
Try to make this day global for the whole organization; it becomes less effective when some teams are working, and some are resting.