A quick tip for Scrum Masters as we head into the summer months. You may have recognized this in the past but the allure of sunshine and warm weather can impact the productivity of your team.
A study by Captivate Network of 600 workers reveal a 20% decrease in productivity during the summer. There are many reasons for this and the study indicates a few of them. Between long lunches, leaving a little early on some days, and company outings this does make sense. After the crazy winter we’ve had in the Midwest, we are all feeling the need to venture outside and enjoy the sunshine.
If you are sensing a productivity lag with your teams, here are a few things to consider:
Adjust your planning velocity. Reduce the velocity used to determine how many stories the team will commit to during a sprint. I call this the “summer velocity.” I have used a 25% reduction in the past and it seems to be about right but tweak as necessary. If the team finishes their sprint stories early, the team can always pull stories in from the backlog. By adjusting the velocity, the frustration of participating in a sprint review with unfinished stories and nothing to demonstrate is removed.
Establish realistic expectations. If you have a major release planned for later in the summer, prepare the organization for variability. If possible, Mike Cohn recommends planning slack by using feature and schedule buffers. Feature buffers inform the organization which features may not be completed by the release date while schedule buffers are created by adding a period of time to reflect uncertainty. [1]
Amplify productivity cycles. As you observe your team, you may begin to notice segments of the day when they are more productive than others. Some teams work well in the morning while others don’t really get going until noon. When you have identified the productivity cycle of your team, make the best use of this time but clearing anything that could interrupt them or cause a loss of focus and energy. Perhaps meetings or team social activities can be shifted to non-productive cycles.
Enjoy the summer everyone!
References:
[1] Cohn, Mike (2006). Agile Estimating and Planning (pg. 188-189) Prentice Hall.
3 replies on “Summer Velocity”
Len,
I’m torn on this, I believe my role as Scrum Master means that I encourage (nay even push) the team to perform to their highest level in my engagement with them, and protect them at all costs in my engagements with the rest of the org.
While I like to be realistic, allowing/encouraging the team to relax just because its summer doesn’t qualify as pushing them hard internally and could be a slippery slope (Christmas, Easter, Memorial Day, Arbor Day, Groundhog’s Day where does it end?). (http://list25.com/25-strangest-holidays-that-people-actually-celebrate/) :-)
I look forward to a spirited discussion with your other blog devotees.
Wade
ScrumMaster, PSM I
Thanks for the comment Wade! Here are a couple thoughts to get the conversation started.
The spirit of this post was written to reflect what teams face in reality, as you mentioned. Based on the survey mentioned in the post and my own experiences, there does seem to be a correlation between summer and a reduction in available hours. The post is meant to stress that historical velocity should be adjusted whenever circumstances warrant and not use it blindly thinking this sprint will be exactly the same as the last sprint. I would rather see a team commit to a little less and if they get that finished they can pull in the next story on the backlog. The alternative would be either missed commitments (a poor review session) or the team would need to be “pushed” as you mentioned to work additional hours to make up for the time missed. I am a strong advocate for “pulling” instead of “pushing.” https://illustratedagile.com/2012/06/19/coaching-pull-scrum-team-dynamics/
I believe the Scrum Master is there not to protect the team from the rest of the organization (although this may need to happen occasionally) but to protect the team from themselves. Most teams I have seen take too much on and by doing so quality suffers, shortcuts are taken, and the team falls out of “flow.”
Looking forward to further discussion!
I will argue that “pushing” a team is not the right approach anyway. If the team slacks, and the product owner is unhappy with their results, trust will erode. All that is bad when trust is lacking will follow. I believe that the scrum master should be neutral/”Switzerland” — just reporting the truth to everyone.
That DOES mean reminding the team that if they don’t deliver, there ARE people who will be unhappy, and bad things might follow. It does not mean pushing the team; just help them see what the consequences are for reducing effort. And, I suppose, help the product owner or other interested parties understand the benefits of a happy team (however happiness is achieved).
Final thought: there is something to be learned from the Results Only Work Environment model. Not all companies, teams and people are truly mature enough to handle ROWE (and ROWE as a concept is probably going to fall hard into the Gartner hype cycle trough, if it hasn’t already), but as a model, I think it fits well with agile principles. How about “we value making and meeting reasonable commitments over counting the hours your butt spends in a chair?”