Sweden is a great country! We even have laws that states that everybody has the right to five (5!) weeks vacation every year. Many people even have 6 or more. And most of us take at least 3-4 of them in a row during the summer - the best time to be in Sweden.
That’s all good but what happens at the offices do you think?
Well that’s easy to figure out. There’s no-one there. And since not everyone has vacation at the exact same time (normally) this can go on for about 2 months or more. This of course poses a problem for teams that want to work close together.
Even if you don’t have 7 weeks vacation in your country you may find the reasoning in this post interesting. I learned a lot when I thought about this (and from brilliant people I talked to).
At the last Lean Coffee I attended I asked the question about what people do during the summer when working with agile; How do you manage your summer sprints? The discussion wandered off (I’ll get back to that) but we started with some practical stuff.
Sprint length
The first, obvious question, was how long the sprints people had during the summer. Here’s a couple of possible solutions:
One really long sprint that covers the whole time until we’re all back together. I’ve heard of 7 week sprints or even 3 month sprints. This seems to be the way that most inexperienced teams seem to lean towards. The obvious problem is to “stack up” with things to do. Common solutions are either to really have a lot of things in the backlog ready to be started or just do technical stuff when the business stuff runs out. To create such a stock of work items is both hard and may not be what you want - all the talk about agile is out the window. I don’t like this approach as it’s basically abandoning all the values we have strived to come closer during the “normal” season.
Shorten your sprints and do what you can with the people that happen to be in the office at the same time. This is a flexible solution in which you scope down to, for example, 1-week sprints. The planning is done with the people present and you only take on what’s possible for that workforce.
I like this approach because of the flexibility - but it has some problems to it.
- Who decides? The big problem with an extended period of time of people being away is that you don’t have the “right” people to ask questions. If you’re stuck - you are really stuck. So you need to be careful what to pick. Picking the wrong stories leads to a lot of stories being “almost done” - an agilist’s worst nightmare.
- Sooo … what can WE do? You may find yourself in a situation where it’s just 2 database guys at the office on a week. And the top 10 priority stories have to do with front-end stuff. This can either be solved by dodging the things you cannot do (breaking the priority order) or start learning (yes, even though it goes slower).
What vacation? We run as normal here. Some teams just adjust to the fact that they are fewer people and run as normal with 3-4 week sprints. That’s perfectly fine but has some intrinsic problems to it. People we need to ask are not present. When we get blocked it’s hard to unblock since the needed people are not present. Also planning and acceptance are subject to problems due to people being absent.
Responsibilities
Yes, as you can see, a lot of the problem has to do with responsibilities. First and most apparent the responsibility of requirements and acceptance of work items. This is commonly done by one person. In fact, even the agile method Scrum advocates a single Product Owner. So if she is not present … we have a problem to solve.
But there are other responsibilities as well - we still have specialists that cannot easily do other work. Designers, database experts or programmers are examples of that.
“I don’t know much about that part of the system. It’s Anders’ field. I’ve never touched it. We cannot take that story on.”
The vacation times are great for spotting these areas where we are vulnerable to a low truck factor (number of people that need to be hit by a truck before the project is in serious trouble). And then do something about it.
Learning
So more than anything I think the focus of the summer sprints should be on learning. When did we run into problems? Are there areas that just one of us knows about? Can we share the acceptance responsibility? Can it be delegated?
We’re talking a lot about cross-functional teams that share responsibilities but in reality … this belongs to someone. This is a great opportunity to find those out.
The CIO of the Swedish lorry maker Scania, Leif Östling, has a saying that has spread throughout the organization:
Love your deviations!
That’s a great, although a bit negative, view. The deviations are areas where we can improve. That’s that part that doesn’t work - let’s focus our attention there.
Summary
I would recommend to do a summer sprint retrospective when the whole team is gathered again to note these problems down and start to make plans for how to manage the next vacation time better. In Sweden that would be during the Christmas holidays when we all go to another 2 weeks of free time. :)
Maybe this “problem” could be the start of your team starting to really collaborate. If nothing else so just to be able to handle the next vacation period.