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 have 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 wander 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 seems to lean
against.
The obvious problem is to "stack up" with things to do. Common solutions
is 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
happens 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 have 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 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 week. And the 10 top
priority stories has 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 team just adjust to the
fact that they are fewer people and run as normal with 3-4 week sprints.
That's perfectly fine but have 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 is
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 advocate a single Product
Owner.
So if she is not present ... we have a problem to solve.
But there's 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 spot these areas where we are vunerable
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? Is 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 team that share
responsibilities but in reality ... this have a way of beloning 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 have spread through out the organisation:
> 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 goes to another 2
weeks of free time. :)
Maybe this "problem" could be that start of your team starting to really
collaborate. If nothing else so just to be able to handle the next
vacation period.