Agile Banana

So you've ran a successful retrospective. Your team has generated lots of great ideas, and they've converged on a plan of action. What now?  How do we help our teams follow up on the actions and decisions they've reached in a retrospective? An agile / scrum process improvement log can help.  It looks like this:   The log should be saved in a space that is accessible to the team for reference such as confluence. However, discuss with your team before you make it more publicly available. It's important that teams feel that retrospectives are a safe space for honesty and to share grievances. Having an improvement log publicly available may make teams feel less comfortable raising issues if they know senior stakeholders have an eye on the issues being raised.  Having an improvement log is also useful for allowing the team to look back over all the issues that they've overcome, and reflect on whether past issues are still slowing things down. It's often appropriate f...

Do you have a list of things decided or agreed in previous retrospectives that still haven't been moved forward. It's easy in a sprint to focus on today's problems, and forget about what we said yesterday. I've certainly been guilty of this. Apart from keeping a retro log of all the actions that are decided in a retrospective, it can be useful once in a while to revisit things that have been discussed and agreed previously, but are still outstanding. This retro allows teams to reflect on the problems and decision that were made over the past few months, and decide whether they're still an issue - and if they are, what to do about it. Setup Draw a fire extinguisher, and surround it with empty sticky notes On another section of the board, draw a bucket and mop On sticky notes, write a short summary of decisions / actions agreed in previous retrospectives that are still outstanding. Stick these around the bucket and mop. Instructions Ask the team - "are there any ...

Staff turnover is a fact of life for all teams, including agile teams.  A departing team member can turn out to be a blow, or a blessing, or anything in between. What is certain is that it will cause some disruption.  The team may also need to go through a phase of re-forming and storming, as per Tuckman's stages of group development model . Whatever happens with team dynamics, in the short term we can plan for a team members departure by making sure that s/he doesn't leave a knowledge gap in the team. It's common for team members to become more expert in certain areas of the project or product that their team mates. Even if approaches such as pair programming can minimise this impact. For example, one team member may take on the responsibility of releasing code through the delivery pipeline. Even if this process is well documented there are often quirks that  an expert would do automatically without referring to documentation (or taking the time to document the quirk). S...

A common question for agile teams is this: "When, if ever, should we re-estimate user stories?" Mike Cohn has written on the topic of re-estimation , and largely comes down on the size of avoiding re-estimation in most circumstances. There is no fundamental rule about this in the Scrum Guide on Scrum.org. So, essentially - when this issue comes up with your agile team, it's worth a conversation. This exercise will help your team reflect on why and when they might want to re-estimate. In the exercise below, I put down a few preliminary thoughts in thought bubbles. I then asked the team what we should do when we realised mid-sprint that a user story was more complex than we'd originally estimated.  Why and when did the team think it would be appropriate to: Add a new story Change the estimate mid-sprint Take the hit, and just absorb the additional effort in the original estimate As a preliminary exercise, you could also ask your team to capture their thoughts on an eve...

This retrospective is a spin on the Well, Not so Well, New ideas retrospective outlined on funretrospectives.com   Instructions: Setup a board in quadrants  The first three quadrants are Happy, Sad, New Ideas The last quadrant asks your team to reflect on a particular issue that they've faced recently. This is particularly useful if you've noticed something recently that you think the team would benefit from exploring in more detail. In the example below, the team had recently experienced friction over whether it was right or not that every story seemed to be estimated as five story points. Ask everyone to capture their reflections on the last sprint on sticky notes and move them to the appropriate quadrants. You can then run a voting / filtering exercise to help focus discussion and decide on a way forward.

This is a quick maturity assessment exercise that can either be the sole focus of a retrospective, or as a quick exercise that is combined with another activity.  There are many different ways that a team can assess their "agile" maturity. In this example, I've used the twelve principles taken from the agile manifesto .  Instructions: Write out the twelve principles Create a scale so team members can capture how they think the team are doing. In the example I've used just three scale points "Never", "Sometime", and "Always". Give each team member a pen (or ask them to choose a colour) Ask each team member to mark on the scale how they think the team are doing against the twelve principles.

Sometimes we can just ask our teams "how did it go?" But often, we can elicit more discussion by providing a conceptual framework to help answer that question.  This retrospective idea covers the set the stage and gather the data stages of the agile retrospective framework. As an extension to the exercise below, ask your team to dot-vote on ideas for further discussion, and based on this identify next steps. Setup Create four columns. At the head of each drawn four weather symbols depicting "Sunshine", "Cloudy with sunny intervals", "Cloudy with showers" and "Dark and Stormy". Set the scene Ask your team members to think about the sprint that has just finished. Which of the weather symbols best represents their feelings about how the sprint went.  Ask everyone to write their name on a post-it note, and then add it to the appropriate column on the board. Once everyone has put down their post-it notes, ask everyone to say just a few sente...

Working on a project or product can feel like a slog. Like it or not, whatever we do to clear blockers and spice things up, scrum can feel like an uphill struggle. We finish one sprint, and start a new one, taking another slice of stories from the unrelenting product backlog. As Scrum Masters, it's part of our role to be unrelentingly positive and optimistic. To celebrate achievements and call out good practice.  So, in this retrospective idea I'm suggesting something a little different. The idea is not to identify a way to improve. Unlike most retrospectives, the purpose of this retro is a mood booster. It gives your teams an opportunity to reflect on what they enjoy, what's going well, and what they've already achieved. Setup Create a 4x4 grid containing the quadrant titles "Achievements", "Teamwork", "Compliments" and "Things I've learned" Around the grid, give everyone an individual table top with a pack of sticky notes Ru...

Sometimes we want to reflect on the broader picture. Where have we been, what challenges have we faced and overcome, and where are we going.  This retrospective works well for project / product milestones, or as an exercise for starting a new year. It looks back at a longer period of time than a single sprint, before looking forward to next year or iteration. It covers the gather ideas section of a retrospective. For more info, see the post on how to structure an agile retrospective . Legacy of the Past Ask the team to reflect on the biggest challenges they've faced over a given time period (for example, over the past 6 months, or over the past year) Ask each team member to capture their thoughts on sticky notes OPTIONAL: give the team a few themes to reflect such as customer input, teamwork, wider project and development process Hopes for the future Referring back to the legacy of the past, ask the team to reflect on their hopes for the future: where do we want to be in 6, or 12 m...

Have you ever been in a retro which has quickly descended into rambling conversation, or worse, a "whinge fest" where lots of grievances get aired but without a constructive way forward. Everyone leaves feeling like things are a bit rubbish, feeling better for having got it off their chest, but downtrodden that there doesn't seem to be a way forward.  We can help our agile teams generate actionable insight in retrospectives by providing structure to our retrospective that maximise the chances of teams being able to make positive changes to their working processes and practices.  The following framework for running a structured retrospective is outlined in the book Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen.  Set the stage Gather the data Generate ideas Decide what to do 1. Set the Stage (5 - 20 minutes) The first stage is about getting everyone into the right mental place to constructively reflect on the past sprint or iteration. If you...

If we were in a film... This is a starter exercise for an agile retrospective that will take 5 - 15 minutes depending on the size of your agile team. It's a great, fun, low-risk exercise for getting team members talking at the start of a retrospective. It brings out different perspectives on how the team feel about the project as a whole and builds a greater sense of team empathy and cohesion.  In the following example I used  Miro  which is a great collaboration tool for remote teams. Setup: Create a grid, with a space for each team member Give each team member two post-it notes (one to write the name of the film, the other to write a brief summary) Optional: give team members access to the board a few days in advance so they have time to think abut it Running the exercise: Ask everyone to write on their first post-it note the name of a film that most reminds them of what it has been like to work on the over the past sprint (or x number of sprint, or project as a whole)...

Ever read a great article about Scrum and thought, wouldn't it be great if my team did this. But then when you've suggested the idea, it was received with indifference, or worse, resistance? We've all been there. It's hard not feel confused or deflated about why others don't feel the same enthusiasm as you do about some of the great ideas you come across. Well, if you want to get a better result, this retrospective idea is for you. This retro follows the typical retrospective format as set out in  Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen . In the following example, the team were asked to read an article about Backlog Refinement in preparation for the Retrospective. However, the article and topic in question can be changed to suit the needs of your team. I've used Miro in this example below which is a great collaboration tool for remote teams. Setup 1. Circulate a link to the article you'd like your team to read. Set asid...

The following retrospective follows a simple format for helping teams reflect on any of the events or meetings that routinely take place during a sprint. The following example is used to help my team reflect on Backlog Refinement. This retro follows the typical retrospective format as set out in  Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen . Setup Draw some type of scale - could be as simple as a line drawn on a whiteboard. Team members will mark on the board how they feel about backlog refinement. Draw a box with two columns - one will be used to capture what the team think is currently good about backlog refinement, and the second will capture what the team think could be better Draw a box with two rows - one will be used to capture the top three improvements that the team want to see, the other will capture the steps that the team need to take to make those improvements a reality Get a wad of post it notes Set the stage Ask each member of the ...

Mood by Masterpiece This is a starter exercise for an agile retrospective that will take 5 - 15 minutes depending on the size of your agile team. It's a great, low-risk, abstract thinking exercise for getting team members talking at the start of a retrospective. It brings out different perspectives on how the team felt about the recent sprint, and builds a greater sense of empathy and understanding. In the following example I used  Miro  which is a great collaboration tool for remote teams. Setup: Select any six pieces of artwork Lay them out on a grid Give all team members a post-it note with their name on it Running the exercise: Ask everyone to drag their post-it note to the piece of art that best encapsulates how they feel about the sprint that has just finished. Once everyone has placed their post-its, ask each member of the team to say just a sentence or two - doesn't have to be anything profound - about why they've chosen the piece of art that they have. Outcome Asi...