Now that's what I call a plan.

Creating a bunch of stickies never felt like a satisfactory result from planning. This is a reflection on the progress made by one team to create a real plan of how to convert story into software.

Stage 1 - Creating tasks without conversation

The team's planning session creates stickies for various tasks that we need to develop the feature. This is led by only a few of the developers and it is almost entirely directed by them. The stickies represent pretty big elements of work and the estimates are pretty high - most are over a day in length. There are very few testing tasks, which are created by the QA guy only.

Observations:

• The team aren't thinking how to do this work - someone else has decided and are dictating the tasks as they see them
• The tasks are not very granular so detail is being missed and the resulting estimate is not very accurate
• The team is not owning the QA - they are creating 2 teams which might not join up to deliver the work

Stage 2 - Experimenting with Diverge and Merge

A recommendation from our Agile Coach gets the team using Diverge and Merge to create tasks. The whole team creates tasks in parallel and then they merge their stickies. This breaks the dependency on individuals leading and makes everyone think about what needs to be done. Merging creates conversation as some people think of things that others haven't and we all reach agreement where we have the same tasks. To make this work, it is need to follow the work through sequentially. You can optionally play a game to see who keeps the most stickies on the board, which keeps the session flowing.

Observations:

• The team don't really buy into Diverge and Merge but the sequential story of what needs to be done makes sense to them
• Involving more of the team means we have less direction from individuals - there is more ownership from the team rather than following individuals
• QA still a secondary process within the team
• Tasks are still quite large

Stage 3 - Creating tasks sequentially

SM encourages the team to explore how to do the work sequentially, encouraging quieter members of the team to contribute. Larger tasks are broken down and things we often forget also take time are included like documentation, deployment packages, merges. The QA guy is still doing the same thing but SM asks them to explain the approach to the team, which does not result in a lot of feedback.

Observations:

• Following a linear path through the tasks makes it easier for the SM to pull developers into the conversation
• The larger tasks were hiding detail that we need to discuss in order to estimate - breaking them down helps reveal these
• Asking the QA guy to explain the testing approach helps to breakdown the 'us' and 'them' - it introduces the notion that the whole team should understand testing, led by QA

Stage 4 - Team ownership of Quality

We start the planning by talking about testing not development, which was an action raised in a retro. The team create a basic test plan and everyone estimates the test tasks. There are clear gaps in knowledge as estimates are wildly different - team estimates and indicates which tasks need pairing for knowledge transfer.

Observations:

• Talking about testing first influences the order they develop in, so the tasks are a little different.
• The testing plan being known by the team means they can shift between development and testing tasks - this gives the team more options as to how they deliver the work during the sprint
• The knowledge sharing is clear and improvements are found easily as a part of the process - no retro needed for this one

Stage 5 - Team collaborates on an approach

The team realise some stories need more thought. If left to the sprint, these decisions need to be made by a single developer rather then by using the wholes teams skills. A retro action is to use a whiteboard session to discuss the approach before a story is started. The sessions visually describe the areas of the system making it easier to spot difficulties or additional tasks that might be missed with conversation alone.

Observations:

• Pictures work better and getting people to explain using the diagram helps too
• This is very Just-in-Time - is there an earlier opportunity for this?
• Some areas of discussion maybe go too deep - the team sometimes dive a little too deep into implementation.
• A retro action from the team empowers them to huddle if they need team ideas/consensus - this helps counter only one or two developers deciding things without anyone else knowing

Stage 6 - Planning using a whiteboard

The team move the whiteboard session to planning and then decorate the system areas using tasks as they follow the development sequentially. The team discuss testing as a part of the conversation, making testing more integrated into the development. By grouping the stickies to areas of the system, they are able to see how many of them could work on the story at the same time.

Observations:

• The combination of a picture and sequentially discussing the development works nicely - it helps expose tasks the team has frequently missed
• The team is starting to think more about how the tasks could be done in parallel by picturing areas they can work on without tripping over each other
• Testing tasks are easier to spot - impacts on existing tests are highlighted quickly

This journey took quite a few sprints. There were regressions as well as advances but when I look back I saw these stages of development. The retrospectives drove many of the changes but we also saw spontaneous creativity - using the whiteboard sessions to plan against, is a good example.

The key thing I saw from the team was a shift in focus. Instead of planning how to do the development, they are now thinking about how to deliver the story. This goes further than a list things to do - it should aim to answer the questions:

• What order is best to do these tasks in?
• Who has specialist knowledge that we need to leverage?
• What does testing look like for this story?
• How can everybody assist with testing?
• How can we get everybody working on the same story?
• What do we need to knowledge share on for the future?
• What does the final solution to this look like?
• What are the 'risky' tasks?
• Who else might we need help from?

What does your 'plan' look like?

The 'real' Situation Cards

My wife is awesome except for the odd occasion when she stomps all over one of bright ideas. Then, obviously she turns into an insufferable little smarty pants.

Such an event happened recently, when I showed her some of my blog articles. On reading the stuff I had written on Situation Cards, she simply said:

"Hmmm.... these look like Social Stories..."

What? Surely, you must be mistaking my incredibly creative Situation Cards with something else.... Turns out, not.

Social Stories and Comic Strip Conversations are used to help kids with autism understand social situations.

Although the value I was trying to derive from Situation Cards is slightly different, the medium and concept are the same. These have been around since the early 1990's and were created by Carol Grey.

There is a load of information on these which is well worth diving into if you found the idea interesting. For example, Carol Grey uses colours to indicate different feelings or ideas.

Although this was designed to help kids with Autism, Social Stories and Comic Strip Conversations have been used with a wide range of people and circumstances, so why not understanding business value too?

Super quick themed retrospectives

At the beginning of my current role, I decided (possibly foolishly) that I would not repeat a retro with the same team. The goal was to create a new retro for each team, every time.

Some, I have lavished time on but when you need to pull one together in double quick time, I took the advice of Helen Meek who is the master of the themed retro.

The theme is usually a movie but musicals, sports, bands or TV shows are equally applicable. You can get creative with this and I think pretty much anything goes.

We all want to get actions from our teams so we pose questions about the sprint to help them look back and find those improvements e.g.

• What problems did we encounter?
• What's going to hit us next?
• What went well / not so well?
• What went according to plan?
• What caught us by surprise?

etc etc

Using the theme, we can cunningly wrap the same questions up to keep the whole thing interesting and unique.

Here is an example:

Happy, Mad, Sad is sooo 1990s! Replace Happy with Joy, Mad with Anger and add Disgust and Fear and you have the main characters from Inside Out:

What made us happy?

What did we find unpleasant?

What made us sad?

What should we be scared of?

What made us loose our temper?

Quick and easy. Also works with kids up to 8 years old :)

With a bit of imagination you can pick 3-5 scenes from any film and come up with some questions to get your team thinking here are some examples from "The Internship" (which was an unpopular choice solely due to it's Rotten Tomatoes score, geeks eh?):

How did we help each other out?

What did we get wrong?

What can we celebrate about this sprint?

Since these are quick, you can tailor them to the teams current situation. When a few people left one team, I quickly added a '"How are we going to stay together?" question in a matter of minutes.

Google is an obvious place to have a look for scenes from films or you could have a look at film-grab.com to get those ideas going. Here's one that Dan Rushton sent me, which made me chuckle:

Did we see anything shocking?

Still stuck for ideas? Get the team to suggest a movie or something they are interested in. So when I heard one of my teams discussing the Great British Bake Off...

What was our showstopper?

What was the technical challenge?

Which of our creations would have turned Mary's stomach?

What did not go according to plan?

Maybe it could be a new film they are all talking about? Maybe a Xbox/PS4 game? A season finale, perhaps? The format is simple and flexible and I enjoy them as fillers between more focused and structured retro's when there is something I want to "deep dive" into.

Be warned. Some people don't get metaphors. There is no helping these people, believe me I have tried :(

For a masterclass, be sure to visit the many blogs of Miss Meek, enjoy!

Why Scrum teams between 3 and 9?

We all read the Scrum Guide but have you ever wondered why the band of sizes that is prescribed?

Recently, I have been working with a large team which was 10 people (8 developers and 2 QA). It was interesting to see the problems that came from this size team so I thought I would jot them down.

Problem 1 - Capacity
If you have a large team, you end up with a large capacity. A 2 week sprint for 10 people means an epic 540 hours (6 hours a day for 9 days, after taking out 1 day for ceremonies). That's a lot of work to prep and get ready! Most sprints we found it difficult to prep enough for a commitment against our full capacity, forcing us to bring more in mid sprint.

Problem 2 - Prep
Having mentioned prep, the larger the team the more difficult it is to get everyone focused. It also has the side effect of you sacrificing over a days development for each hour you prep. This is obviously scaled up, you cannot escape this - but the larger the team, the slower the prep felt which means the losses are amplified. We had an additional problem that our team area was not really big enough for everyone to see the ample 50" screen we used to access our backlog.

Problem 3 - Crowd Control
Prep and retro's were interesting times for the Scrummaster. Getting people focused and keeping them there was challenging. Finding a space which we could work with was a challenge. Prep sessions were either silent or we had too many voices at once, which we needed to work harder to bring everybody under control.

Problem 4 - Visualisation
Large capacity means lots of stories. We found it difficult to visualise the work simply because we could not get it all on the wall. This meant we often had stories 'waiting' to make it to the board. This made if difficult to see the full picture for both the team and the stakeholders.

Problem 5 - Ceremonies
With more people we needed more time for pretty much every ceremony - this ate into our sprint window. With lots of work the planning sessions often turned into epic half day marathons that everyone hated and retro's would take about 50% longer just because it took a bit longer to coordinate the team for each part of the retro.

Problem 6 - Sprint Composition
We had to be more careful about what tasks ended up in a sprint. With so many people, we often ended up with stories that blocked each other since they were in one area that shared code, unit or integration tests. This stopped us from being able to work in parallel on them. One sprint contained only stories for a single component, which caused us a multitude of delays as we tripped over each other repeatedly.

Counter measures we tried:

Split Prep - We did 2 rounds of prep, allowing us to sanity check the requirements and do investigation using the bare minimum of developers, minimising the impact on the team. Our desired outcome from this round of prep was that the developers involved would present the story to the rest of the team, replaying allows the PO to confirm solid understanding. By the time it got to the team we knew it could be done and had any investigation/spikes covered so it was all about spreading understanding of the story.

Timeboxes - when we had the full team at any session we enforced 1hr timeboxes. More than that and people were too fidgety to work with. If we needed longer we broke up for a 15min break to get refreshments and repeated the time box.

Diverge and Merge - in planning we asked the whole team to task out the story. There was obvious duplication but the differences were the interesting bits that leverages the teams different thinking on the problem - some people thought of things that others did not. We then had a game to see who could keep the most stickies on the board. This worked better than allowing one person to drive but was not always liked by the developers. Main benefit is you get everyone engaged.

Two Boards - for a while, we had 2 different boards for different classes of work. This allowed us to visualise everything but also meant we had 2 stand ups. Not going to lie, it was weird.

Two Retro's - we did 2 retro's for the first sprint so we could keep the groups small. Universally hated by everyone we did not do it again. The split was based on the classes of work we used to split the boards BUT people worked across the boards so it was very odd. Not recommended.

Huddles - we often had 2 standups a day to coordinate work. With a larger team, they can burn through tasks quickly when working in parallel on a single story. This meant more coordination that a single stand up was needed. Wasn't a bad lesson to be honest and we do this even now when tasks are not moving or causing problems.

In conclusion, the 9 boundary is probably arrived at from trial and error. We were only 1 person over the 9 but we saw some interesting effects - I would guess team 8 and up might see some of these issues.

We had 2 BA's as well as the PO and myself making the full Scrum team a whopping 14 people at the majority of the ceremonies. Although the Scrum guide only considers the development team, you might was to think a bit broader and how that might effect your ceremonies.

One question I was asked - why not split the team into 2? This team worked on a single product. Splitting the team would have meant extra coordination by the team to make sure that what they were working on was known about by the other team. The team were also concerned about knowledge transfer, which they had worked hard on in the last couple of months leading to much better product knowledge throughout the team - splitting the team could have set back this progress.

My sweet spot seems to be around 6 - large enough to deal with holidays and sickness but small enough to enable knowledge transfer. This also feels about right in all the ceremonies.

Visualising Sprint Planning

I heard a fantastic thing today:

"Well, we have a velocity of about 40.... so we should be able to handle three 13 point stories"

Let's explore how this might work using some pictures.

We can start with a box representing our sprint. We start on the left and finish on the right, exactly like a timeline. We have 8 developers on the team, who pair the majority of the time so we can see the sprint divided into 4 parallel streams:

As I blogged about previously, I know my team deliver 13 point stories 10-13 days based in previous history. Visualised, this would look like:

Not a great start.

For the purposes of this blog, I'm going to imagine we have sorted this issue and the team have a track record of delivering 13 point stories within our sprint window of 10 days. So going back to the previous statement, we can view the sprint like this:

First obvious issue, what would the last stream be doing? OK, so we had some spare capacity - according to our velocity we had 4 left over so we could bring in a 5 point story and still be OK. Five point stories are taking about 7 days:

We have a little slack, which is never a bad thing. However something more sinister is going on - these developers will not have many options to deliver this work.

The pairs on 13s will be stuck with that story from beginning to end. Everyone else has a similar problem.

We have 4 stories in play. 3 will probably finish around the same time, which is right at the end of the sprint. We only have 2 developers at the end to help get these stories across the line as far as testing goes. One developer on each story could mean one story is sacrificed.

The numbers and stories 'fit' but this is less than optimal and still pretty scary.

If we can, we aim to finish stories mid sprint. This allows us to mix up the teams skills or to add resource to another story if required. In the previous example, although we could try to do this we risk not delivering the stories at all.

So if we could break down the stories a little, we could also assess risk and decide when to start a story. In the following example, we have a big 13, two 5's and a 3 all in progress:

If everything pan's out the guys working on the 3 will finish in time to help out with both of the 5's or start another story. Alternatively, they could help out with the 13 if we feel there is more risk in that not being completed.

With the 2 fives being complete, we could swarm on another story that we tasked out specifically to allow more people to work on parallel or we could mix up the pairs and pull in 3 smaller stories - probably a 2 and a pair of 3's might fit if we look over our lead times. Merging 2 of the streams and working on 1 story would lower WIP, which reduces lead times which is another option.

Alternatively, we could benefit from a bit of slack and allow the team to evolve their development practices. Seeing that they are no longer working from beginning to end, we have that option also.

All these options start for us in prep and planning. Our choices on how we break up and task out stories allows us to plan how we are going to deliver that work. Just relying on numbers is way to simplistic. Knowing a bit about your leadtimes gives you pretty powerful ways of visualising how the sprint should pan out.

Like photos, sprint composition is an art

A while back I started looking at metrics used in Kanban to better understand some of the patterns I was seeing in my sprints. The change from looking at a sprint velocity to looking at leadtimes for individual stories has been an eye opener.

In particular, I started to look at the composition of sprints rather than just trusting a velocity. The problem I have with velocity is the perceived safety it provides. Estimate stories, add the totals and when you reach something near your velocity you should be good to go.

Imagine this: we have a velocity of about 40 so we should be good to take in four 8 point stories and still have a little room right? This is where leadtimes start to give us a little more information.

My team is quite large, having 8 developers and 2 testers. We generally work in pairs so I see this as 4 parallel development tasks with an additional 2 testing streams. The team work on development and testing in parallel as much as possible - joining up is still a little fun but we get by.

I know from looking at my leadtime data that the average leadtime for an 8 point story is about 6 days. The worst we have turned a 8 point story around in is 9 days, with 4 days being the best. We work in a 2 week sprint cycle, which is realistically 9 days once we take out planning and other ceremonies.

Working with the averages alone, to have a 50% chance of completing all the 8 point stories in the sprint, we would need to start them all by the 4th day of the sprint. If we wanted this to increase to a 85% chance, the leadtime increases to 8 days meaning we would need to start them all on the second day of the sprint.

Here are some of the problems this could introduce:

Higher WIP: With 4 stories that all need to be started within a few days of each other, we force a higher WIP. Higher WIP means longer lead times.

Loss of fluidity/options: With 4 parallel work streams each using a pair of developers, we might find it hard to move people between tasks. We basically end up with a static pairing from the beginning of the sprint to the end. This limits our options or introduces waste where we have to move people around e.g. illness or a specialism that we have not shared yet.

QA 'tsunami': There is a risk that all 4 stories will need QA at around the same time. This might create a bottleneck in testing and slow throughput. If you had some flex in the team, you could get the developers to help with the testing - in this scenario that is probably not an option.

The composition of how that 40 points is reached is as important as the number itself.

Having a mix of smaller and larger stories creates more opportunities for the team to collaborate on delivery. Having stories finish regularly throughout the sprint allows the team to find points at which they can mix up their pairing or help out with other stories in progress. Having this flex allows you to shift responsibilities around the team to help keep stories moving across your board.

If you do have larger stories then look to create tasks during planning that allow a larger number of people to work on the story at the same time. This helps lower your WIP and decrease the leadtime for the story, which will give you more choices as to when you can start the story during the sprint.

Be careful not to overload a story - just putting more people on a story will not make it progress faster, it needs to be a part of the plan.

This might go back as a far as preparation where you could choose to break up stories a little further to allow them to be worked on in parallel during the sprint. You might need to negotiate on the independence of the stories you have broken down but it might save you from negotiating on what you can deliver.

Describing value using Situation Cards

EDIT: I have since found out that Situation Cards are really similar to Social Story and Comic Book Conversations.... read more here

A while back I wrote about situation cards, which Dan Rushton and I came up to help connect developers with the reason why we were doing a particular story.

Our team works on systems where we are essentially passing messages between different services which is particularily difficult (read: boring) to demonstrate in the review. We all hate Powerpoint but looking at Fiddler or SoapUI is way more dull.

Dan's brainwave was to use the situation cards to introduce the stories we had worked on during the review. The feedback from the stakeholders was excellent and they wanted to see this happening earlier in the process.

We now include making situation cards as a part of our prep sessions. We ask the team "How would you explain the value of this story?", putting them in the place of the customer. Sometimes a single card with a one-liner can be used, usually it takes a mini dialog to explain the value:

In the example above, the value stems from additional information to help the customer pin down issues in an area of logic which is hidden from them. By handling the error differently we can show which data item is the cause allowing our customer to find the problem in the logic that drives the output from simply asking the customer which data item are showing as errors.

You might notice that it took me a lot more words to describe this than we used in the situation cards but the level of detail is essentially the same.

This does not happen by accident - a series of conversations happened before we came up with the dialog in the situation cards. The words are not accidental, we arrived at them through discussion.

The cards provide context which helps but they also act as a constraint. At a very simple level, we have very little room! Further, when we are writing them, we are thinking about how we will read these during the review - they need to be short and direct otherwise you sound like a crazy person.

We can easily refactor conversations to convey the value in as few cards as possible by changing the dialog and removing cards.

We have a series of these to represent different situations - we usually use the man on mobile to covey the customer and the man at the workstation to represent the response from the team. We also have a man in a call centre to represent interactions with our customer's customer which has come in handy too.

These become Powerpoint presentations which we then use as initial storyboards in TFS - we simply attach them as storyboards which are stored on our local network. We create them in prep and then use them when we introduce the story to the team to kick start the understanding of 'Why' we are doing this story, which is what we originally intended these cards for.

Interested to know if anyone else uses these or something similar - feel free to leave feedback if you have :)

Size (sort of) matters

Recently, I have been keeping a small set of metrics on the stories from my team. I started with simple dates so I could look at leadtimes - the time taken from when we start a story to when we deliver it.

With just these 2 dates you can do a lot! A lot of this came from looking over what was presented by Mattia Battiston at a meetup not so long ago. In particular, I was interested in his observation that there is very little correlation between story sizes and leadtime. This is something I have battled before so I was interested when my own data showed a very similar pattern:

Looking at this you could infer that a 2 point story might take as long as n 8 point story, which is hardly useful. What I missed for a while is the upper bounds across all the story sizes. We have a couple of anomalies at the top but the vast majority are within 10 days - which you should know is the length of our sprints.

That caught my interest. Although we cannot say with any sort of accuracy how long a 5 point story will take - in this example the longest was 26 days and the lowest was 4 days - we can say that 95% of 5 point stories can be delivered within 10 days or less. You can repeat a similar statement for story sizes 8 and below.

So maybe we should revise what we are expecting from our estimation by the team. What we are very good at doing is working out what can deliver within our sprint window. What we actually want to know is how many stories we can expect to be delivered if we want to use this to forecast, which is our throughput.

For me, looking at leadtimes influenced how we were working on and preparing stories. Littles Law describes how we should see a lower leadtime if we lower our WIP. We think more about how more of us can work on a single story, this often starts in prep. We open less and this lowers WIP, decreasing leadtimes.

Having a leadtime which only just fits in a sprint window means we have limited options on how to plan the work in the sprint - we have to start everything on day 1. This would mean loosing fluidity - everyone would be one a single story from beginning to end. Not many options for us at all.

Lowering leadtimes by a few days gives us some flexibility in when we can start stories. We use our story points to influence when we start on things. Larger stories might need to go first but smaller stories run in parallel so that we can deliver throughout the sprint rather than everything at the last minute, which would probably create a bottleneck with testing.

For me the sizes of stories begin to matter less and less. They serve their purpose during prep and planning and help us get to the answer: "Will this fit in our sprint?". When we see a 13 we look to break it down further since we can see it is rarely delivered in less than 10 days, which does not give us enough options. 

If we bring something in mid-sprint, we can look at the previous leadtimes and give a percentage "75% of previous 5 point stories have been completed in the time we have left" allowing us to make a commitment with some accuracy on success.

There are many more interesting things you can gleen from leadtimes and some basic spreadsheet fun, Mattia's presentation is a great place to start.

My Retrospective on my Retrospectives

I have been doing regular retro's for about a year since I changed direction career-wise. I have recently been looking over how my style has changed and looking at why these changes came about.

Working with an experienced Agile coach has certainly been the catalyst - Helen Meek has pointed out many areas of improvement which I have been gradually working on over the last few months. Other inspiration was from an amazing talk from a lady who works with kids on the Autistic spectrum called Gina Davies.

She describes how she centers attention around a box. There is something different every time in the box and the kids she works with respond to this by sitting and waiting to see what happens next. You don't realise how effective this is until you see some video - kids with ASD don't get 'waiting' but after a relatively short amount of time, they start to participate and want to wait to see what happens next. The box is 'magic' - something new happens every time.

So this got me thinking, what's my 'magic box'? The obvious answer is the retro. It should be fun and engage the team. It should be something we all look forward to. Here's my observations on things that I have changed over the last 6 months:

Keep it Fresh - One of the key things I have tried to uphold is to never repeat the same retrospective with a group. I mix up sections of the retro or come up with a dedicated retro to target a specific area that the team needs to improve on. Sometimes I am inspired and come up with something completely new, other times I spend some time putting something together using the awesome Retromat.

Experiment - Each team is different. Different styles and techniques fit with some teams and are lost on others. Experimenting with formats lets you continuously improve getting the team involved and engaged. You also learn what works for a given situation - your retro style and format may well change depending on the sprint and team morale.

Sit back, relax - Helen encouraged me to sit back and watch the team rather than stand up and direct. Sounds easy but your team may now be a bit lazy! By you sitting back 2 things will happen - first your team will need to get more involved and second you can observe your team and start actively getting people involved. Helen encouraged me to direct, rather than lead which is a really nice way of seeing it.

Stories not Events - I have noticed that the events that stick out are usually the bad ones. These are usually the ones brought up with allows for improvements but does not help with celebrating successes. We should be pepped by the end of a sprint! Using timelines you can encourage storytelling, allowing you to replay a sprint from beginning to end. You can journey through the sprint, looking at what happened so you can see both the good and bad points.

Be prepared! - I spend as much time prepping a retro as doing one, if not more. Since I vary my format, I have to spend some time thinking about what I am going to do. This is a good thing and the team deserve it. Playing out the same retro might feel safe but I should imagine the team dread it after a few months. Dedicate time to preparing your retro, fitting it in with the teams personalities and requirements.

I'm sure there is more but these are the ones I have had on my mind recently. Enjoy!

Reference Conversation

So, I have this problem. I find it very hard to start conversations. This has never really been a problem, I put it down to how I'm wired. Just recently, I have cause to think this is holding back my career progress so I have been working on understanding why and finding a solution or workaround.

First, I looked back and realised that fear had a big part to play. I have a tendancy to build up the conversation in my mind, running scenario after scenario in an attempt to control the conversation when I have it. In reflection this creates a negative feeling around the conversation so I shy away from starting it in the first place.

The build up also means that if I do start a conversation I am already apprehensive about it, which I am pretty sure the other person picks up on. Bad news all round really.

Now, I use 2 things to help break this cycle. The first is to think only about what the conversation is about and how I let the person know that. Seems simple really, I just work out how I open the conversation e.g if I am just checking in, I let the person know that in the first few seconds so they can relax.

Even if this is something that the other person might find difficult to talk about, I realise that I only need an opener - something is worrying me, this is why, now lets find a solution. I find this far less scary to think about.

This got me some of the way in that I could shut down a thought process by recognising it as daft from the outset. Once I had an opener, I could put it to one side as there is nothing left to think about.

Then I needed to find a way of countering the fear of starting the conversation, which felt like a learned response at this point.

Taking a cue from story planning, I came up with the idea of having a reference conversation. This gave me something I could refer to in the lead up to a conversation if I was feeling anxious about it. Similar to how we would use a reference story in planning, I would compare the type of conversation I was going to have with my reference conversation in help me recognise that it is really much less than I had built it up to be.

I use my reference conversation at any point that I am holding back from a conversation. If I am putting off booking it or starting it, I review my opener and remove my fear by comparing with my reference conversation.

For me, my reference conversation is one that I would not have the words for. It is one that I can think about and realise that all mine are trivial in comparison. As simple as this technique is, it has helped me move on and focus on having the conversation itself.

Don't kill good behaviours

Just recently, an update to GMail totally threw me when it subtly changed the way it did something that I use many, many times a day. Although this change probably seemed trivial to the team at Google, it really has been a pain in the neck for me.

Changing the user experience for a popular piece of software is a difficult tightrope to walk. Too little change and you stifle progress whilst changing it too much risks loosing or annoying the user base.

So what caught me out? I get a notification of what has changed in my groups as a top level entry in my inbox. I found this useful since I could simply go to the group, see what has changed and read the items that were of interest at that moment. I return to my inbox and the notification would be removed - happy days.

The update has subtly changed this. Now, it seems to want me to read ALL of the items the notification is related to. If I don't then the notification remains at the top of my inbox until I have viewed everything it relates to or I simply dismiss the notification by swiping it to the left.

This is a tiny change in all reality, it could even be a mistake but I find this change in behaviour very annoying since it requires more action from me. I imagined how this might have been recorded:

Given 1 or more groups have been configured
When the user enters their inbox
Then a notifications is displayed for each group that has new mail
  And the notifications are at the top of the inbox
  And the notifications are ordered descending by the amount of new mail in the group

It has long been my contention that the words we use in scenarios are often a bit sloppy. In this case you could easily interpret this in 2 ways, which revolves around how we interpret a 'new' mail item. Is a mail item new if it has never been opened or when it has been seen via clicking on a notification?

By not really explaining what 'new' means we may have killed existing behaviour by simply misinterpreting what the original intention was. In this case the word 'new' is not clear as it is open to interpretation.

A good practice is to think how this could be interpreted in the future. Would this be exactly the same as now? If there is any doubt, then deliberating over the words used is a good use of time. The emphasis should be on the author to think about this rather than make the assumption that the reader will interpret correctly.

It is worth thinking about what you know and they don't - the conversation for my scenario may well have included what 'new' meant or it could have been well established by that specific team. Since it completely missing from the scenario, we will never know.

As the author we have access to the whole context of the conversation, so the odd word here or there does not appear to matter. If we take a step back and put ourselves in the place of our intended audience we can often see assumptions we have made and save them a lot of time and effort in the future.

Retrospective: The 'Perfect' Sprint

This retrospective switches the attention of the team from the sprint they just had and allows them to explore what their 'perfect' sprint would look like. I have used this with teams that had a bad sprint - topics from the sprint will surface irrespective.

We represent the sprint as 4 columns - Prep, Planning, Dev Day, Review. You can choose the columns you want to focus on. The team then write up stickies for their perfect sprint, focusing on a column at a time. You will find that opposites occur at this point e.g. the opposite of what actually happened in this sprint. You can pose questions to get to the root cause and add more stickies if required.

I usually pair people for this, which seems to work better that everyone individually participating. I allow a time box of about 5 minutes and then we quickly go through the points raised. You can group common themes at this point. We repeat this for each column in sequence, following a journey through the sprint.

The key is keep the team focused on the perfect sprint. You can dive into specific issues as required - these will likely be based on the current sprint so they make good topics for discussion. I found this fits into a 60-90min retro with 4 columns at a good pace. If you have less time you can use less columns.

At the end we start to highlight what is in our control. This is usually pretty high - 50-75% seems to be about right. This leads the team to the obvious question - why don't we have our perfect sprint more often, given so much of it is in our control?

This outcome drives which actions we want to take into the next sprint - taking one from each column is a nice idea, but it does depend on what you came up with.

Retrospective: Ghost's of Retro's Past

This is a retro design to confront teams with actions from retros that have not been put into practice. Without actions there is little point in the retro, right? This is not a format you can run regularly - ideally you should not have to!

Start of by hunting down all the outcomes from the previous 4-5 sprints. Print them off in large print, cut into individual cards, fold them up and place them in a bowl. On a board or wall, draw out 3 columns - Ditch, More and Done. The team now take it in turns to pick an action from the bowl and place it in the column they think the action is relevant to.

Encourage discussion at this point - I played devils advocate often e.g. "I thought that was done?", "Didn't you do that?", "Yeah, we said that 3 months ago...." - you might not be so mean.

If actions are in More they are still relevant so there is no reason why they should not be done. Anything in More represents a missed opportunity for change. It is worth pointing out how awesome these ideas are and that they already came up with them - seems like a bit of waste.

Ditch suggests this is no longer relevant - you might want to explore if this is because they are old or we have evolved as a team. You might want to ask why didn't we need it? What do we know now that we did not know when we came up with this action? How did we ever survive without it?

You can also look at the Done actions and look at why they were Done - are they special/easy... what was different? It might come as a surprise how little has been 'Done'. This can be a valuable learning exercise in itself.

You can now focus the learning on why we did not do these things and then tease out which ones from More should we do immediately. Make sure the team buy into addressing these items in the next sprint. Ask the question "What could we put into practice today?".

Retrospective: Island Voyage

The concept behind this is to encourage the team to replay their sprint and discover key parts of their journey. The linear voyage you take the team on means we focus on the whole sprint rather than just remembering the final few days, which might not be the best to refer to.

You start with drawing an island in the top right of the board. This is the destination and represents what we delivered. Mine has palm trees and a tiki bar - it is a lovely place to be :) You can have fun with the name, mine was 'Delivery Island' which is a bit boring.

You start the retro by asking, which kind of vessel represented this sprint as the icebreaker. You draw this in the bottom left hand corner of the board. You can play with the speed of the boat, how large it was, was everyone on board, did we have space space for more stories, what kind of motor did it have, was everything ship shape - you get the idea. Naming the boat is a nice touch.

You can then spread out the visual cue cards for the team to see. These help them explain events or things they noticed on their journey to the island in the boat they described. I usually give a description of what they are too as this gets peoples creative side kick started.

If it was a not a clean sprint, you can ask the team where they got to. Was it close to the island? One of my teams decided they got to 'Acceptance Bay' but never made it the island itself. Maybe it went terribly and they ran out of fuel halfway?

Encourage them to use the cards as cues to describe their journey to the island, these can represent things we saw, things we avoided or things we did e.g.

• did we avoid any big storms or did bad weather push us off course (hurricane)
• did we know where were going (compass)
• was our time kidnapped or did we have to go out of our way to avoid being kidnapped (pirates)
• is there blood in the water or do we need to be cautious (sharks)
• did we see anything amazing (sunset)
• did anything distract us (dolphins)
• was there somewhere we would have preferred to be (desert island)
• was there the threat of destruction (sea monster)
• what held us back or what stopped us from floating away (anchor)
• what could sink us or what did we manage to avoid (whirlpool)
• did we have anyone overboard (man overboard)
• where we all alone or did we loose our way (dead calm)

The cue cards mean the team don't have to draw anything but if you have a creative bunch, ditch those immediately! If they cannot see a picture that represented what they wanted then they can draw anything they like. You can find pictures easily on Google - I would watch out for mermaids though, they tend to be NSFW (you have been warned).

During the journey you can experiment with detours - you can ask "did we have to go that way?", "Was this the scenic route - was there a more direct way?". You can also explore short cuts - these represent a better way of doing things based on what you know now - "Can you see a faster way of getting from here to here?". Maybe you the team got lost? If so, how did they get their bearings again?

The journey path can meander and double back on itself if the team had problems. It can suddenly go straight if there was a breakthrough. You can go around features if you avoided them (The Hurricane of Support) or show the path going through them (The Whirlpool of Broken Builds) if it was a rough time. You can stop off at places if you had slow progress and show the paths of other obstacles that you crossed which maybe hindered or halted your progress.

The linear nature of the journey lends itself to story telling and the nautical metaphor is pretty easy to grasp. By telling the story of the sprint, you often cover things that we might have forgotten about otherwise.

"3 Strikes" Quality Monitoring

This concept came about through discussion about how Defect waste should be measured. There are a load of posts on the 7 wastes, which I will not go into now but this started a discussion that led to something interesting.

We found 3 different gates which we think could be used to actively monitor the quality of our organisations products and development processes:

1) Defect Waste - This is a measure that is purely within our sprint. If we are working on something new and we find a defect with it in our sprint during QA, we label the time to resolve the issue as defect waste. This may seem harsh but it has interrupted our flow through the development process. We had complete acceptance criteria and access to the domain knowledge that created it - so in an ideal world this should never happen.

This a symptom of other problems e.g. are developers buying into the acceptance criteria, are the criteria strong enough, are the developers even reading the criteria? This also encompasses questions around the effectiveness of regression and automation suites, which is another area the team can improve on.

2) Release Testing - A series of teams all feed into a release, which is where we realise an integrated version of our application. We typically run automated suites and exploratory testing here, ideally this is built from tests created by the teams in addition to system level tests. Anything we discover here is irritating since we now need to fix it before we can release.

I find this hard to monitor since the issues raised look like any other issue and it is difficult to pick them out - ideally we are only interested in stuff raised during testing and dates are the only data I can currently rely on. It symbolises complexities around integrating work from multiple teams and possibly improvements for teams in terms of DoD depending on the problems found.

3) Bug Reports from Customers - The last place a bug will be found is by the customer, which means the organisation has failed! It should not make it this far but that does not mean we cannot learn from it. The number of the issues being raised by the customer can be used as the final gated measure.

It has evaded both of the other gates so may well be down to customer specific data or configuration. It might inform how we guard against regression for specific customers who are using features that might be specific to them or rarely used.

These 3 measures can be used to monitor trends. Ideally, we would see all of these trending towards zero in every sprint, every release and for every customer. The combination of the 3 gates tells us more about about how we treat quality throughout the development process.

By making these measures visible we can also start to re-focus the development teams on a wider view of what we term as quality for the products we build.

Symbols not words

It is rare that something I try just works but this is something that was simple and helped one of my teams.

We were finding it awkward to track the overall state of a story on our manual board. Without this it was easy to miss something interesting during the stand up and even more difficult for the business to look at the board and understand what we were working on.

The team always talked about 'bringing an item into play' so I started to use a CD/DVD play symbol to indicate the items we were currently working on. This quickly evolved to use the stop symbol to show a story had not been started yet, a pause symbol to show the story had something blocking it and eventually a fast forward symbol to indicate that the team were swarming on that single story. Once we used the eject symbol when a story was pulled from the sprint due to a really late change in customer requirements.

It seems almost trivial, but the mere fact we could see the state of all the stories on the board helped with:

1) WIP - before it was too easy to start working on something without finishing something else. There were several instances where we had a high WIP and some items could not be done by the end of the sprint. Being able to see status of the board pretty much stopped this overnight. Never quite understood why but the added visibility meant it was much more difficult to hide opening another story, allowing the team to form and keep an agreement on WIP.

2) Stand ups - we focus the stand up on the 'in play' stories, drilling into each one and organising the day around closing them. We often update the symbols to reflect what we agree to do for the day e.g. pausing a story so we can swarm on another one if we feel it is stuck and we won't incur waste in doing so.

3) Waste - the states of the story give clues to any waste that might be happening during development. If a story is paused - do we have a delay or hand-off? If a story is in play but seems to be stuck in a particular phase of development - maybe we have re-learning happening? If we have to play a paused story - maybe we should be looking for task switching? I can ask questions that help the team see waste and record it more accurately but the clue's start with status of the story.

We have also used padlocks to indicate if something should not be touched - happens occasionally if we are working on anything that needs approval by the organisation but we are slightly ahead of the curve and have already planned the item.

The key observation is that everyone 'gets' these symbols. They convey specific information quickly and easily with no training required. They drive team conversations and most importantly, the team has adopted them which is probably the best endorsement you can get.