Using extremes to help teams

This is technique I have been using for a while and has a wide range of applications. If you are familiar with affinity mapping, then this takes that and expands it for use in several different areas.

Let's start off with a simple application....

Story sizes have not been working for me for a while. I love the conversations which often uncovered something we had forgotten or someone knew that nobody else did. Unfortunately differing sizes were often a catalyst for these conversations.

In my previous blog about super fast sizing, we used a different way of sizing that I think gets you the best of both worlds.

How I use this in refinement is knowing where to put more effort. 5 days or less needs no more intervention. The team I work with now even have something called a 'fast track', which is 1 day turn around which they do not refine since it would cost more to talk about than do.

More than 2 sprints means we need to spend some time looking at how we could break it down. The ones in the middle we also try to break down but can also accept the increase in risk if we want to.

Asking these questions and gauging the response from the team allows you to invite conversations as a facilitator and help the team explore the scope of the story.

You can also use this for long term estimates. When I was asked about how long a piece of work could take I used extremes to give some idea - "4 months is too pessimistic but 2 months feels to optimistic but it will be somewhere between the two. With progress on this bit of work I would expect this come in as we know more, which I can update you on as we progress". This was just enough to allow our stakeholder to plan.

I often use fist of five voting to get people's feedback on ceremonies. This again uses extremes and you can be playful to make it more fun e.g. ".... where no fingers is 'please, please never ever do this to me again' and 5 fingers is 'this is sooo cool, I think I might get in early just so we can sneak another one in before work'"

Recently, I have used extremes to challenge the status quo. When looking at staff retention, we can honestly ask what would happen if nobody left - is that ideal? This extreme stance makes us realise that the extreme is not ideal either so we can start to ask questions about what is the ideal. In terms of staff retention, we can be realistic about what to expect using the extremes to guide that thought process.

My favourite comes in exploring ideas. We had an example where we were talking about testing strategies and testing environments. We used an extreme to explore some new thinking rather than just what we had.

In this extreme, we asked what our testing strategy look like if we only had our production environment and our local development environments - no dev or integration environments. We explored what branching and releases might look like, what testing we could do and where and the risks we would face.

It's deceptively simple and you have probably be using it without realising in some areas, enjoy!

Retrospective: Health Check Retro

Across the organisation I work with, we do a quarterly health check which is very much stolen from the excellent work Spotify did way back in 2014.

One of the problems our community of practice brought up was follow up by the teams themselves. We did this which gave the organisation this fantastic view of how we feel about the teams we work in but the teams never used the same information to improve. Odd right?

I was guilty of this and so I decided to have a retro to focus on improvements the team wanted to make before the next health check.

The setup for this retro was to get the team to vote on the areas which they wanted to see the most improvement in. This was a really quick dot voting exercise at the end of a stand up.

In the retro itself, these are the focus areas. We kick off by asking the team to list the problems they see in each of these areas. I like time boxes and gave them a whopping 7 minutes to pull these thoughts out into a flurry of post its.

I now pick on someone in the team to group the post it so we can see some themes. This is often the person who has used their phone the most or failing that a BA (since they usually have a knack for seeing some groups).

Next, we focus on just a few problem areas by dot voting. Getting them to list the problems means I can now complete the setup and ask them to find solutions for the problems we came up with, again giving them an aggressive time box to work to.

We now go through everything we have come up with, clarifying anything that is abstract (there are always a few) and asking some questions to get people thinking about what they are trying to solve:

How does this help solve the problem?
How is this related to the problem?
If you did this, what do you hope to fix?
Will this fix the whole problem?
What else might be have to do to fix the problem?

This bit is to clarify what everyone has come up with, which is important since we are going to ask people to own these.

The last part of this is the ask people to come up and choose 2 solutions. One that they put into practice this iteration and another one which is longer term. If people look like they lack enthusiasm, point out that the first people get to cherry pick the best things.... that usually helps.

They each read out what they chose for this iteration and talk about what they intend to do. We can keep on top of these in stand ups, asking what help we need to give to keep up the momentum.

Their homework is to think about how they will bring their other longer term task into action and what help they will need, which we will discuss in the next retro.

Retrospective: Protest!

This is my new favourite retrospective.

Emotive and simple, it encourages members of the team to voice their concerns and create a protest.

Literally.

The format is very simple. Use the PowerPoint deck to show some examples of signs from protest and then get each member of the team to come up with a protest of their own along with a sign that would explain it.

I have been curating signs from protests for a while on Pinterest. I would give the link but they contain a wide range of swearing so it does not feel 'cool' to include the link here. Contact me if you want me to share the board privately.

You can then talk about each person's 'movement':

• What's the cause?
• Who is the audience?
• Who are your followers?
• What's your ideal solution?

This is more of a way to get the team to open up about issues they feel strongly about. These might not have been addressed so this gives a direct way of the team telling you what their cause is - without having to start a real protest!

View the Protest PowerPoint

Remembering past last week

We know from experience that people often have very short memories when they participate in a retro.

It is no surprise that we only usually get the problems from the end of the sprint since this is often where the pressure is. Any good things are usually drowned out by the tide of problems we discovered yesterday.

So imagine my delight at taking people back over 6 months. And not just one team - a whole bunch of teams all working on the 'Consents' programme of work which basically made our company GDPR compliant.

So here is the method I used, which worked nicely and created some good conversations and insights for the people who participated.

We first set a homework task. This is essentially the ice breaker but served a purpose too. The team were asked to bring a picture that represented the project at the beginning and one that represented the project now.

The idea is to get people to think back to the beginning. I was conscious that different people got involved at different times and that is fine. We just wanted them to take the time to think back right to the beginning to break the cycle of only remembering the last things.

I drew a timeline which represented the project from beginning to end and got people to show the pictures they chose and explain why e.g.

A picture of the lone ranger herding some cats was because that person really didn't know how to go about this project at the start, they chose a cover of George Orwell's '1984' to explain that during the project he became much more data security aware and by the end it was something he was seeking out since he was interested in it.

We heard several stories which started with this very simple beginning and end. You don't need everyone to do this (they won't) but a couple set the scene. This is usually funny and often thought provoking - I have used this as the basis for a team retro too.

Next we add some points on the timeline to give some scale. For us, we added some key sale periods  and Christmas. It will always be terribly inaccurate, you just need enough to make sense of the timescale as a whole.

With about 20 people in the room, you will generate a LOT of data. The trick is to find a way of bringing out trends. Grouping will take too long so I use a colour key and an additional dimension to allow the group to talk about what happened.

With this group, we gave them different coloured post-its depending on their role in the project, there were 4 in total. The dimension we added was good/bad - if the thing they are remembering was good then place it above the timeline, the opposite for bad. The further it is away from the timeline, the more pronounced that is.

I then gave the group 7 minutes to go post-it crazy and place these insights on the timeline. I can be messy and little loud but it's only for 7 minutes!

Once finished we asked them to look at what they had created:

Next, we ask them to look for some trends:

* On balance, which group of people had the most insights? Who had the least?
* On balance, was this a positive experience or a negative one?
* Was there a specific part of the project where something was wrong? What happened?
* Which part of the project was busiest and why?
* What happened here? (point to a cluster or peak)
* Was this the best thing that happened? (point to top post it) Why?
* Was this this the worst thing that happened? (point to bottom post it) Why?

For the most prominent groups, we asked them to tell their story from beginning to end. This is often lead by and individual but they speak for a group since people tend to work together to remember what happened.

People add insights from their own perspective as each of these is told. Over half the session is just this. As a facilitator, you can ask open questions and maybe pull in individuals who aren't speaking or look like they want to but cannot break into the dialog.

At this point we collecting data, sharing perspectives. I usually ask for the high and low point from each of the story tellers, which can break them out of concentrating on a single time period. You can pull out specific cards from the wall if there are interesting ones but the purpose is not to use that data - it is just a vehicle to get people to think across the whole timeline and highlight areas that might be interesting to talk about.

To close, we want some canned insight that we can learn from. To do this I pose the question:

If you were on another project and you were working with some new people, what advice would you give them? If you could hand them a piece of paper that would help them, what would it say? What mistakes would you want people to steer clear of and what inspiration could you give based on what we have found out today?

The output is a single statement from each person. We grouped these into themes that allowed us to see where there was consensus in their experience even though their involvement and roles in the programme were completely different. As people left, we asked them to vote for their favourites and encouraged them to use this insight to improve the next programme they were involved in. We share the favourites with the more senior management and try to steer the structure of work at a higher level based on this feedback, hopefully improving each one as we go.

All worship Board God

The use of boards by teams is nothing new, every team I work with has some way of visualising their work. Many teams seem to stall at changing the board, leaving ownership to some individual (maybe the ScrumMaster or the most vocal member of the group).

This is a shame. Since the board mirrors the teams process, which is owned by the team.

I was in a situation where the board was being dictated by a single person and the team looked too scared to change it. People would compain about the board by not try to do anything about it.

In a moment of frustration, I thought "Fine, you fix it".

Enter the 'Board God'.

If anyone ventures a strong opinion on the board you can appoint them as 'Board God' for a week.

The Board God can do anything to the board they like and the team have to follow their direction for that week. At the end of the week, the team decides what they will keep and what they will reject. Stripped of his or her powers the Board God must accept their decision.

If I hear someone grumbling about something on the board, I usually appoint them 'Board God' to see how they will solve the problem they are grumbling about. Eventually, people will start to ask if they can be 'Board God' to address a specific issue that they can see.

This can trigger a spate of change, where different 'Board God's' mess with each others changes. This is a positive thing since people are getting involved with the board and ultimately the process itself.

Teams that have learned to embrace changing the board often evolve their process outside of the retrospective, shortening feedback to days or even hours.

When used in conjunction with scoring stand-ups, a team can inspect and adapt quickly. I have seen stand ups of 20+ people go from train wreck to useful in under a week using peer feedback. A score of 3 or under means you have to share what was wrong for you and the team agree corrective actions for the next day there and then.

'Board Gods' provide a solution to a problem that is then inspected by the team. The process adapts to the use the good bits and things that do not work are discarded in a safe to fail way. One team I worked with even versioned their board to help them understand when a lasting change was implemented.

This idea started as a punishment but has turned out to be a useful tool to remind teams who owns the process and encourage them to get involved in shaping it.

Bulk Estimation at Speed

So, today I faced a new problem. The forecasting I have been using for a while has been throwing out some dates that 'feel' very pessimistic. I want to trust them but they look wrong so I find myself with a dilemma of how to test the forecast in a sensible way.

A previous observation was that whilst asking people how big something is gives a wide range of results whilst asking them if something can be done in a set amount of time is easier to answer and is just as easy to use and interpret as a number.

So given I have a backlog of about 50 things I need to test, I welded these 2 things together and came up with the following session that I ran with my own team.

The only prep you need to do for this is to prepare 2 question cards. The first question is based on the ideal time it should take to do a story. At time of writing, my team want every story to be 5 days or less. So the first question card would be "Will it take 5 days or less?". The second question card, is the opposite extreme of that. So for us, it has gone terribly wrong if it will take 2 or more sprints which is what we have on the second card.

There should be a gap between these which is your middle ground. The observant among you will realise these options look like T-Shirt sizes - which they are! We don't ask that question - we ask is it bigger than X or larger than Y giving a wide difference. If it neither then it must be in the middle ground.

So here's how we ran the session:
Print out your backlog with title and maybe a narrative (as a... I want... so that)
Stack them in the same order as your backlog, highest priority first
Grab a selection of developers and include some QA

Put the question cards and middle ground card on the table

For each card and ask the questions

Expect discussion but keep it short:

* Encourage listing assumptions if that would make it easier to answer, document these if you can

* Re-iterate the ranges using days ("So if you started on Monday, it would be finished by Friday")

* Use comparisons ("Remember that piece of work on X that took 2 sprints, is it as difficult as that?")

* Watch out for unknowns which drive up estimates, mark these for later investigation/refinement

* Use timeboxing if you think it makes sense

Stack the card on the relevant answer card

Scoring a story whilst telling the story

I was quite surprised as how fast my team did this - 52 stories in 1hr. We can then visualise the backlog in order and colour code the cards to show us the sizes from the team. You would expect first stories to be all green and then progressively turn orange then red as we head further way from the top of the backlog.

That's not what we found. 

We found a mix across the backlog that we needed to verify. We discovered that this showed what the team did not have a good understanding of, allowing us to focus our time on refining the cards that were big because we were scared or confused by them.

As far as validating the forecasting, we could now model a series of sprints based on how long they might take which looks a little like a gant chart but is throw away so I will allow it. More importantly it allowed us to see how we might reduce some of the risk in our delivery but tackling the unknowns upfront and ensuring we only develop the smallest stories we can, which are far more predictable.

More importantly, the team found this useful as a confirmation of what we would be doing and in what order allowing them to spot things that had been overlooked. They did this by telling a story of what the system would look like as they developed each story. 

They checked the system by also finding places where a demo would make sense and the system would provide end to end functionality that could be seen and understood by stakeholders. We found having a system diagram very useful in this as the developers can point to what they are talking about and everyone understands the context.

They even asked if they could do it again, which is surely the sign of good times :)

Experiments with Emergent Leadership

My self and a colleague recently attended Tobias Mayer's Emergent Agile Leadership workshop. Part of the corporate sponsorship deal we have at my current place is that when you come back you share your notes or what you learned.

I added the acceptance criteria that whatever we did should be something interactive with the community we have, since I think note taking is subjective and nobody really understands the context. That and I hate writing notes - I am terrible at multitasking!

Then we went on the course and realised what an enormous challenge we had set ourselves. Tobias guided us through 2 days of very thought provoking discussion, mixed with some games and interactive exercises. At the end, he left us with this closer:

What is your intent on leaving here? This workshop has supplied no formula, no model, no process.

The workshop was a journey of discovery. Not something that you can shrink wrap. It was something that you can only experience. Leaving us with a lot of head scratching to do - how do we introduce some of these ideas to our community? How do we get 2 days worth of thinking into an hour?!

We started to think about how we could re-create elements of this. We wanted to create a little discomfort and we wanted people to engage in deep discussion, which was something we realised we did very little of but got a lot out of.

I also wanted a bit of quirk! So, here is what we did.

We came up with a game. In separate teams they all had to cross a river (one side of the room to the other) using only the stepping stones (a3 pieces of paper). The goal is to get everyone across, racing the other teams. There are rules but they have to uncover them. A judge will let them know when they have broken a rule - the whole team has to start over if that happens.

"Maybe, we all need to be on a stone at the same time?"

The judges are told the rules away from the group. There's actually only one - don't let them all cross! Essentially, they randomly get the team to start again. I know it's cruel.

This is to cause the team to communicate and experiment. We suspected people would jump forward into a leadership role and some would follow. We also wondered if the leadership role would be with a single person or would move through the group as they fail miserably to complete the task. Would leaders step back when others stepped forward? Would the leader help at all?

At the end of the game we asked everyone to point to who they thought was the leader. We then separated the leaders and asked them:

Were you aware you were the leader?
Why do you think people saw you as the leader?
Were you trying to lead?

The others, we separated into groups and asked them these questions:

Why did you see them as the leader?
Did you choose them or did they step forward?
Was there more than one leader? How did they share?

We then explored some of the themes from the groups. We noticed that in some groups there was no dominant leader - so it was emergent and moved around. This allowed us to explore leadership as an energy that anybody can bring on demand. We also talked about how participation is a central part of being a good citizen.

We then re-created a discussion session from the workshop, using Tobias' own content so they had the opportunity to explore and think about a specific theme. We finished up with asking the community how they would like to proceed and if they would like to explore some of the ideas a little more deeply.

Although this cannot replace the workshop we went on, we think it did get people thinking a little differently about leadership in their own teams. Many thanks to Tobias for helping us 'see it' a little more clearly.

Retrospective: The End

People leave. Occasionally, this will be the SM. This retro is dealing with the handover to the next SM and acting as a exit interview for the SM.

The goal behind this is to give the new SM insight into how the team regard their process, what they need help with and most importantly what they want to keep. This was to give my new SM a good idea of what the teams buttons where so he would get off to a flying start with the team.

It also helped me see some improvements that I could carry with me to my next team. Some I knew about some I needed to acknowledge. SM's, like teams aim to continuously improve.

The icebreaker I used was a simple game where I wrote up some numbers and asked the team what they thought they correlated to. I went back to when this team formed and found totals for: Number of Sprints, Total number of stories, Total number of points, Longest Lead time and average velocity.

Then we did a happiness radar to give the overview of what the team think about 3 areas:

• People - the people they work with both in and out of the team
• Technology - the kit they work with on their local, development and integration environments
• Process - the way they work

I gave my team 2 votes each and they created this:

Thinking like my new SM, I would be thinking "Hmm, I wonder what's up with the technology?" and maybe "So, observe for a while since these guys think everything is working just fine".

The last section was just a post it session around some key questions:

• What should the SM leave alone?
• Is there something the new SM should look into straight away?
• What are our strengths?
• What does Richard do that our new SM should do too?

As usual, it's the little things that made me chuckle - biscuits, always a favorite:

When the SM arrived I went through what the team had said and gave them a rough history of the team so he had some context. Not only did I find this process quite therapeutic, I think it helped the team know that the next SM would help them continue on their chosen path rather than make them take a different route.

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?

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!