Taking a Sprint Off to Rest
Taking a Sprint Off to Rest
In this article, we pull a challenge from the sports page, that of resting key players, and wonder if there is some merit in the world of Agile.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
There has been a trend in the National Basketball Association (NBA) where teams are allowing their marquee players to take a night off during the regular season. This has drawn some criticism from fans and the media since people are buying tickets to the games with an expectation to see their favorite players actually play the game they are paid to play.
This made me wonder if it's okay to take time off during a Sprint to simply rest. Not taking vacation time or recovering from being ill, just taking time off to rest.
Putting Things Into Perspective
A regular season in the NBA is 82 games. Let's say the marquee player decides to take five games off during the season, which translates into about 6% of the regular season. The typical Sprint team member ends up working about 235 days a year (with vacations, holidays, sick time) and 6% ends up being about fourteen days. Interestingly enough, fourteen days is right between the number of days for a two-week Sprint and a three-week Sprint.
Would do you think your Scrum Master, Manager, or C-level executive would say if you told them you needed to take fourteen days to relax - without taking vacation time, but you still expect to be paid for it? I am sure the request would not sit well.
Is This Justified?
While asking for 14 days off in a row may be excessive, studies have shown that taking breaks does have a positive impact on employee’s productivity. In fact, the following study at open.buffer.com provided these three benefits:
Breaks keep us from being bored - brief interruptions are crucial when trying to get back on-track and in the groove of being productive.
Breaks help us retain information and make connections - understanding the "diffuse mode" of the brain can be helpful toward maintaining productive results.
Breaks help us reevaluate our goals - taking a break makes it easier to step back and keep the big picture in mind.
The article goes into detail about various methods to think about when trying to implement a break strategy.
So Why Not Take Off an Entire Sprint?
Taking these findings a step further, if your team has continued to deliver Sprint after Sprint, I wonder if taking a Sprint off might yield some significant benefits. This is not to say that everyone simply checks out and does nothing, but perhaps this can be a time that is focused on other aspects:
Training Opportunities - allow the entire team to learn a new technology or skill.
Volunteer Opportunities - offer the team's services to a non-profit in dire need of technical assistance.
Focus on Other Challenges - look for another opportunity that would have otherwise not been considered a priority.
In essence, each of the suggestions above would serve as an interruption (fending off boredom), stimulate the brain's "diffuse mode," or provide the opportunity to take a step back and appreciate the bigger picture.
Upon hearing the challenges with the NBA regarding players resting when fans are expecting them to play, I wasn't happy about the situation. The road to becoming an NBA superstar is the dream of so many basketball players, that it seems trite for anyone to feel like they are entitled to just not play, but still get paid - all the while the stands are being filled with ticket holders expecting to see their favorite player in action. After all, 82 games are really not a lot of games for a professional athlete.
However, when I put this idea against an Agile team and consider the potential benefits to taking a Sprint off, I no longer believe the idea is as absurd as when I started thinking about this situation.
What are your thoughts?
Have a really great day!
Opinions expressed by DZone contributors are their own.