Agile Banana

Chapter Three: Teams A good team can outperform a bad team by a ratio of 2000:1. They do it by being transcendent, autonomous and cross functional. Quick Summary The best teams have three key characteristics: transcendent, autonomous and cross functional Organisations should focus on improving team performance rather than individual performance, it has much more impact Once teams grow larger than eight they take dramatically longer to get things done Main Points Talented individuals outpace their peers by a ratio of 10:1. But the fastest teams outpace slow teams by a ratio of 2000:1. So there is a much larger difference in team performance than there is in individual performance. Furthermore, when a team grows larger than eight, its performance dramatically decreases . Groups made of three to seven people require about 25 per cent of the effort of groups of nine or twenty to get the same amount of work done. The brain can't keep track of what everyone is doing, so we slow down as w...

Chapter Two: The Origins of Scrum The Scrum development process draws on the findings of a 1986 Harvard Business Review paper, which looked at how product development teams worked in some of the most high performing companies Quick Summary Great teams are cross-functional, autonomous, empowered with a transcendent purpose Look outward for answers - complex adaptive systems learn from their environment Follow the principle of Shu Ha Ri - learn the forms and rules, then introduce innovations, before living the forms and rules effortlessly Main Points The Scrum development process emerged from the findings of a 1986 Harvard Business Review paper. The paper concluded that the traditional waterfall approach to product development was fundamentally flawed. Instead, the world’s most productive and innovative companies had teams that were cross-functional. The teams also had autonomy to make their decisions, and shared a transcendent purpose bigger than themselves. Managers were servant leader...

Chapter One: The Way the World Works is Broken Traditional management approaches have repeatedly failed to deliver big technology projects. Scrum is proven to help such projects deliver more stuff with higher quality at lower cost with fewer people and in less time. Quick Summary Planning is useful, but plans fall apart so assume you'll need to be flexible You're toast if your organisation doesn't change its traditional "command and control" management Fail fast and learn from mistakes - get user feedback early so you can immediately eliminate any wasted effort Main Points The world is constantly getting more complicated, and the work we do along with it. Whenever people are involved in a complex, creative effort traditional management methods break apart. Scrum brings teams together to create great things. That involves everyone understanding the end goal, and delivering incrementally towards that goal. Too much of life is wasted on work that you and your boss re...

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.

Here is a poster I produced using Miro and an infographic on canva.  It is used as a way to advertise in an organisation how a team retrospective can help teams act on good ideas.

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.

Give everyone a sticky note and ask them to write their name on it. Ask "Which emoticon best represents how you feel about the last sprint?" Once every has placed their sticky note, ask everyone to say a few sentences explaining their choice.  This is a nice starter exercise that gets everyone talking and reflecting on the recent experience. It sets the teams up nicely to move into the main part of the retro session. See the retro lounge for more ideas. 

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)...