Thursday, September 13, 2018

Regain team motivation by using slack time | Supreme Agile


Similar to real life, you can’t always sprint. If you're not a robot you need to rest in between sprints. What’s relevant to the best athletes is relevant to scrum software development as well. 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 very intensive because their main purpose is to provide value to the customer who is 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 very fast 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 really no time for resting, which is highly important.

“Slack time” provides the rest time the team needs in order to regain their strength. But that's not all: it also helps increase team motivation and morale (important 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 that they need 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, so they can 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 very simple: 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 to introduce some kind of slack before the team starts the new sprint. We would like to make sure the team has time to rest and think in the period after the sprint retrospective and before the next sprint planning meeting.  

One thing that I learned over the years is that you cannot always succeed with this approach, but at the very least, you need to try to give the team some slack prior to jumping into the planning meeting. To do so, 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 12:00: 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 there are some tips that can help:

  1. Learning days should be added per month and not after each sprint, so in the case of two-week sprints, we will add one learning day at the end of the second sprint.
  2. Although this time is dedicated for 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.
  3. Try to make this day global for the whole organization; it becomes less effective when some teams are working and some are resting.


Thanks to Tally Helfgott for proofreading :) 

Linkedin Profile


No comments:

Post a Comment

My Presentations