Summer sprints - a time to learn

· August 15, 2012

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.

Twitter, Facebook