Posts Tagged ‘retrospectives’

IMG_3317

Information radiators (IR) are used to help teams see information transparently so they can make fact based decisions about how they want to change.  But how do you know which information radiators to use with a team?  How do you know how many are needed and what to display?

The best way to use information radiators is in response to something you see or something the team is struggling with but needs a way to really understand what’s happening in order to grow.

In the story below a Scrum Master started using this version of a sprint (points) burn up so her team would have a visual representation of how they were actually working together during sprints as a basis for which to develop improvement experiments.

  • Symptom #1 they were consistently not finishing all of the work in the sprint
  • Symptom #2 they were starting a lot of work at one time in the beginning of the sprint but rushing to get work tested and accepted during the last two days of the sprint
  • Symptom #3 they were carrying over stories and said that it was okay because it gave the testers something to do while the developers were heads down during the first 8 days of the sprint – which indicated that they were actually doing mini-waterfalls.
  • Symptom #4 they were adding stories to the sprint after it started before the original work was complete weren’t finishing the new work brought into the sprint

During the first sprint review they analyzed the burn up and noticed that the green bars that represent points accepted did not show up until the last two days of the sprint.

  • They realized that starting a bunch of stories and working on them separately didn’t make them go any faster because it created a bottleneck in testing at the end of the sprint which left some stories unfinished.
  • They decided to pair up or swarm on work in order to open fewer stories at one time and get them tested and finished earlier in the sprint.

During the next sprint they paired on work and focused on finishing rather than starting work.  At the end of the sprint they analyzed the burn up again and noticed improvement, but not enough.

  • They realized that they were less successful completing larger stories because they took longer to develop which caused them to start testing too late in the sprint to finish.
  • They decided to break stories into smaller more manageable pieces of value so they could finished them quicker.

During the next few sprints they noticed that working with smaller stories helped them close stories faster.  By continuing to pair on stories and limit work in progress they found that they were able to more consistently deliver stories every few days during the sprint.

The team noticed that though they had begun to deliver at a more consistent rate they were still having problems finishing all of the work by the end of the sprint.  They analyzed the burn up in their next retrospective to see if they could gain any new insights.

  • They realized that they were actually finishing the number of points they originally forecast during sprint planning.
  • They recognized that during days 4-6 they finished 10 points of work but they also added 10 points.  They also recognized that every time they finished a story they seemed to add another which was contributing to why they had unfinished work at the end of the sprint.
  • They decided to work on breaking down their tasks better so multiple people could swarm on stories.
  • They also decided that instead of a developer bringing a new story into a sprint when there wasn’t development work on any of the stories the developer would cross over and help the testers with a story they hadn’t developed.
  • Lastly they decided that in the last 2 days of the sprint, if there were no stories they could assist on they would focus on some smaller technical debt clean up tasks rather than bringing in new stories they would not have time to finish.

Over the span of a quarter the team was able to effectively make improvements to their delivery and predictability by using this information radiator to help them visually inspect their work habits.  At the end of the quarter the team felt that acceptable improvements had been made and analyzing the burn up during retrospectives was no longer a value add so they abandoned that practice to focus on other improvement areas during retrospectives.

Advertisements

2015-12-03_13-22-04

(This post is by guest blogger, Kenny Barnes.)

For our latest retrospective, I created a jeopardy board using JeopardyLabs – Online Jeopardy Template.   I used a mix of Agile related categories (Scrum, Agile), items related to the team [Working Agreements, Sprint (more details below)] and something the team is really passionate about (Star Wars).  It took about an hour and a half to come up with the questions/answers and setup the board.

To play the game, the team drew numbers and broke up into two teams.  The teams then took turns picking a category and amount.  If the team picking didn’t know the answer, the other team had an opportunity to answer and take the points.  We ended with a final jeopardy question related to Star Wars that saw one team answer correctly for the win.

Now you might be asking yourself, well this is cool but how did you come up with an action plan or discuss any team issues?  Well the Sprint category took care of this.  The “answers” in this category had both teams, regardless of who selected it, come up with things that worked well, didn’t work well, wins to celebrate, etc.  Each team had two to three minutes to come up with the answer to these questions.  We then had each team give their answers and we discussed them.  The $400 selection was what do you want to try this next sprint.  We had a great discussion and came up with our action plan.

The team really enjoyed playing the game and the change of pace it offered.  They definitely want to do it again next quarter.

IMG_4457

This week I was walking past a conference room where a Scrum Master was preparing for the team’s retrospective.  I had to stop and take a picture because I really loved what I saw.  Here are a few of the things that really impressed me:

  1. The team’s improvement plan from the last retrospective is represented. This helps to solidify the value from the last retrospective’s suggested improvements.  By circling back around and discussing the team’s experience with the past action plan it helps the team to measure to see if the changes actually impacted their ability to become higher performing.  This also helps the team intentionally create ways to ensure that they act upon the plan they create because they re-evaluate how they implemented them and if the changes need to be adopted as part of the working agreement or if they were not valuable enough to continue.
  2. It is creative and fun.  You don’t need to be an artist to draw pictures for a retrospective.  In fact, I’ve found that scrum masters who can’t draw well but do it anyway have the most success!  Being willing to really put yourself out there when you know there’s an obvious lack of talent shows the team that you are willing to bring your full self in order to help them grow.  It helps to foster trust and relationship because you aren’t hiding your weaknesses from them.  The lack of drawing skill usually becomes a fun joke for the whole team as they try to identify what your pictures represent.  (In this retro the big joke was, “What in the world is the monkey doing?”  Answer= He’s pulling the elephant’s tail and frustrating him!)
  3. It uses the coaching skill of metaphor. This picture represents the teams experiences through the last sprint.  It helps the team to look at the sprint from multiple perspectives.  The perspective of positive things like things that specifically are helping us to do well and be better and things we want to celebrate.  It also helps the team get real about what’s frustrating them and what is really holding back their growth and progress in areas.  These perspectives take the team deeper than just what went well and what didn’t.

At an open space event the other day a group of people were pondering the topic “Getting people to be engaged during meetings.”  Inevitably the conversation turned to retrospectives.  People described how some teams complained about being forced to have retrospectives and how others went without complaint  but didn’t really participate.  Some of the frustrations were that introverts never want to participate and have fun conversations with their teammates.

In short, some scrum masters were describing ways that they have been trying to pull their teams into a place of participating but weren’t being successful.  Teams were feeling forced to do something they didn’t want to do and scrum masters were frustrated because no one wanted to play this very important game with them.

As I stepped back from the conversation I began to realize that what was missing was the understanding that there is an art to being able to facilitate an effective retrospective that starts long before the meeting.  The scrum masters role in the retrospectives isn’t simply to facilitate while people to talk about what went well, what didn’t go well, and what will we do to improve in the next sprint.  It is about creating new awareness.  It isn’t about pulling people into the conversation.  It’s about creating space for them to learn and grow and innovate in order to become higher performing.

This space doesn’t start in the retrospective.  It starts days, even weeks or sprints before the meeting.

As scrum masters, it is our job to cultivate vision.  It starts by stepping back every single day and seeing what the team doesn’t see.  How are they working together?  Do they really know what they are trying to become as a team?  What does high performing look like?  What are their goals as a team?  Where are they struggling and can’t see it for themselves?  What bad habits are they repeating?  What decisions are they making that are out of alignment with the agile values and principles, scrum values, and proven best practices? What’s the elephant in the room that everyone smells but no one will talk about?  What are they doing really well that they don’t even recognize?  What amazed you and made you proud?  Where do you see growth?  Where do you see them falling back?  What do they need to see?  What conflicts need to be resolved?  What isn’t being said?

It is our job to see the big picture over time and not just the little pieces of each sprint.  Planning retrospectives is about strategy, not just tactics.  It isn’t good enough to have a book full of retrospectives and blindly pick one just to mix it up each sprint.  The purpose of changing retrospective methods isn’t so the team doesn’t get bored.  We must pick the right tactic to bring the right result at the right time.  It’s up to us to remember what they said success would look like five sprints ago and bring it back around for them to see if they are getting closer to their goal.

Choosing the right retrospective format includes processing this information and crafting a retrospective that will create space for them to see what they can’t see.  It creates an atmosphere of safety where people feel comfortable with who they are so they can communicate with their team.  This means that we have to understand who they are, how they learn, and how they communicate.

Are they analytical and need more concrete types of questions? Are they visual and need to envision the questions and problems they are trying to solve? Are they auditory and need to talk through things with others to gain perspective and revelation? Do they speak in pictures, tell stories, or have a creative nature where things like props, play dough, and pictures will help them?  Are they introspective and need space to think before speaking?  Do they think through problems while talking?  How do they face conflict?  What motivates them?  Where are their passions?  Are they extroverted and get energized through interaction?  Are they introverted and get worn out through interaction?

These are things that the scrum master has to understand about the people if they want to foster engagement and growth.  Every team is different.  A style of retrospective that works for one group may not work for another.  There is an art to creating space and safety for people to gain new awareness and growth.  Successful retrospectives aren’t measured by how much participation and fun you are able to muster up but in how much actual growth the team gains through the activity.  Taking the time to really see your team and understand what they need to experience in a retrospective is the first step.

Earlier this week I attended a retrospective with team I am coaching and watched as a growing scrum master stood up and started the retrospective saying, “Ok guys, I’m going to step completely out of my comfort zone again today.   You didn’t like the activity that we started the retrospective with last time so I’m not going to make you do that again.  Instead, I came up with something else that I hope you will like a little bit better…”

What he did was really cool and very simple.  He asked his team to take a post it note and write down 1-3 words that described how this sprint was different than the previous sprint.  He collected the notes and put them up on the white board in the form of a circle.  The team briefly discussed the items and this allowed both the team and the scrum master to get a feel for their overall perception of the success of the sprint and if the team was moving in a positive or negative direction as far as overall improvement.  This opening “set the stage” activity broke the ice perfectly and gave him a wonderful springboard into his “gather data” activity – which he did with genius style!

Kyle Duke, who has incredible raw talent to be a great scrum master, proceeded to use the 4L activity (Liked, Learned, Lacked, and Longed For) to draw information and conversation from his team.  I sat on the sidelines astonished as I watched him introduce this in a way that I had never seen before and almost died laughing.  He was amazing.  When he transitioned into this activity, Kyle said, “Ok, team help me out … what are our quadrants?”  He drew four quadrants on the board and proceeded to get the team to “help” him label them.  Since they had only used this method once before no one knew the labels.  It was hilarious to watch Kyle guide them letter by letter into each square until they guessed the labels.

I saw Kyle do other really amazing things like ask for permission from his team to combine post it notes together when he thought that they meant the same thing – instead of just assuming that he could make the decision for the team.  When he wanted to make a clarification on what someone wrote on a post it, he asked, “Do you mind if I write that on here?”  These actions provided a place of safety for his team and also create an environment where the team knows that the scrum master is not a manager of the team, but a member of the team.

I was really proud.  Kyle did a great job.  His team felt safe.  They opened up and talked about the stuff that really mattered and they had a great time.  I love seeing scrum masters coming into their own and really having the courage to do things that are outside of their comfort zone in order to help their teams succeed.  This is true servant leadership in action.  This is scrum.  This is why I love being an agile coach!