Archive for the ‘Agile’ category

Incremental Release Planning

November 25, 2012

Release planning for a Scrum project can be a tricky proposition. The project’s stakeholders justifiably want some early predictability as to when individual releases are likely to be delivered. I frequently see teams attempt to accommodate this by tackling their project’s release planning in one big up-front meeting. Having one release planning session for a whole project’s deliverables can leave the team feeling that they have offered up no more than a very rough guess based on scant effort and consideration. The result can be a release plan that the team do not believe in.

For the last six months I have taken a different approach. Rather than having one big release planning session I have spread the exercise over several short sessions using a visual technique. I did not come up with the technique. A team member briefly described it to me in passing after attending a Scrum course with Martine Devos. I have added my own refinements over time to evolve those initial rough details into an effective working practise, the details of which I present in this post. In lieu of a better title I will refer to the technique as Incremental Release Planning (IRP).

The idea of IRP is to have several sessions, each of which plans out one release. This allows the team to concentrate on estimating one batch of (probably) related requirements at a time. The individual IRP sessions are short meaning that the overall time spent on release planning should be roughly the same as for a single monolithic meeting.

However, there is a gain in that the estimates should be of higher quality provided certain prerequisites are met. The good thing about these prerequisites is that the responsibility for fulfilling them falls, for the most part, with the Scrum Master and Product Owner and not with the team members. This leaves the team free to get on with the business of producing working software.

Crucially many IRP sessions can be held over a short space of time. In my experience planning 4-6 weeks of work can be planned comfortably every 2 weeks or so. Before long these sessions cumulatively provide a complete release plan made up by informed, considered estimates. Estimates the team believe in.


Listed below are the prerequisites I find are required for IRP to operate effectively:

1 – Quality Requirements. The requirements must be fleshed out. It is impossible to provide accurate estimates to one-line stories whatever technique you use for planning. The Scrum Master should work with the Product Owner and/or Business Analysts to get each Story’s requirements into a suitable state for planning.

2 – Stories Grouped into Releases. The project’s stories should already have been grouped roughly into releases and an implementation order for the releases should have been decided. It is the Product Owner’s responsibility to do this (with the Scrum Master’s support) as the exercise represents a form of prioritisation. Depending on the outcome of any particular IRP session stories can, of course, be moved between releases.

3 – The Team’s Velocity. It is difficult to have an up-front release planning session without an idea of the team’s velocity. The same is true of any individual IRP session. Before the first IRP session the team should ideally have carried out several iterations of work and the Scrum Master should have an idea of their velocity. As the IRP sessions proceed so will the sprints. This will lead to a more accurate idea of the team’s velocity over time.

4 – Team Review Time. The team should spent some up-front time reviewing the stories before each IRP session. The Scrum Master can organise this by sending out the list of stories to be planned prior to each IRP session (perhaps a week beforehand). This step is crucial if the session is to proceed quickly. As a process gate I ask immediately prior to an IRP session if everyone has reviewed the requirements. If any person has not then I terminate the session and request that they do so before we reconvene a short time later. Unsurprisingly I have only had to do this once at our first session.

5 – Availability of Product Owner. The team will inevitably have questions around the requirements. The Product Owner and/or Business Analyst must be available to answer these questions quickly for the session to proceed smoothly. The Product Owner must also be available to make decisions around prioritisation changes.

6 – Availability of the Scrum Master. The Scrum Master runs the IRP session moving the team through the steps, keeps the session flowing and, where necessary, stops the team and Product Owner from getting bogged down in the details.

The Steps

With all the prerequisites fulfilled the IRP session can start. For materials you will require a whiteboard and cards filled out to represent each story.

I have illustrated this post with pictures taken at during one of our typical IRP sessions which proposed 12 stories for a release.

Step 1

The first step if to divide the board horizontally into three sections: Small, Medium and Large. The core mechanic of IRP is in the relative sizing of stories. Note that at this stage of the session that there is no mention of story points or velocity. These concepts feature towards the end of the session.

Click to Enlarge

Step 2

Next request that the team place each of the cards into one of the Small, Medium or Large columns depending on their perceived relative size to each other. What the Scrum Master wants to encourage here, and throughout the session, is for the team to collaboratively decide where each card should be placed.

Click to Enlarge

Click to Enlarge

I tell the team to get stuck in at this point and make it clear that all team members have free access to the board. This tends to get the cards placed quickly and also provokes discussion between individual team members and between the team and the Product Owner. Do not move to the next step until some level of consensus is reached on the placement of the cards. However, make it clear that the placement is not final should any intractable disagreements take place.

Click to Enlarge

Click to Enlarge

Step 3

Next the board is divided again, this time vertically, into three more Small, Medium and Large sections. The idea is to further divide the initial three levels of granularity by another level providing nine slots in which to distinguish the relative size of the stories. The team should now redistribute the stories – this time over all nine slots.

Click to Enlarge

Click to Enlarge

This will no doubt result in yet more discussion and closer questioning of the requirements as the team attempts to distinguish between the stories in terms of effort, complexity and uncertainty. The Scrum Master should facilitate these discussions until, again, consensus on the placement of the cards is reached. Note that at this point it is perfectly valid for stories to move from any one slot to any other should the team change their mind on relative sizing as they compare stories and tease out requirements from the Product Owner.

Click to Enlarge

Click to Enlarge

With the refined placement of stories agreed, ask the team to verify it quickly comparing the stories in each size section with those that are immediately smaller and bigger. Cards may be moved again as they deem appropriate. Note that in this example we did not require all nine sections (here we used only eight) to get a granularity of relative story sizes that the team was comfortable with.

Step 4

It is at this stage that story points are introduced to the process. Each section on the board now contains a set of similarly sized stories with the smallest stories in the top-left section and the largest in the bottom-right section. The idea is to assign a story point value to each story section and therefore to each story.

Click to Enlarge

Click to Enlarge

We currently use the following story point values: 1/2, 1, 2, 3, 5 and 8. However, the technique is adaptable to any range. I start by asking if the stories in the smallest, top-left section are a 1/2 story point. If so I write 1/2 in that section and move on. If not I ask if they are 1 story point and so on. In this example the team chose 1/2. I then move to the stories in the largest bottom-right section and ask if they are 8 points. If they are I write 8 there, if not I ask if they are 5 point stories. In this example the team chose 5. I then turn to the second smallest section and ask if these stories are 1/2 pointers or 1 pointers (roughly the same size or roughly twice the size of the smallest stories). I then turn to the second largest section and so on.

This process continues, working towards the middle, until all of the story sections are assigned points. I then ask the team to cast their eye over the proposed story point estimates to verify whether or not they are happy with them. If they are then the Product Owner and team can be dismissed for a while. If they are not we can move individual cards until the team is satisfied.

Step 5

The Scrum Master can now total all of the individual story point estimates to get a figure for the entire release. For this example we have:

1 story x 1/2 SP= 1/2 SP

3 stories x 1 SP = 3 SP

1 story x 2 SP = 2 SP

4 stories x 3 SP = 12 SP

3 stories x 5 SP = 15 SP

Total: 32.5 SP

Combined with the team’s sprint velocity of, in this case, 14 story points, we get the following calculation for the sprint duration required to complete the release’s work:

32.5SP / 14 = 2.32 sprints

Our sprints are two weeks long which gives us a release work duration of 4.64 weeks. I tend to round up to the nearest week which gives us an estimate of five weeks for this release.

Step 6

Armed with an estimate the final step is to validate it with the team. The team’s buy-in to the estimate is crucial. To get this buy-in the Scrum Master reconvenes the team (but not the Product Owner) and informs them of the estimate in weeks. As transparency is important the Scrum Master should also detail the process by which the figure was calculated. The Scrum Master then asks the team if they think that the estimate is reasonable, i.e. do they think they can complete all of the release’s work in that time?

I do this using the fist of five. If anyone votes with a one or two then some discussion can take place as to why they are uncomfortable with the estimate. If the responses comprise threes, fours and fives then the IRP is over and the estimate can be provided to the Product Owner and be incorporated into the full release plan. Should the date prove to be disagreeable to the Product Owner then they can move some work between releases and see the impact that this has on the forecast date. With all the of the figures available this kind of what-if analysis is straight forward. Note that any such changes should be verified with the team to ensure no dependency issues are introduced by reordering stories.

Sprint Planning and Actuals

Note that the IRP estimates do not in any way negate the requirement for sprint planning. This still needs to happen at the beginning of each sprint and I do not make IRP estimates available at this time. All stories must be re-estimated as a lot may have changed between the IRP and the sprint when the work is to be done. However, the IRP assists with sprint planning as the team have seen all of the stories before and have discussed them together. I do, however, compare IRP time estimates with the actual time taken to complete releases as it is interesting to see how accurate IRP is against actuals. The reason I believe so firmly in this technique is that, so far, estimates have been fairly close to actuals (plus or minus 1 week for 4-6 week releases).

Summing Up

IRP is a technique that has worked well in our team. While we cannot provide one big release plan in a single hit we have been able to provide regular release plan updates from early on in the project which prove to be reasonably accurate. Repeated IRP sessions have quickly led to a complete release plan early in the project’s life. I have found these sessions can be run very quickly with 4-6 weeks worth of work being planned in just 30-40 minutes

The IRP technique does require some preparation from all parties. However, the preparation effort in terms of requirements definition and team review pays dividends later when the stories are actually implemented as nothing about the work is a surprise to the team.

Reflections on Lean Agile Scotland 2012

September 23, 2012

The Lean Agile Scotland 2012 (lascot12) conference has just ended. In this post I will be setting down my thoughts about the event while they are still fresh in my mind. Lascot12 is only the second Agile conference I have attended. The first was the London Scrum Gathering almost a year ago (I wrote about my experience of that event in this post). That being the case I will make some general comparisons between the two events in this post.

First up a big thank you to Chris McDermott for organising the event. Something like this was needed in Scotland and he made it happen.

Click to enlarge

Some general stuff next. The venue was an inspired choice: Our Dynamic Earth. It is an interesting building nestled beside Salisbury Crags which is an awesome setting. The conference facilities were top notch with good facilities, catering and the like. The overall organisation was superb and Chris’ team of helpers did a great job and kept everything flowing smoothly.

Next to the schedule. The conference was two days long. Each day started with an hour long key note. Thereafter two tracks ran throughout each day each with seven 45 minute speaker sessions interspersed with breaks and lunch.

Here is my first comparison with the London Scrum gathering. The gathering was a lot bigger. It had a whopping seven tracks over two days followed by a day of open space which had at least as many parallel sessions. This gave attendees a huge amount of choice. However, I found that this had its draw backs. It was tricky to pick the sessions I wanted to go to and, in hindsight, I discovered by comparing notes with other attendees that I inadvertently missed some very good sessions. At lascot12 I only had to choose between two different sessions in each slot. This made it much easier to decide what I wanted to go to. Even better is that all sessions at lascot12 have been videoed and will be made available online soon. For example, I missed the “Chaplin’s Craft” session but am looking forward to catching it on the web later.

Click to enlarge

Having less choice is only truly an advantage if the sessions that are on offer are top notch and have variety. I am happy to report that the overall quality of the sessions was rather high. Likewise the topics covered a wide range of subject matter including coding techniques, team building, testing and war stories. I liked the fact that this was an Agile conference and not just a Scrum conference or a Kanban conference.

One thing about the sessions in general that differed from many of the Scrum Gathering sessions was that they were not as hands on. In many of the Gathering sessions I got to try stuff out and they were generally more interactive. In London I recall trying out new techniques in groups, roleplaying difficult conversations and, in one memorable session, we were taught team building via the PC game Left 4 Dead. The lascot12 sessions were, in the main, a little more passive although we could ask the presenters any questions we liked (time permitting).

So what sessions did I attend? My mission at the conference was to find out more about what makes a successful team. This guided my choice of sessions towards those that were team and people centric as opposed to those focussing on technology or process. Of the sessions I attended the following are those that I believe have informed my ongoing quest the most:

Individually Smart, Collectively Stupid – David J Anderson

This was the day 1 key note. Do people sometimes behave in one manner individually and in another contrary manner when acting as a collective? That was the point of this session and I would have to agree that it does happen. With examples ranging from Olympic cycling to the “Rangers Situation” (kudos to David for bringing that up at a conference taking place in the central belt!) this was a humorous and thought-provoking key note. It has led me to challenge one long held belief on my own project regarding release size.

Leadership on all Levels. Why? And How? – Florian Eisenberg

If nothing else this session won the award for the best slides. Minimalist circles and lines can sometimes convey so much more than a flashy slide set. The slides weren’t all the session had to offer, however. Florian delivered a presentation detailing how we can foster an environment where leaders naturally emerge. I took a number of lessons from this session.

People Patterns – Joe O’Brien

The more I ply my trade as a Scrum Master the more I find I have to really understand the people I interact with. This session was packed full of tips to aid us in understanding our fellow humans and how to engage with them productively. And Joe was hilarious while at the same time educating us. My main lesson from this one: I shouldn’t listen to the voices in my head.

Respect for People – Liz Keogh

This day 2 key note was a tricky session for me. There were so many things that Liz said that really resonated with me and yet there were a fair few lessons I did not agree with (see below when I talk about Scrum and Estimation). This session was all about the things we do that can be respectful or disrespectful to people. Disrespect can be so damaging within a team that we should do our best to avoid being responsible for causing it. However, causing disrespect is such a minefield that the best tip was that we should forgiving of those that we feel have disrespected us. This session is proof that you do not have to buy into a whole session to be able to garner useful information from it.

People: Your Most Agile Ingredient – John Peebles

John’s session concerned great teams. I believe a great team is one that delivers for their customer while at the same time having fun and enjoying their work. Have I ever worked on a great team? Sometimes the teams I have been a part of have been like that for periods of time but never consistently. John made it clear that it is possible to build a great team and imparted some of the practises he uses to bring teams on. It gives some of the rest of us hope.

I mentioned above that this wasn’t a Scrum or Kanban or “anything really specific” conference for me. If anything Scrum got a bit of a kicking in some of the sessions. Estimation, on the other hand, got a harder time again. If Scrum got a metaphorical beating then estimation was led down an alley and shot in the back of the head by some of the speakers. Now that is cool with me. I don’t believe in having sacred cows in our industry and we need to constantly challenge our beliefs as to what is the right thing to do.

No, the only thing that bothered me was the exaggeration of how bad Scrum and estimation were in the field with the intimation that it was that way for everyone. Rhetorical questions like “who wants to spend two hours in estimation every sprint?” and “who wants to spend a day release planning every 3 months?”. Well nobody wants to and from personal experience I know not everyone does (15-30 mins for sprint planning and 30-40 minutes for release planning is typical for our team – preparation is everything).

I do currently practice Scrum and our team does do estimation on the release and sprint levels. I do believe that both can work. I do believe that they are useful. I also think that it, like anything else, they can be misused horribly. It is my job to ensure that this does not happen.

Click to enlarge

The final thing I would say on the subject is that my disagreements have a massive caveat. There were many things I disagreed with at the Scrum Gathering last year and now I’m doing a lot of them (Full Time Scrum Masters? Pah! Oh wait, now I am one…). I won’t rule anything out this time. I not so naive that I do not believe that there are always better ways of doing things. This is why I went to the conference in the first place: to find out about the better ways, to be persuaded.

In closing I believe that lascot12 was a great success. I really want there to be an lascot13. If there is then I will definetely be there.

Lean Coffee Glasgow

September 16, 2012

A few weeks ago an Agile minded colleague told me about a relatively new discussion forum that was running locally in Glasgow. They explained that like-minded Agile proponents were getting together regularly to exchange ideas. What was most interesting was that they were running their gatherings according to the rules of something I had never heard of before:  Lean Coffee. Intrigued I decided to go along to the next session.

In preparation I did some reading and found that Lean Coffee is a relatively new phenomenon which is, nonetheless, quite popular with Agile folks around the world. The format is designed to democratise meetings by preventing any one person from setting or controlling the agenda. The suggested venue is a coffee shop. However, this is Glasgow so the organisers here decided on a different setting: a pub. Great thought I – I get to learn about a new way of running meetings, have interesting discussions on Agile topics and I get to drink beer at the same time.

The next meeting was scheduled for a Wednesday evening at 7pm in a local hostelry called The Crystal Palace. Six people attended (a good number for this type of session as it turned out) and we were a varied bunch. Two, including myself, were new to the Lean Coffee concept and one of us was completely new to Agile. One of the old hands took the time to explain how the session would run to the newbies:

  1. Everyone takes a few minutes to write up one or more stickies with topics they would like the group to discuss.

    Click to enlarge

  2. Go through the stickies one by one with the author briefly explaining their question or topic.
  3. Everyone dot votes on the topics they most want to discuss. Each attendee gets three votes to spend – they can put multiple votes on any one topic and can vote for their own topics if they so wish.
  4. A Personal Kanban is created with three columns: To Do, Doing, Done. Stickies are used to create the headings (see picture).
  5. All topics are placed under the To Do column in priority order according to the number of votes they have received.
  6. The top topic is moved from To Do to Doing.
  7. A 15 minute discussion ensues around the topic. A smart phone is handy to do the timing. If discussion around the topic dries up before 15 minutes then progression to the next step comes early.
  8. The topic is moved to the Done column and the next To Do topic is moved to Doing.
  9. Repeat until the session time (two hours appears to be typical) or topics are exhausted.

The session ran as described and I found I rather liked the format. For a start it is a simple concept. This simplicity meant that the technique was easy to explain and quick to run with most of the time being spent in discussion rather than process.

Secondly the approach has an advantage over traditional meetings where the agenda is typically set by one person. Here all of the attendees decide on the agenda by suggesting topics and by voting for what they want to spend their time discussing. This give the attendees ownership over the agenda and ensures that everyone gets something relevant to them out of the session.

Importantly the attendees collectively  ensured that the session was a safe space where opinions were respected. There were no stupid questions and nobody lambasted anybody for what they had to say. There were disagreements to be sure but these were discussed in a grown-up manner rather than becoming heated arguments or slanging matches. Best of all there was no moderator to make this happen. The attendees moderated themselves.

The range of topics discussed over the course of the evening was varied. For example, there was an interesting conversation around the relative benefits of Stories and Use Cases, discussion around which sessions we were most looking forward to at the upcoming Lean Agile Scotland Conference, an explanation of what Kanban is for those of us who were new to it and discourse around what we were all reading.

I had an enjoyable evening and learned a lot over the course of the session. For example, I picked up two specific techniques which I have since applied to my own team. For the trivial expenditure of two hours and a few pints this was a bargain and I will certainly be attending future sessions. Although I will be referring to the sessions as Lean Lager from now on given the likely venue.

If you are in the area and have an interest in Agile then I would recommend that you come along. Lean Coffee/Lager is a friendly forum for exchanging ideas and networking and is open to all. For details of the next session see the Lean Agile Glasgow Meetup Page.

DIY Sprint Retrospective Techniques

August 12, 2012

A few month’s ago I wrote about several Sprint Retrospective Techniques that I have found to be particularly effective. I noted that having several techniques in my arsenal allowed me to keep retrospective sessions fresh for my team. This has helped to ensure that we have a steady flow of corrective actions to aid us in our quest for continuous improvement. Since writing that post I have been rooting around on the web looking for other techniques to add to my tool kit.

One useful source for retrospective techniques I have found is the Agile Retrospective Resource Wiki. It lists more than a dozen retrospective techniques in varying levels of detail. While I have made use of several of the techniques listed in the wiki I have found that none of the remaining techniques fit with my team’s current requirements. Some strike me as being overly complex (simplicity is a major factor when it comes to an effective technique) while others are designed for a specific type of issue that we do not need to explore at this time. Rather than give up and stick with the same set of retrospective techniques I thought I would have a go at creating one of my own. This post describes my experience creating my first DIY Sprint Retrospective Technique.

I reckoned that creating a workable general purpose technique would be beyond me on my first attempt. By general purpose I mean that you can apply them to identify any kind of issue. Good examples of general purpose techniques are my favorite three techniques: The Wheel, The Sail Boat and Mad Sad Glad . However, special purpose techniques which aim to address a specific type of issue have their place. So I settled on creating a special purpose technique to address a particular problem my team was having.

The issue in question was boredom. My background as a software developer leads me to take this issue seriously because I know from experience that developers are usually creative individuals. They like to solve interesting problems and stretch their minds. While not every task can be interesting an overload of dull activities can demotivate a team of developers. Demotivation will slowly kill a team’s velocity and has to be addressed. Additionally boring tasks can be an indication of repetition and unnecessary work. Eliminating repetition through automation can improve  a team’s velocity.

I observed signs of boredom creeping in during the stand ups as expressed by the team in their use of language and in the tone they used when describing their progress. I decided to nip this in the bud by exploring the issue in the next retrospective using a new custom retrospective technique.

Click to Enlarge

For the new technique I drew inspiration from an unlikely source: a Dilbert book I owned more than a decade ago. It was a type of employee survival handbook written in the Dilbert style. I recalled that it contained a four square grid diagram that was used to describe different types of manager. I have recreated this from memory here but probably do not have the labels quite right.

Despite the obvious comedy around this example (you really don’t want your own boss to be in the smart/evil quadrant) the basic idea of the four square grid looked suitable for my needs. I modified it to my requirements and ran the retrospective as follows.

Step 1: First of all I drew a square on a white board and divided it horizontally into two halves. One half was labelled “Interesting” while the other was labelled “Dull”.

Click to Enlarge

Click to Enlarge

Step 2: I asked the team to think about the things they had done over the sprint and write out a sticky for each. For each task they were to decide whether or not they had found the work to be dull or interesting and place the sticky in the appropriate half.

Click to Enlarge

Click to Enlarge

Step 3: Once all of the tasks had been placed on the board I then asked the team to write the rough amount of time each task took on their own stickies. These values could be expressed in terms of hours or days and did not need to be exact. I then divided the square vertically into two further halves which I labelled Short and Long.  With this second split in place I asked the team to split the tasks into one time category or the other depending on how they had taken relative to each other. Tasks that took hours moved to the Short quadrants while those that took days migrated to the Long quadrants.

Click to Enlarge

Click to Enlarge

Step 4: We now had four quadrants representing the following groupings of tasks: short interesting tasks, long interesting tasks, short dull tasks and long dull tasks. Of most interest from these is the long dull tasks. These represented the types of work which generated the most boredom for the team and perhaps the best opportunity for automation. We discussed each of the long and dull task stickies in turn and identified actions to shorten or eliminate them. While the main corrective actions fell out of this quadrant of the grid we also found it fruitful to have a discussion about the shorter dull tasks and the remaining work which was considered to be more interesting.

Click to Enlarge

Click to Enlarge

All in all I think that the session went rather well. We identified several corrective actions for the longest boring tasks. When implemented these actions have the potential to make work more interesting for the team and eliminate waste effort in the project.

I could have run the session far more simply. I could instead have asked the team to share which tasks they had found to be large and dull. I could still have used the grid for this by drawing it in its finished form upfront and asking the team to place tasks in the dull and long quadrant.  However, I do not think that we would have benefited as much from this shortened approach. This is because it would have been much harder for team members to answer one big question with several dimensions than to follow the process outlined above. The technique answered the same big question by asking a series of simpler questions. The long running dull tasks simply emerge by following the steps.

Focussing on one question at a time is the key to why this technique works:

  1. Of the tasks you did which were dull and which were interesting?
  2. How long did each task take?
  3. Which tasks took the shortest and longest time?

From these simple questions and the division of the grid the issues are automatically identified ready to be addressed.

With the success of the technique in identifying long-running dull tasks I gave some consideration to generalising the technique to identify other types of issues. It turns out that this be can achieved easily with only two variables: the subject written on the stickies and the labels used on the grid.

The type of subject used on the grid can be anything. For the above example it was tasks from the last sprint. It could just as easily be bugs, stories or support issues or anything else that the team routinely does in a sprint.

The grid labels can also change.  The above example uses interesting vs dull and short vs long. Some other examples are:

  • Shorter v Longer (than estimated velocity)
  • Missing v Complete (story requirements)
  • Collaborative v Non-Collaborative (task execution)
  • Simpler v More Complex (than planned)
  • Planned v Unplanned (stories in sprint)
  • Finished v Unfinished (stories in sprint)

Knowing what goes on the stickies and what labels to use on the grid is a matter of knowing what impediments a team is suffering from. This is a core skill for any effective Scrum Master.

Click to Enlarge

Here is another concrete example I intend to use for my team’s next retrospective. For this retrospective I want to identify where missing story requirements are hurting our velocity. I will run the same technique as before with a couple of modifications. The changes will be to have the team post up user stories they completed in the last sprint and to use shorter v longer (than estimate) for the x-axis and missing v complete (requirements) for the y-axis. Any stories that wind up in the bottom-right grid (longer than estimated stories with missing requirements) may be instances where missing requirements are impeding us to a large degree. Corrective actions identified here may help us eliminate the issue in future.

Despite my coming up with this technique independently I doubt it is entirely original. However, I feel I have to give it a name anyway. The name I have chosen is Quartering. I think this is quite descriptive as that is exactly how the technique operates. The team’s activities in the last sprint are split into four quarters to reveal which may have been executed less than optimally.

The main lesson I have learned from this whole exercise is that I do not need to rely on others to come up with useful, general-purpose retrospective techniques. Anyone can do it themselves with a little imagination and a minimal amount of effort. There is no excuse not to continually change retrospective approaches when you can invent your own. This is especially true if people publish their own working ideas as is the case with the Agile Retrospective Resource Wiki.

On that note, if you think that Quartering may be of some use within your own retrospectives then please feel free to use it. I would be interested to hear about your experiences with it and any of your own DIY Sprint Retrospective Techniques.

Should a Scrum Master be Part Time or Full Time? – Revisited

June 16, 2012

Six months ago I wrote a post entitled Should a Scrum Master be Part Time or Full Time?. In that post I came to the following conclusion:

“Ideally I think that the Scrum Master should spend most of their time being a Scrum Master. However, my own experience shows me that I am a more efficient Scrum Master if I do the same work as the team so that I share the same experiences as them. This doesn’t need to be a large amount of development work and may even take the form of the Scrum Master pairing with team members. Unfortunately I cannot dedicate as much time as I would like to being a Scrum Master where I work now. Hopefully I will have the opportunity in the future.”

It is my belief that Scrum Masters can only improve if they constantly challenge their beliefs. If a Scrum Master thinks they have the perfect set up and there is no room for improvement then they are dead in the water. Continuous improvement does not just apply to the team or its processes it applies to the Scrum Master too. Six months is a long time and my opinion on the full/part time debate has shifted in that time.

As I stated in the previous post there are two reasons that Scrum Masters are part-time in my organisation. The first was that  resource constraints meant that  having dedicated Scum Masters was not practical. Therefore Scrum Masters were also expected to do development work. Secondly nobody within the organisation (including the Scrum Master themselves) considered that a Scrum Master’s responsibilities were substantial enough to merit a full time job.

At the time I felt that the first reason was set in stone but disagreed with the second. I believed that there were more than enough tasks to occupy a full time Scrum Master if they were to take their team to their full potential. Besides simply running all the Scrum ceremonies and producing the required artifacts there were many useful tasks I could engage in. For example, really going to town identifying and mitigating impediments, pro-actively shielding the team, grooming the backlog, etc.

Subsequent to writing the post I started to question whether or not my organisation really cared if I was part time or full time. After all, surely what they really cared about was that the team was productive. If the team was more productive overall with me as a full time Scrum Master than as a part time developer then who was to argue?

So I bit the bullet and started spending more of my time being a Scrum Master and less as a developer. As expected I never ran out of useful things to do which aided the team’s productivity and started to see a improvement in our velocity despite my contributing less to stories directly. I ran this as an experiment and did not ask for permission. Unsurprisingly management cared more about results than how the team worked internally. There was an interesting side-effect too – my job became less conflicted.

To explain this I will dip a little into the balance of a Scrum team. There are three components to a Scrum team: the Product Owner, the team and the Scrum Master. The Product Owner and team usually have two underlying but conflicting concerns. As the customer the Product Owner is interested in getting as much value as possible and this materializes as getting as many stories completed as possible. The team, on the other hand, is driven by quality. They want to get stuff done sure, but they want it done right. However, quality takes time to bake in. The Scrum Master is supposed to be in the middle balancing the two concerns producing the best possible compromise.

So what happens when the Scrum Master is also a team member? They are conflicted between being a team member and being the balance between the team and the Product Owner. The more I removed myself from development the less of this conflict I felt and the more free I found myself to impose balance without being biased towards the team. I believe that this led me to perform better as a Scrum Master.

Another thing that got easier that was sprint planning. As I have removed myself from development I have also stopped taking part in estimation. Previously I had to constantly context switch between playing planning poker and running the game. This was frankly exhausting and broke up the flow of the session for everyone. This is no longer an issue and the estimates have not suffered for having one less participant.

So far so good. However, in my earlier post I also stated that having a deep understanding of the team’s activities through carrying out ongoing development work made me a better Scrum Master. I still think having a development background can help a Scrum Master deal effectively with a team but I no longer believe that it is not the be all and end all. I have definitely let go of the idea that I have to be hands on getting the stories done. It is simply not as important as being the effective, unbiased glue that holds the team and Product Owner together. Nor does it trump concentrating on actually running the Scrum ceremonies as opposed to also trying to be a team member in them.

Unfortunately I have not fully extracted myself from my development role but I am working on it and am happier and more effective for it. More importantly the team is more productive as a result.

Planning Poker: Cards Versus Smartphone Apps

June 2, 2012

My team have been using Planning Poker in our sprint planning for quite a while now. I like Planning Poker because it is quick and it works. I have a couple of card decks I’ve picked up on training and at conferences and even made my own. Recently I decided to run an experiment within the team to utilise smart phone apps rather than cards for our next planning session. I reasoned that perhaps the team, being software developers, may prefer to utilise apps on their flashy phones rather than use boring old cards.

On the face of it the modern smart phone seems ideally suited to Planning Poker. Most people I know have one, they have large bright screens which are usually approximately the same size as a Planning Poker card and, I reasoned, somebody must have written a Planning Poker app for them (and it would probably be free). Quick trips to the Google Play and iTunes stores confirmed that not only had a Planning Poker app been written but that dozens of different apps were available.

Prior to planning I requested that the team go and find a Planning Poker app for their phone for use in the upcoming session. The choice of app was entirely up to them. In the team we have four Android wielding members and one iPhone owner. Here is a list of what app each team member decided to use:

Proof of the sheer number of Planning Poker apps available is that everyone picked something different. Choice is certainly not an issue here. My own selection was the simply named “Planning Poker” by Unboxed Consulting. It appealed to me because it was very simple to use and I could customise the set of available card values easily (we use a restricted fibonacci sequence including the values 1/2, 1, 2, 3, 5 and 8).

All of the apps operate in the same fashion. The user starts the app and a screen appears with a grid of all possible card values, they select one and a representation of a card with the chosen value appears. They can then dismiss the card and return to the grid in preparation for the next round. The advantage of using the apps rather than a deck of cards appeared to me to be slight. However, I wondered if the novelty value and convenience factor of the apps would allow them to usurp the cards. It would be up to the team to decide.

The session went as quickly as usual with no technical malfunctions. Once my phone did not register my making a selection and I initially showed the selection grid as my estimate. That wouldn’t happen with a real card deck but, then again, I was in too much of a hurry. All of the app’s representations of card values were legible although I did find the Bacon Planning Poker’s use of rashers of bacon to make up numbers to be a little bit too weird. Then again I’m not a big fan of bacon.

With the session done I wanted to know whether or not using the apps would be a permanent feature of our planning. I asked the team to dot vote. What was their preference: apps or cards?

The dots went up rapidly with not a hint of hesitation from anyone. The results were unanimous:

Click to enlarge

So cards are here to stay in my team. Smartphone apps are great for many things but are no match for real Planning Poker cards.

The Story Grid – A Simple Sprint Planning Technique

May 19, 2012

I have two main techniques I utilise when carrying out sprint planning. One is the effective and venerable Planning Poker. The other technique didn’t even have a name until today as I had to name it in order to write about it. However, it is just as integral as Planning Poker to the sprint planning sessions I run and has been a feature in them for more than a year. I have decided to call it The Story Grid but should point out that I didn’t come up with the actual idea. It was a suggested to me by Scrum Coach Martine Devos and, as far as I am aware, was a completely off the cuff idea from Martine intended to solve an issue our team was having with sprint planning.

The issue that we were having was that, in the heat of sprint planning, it was tricky to keep a track of when the team had reached their forecast capacity for the sprint. I, as ScrumMaster, could keep a running total of planned story points versus capacity but this was tedious to do and held in my head or on a piece of paper. The solution was to maintain a visual representation of the planned stories versus the total time available in the sprint which everyone could see: The Story Grid.


The idea is simple. First comes the preparation:

  1. Prior to Sprint Planning the Scrum Master forecasts the amount of story points that the team can be expected to complete in the upcoming sprint (I have a process which I use to do this which I cover in a later post).
  2. Next on a whiteboard the Scrum Master draws a grid with the number of squares being the same as the next sprint’s forecast velocity. Each of the squares represents one story point and should be drawn to be large enough to hold a sticky note. This is the Story Grid.
  3. The Scrum Master then obtains a list of proposed stories for the sprint from the Product Owner or plucks the first N prioritised stories from the Product Backlog.
  4. Finally for each proposed story a sticky note is created containing the story’s name. These notes should be placed next to the Story Grid listed in priority order.


During planning:

  1. The highest priority story is selected and estimated as normal. My team utilise Planning Poker for this.
  2. The Scrum Master writes the estimated story point value onto the sticky note.
  3. The Scrum Master then places the story’s sticky note onto the first square of the grid.
  4. If the story was estimated to be more than one Story Point then score out the following squares until a number of squares equalling the Story Point value of the story are blocked out.
  5. Repeat this exercise for each candidate story in priority order. Newly estimated stories are placed in the next available square. Carry on until the Story Grid’s squares are exhausted.

A Simple Example

Here is an example of the technique in action. In this fictional Sprint Planning session there are 12 story points forecast for the next sprint. In addition there are six prioritised stories labelled stories A-F. Valid story point values for estimation are 1, 2, 3 and 5.

Initially the 12 square Story Grid is empty:

story grid 1

Click to Enlarge

Story A is estimated to take 2 story points. It is placed in the first square and the second square is also scored out. Two story points have been consumed on the grid.

story grid 2

Click to Enlarge

Story B is then estimated to take 3 story points. The grid now looks as follows with five story points consumed.

story grid 3

Click to Enlarge

Next comes Story C which is estimated to take only one story point. This is placed in the next available square but no other squares are scored out.

story grid 4

Click to Enlarge

Story D is estimated to take five story points and consumes five squares accordingly.

story grid 5

Click to Enlarge

Finally Story E is estimated to take one story point and is placed on the grid to consume the final square.

story grid 6

Click to Enlarge

The team have now estimated enough work to fill the forecast velocity for the next sprint. There is no capacity for Story F. It simply won’t fit if Stories A-E are to be completed too.

That was a very simple and idealised example. Next I will discuss how the Story Grid operates with less neat examples.

Away From the Ideal

In real world Sprint Planning the first N stories will not necessarily fit neatly into the forecast team capacity. Even if they do there may be other lesser priority stories waiting in the wings that the Product owner is keen to see in the next sprint. This was the case in the example above with Story F. The idea is to plan until the squares or full. If any stories overflow the grid and/or any stories are still to be estimated which do not fit then the Product Owner has a choice.

The Product Owner  must still respect the team’s estimates. However, they can decide to pull items from the grid (and therefore the sprint)  in place of other stories. This is why noting story point values on the sticky notes is important – the final steps of the Sprint Planning session may involve moving stories in and out of the Story Grid to get the optimal fit that suits the Product Owner. There is nothing wrong with this provided the team agree that the chosen order is still technically feasible. The Story Grid is still serving a useful purpose here as it can be used to visualise the new sprint make up. Finally once the Product Owner is happy with the selection of stories and the team agree that the order is practical the stories can transferred to the Sprint Board.

The Advantages

The most attractive thing about the Story Grid technique is that there is a up-to-date visual representation of the planning session’s progress which is available to everyone as the session progresses. It is clear to the Scrum Master, team and, most importantly, the Product Owner how close the team is to capacity after each story’s estimation. I really like it as a Scrum Master because I no longer have to separately maintain and communicate how close the team is to capacity. The Story Grid has become an integral part of the process. This allows me to focus my mind on everything else that is going on in the session and therefore speeds planning. Finally it is simple so everyone tends to get the idea quickly.

Click to Enlarge

One final practical point when it comes to Story Grids. You will very quickly become tired of drawing them. For this I offer up a practical tip which I received from the ScrumMaster of my first Scrum team six years ago: electrical tape can be very useful as a Scrum Master. You never need to redraw and it can’t accidentally get onto your hands when placing notes like you can with whiteboard ink. As you can see from this picture of my team’s last  Sprint Planning session I should really get around to buying more tape to fill in the verticals.

Sprint Retrospective Techniques

April 1, 2012

Note: since writing this post I have come up with a new sprint retrospective technique called Quartering.

Note 2: you can find even more simple and effective sprint retrospective techniques in my follow up posts Sprint Retrospective Techniques 2 & Sprint Retropective Techniques 3.

When interviewing prospective Scrum Masters there are a number of questions I ask them about their retrospectives. First of all I ask if they hold retrospectives with their team after each sprint. I then ask how they run their retrospectives. Finally I ask if they vary how they run their retrospectives. The answers to these questions are one gauge I use to measure the the candidate Scrum Master’s level of experience. I focus so much on retrospectives because how they are run is crucial if a Scrum team is to function efficiently.

Holding retrospectives is vital to Scrum teams who are looking to continuously improve (and a Scrum team that is not looking to continuously improve isn’t worthy of being called a Scrum team). Holding retrospectives after every sprint is a must if a team is to maintain its pace of improvement. Having a technique for running retrospectives is important for imposing a structure on the team’s discussion. However, having many varied techniques is essential to keep the exercise interesting for the team and to prevent great ideas for improvements from drying up. Retrospectives that become staid are little better than not holding them at all.

I have encountered several retrospective techniques over my time as a Scrum Master. Here are three simple techniques which I find work well.

(each technique requires the following resources: whiteboard, white board markers and stickies/post-it notes).

Technique 1 – The Wheel (also known as the Starfish)

  1. Draw a large circle on a whiteboard and divide it into five equal segments
  2. Label each segment ‘Start’, ‘Stop’, ‘Keep Doing’, ‘More Of’, ‘Less Of’
  3. For each segment pose the following questions to the team:
    • What can we start doing that will speed the team’s progress?
    • What can we stop doing that hinders the team’s progress?
    • What can we keep doing to do that is currently helping the team’s progress?
    • What is currently aiding the team’s progress and we can do more of?
    • What is currently impeding the team’s progress and we can do less of?
  4. Encourage the team to place stickies with ideas in each segment until everyone has posted all of their ideas
  5. Erase the wheel and have the team group similar ideas together. Note that the same idea may have been expressed in opposite segments but these should still be grouped together
  6. Discuss each grouping as a team including any corrective actions

The steps are illustrated in the images below:

Click to Enlarge

Click to Enlarge

Click to Enlarge

Click to Enlarge

Click to Enlarge

Click to Enlarge

Technique 2 – The Sail Boat (Or speed boat. Or any kind of boat)

  1. Draw a boat on a white board. Include the following details:
    • Sails or engines  – these represent the things that are pushing the team forward towards their goals
    • Anchors – these represent the things that are impeding the team from reaching their goals
  2. Explain the metaphors to the team and encourage them to place stickies with their ideas for each of them on appropriate area of the drawing
  3. Wait until everyone has posted all of their ideas
  4. Have the team group similar ideas together
  5. Discuss each grouping as a team including any corrective actions going forward

The pictures below show a couple of retrospective boats:


Click to Enlarge

Click to Enlarge

Click to Enlarge

Technique 3 – Mad Sad Glad

  1. Divide the board into three areas labelled:
    • Mad – frustrations, things that have annoyed the team and/or have wasted a lot of time
    • Sad – disappointments, things that have not worked out as well as was hoped
    • Glad – pleasures, things that have made the team happy
  2. Explain the meanings of the headings to the team and encourage them to place stickies with their ideas for each of them under each heading
  3. Wait until everyone has posted all of their ideas
  4. Have the team group similar ideas together
  5. Discuss each grouping as a team identifying any corrective actions

The pictures below illustrate the technique:

Click to Enlarge

Click to Enlarge

mad sad glad after

Click to Enlarge

What Are the Techniques Good For?

So that describes the process for each of the techniques. You probably noticed that the techniques are broadly similar. Each divides the whiteboard into areas for different categories of ideas. The team is then invited to place their ideas into each category. The team then groups similar ideas together. Finally the team goes through each grouping identifying corrective actions.

So why do I use these particular techniques? What is good about them? There are a few reasons.

I like all of these techniques because they are simple. They can be explained to a team very quickly. They require only basic materials. They can proceed from start to finish in well under an hour and you still end up with a good set of corrective actions.

All of the techniques encourage the entire team to participate. Each team member can place their own ideas on the board with equal weight. If instead ideas came forth via a discussion more vocal team members could take over while shyer team members would withdraw. Where there is no initial discussion this cannot happen and the team benefits from everyone’s input.

The grouping exercise is also key because the team members do it not the Scrum Master. They are again participating directly and putting their own stamp on the exercise by deciding which ideas are related. Also with the grouping in place corrective actions become easier to identify and prioritise. If, for example, there are double the number of stickies for one grouping as opposed to another then it is obvious to all that the first grouping probably represents the more pressing issue.

As the team is so involved in the retrospective from start to finish they get a justified feeling of ownership over the process and any corrective actions that are identified.

With these techniques the Scrum Master’s job is also easier. They have a structure for their retrospectives and do not have to do all of the work in the session. The Scrum Master simply keeps the process moving perhaps using improvisations. For example, when picking the next grouping to discuss they may ask the team to dot vote for the most important groupings or ask a team member to pick what is most important to them. Such minor changes are important to keep even varying retrospective techniques fresh.

Those are the similarities. It is important to note that there are also differences between the techniques. The differing categories between each technique are key. They lead to different types of ideas being raised as they each make teams think in a different way.

The Sail Boat, for example, is very simple. What is helping us? What isn’t helping us? However, you can elaborate on the process. I like to add rocks to represent risks that could ‘sink the project’. You could also add a sun to represent ideas for the team’s hopes.

The Wheel takes the core idea of the sail boat’s sails and anchors further. It not only asks what is making the team faster or slower but also goes into more granular detail about what the team should start/stop, do more of/less of or simply continue doing as before.

My personal favourite is Mad Sad Glad. The categories do not focus on the back and white of team productivity but instead look at the types of emotions the team experienced over the sprint. This can elicit some very interesting ideas. I especially like the distinction between Mad and Sad. Both are obviously negative but each can attract quite different issues from a team.

The Mad Sad Glad technique can also be extended. For example, I sometimes add a fourth category labelled ‘Scared‘ where the team can post the things that they fear. For instance, the team may fear that they will not make a crucial delivery.

So on the face of it the techniques are similar. However, they elicit different types of feedback and different corrective actions. They also inject a bit if fun into retrospectives. Finally with the application of many techniques retrospectives do not become boring affairs and the team’s ideas for improvements do not dry up.

So now that the team is armed with corrective actions what do they do with them? I will cover this topic in a future post.

Should a Scrum Master be Part Time or Full Time?

November 26, 2011

Note: the opinions I make in this post have shifted. See for Should a Scrum Master be Part Time or Full Time? – Revisited details.

My professional background is as a software developer but I have also been a Scrum Master for a few years now. So far I have been a Scrum Master for three sizeable projects while working for the same organisation. In every instance I have been both a Scrum Master and a team member. So far this has worked out fine. The projects have been a success and I have found that I am able to contribute directly to the team’s velocity by completing User Stories and indirectly by performing my Scrum Master responsibilities.

This set-up had always seemed to be perfectly natural to me. It never occurred to me that a Scrum Master would be anyone other than a developer because only a developer could understand the team’s activities to a degree such they could effectively facilitate the elimination of impediments. Likewise it always seemed a no-brainer that the developer/Scrum Master should be working on User Stories when not busy with Scrum Master responsibilities.

So all was well in my world. Ignorance is bliss, etc. Then I attended the London Scrum Gathering this year and had my eyes opened to other possibilities. I was in a session about identifying impediments when I had a brief conversation with the presenter (I forget exactly what started this exchange):

Me: “‘That’s true except when Scum Master is also a team member”
Presenter: “We won’t discuss that particular dysfunction just now”
Me: ** stunned silence **

This took me back a bit but I held my questions. The session was about impediments and I didn’t want to be pushy and take it off track. Besides a session entitled “Scrum Master – Role or Job?” had run the previous day. I had not attended preferring another session ‘Maximising Sustainable Pace” but now wished I had. That would have been the perfect time discuss the question.

Luckily in a later session another presenter also stated in their presentation that a Scrum Master should be full-time. I pursued this in the Q&A at the end by asking why this should be the case. The answer was interesting and I’ll paraphrase it here: “Ideally a Scrum Master will be full-time but in smaller organisations this may not be possible because of resource constraints. The reason they should be full time is that there is no end to the useful things a committed Scrum Master can do to help their team go faster”. At the time I remember stating to the presenter that if I had to choose between my two roles I would choose to be a developer. Now I am not so sure.

In my opinion there are two reasons that Scrum Masters in my organisation are part time. First off, despite it being a large organisation, there are resource constraints that mean that  having dedicated Scum Masters is not practical. Secondly nobody considers the Scrum Master’s responsibilities to be substantial enough to merit a full time job. I cannot argue with the first reason but I am now not as convinced by the second reason as I used to be.

I have since checked out the presentation from the “Scrum Master – Role or Job?” session and found it to be thought-provoking reading. If you check it out then pay attention to the speaker notes as well as the slides as they add a lot of detail. The most important message I took from reading the presentation was that the more a Scrum Master acts as a Scrum Master as opposed to anything else then the more they can help their team to reach their full potential.

In the last few sprints I have been paying more attention than ever to impediments. I pay close attention to what team members say in the stand ups and during the day to see if there are issues developing which I can help eliminate. Identifying more impediments has led me to spend more time facilitating their removal. This has taken time away from me carrying out my other role as a developer. However, it has also allowed team members to go faster than they may have done otherwise. Recent sprints have also seen an improvement in the team’s velocity. As I can help my team go faster by being a Scrum Master more I will certainly be carrying that on.

So am I converting to be a full time Scrum Master? The answer is no for two reasons. The first is that it simply would not be allowed where I work. The second reason is more interesting. I think the reason I can facilitate the removal of many impediment effectively is because I am a developer. I carry out the same types of stories as the other team members I am helping. I develop in the same code base, do the same testing, follow the same definition of done, etc. In short I understand the team’s day-to-day job so I can bring more insight to the removal of impediments.

So where does this leave me on the part time versus full time debate? Ideally I think that the Scrum Master should spend most of their time being a Scrum Master. However, my own experience shows me that I am a more efficient Scrum Master if I do the same work as the team so that I share the same experiences as them. This doesn’t need to be a large amount of development work and may even take the form of the Scrum Master pairing with team members. Unfortunately I cannot dedicate as much time as I would like to being a Scrum Master where I work now. Hopefully I will have the opportunity in the future.

Would Your Team Survive the Zombie Apocalypse?

October 21, 2011

Click to enlarge

I like Scrum but I love zombies. If there is a zombie related book, comic, film or computer game then I’ve read it, watched it or played it. So what would happen in the unlikely scenario that the two were combined? My favourite session of the 2011 London Scrum Gathering was on hand to answer this unlikely question and another: “Would Your Team Survive the Zombie Apocalypse?”

When I saw the session described in the gathering’s program guide it simply read:

“Would Your Team Survive the Zombie Apocalypse

An exploratory team dynamics session using lan based cooperative gaming”

My first thought was “This session has to involve Left 4 Dead” while my second was “No way am I going to miss this!”.

For those who don’t know Left 4 Dead, it is a computer game for PC and Xbox. It is a cooperative first person shooter where each player assumes the role of one of four survivors caught up in the “Inevitable Zombie Apocalypse”. The objective for the survivors is to progress through a series of game levels known as chapters before ultimately being rescued in a epic finale. At the end of each chapter is a safe room where the survivors can stock up on guns ammunition and medical supplies. Unfortunately for the survivors the areas between safe rooms are populated with zombies known as “infected”. Singly the infected do not pose much of a threat to the survivors but en masse it can be a different story with the potential to be overwhelmed by the so-called “Horde”. In addition the survivors will come across monsters known as “special infected” which are far more deadly than regular infected  having special skills like such as the ability to pin survivors down rendering them helpless or cover them in toxic goo. The survivors can fight back with progressively powerful guns, melee weapons such as baseball bats and axes and make use of special items such as medical kits and molotov cocktails.

What does Left 4 Dead have to do with Scrum? For me Left 4 Dead is the ultimate cooperative shooter game. If a survivor goes off on their own they will die. If a survivor is pinned down by a special infected and they are not helped by a team mate they will die. If a survivor is knocked over and not helped up by a team mate they will die. If a team does not share their resources such as medical supplies their team mates will be slowed down and will die. If a team do not work together during the epic set pieces thrown up by the game they will all die. There are other examples but you get the idea. Survivors have to work together or they will die. The game mechanics of Left 4 Dead make communication and effective team work more important than any individual survivor’s skill with a keyboard and mouse or controller.

One of the main advantages of Scrum is the creation of self-organizing, self-led teams. For me Left 4 Dead simulates this ideal with its cooperate-or-die game mechanics. The goal of self-organizing to complete deliverables is replaced with simply surviving and, ultimately, being rescued.

Click to enlarge

The session was organised by James Scrimshire who described it as a means of illustrating the Five Dysfunctions of a Team. This was a new concept for me and I’ll try and do it justice here.  The dysfunctions are layered one on top of the other in a pyramid with each dysfunction being the cause of those above it. For example the bottom dysfunction is “Absence of Trust” which can occur where, for example, people don’t ask for help because they don’t want to feel vulnerable. This can feed directly into the dysfunction “Fear of Conflict” because with no trust a team will not wish to get into conflict with each other. Fear of conflict is a dysfunction because in some cases, conflict, as opposed to artificial consensus, can be good for a team. The layers carry on through “Lack of Commitment”, “Avoidance of Accountability” and “Inattention to Results”.

Click to enlarge

There were eight networked PCs available grouped at two tables with keyboard and mouse for controls and microphone for communication (although I quickly took mine off preferring to talk directing to the rest of the team). We all had flat screen monitors and the output of one of these was replicated on a large screen. This allowed those attendees not playing to get a flavour for what was going on. The PC cases had been modified to show a very cool Left 4 Dead logo and each player was given a one page illustrated guide to the game’s special infected and items. James and his assistant Sam were on hand to jump-start the players with a quick guide to the game’s controls. James is to be congratulated for the organisation and level of detail he put into this session.

The initial session utilised a special game mode in Left 4 Dead called “Versus” whereby one group of four takes on the role of the survivors while the other group of four plays as the special infected. Each team takes a turn playing survivors or special infected for each game chapter and a score board is maintained. I’m a veteran Left 4 Dead player and so far this is standard stuff. However, there were several twists that made it more interesting and applicable to the session.

Normally in Left 4 Dead you play over the Internet with people who are usually strangers with only voice for communication. This anonymity can lead to people being quite vicious to each other sometimes hurling abuse when things don’t go their way. Here, however, everyone was in the same room. This made it a very safe experience, especially for the majority of attendees who had never played the game before. With this safety in place teams could quickly start to develop some trust for each other and communicate more effectively than they would to do remotely.

Click to enlarge

The next interesting thing was the range of skills available in the teams. A couple of people such as myself had played the game before, while some had maybe played other similar first person shooter games such as “Modern Warfare”, while for some people it was all completely new. This gave those with experience the opportunity to help their team mates by explaining game mechanics as they went along, guiding them through the unfamiliar levels and, initially, protecting them. For the first few levels my team had two experienced players while the other had none. We tanked them which led to a rebalancing of the teams by James so that one of our experienced players swapped teams. This made things far more even but it is important to note that even before the rebalancing the inexperienced team showed improvement as they learned to work together. By the end of the session the two teams were performing equally well with the previously inexperienced team members coming forward with their own ideas of how to succeed at the game.

Click to enlarge

The most interesting twist was what happened between levels. Rather than just plough on with the next level we took a break and had a talk within the teams. Part of this was a discussion of where our team was on the five dysfunctions pyramid and whether or not we were climbing it. We also talked about what went well, what didn’t and what we could do to improve for the next round. This was, of course, a mini retrospective and it certainly helped the teams to identify solutions to improve their performance. In fact with the addition of the retrospectives it could be said that each level of play was the equivalent of a sprint in Scrum terms and it certainly worked out that way.

What I really liked was what I saw when I was watching others playing rather than playing myself. In a very short space of time you could see these small teams of strangers playing a computer game and quickly accelerating through the stages of Forming,  Storming, Norming and Performing. It was nice to see this in action as with a normal software development team these steps can take months to progress through.

Click to enlarge

The pictures featured in this post are not from the first session which was held in a small conference room. That was cool enough with a largish projector and modest sound system. What was even better was when the session was expanded into the Open Sessions time on the third day. For this James took over one half of the main conference hall. This had a massive screen (as you can see from some of the pictures) and a very loud sound system. It was awesome switching being seeing Left 4 Dead on the big screen and watching the interactions between the team playing while hearing the loud screams of infected and the roar of machine guns.

Click to enlarge

A modification for the second session was to have only four PCs and have the team play the straight campaign game, i.e. the special infected are controlled by the game, not other players. This is actually my favourite mode when I play myself and I think it works better for the purposes of the session as the element of competition with another team is removed. James also remarked that it is easier for him to keep an eye on one team rather than two which makes sense. I like that the session’s format is a work in progress. I can see this emerging concept  mutate further over time as James presents it. There is certainly scope for expansion and perhaps a Left 4 Dead mod may appear to support it at some point.

What this session was not was simply wasting time playing a computer game. The session proved to be a good tool for demonstrating team dynamics and rapid team evolution while playing a game. I hope the concept is carried on and developed because it has a lot of potential.

Update: James has written his own post about his motivations for creating this session. Check it out here.