Scrum basics: Retrospectives

Retrospectives are a frequently overlooked aspect of scrum.  Perhaps this is because they are “non-functional”, in the sense that they don’t contribute directly to the output of the team.  I maintain, however, that good retrospectives are the key to a highly functioning team.

What is a retrospective?

A retrospective is a meeting where the team get to reflect on their current progress and process and decide how they can improve it.

What does it mean to improve progress and process?

It can mean absolutely anything … the team get to decide.  Remember that the purpose of scrum is to build a team that can smoothly and effectively deliver business value on a regular basis.  Anything which gets the team closer to this goal counts as an improvement.

It’s also important to point out that it is the team themselves which decide how they can improve.  People such as managers, IT directors, agile coaches and so on can make suggestions, but the team needs to take ownership of their process.  This is what it means for a team to be “self-organising” … an agile term which is bandied around a lot and is often misused.  The self-organisation of a scrum team is the main points of retrospectives.

What’s the difference between a good and a bad retrospective?

Retrospectives, like a lot of things in agile, need to be judged on their outputs.  A good retrospective will produce improvements that address important issues the team is facing.  A poor retrospective will skirt around issues and address unimportant issues.

For instance, suppose a team is consistently releasing buggy software.  A good retrospective will attempt to address the bugs, both in terms of fixing outstanding issues as well as attempting the underlying cause of the bugs.  A bad retrospective would focus on other incidental issues, e.g. variable names not adhering to the agreed coding standards.

Poor retrospectives can happen for a number of reasons:

  • they may be unaware of how well they are meeting business priorities (e.g. they don’t know that their software is buggy)
  • the team may be unaware of business priorities (e.g. they may mistakenly think that the bugs have a minor impact)
  • the team might not care about business priorities (e.g. they don’t care about their bugs)
  • the team may be unwilling to talk about their problems
  • the retrospective meeting might get side-tracked into addressing low priority issues
  • … and so on

Some of these issues can be addressed by ensuring good communication between the team and the business.  Some of these issues can be addressed by being careful with the retrospective meeting and its format.  The retrospective meeting can be structured in such a way that it encourages the team to discover, explore and address their big issues.

What’s the format for a retrospective meeting?

There is no single format retrospective meeting, and there is no retrospective format which is best.  Retrospectives can take many forms.  In fact, the format of retrospectives should be changed from time to time, as this encourages people to think about their situation in new ways.  A great resource for ideas about different formats is Agile Retrospectives, by Esther Derby and Diana Larsen.  There are many other resources available on the web too.

What would you suggest as a starting point?

Here is a retrospective which I often use for teams that are new to retrospectives.  Please do not use this without thinking about it and deciding how it will fit your team.

1. Introduction

Some sort of icebreaker activity.  For instance, everyone gives one word that for them sums up the sprint. It can be accompanied by explanation or not. Questions are not allowed at this point, since people should be thinking rather than talking.

2. Review previous actions

Look at the actions from the last retrospective.  Decide which were completed, perhaps discuss how effective they were and decide which, if any, the team should carry on with.

3. Gathering data

Everyone writes post-it notes to fall into 2 categories - "What went well" and "What went not so well". The team gets 10-15 min to write the notes and then individuals take it in turns to stick them up onto a whiteboard. As they stick up a note they should introduce it to the team "I wrote xxx because I felt that ...". Some questioning is allowed here, but the point is really just to gather information.  The use of post-it notes is a great equalizer and prevents dominant characters from dictating the course of the meeting.

4. Extracting insight

The facilitator then looks to group up the post-it notes into topics / themes. For instance, there may be a number that relate to daily standup meetings. Put these in a clump.

5. Decide on actions

The team now decide on actions to address the items that didn't work well. Start with the biggest clumps of post-its, since those are the issues that are causing the most pain. Generally it's not worth trying tackle all issues. When you have 4-8 actions then call time. There should be lots of discussion and brainstorming during this part of the retrospective. All actions should be specific and should have an owner who is prepared to take responsibility to see it implemented during the next sprint. If nobody volunteers to own an action, then throw it away because clearly nobody wants to see it implemented.

Actions which cannot be implemented by the team are not allowed, e.g. “business users must stop changing their mind”.  Actions which are vague (e.g. “improve communication”) need to be explored more and made specific.

October 21 2011

Downloading the session recordings from BUILD Windows 2011

I’ve updated the previous session downloader, originally published by Naeem and Marcin, to download the sessions from BUILD Windows 2011.  It will give you the option to download only the sessions that have video published, so you’ll need to keep checking it over the next few days as sessions get published.

Build session downloader

The app will run up to two concurrent downloads, and will queue up further requests.  So you can tell it the list of videos you want, and leave it to do it’s thing.  Downloads can be cancelled.

Note that it’s the High Quality WMV that will get downloaded.

You can get the source code at from Bitbucket, or you can download some pre-compiled binaries (.Net 3.5 required) or you can now get it using clickonce here.  Please let me know if you have any trouble with it.

UPDATE: Forgot to mention, as with the previous downloader this app supports resuming of partially completed download.

September 16 2011

How to set up a Windows 8 virtual machine

There are a number of options for getting your hands dirty with the new Windows 8.  Naeem has a great setup script for dual-booting, but I decided to try setting up a virtual machine.  I have a number of choices for the hypervisor:

To set up the VM in Virtual Box, click the New button from the toolbar.  In the wizard, choose a name for your VM and then choose WinXP x64 as the OS:

win8 pt1

On the next screen, make sure you give the VM more RAM than the miserable default of 192MB:

win8 pt2

Then you need to setup the details for a new virtual hard disk:

win8 pt3

The rest of the screens in wizard are pretty straightforward.  Once you have your VM setup, you need to connect it to the downloaded Windows 8 ISO.  You do this by opening the settings screen for the VM and clicking the CD icon (took me a while to work this step out):

win8 pt4

Then on the popup menu, click “Choose a virtual CD/DVD file” and browse to the ISO image for the Windows 8 developer preview.

win8 pt5

Now you are good to go!  Start your virtual machine and it will launch you straight into the Windows 8 installation process.  Hurray!

But what’s it like to use Windows 8 on a VM?

To be honest, it’s not the best experience out there.  Simple things like moving the mouse around are noticeably laggy … it’s unlikely to be my laptop since I’m on a Core i7 machine with 8GB RAM. Also, Windows 8 does not seem to get correctly informed of the screen resolution.  This results in the reserved 1 pixel strip being impossible to hit.  Boo!

These performances issues do not occur if you boot the OS on the machine directly, so I’m pretty sure it’s a consequence of the virtualisation.

Having said this, it’s better than nothing.  If dual boot or a dedicated machine are not options for you, then a VM will allow you to have a sandpit for playing with some of the new tech from Microsoft.  Enjoy!

September 16 2011

Scrum basics: The daily standup meeting

Easy to start, difficult to masterSometimes referred to as a “daily sprint meeting”, this is a short meeting that happens once a day.  At this meeting, each member of the team should answer three questions:

  1. What did they do yesterday?
  2. What do they plan to do today?
  3. What issues are blocking or slowing down progress on their tasks?

The purpose of the meeting is for the team to co-ordinate their activities, to avoid duplication of effort and to ensure that their output is not in conflict.  The meeting should typically last 15 minutes or less when everyone is in the same room.  Somehow when people attend by phone or Skype then the standup meeting normally takes 20-30 minutes.

When the daily standup is working well for the team, it will often spark off a number of side conversations.  These are typically relevant to just a few members of the team.  Best practice is for these discussions to take place immediately after standup.  So in general, team members should leave the daily standup with a list of people to talk to about specific matters.

IMO the daily standup meeting is the best indicator of how well the team works together. In a high-functioning team the members collaborate actively and are concerned with both how their works impacts others as well as how the works of others impacts their own work. This means that the members of a high-functioning team are (a)actively trying to give useful updates; and (b) are actively listening to assess the impact of other people’s updates.

When to hold the meeting

Ideally the meeting should be held at the start of the day.  This provides team members with a good way to plan their day and formulate their list of activities.

However, there are sometimes a number of circumstances that mean this is not possible.  For instance, a team may be distributed over a number of timezones.  In this case, it is more important to pick a time that allows everyone to attend.

People who miss the meeting

A great habit to establish on the team is to ask people to send an email to everyone if they can’t attend in person.  This highlights to the team that the important aspect of the standup meeting is actually about communication.

Things that can go wrong

There are lots and lots of ways in which the daily standup meeting can wrong.  Here are some of the ones that we at #Fellows have seen:

  • Standup meetings can last too long – we’ve heard times of an hour!  This is often caused by people holding topic-related discussions during the meeting and not afterwards.  This can be addressed by having a team agreement that allows discussions to be parked until after the meeting.  Over-long standup meetings can also be a sign that the team is too big.
  • Some individual can give overly long updates – some people are not naturally concise and it can sometimes appear that they just like to talk.  This situation is best dealt with by taking the people aside and having a one-to-one chat with them, and explaining the difficulties that they are causing for the team.
  • Standup meetings can be too short – although those suffering from over-long standup meetings may find this incredible to believe, an overly short meeting is not good either.  This indicates that team members are too focussed on getting out of the meeting and don’t give enough detail in their updates.
  • Updates of planned activity can be vague – the standup meeting actually requires that team members have a reasonable idea of what they will do over the course of the day.  Some people resist this level of forward planning and instead say “… and then I’ll pick up the next task”.  This is not acceptable for an update and it needs to be clear to people why not.
  • Updates of completed activity can be vague – if team members are unable to understand someone’s update then it’s a signal that there may be different ideas about the actual work being done.  This should be resolved by dicussion outside of the standup meeting.
  • Updates cannot be reconciled to the sprint backlog – this means that the tasks on the sprint backlog no longer bear much resemblance to reality.  They team members should scrap them and draft some new tasks that more accurately describe the actual work.
  • People talk about activity rather than achievements – if team members are regularly saying “yesterday I worked on X and I will continue with it today” then it’s a signal that the planned tasks are too big.  If tasks are sized so that they are achievable within a day, then every team member should be able to give an update of a completed task every day.
  • People switch off when they are not talking – if team members are not actively listening to other people’s updates then it shows that they regard the updates as unimportant.  Most people feel this way until they get burned once or twice by not being aware of current activity.
  • Managers and other stakeholders hijack the meeting – while stakeholders are welcome to listen in to the standup meeting, the meeting is held by the team and for the team.  Only those contributing to the sprint goals should be taking up airtime.

Distributed teams

When a team is split over multiple physical locations, then there are a couple of options available:

  1. Everyone connects to a conference call / Skype call and gives updates
  2. The team can be divided into sub-teams which have their own standup meeting

This second option is really only feasible if there are a couple of locations with a substantial number of people.  It will not work if there are a larger number of locations with just one or two people at each.  To handle standup meetings with sub-teams, use the Scrum of Scrums approach outlined below.

Scrum of Scrums

There can be a couple of factors that push the project team to split into sub-teams.  Geographical dispersion may be one (as discussed above), and sheer numbers of people may be another.  Standup meetings quickly become ineffective when there are more than about 12 people involved.

Each sub-team should hold their own standup meeting, as described above.  Following on from that, one representative from each sub-team meets together for a scrum of scrums.  The format is similar to the standup meeting, except that the people are speaking on behalf of their sub-team rather than on their own behalf.

The scrum of scrums should be open to anyone who wishes to attend, but their needs to be a single designated member of each sub-team who will be talking.

Often it’s useful for the sub-team representative to report back (informally) to the other members.  This allows them to highlight the activities of the other sub-teams and deliver solutions to blocking issues that have been raised.

September 12 2011
Newer Posts Older Posts