Retrospectives with Distributed Teams

 Comments Off on Retrospectives with Distributed Teams
Nov 242012
 

Retrospectives are no less important for distributed teams than co-located ones, but there are additional challenges that have to be overcome to make them effective. In this post I’ll share a few of the things I have learned.

Timing

What’s the right schedule for retrospectives with a distributed team? With co-located teams, I like to end sprints on Fridays, and have a retrospective at the very end of the sprint – not wrapped up with the planning for next one. This brings psychological “closure” to the sprint, giving the team an opportunity to get everything out in the open so they can relax at the weekend, and come fresh to the planning session for the next one. With distributed teams in different time-zones this might not be feasible, but I recommend getting as close to it as possible.

Well managed retrospectives with co-located teams can run for a couple of hours or more without losing their way – or the concentration of the team! Much more intense concentration is needed to engage in a long conference or video call, and I’ve found that when the hour mark is passed the meeting becomes less and less productive. So, time-box the retrospective to ninety minutes, but craft an agenda that’s doable in sixty.

Culture

Cultural differences come to the fore in retrospectives. In particular, different norms around hierarchy, openness and directness can but a big damper on the whole effort. You can’t change someone’s cultural background but you can do a lot to explain the purpose of the retrospective, and ask them to step outside their comfort zone for a little while so the meeting can achieve its goals.

Use the Retrospective Prime Directive as a starting point, and give examples of the kind of feedback you expect. Use activities which allow team members to feedback anonymously, when you think that might expose facts and opinions that would otherwise stay hidden. If all else fails, talk to team members individually before the retrospective, help them understand the value of giving their input to the whole team, and to think of ways to communicate unambiguously that are also comfortable for them personally.

Technology

Thankfully, we have come a long way from telephone conference calls in the past few years! Retrospectives that only use audio tend to be tedious in the extreme, and although video calling is better it remains a far cry from the rich interaction that comes quite painlessly when the team is in a room together.

There is plenty of new technology which helps us rediscover that ease and richness of collaboration. CorkboardMe is a simple and highly responsive virtual board – of infinite dimensions – that the team can add virtual post-it notes simultaneously. It works really well for visual activities like Mad/Sad/Glad, as shown below. It is limited to post-it notes of different colours and sizes – there’s no freehand drawing – so plan in advance how you will work within that.

Scribblar.com is similar, but a free-form whiteboard. It’s flexibility means a lot more hands-on facilitation is needed, but used judiciously it can solve some difficult remote collaboration problems.

And finally…

The retrospective is an absolutely crucial part of Agile and Scrum – the driver of improvements that allows us to focus on execution during the sprint, safe in the knowledge that everyone will get an genuine opportunity to speak their minds at the end. No matter how dysfunctional a project may be, a working retrospective brings it all out into the open, and drives the team to take specific actions for the greater good of the project and the team. Wherever a team happens to be located, it’s a part of the process that we simply can’t do without.

Nov 062012
 

I passed the Scrum Alliance’s (relatively) new CSP exam last week. Before the switch to a 3-hour 150-question multiple choice format, the qualification was assessed by submission of a written case-study. There was a substantial backlog of papers to grade, which is not surprising as that job, I am told, fell to unpaid Alliance volunteers!

The exam was unlike any I had taken before, so made the whole process of study and assessment an interesting experience which I think is worthy of covering here. What made it so unusual? First, the sheer volume of questions – 150! The CSP exam handbook (PDF) classifies the content into 65 “tasks” in 7 domains, which goes some way to explaining why the questions have to go on… and on… and on. Secondly, some questions are “fluffy” – there’s room for interpretation and shades of correctness requiring you to choose the option which is “most” or “best”. There are sample questions in the exam handbook and a $20, 35-question practice test which illustrate this.

If you have arrived at this blog post from a search engine, you probably want some tips on the exam. I’m happy to give some pointers, but it’s a tough exam so don’t expect that reading a few tips will make it easy to pass!

1. Study

There’s no way around it, this is an exam you have to prepare for with good old fashioned cramming from books. And passive reading isn’t going to cut it, you really have to understand. For me, that means sloooooow reading with plenty of time for reflection and wherever possible, application. There’s nothing like real-world use to take lessons to heart.

The exam handbook has a useful reading list. The stand-out book for me is Scrum Alliance Chairman Mike Cohn’s Succeeding with Agile: Software Development Using Scrum. This has a fantastic scope and gives a good grounding in Scrum beyond the basic framework. Read it, then try as much of it as you can in practice. Then read it again. Then read some of the other books.

2. Read related content

I’ve always found that “reading around a subject” – studying content that’s related but not integral – is very effective. Knowing more than you strictly need to somehow makes it a lot easier to understand what you must. It also provides some mental recuperation without completely going off-piste with the latest paranormal romance (which is, by the way, a genre of fiction that really doesn’t need to exist).

Scrum is about people, technology, management, innovation and much more – so there’s plenty of books you can use to “read around”. On my reading list I had Dan Ariely’s Predictably Irrational and David Anderson’s Kanban, as well as a lot of technical tomes. None of those are about Scrum, but do a great deal to put it into context.

Another great way to learn around is to take part in conferences, meet-ups, and other groups. By sharing experiences you can put yourself in the shoes of other practitioners, and gain an appreciation of situations that you have never seen first-hand.

3. It’s Scrum, Jim, but not as we know it

CSP is a Scrum qualification, but the goes well beyond the mechanics of Scrum – a fact well-illustrated by the content outline in the handbook. Knowing the Scrum Guide backwards is the foundation for CSM and Scrum.org’s PSM I, but won’t cut it for CSP.

A good appreciation of Agile as a generic approach and related technical practices are pretty crucial – you need to have really internalised the Agile mindset to quickly (almost instinctively) assess the right approach in different situations.

4. Put it into practice (but don’t get tunnel vision)

I can’t imagine someone passing the exam without getting into the sticky business of doing Scrum/Agile in the real world. In fact, 2,000 hours of Scrum-related work in the past two years are an eligibility requirement. Working as a ScrumMaster is the most obvious position, but any Scrum role (i.e. developer or Product Owner) could in theory provide the right exposure and opportunities.

Be careful to use your experience but not be constrained by it. CSP takes a broad view of the Scrum world and your experiences are likely to be narrower, and sometimes in conflict, with what’s best in a broad range of circumstances.

5. General multiple-choice exam tips

The common, time-honoured, advice for multiple choice tests is worth bearing in mind. There’s some good tips in the exam handbook, but the ones I find most useful are:

  • Use a process of elimination. If you aren’t confident of the answer but can eliminate two options, the odds are swung massively in your favour.
  • Take your time, but don’t agonise. Methodically work through the questions and when you have done all you can, move on. Racking your brains is more likely to lead to frustration than the right answer.
  • Take breaks. 150 questions is a lot. You can’t get up and stroll around, but you can close your eyes and relax a few moments at regular intervals. Getting a little breather can help maintain perspective.

Summary

I’ve taken a good few technical exams over the years, but the CSP is very different. You can’t simply cram and regurgitate facts to pass, which is refreshing – but challenging. I initially viewed the CSP with some scepticism but have come to appreciate that an automated exam which fairly assesses a complex, nuanced body of knowledge is quite an achievement, and it really means something to pass.