Posted tagged ‘Scrum’

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.

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.

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.

Reflections on the 2011 London Scrum Gathering

October 13, 2011

Click to enlarge

I am writing this post whilst travelling home from London after my first Scrum Gathering. It has been a hectic but rewarding three days. Even though I am dog-tired I want to get my thoughts down while the experience is fresh in my mind. My reasons are two-fold. This will help cement some of the interesting things I have learned. Secondly it gives me something to do on the four hour journey from London to Glasgow (it has been a long time since I last travelled this route and I cannot get over the fact that I’m on a moving train and enjoying a wi-fi internet connection. I love progress). I hope that sharing my experiences as a Scrum Gathering newbie will aid those thinking of attending their first Scrum Gathering.

First some observations on the venue and facilities. The content of any conference can be top-notch but will be let down if the surroundings are not up to scratch. This gathering was held at the Park Plaza Riverbank hotel which is located on the south bank of the Thames within view of the Houses of Parliament. The hotel was excellent with comfortable rooms, friendly and helpful staff, a varied breakfast service, adequate lunch, top-class conference facilities and reliable wi-fi. As expected it was easy to travel to the hotel with it being less than a half hour walk from Vauxhall tube station.

The level of organisation at the gathering was impressive. With the keynotes and various sessions spread over two floors and many rooms clear sign-posting and floor plans were essential. Fortunately these were provided and any changes to the schedule were clearly communicated. Scrum Alliance staff were on hand to assist at the help desks and this came in handy for me when I could not find a session (my own fault – I left the handy booklet that contained the floor plans in my hotel room on the first afternoon). The Gathering Chair Nigel Baker and all of the Scrum Alliance staffers present did an excellent job organising and running the gathering and are to be congratulated.

That’s the banal but very important stuff out of the way. So what about the actual content?

Each day the program ran from 09:00 to 17:00. The first two days of the program began with ninety-minute long key-notes. These were followed by three ninety-minute long session slots interspersed with coffee breaks and a buffet lunch. The format of the sessions was to have seven different topics running in parallel across the many conference rooms. These were categorised into several different streams such as Scrum, Coaching, Product Owner, Change, War Stories etc. The scheduling of the sessions meant that I had to make some difficult decisions as I could only attend six of the 42 available sessions. This was tricky as so many of the sessions that looked pertinent to me clashed. In fact fully a quarter of the session program looked useful to my own work. The program contained a descriptive paragraph of each and was available at the gathering’s website a few weeks before it started. I spent a lot of time on the journey down deciding which I would ideally like to attend and putting them in an order of preference. In addition scrum experts were on hand for drop-in Scrum clinics. Unfortunately I was too busy in the formal sessions to take advantage of the clinics. However, I think they are a great idea and would be very useful for anyone with questions or concerns about their own implementation of Scrum.

Rather than go through every session I attended I’ll write about some of the highlights. While most of the content was of a high-quality some items stood above the others in terms of education, applicability and sheer entertainment.

“Managing a Collaborative Multi-National Team in Real Time Using Agile / Lean / Scrum /XP – Building a 100 MPG Road Car in Three Months”, Opening Keynote, Joe Justice

This was an AWESOME opening keynote. I’ve sometimes wondered if Scrum and Agile could escape the confines of software projects and be used to help produce something different. But a car? A 100 MPG car with low-level sport car levels of performance? Built by a team distributed in terms of time and location? I wouldn’t have thought so but Joe and a group of volunteers have done all of this and more and continue to improve and innovate in this and other product spaces. Joe is a great speaker and thoroughly deserved the massive applause he received. Check out for more details.

“Understanding Each Other: Crucial Skills for Teams, Leaders, and Coaches”, “Scrum And” Stream, Tom Mellor

This session discussed how to handle “crucial conversations”. It presented a series of techniques that help to manage stressful or difficult discussions to stop them turning out badly resulting in either silent or violent behavior. Anyone in a working environment will have been on one side of a difficult conversation and had it go badly wrong. The techniques are simple enough but, I would imagine, tricky to apply successfully (indeed it was accepted that some conversations cannot be managed). However, role-playing was used to good effect in the session to give the attendees some practise.

“Would Your Team Survive the Zombie Apocalypse?”, “Bonus” Stream, James Scrimshire

I LOVED this session but am saving up a full write-up for my next post. Zombies and Scrum. Inspired. (Update – the full write up is here)

“Using the Daily Scrum to Identify Impediments”, “Bottom-Up” Stream, Karen Greaves

A Scrum team won’t always be up-front about impediments in the daily stand-up or in the retrospective as they may not know they have a problem. I already had a couple of basic techniques I used to identify when the team was not able to sprint as fast as possible. This session furnished me with even more provided by both Karen and the other attendees. This was a great experience in cooperative learning. (As an aside it wasn’t even dampened for me when Karen dismissed my dual role as team member and Scrum Master as a ‘dysfunction’. I had no idea before the gathering that there was a movement within the community that feels that being a Scrum Master should always be a full-time job. I don’t agree but will remain open-minded for now. Certainly from subsequent discussions I had with my colleagues and other attendees there is not a consensus on the issue).

“Scrumbrella – Scaling Scrum”, “Top-Down” Stream, Nigel Baker

This session covered how to scale Scrum and how to definitely not scale Scrum. It also touched on the relative merits of Rolf Harris, Harry Potter and The Robot from “Lost in Space”. A highlight for me was the showing of a scene from John Carpenter’s “The Thing” to represent what happens when architecture gets out of control. The faces of those in the room who were not inured to horror movies were worth a watch during the clip. Nigel’s presentation was entertaining, controlled chaos which succeeded in communicating to me the reasoning and practicalities of the previously nebulous “Scrum of Scrums”.

Things changed on day three. There was no key-note to start the day and the formal sessions were replaced by Open Space sessions. The idea was that attendees could propose their own sessions. Before the assembled gathering they would take turns to book a time and place and briefly pitch their session. I had my fears about this structure but it was explained that we would be encouraged to leave sessions that did not match our expectations and drop into others at will. I attended a few sessions and did abandon some part-way through. Some weren’t delivering for me and, worse still, in one I witnessed little more than an exercise in ego polishing. Only one really delivered for me and it concerned bringing Scrum to off-shore teams. To begin with it wasn’t quite clicking as various attendees reiterated that there was an issue and a goal to reach to solve it but could not explain how to achieve it despite being insistent that they had solved the issue. The session came alive when some of the attendees who were from India explained from their side how they had been able to promote Scrum in association with their on-shore colleagues to create a productive working environment.

All-in-all the Scrum Gathering was a great experience. Some of the sessions and key-notes were excellent and I picked up many techniques and practices that I will be taking back to my own team and organisation. I also met some great people and indulged in providing a little informal Scrum mentoring myself over lunch on the third day. I’m not sold on Open Space at all but it could be I was just unlucky in my choice of sessions. If you get the opportunity to attend a Scrum Gathering I would recommend that you grab it with both hands.

Certified Scrum Professional for ScrumMasters

August 3, 2011

Warning: this post gets a little acronym heavy.

I recently successfully applied to become a Certified Scrum Professional (CSP) and thought I would share some thoughts on the certification.

The CSP is a second level qualification above Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO) or Certified Scrum Developer (CSD). All of these certification are run by the Scrum Alliance. I myself was already a CSM and was looking to upgrade my qualification after a few years as a practicing ScrumMaster.

The reason I went to the trouble and the expense ($250) is because of a problem I feel is implicit in the CSM qualification. For those not familiar with the CSM certification process I’ll describe it briefly. Candidates pay around $1,500 to attend a two day training course hosted by a Certified Scrum Trainer (CST). Then…well that’s it, they’re a CSM. The CST pays for their first two years of certification on their behalf out of their training fee. That’s right, no exam, no follow-up, nothing to prove that they’ve taken it in. This is classic sheep-dip training in the guise of certification.

(In no way do I want to denigrate the CSM training course itself. I had been practicing Scrum as a team member for about a year when I attended a CSM course in late 2007 hosted by Martine Devos. I found the experience to be very enlightening and a great setup for taking on the role of ScrumMaster within my project.)

That was back in 2007 and, to be fair, things have changed a little. Now you have to take a CSM evaluation online some time after your training course ends. I thought this may be an improvement until I read that you don’t even need to pass the evaluation. If you fail it you still get to describe yourself as a CSM. I find this to be more than a little crazy – there is no actual certification involved in CSM. The ‘C’ should be replaced with a ‘T’ for ‘Trained’.

I wanted to differentiate myself from non-practicing CSMs. I know a lot of CSMs and while most of them are conscientious ScrumMasters a minority of them fall into a worrying bracket: they go on a CSM course, put the letters on their LinkedIn profile but do not practice real Scrum.

Fortunately the CSP qualification looked to be a good way to differentiate myself. The CSP requires you to have used Scrum in some capacity for at least a year and to complete an application form. I won’t write about the content of the application (the CSP agreement forbids it) except to say that I found the questions to be suitably searching and I believe that a practising ScrumMaster can demonstrate real experience by answering them.

I believe that the CSP is a big step up from the CSM as a candidate has to have real experience with Scrum which is then evaluated by (presumably) an expert at the Scrum Alliance. In addition, in two years time the candidate has to re-certify via the same process (but answering different questions). This sounds more like real certification to me.

I spread the completion of the application over several days and spent a total of 2-3 hours thinking about the questions, drafting and proofing my answers. The only painful part of the process is waiting for feedback. The Scrum Alliance site is very upfront about the fact that it can take up to two months to get an answer to your application. In the event the certification coordinator warned me of a three month wait on application. Fortunately two months was what it actually took. However, I still feel this is too long – especially when you consider the $250 fee payable on the event of a successful application.

In closing I would urge any practicing CSM to go to the trouble of upgrading to the CSP. After paying out so much money to be a CSM the extra outlay in time and money for the addition of a CSP qualification is relatively small. After all, there may be Scrum-aware hiring managers who share my opinion of the worthlessness of the ‘C’ in ‘CSM’.