Welcome everybody to this try-out session for XP Days Benelux 2010 in November.
Today we’re going to talk about, in our opinion, one of the most powerful pillars of agile software development. Continuous improvement. We all know the saying “If you’re not going forward, you’re going backward”. I think that sums it up nicely.
By establishing the mindset that an organization must strive for perfection, the insights and experiences of every employee in the organization can be used to improve customer value and reduce wasteful activities.
Besides the profitability of the company, I believe an equal strength is employee engagement. By making it easy for each individual to contribute to the company’s success, it leads directly to higher intrinsic motivation which on its part helps to grow self organization.
During this session we hope to provide you answers to these 3 questions: Why does continuous improvement matters? What are retrospectives How do you run them?
Let’s take a look at the agenda of today.
Since we’re talking about continuous improvement, we thought “hey, why don’t we apply it in this session as well?”.
You notice that under every chair there’s a set of post its and a pen. Please use these during the entire session to write down improvement suggestions.
If you notice something fishy that can be improved, please write it down. It doesn’t matter if you have no idea how to improve it. That’s where we will try to use the power of all the minds in this group. At 2 moments during the session, we will pause and hold a mini retrospective.
This is where your improvement suggestions get treated in detail, so that we can define actions on the spot, which we will apply during the remainder of the session and next presentations.
This picture gives you a summarized overview of what we’re going to do together in this session.
First we’re going to do a little starting exercise to get warmed up,
Then Nick is going to talk about 2wellknown forms of continuous improvement.
After that, we’ll do another exercise. Our goal is to get you to experience the power of retrospectives hands-on, and not only by theory. Exercise 2 will help us to get 2 know each other a bit better.
The next part is about the structure of a retrospective, how do you start, what is happening in the middle and what does closing a retrospective means?
Then the time has come to do our first mini retrospective. We hope at the time you will already have a lot of ideas written on your post its.
The next part is about the role of a facilitator. What qualities are we looking for? What does his job consists of?
We will also take the opposite approach, which anti-patterns can turn a retrospective into a dull no purpose meeting?
Then Laurens will offer you a retrospective cookbook
We continue with a second mini retrospective where we go in depth on remaining improvement suggestions or actions that need further exploration.
Finally we will end with an overview of useful, fun retrospective exercises that are applicable for specific situations.
Okay, if you already noticed things we can improve, you can start writing them down. If not, please do so any time during the session.
Let’s begin with a little warm-up exercise.
I have a hat full of little pieces of paper. Each one contains a simple question.
May I ask you to take a piece of paper out of the hat and read the question out loud, so we can all hear it.
Then answer it in maximum two sentences. Then you pass the hat on to your neighbor and we continue until everyone has had a turn. OK, we’ll go first! …
Thank you all for sharing! We will explain the purpose of this exercise later during the session.
We have 2 well known forms of practicing continuous improvement. Scheduled and triggered.
The difference lies in the initiation.
Some improvement sessions are planned at the end of a certain period where the team takes the time to look at what they have done and what we can improve.
Another way of doing it is by launchingon the spot improvements that are triggered by a malfunction, an indicator, an insight or something else.
Whether scheduled or triggered, it is important that you don’t blindly jump onto the first idea that pops up.
Or you might end up with this. Improvements need to be sustainable and not only focused on the short term solution.
Let’s take a look at how continuous improvement is applied in lean manufacturing and look how they handle these issues before we jump into software development.
This will give us a handy reference model of continuous improvement to keep in mind when we talk about retrospectives.
Let us take a look at one of the most known cases of lean manufacturing, the Toyota Production System.
As Jeffrey Liker explained it in his book ‘The Toyota Way’, it is based on these 4 high level principles:
Philosophy, Process (and more specific eliminating waste), People and Partners and Problem solving.
While each philosophy has its own value, they are all depending on each other and are each indispensable.
Today we are not going to focus on the well known leancharacteristics like single piece flow, kanban or visual management, today we focus on the top philosophy ‘Problem solving’ and more specific continuous improvement.
When Jeffrey Liker began exploring TPS, he started with being amazed by the power of single piece flow, then learned about the supporting tools such as quick changeovers, standardizing work, pull systems and error proofing.
But all along the way he heard experienced leaders at Toyota say that these tools were not key to TPS.
Instead it was Toyota’s commitment to continuously invest in their people and grow a mindset of continuous improvement.
There is always room for improvement and they have to realize that this is a never ending journey.
It was thanks to the teachings of W. Edwards Deming that the Japanese got encouraged to adopt a systematic approach to problem solving, later know as the Deming cycle or PlanDoCheckAct cycle of which I think you’re all familiar with.
The Japanese term for continuous improvement is Kaizen, which actually means “change for the better”, and is the process of making incremental improvements, no matter how small, and achieving the lean goal of eliminating all waste that adds cost without adding value.
An important aspect of kaizen is that the decisions are made by the workers in group consensus.
It relies on team work and self organization. Small groups that solve problems and improve processes on a daily basis.
The focus of kaizen on large changes as well as small incremental changes is different than what many western firms often do. They try to create breakthrough innovations but are weak on constantly improving in small amounts.
Important to know is that continuous improvement in lean is focused on removing waste, or muda.
If we look at our process through the customer’s eyes, which activities add value and which don’t?
Since kaizen deals with improvement we must know which aspects of business activities need to be improved most.
The answer you‘ll find in a lot of lean literature is Quality, Cost and Delivery.
The quality of finished products or services, the cost refers to the overall cost of designing, producing, selling and servicing. And delivering means delivering the requested volume in time.
These three activities bridge functional and departmental lines in an organization and therefore we need cross functional collaborations as well as supplier and dealer relationships.
Now in practice we see two different types of kaizen: large scale versus small scale.
Sometimes also referred to as Kaizen Events versus Gemba Kaizen.
A kaizen event is a focused, intense, short term project where a team consisting of roles from all layers of the organization try to improve a localized process. The event normally takes between 2 and 10 days and is planned.
Gemba kaizen is less dramatic and more subtle, it lies closer to the meaning of continuous improvement.
Gemba means ‘the real place’, the place where the real action occurs. For instance the factory floor or the hotel lobby.
It is the multitude of small enhancements on a continuous basis that form the engine of continuous improvement.
The success of gemba kaizen rests on 3 activities:
Housekeeping Muda elimination Standardization
Housekeeping or the five S’s stand for five Japanese words that constitute housekeeping.
I will not try to pronounce them, but the all start with an S. (seiri, seiton,seiso, seiketsu, and shitsuke). Translated in English this gives us Sort, Straighten, Shine, Standardize and Sustain. While it looks like this is just a matter of keeping a factory clean, it goes further than that. 5 S is a series of activities to eliminate errors, defects and injuries on the workplace. Sort your material and get rid of all the unnecessary pieces.
Straighten, give every item a fixed place and make it visual.
Shine, clean up and inspect for shortcomings.
Standardize, create standards to monitor and guard the previous 3 S’s.
Sustain, the discipline that is needed to maintain this in a process of continuous improvement. If we project this on a software development team, by keeping the team room clean,
We avoid being influenced by old information which may no longer be accurate
assure that every information we look at is still relevant
stimulate the use of visual aids, such as whiteboards and flipcharts
keep our stress level down
make it easier for stakeholders to get the data they need from the information radiators
Muda elimination, or waste elimination focuses on trying to reduce as many non-value adding activity.
For instance a worker who is walking a long way with a tool in his hand is not adding any value.
The value is created by using the tool to fix, maintain or set up a machine.
Muda elimination and good housekeeping go often hand in hand
Standardization is needed to have a reference to which continuous improvement can be applied. Standards get reviewed and updated daily.
These 3 activities are easy to understand and implement and do not require fancy technology or big investments.
Anybody can introduce these commonsense low cost activities. The difficult part is building the self discipline to maintain them.
There are 5 golden rules that apply to gemba kaizen:
Go to gemba first when a problem arisesYou cannot be sure you really understand the problem unless you go and see yourself. You cannot take anything for granted or rely on reports of others. This applies to all levels in the organization, from floor workers to CxO level. Check gembutsuWhich means check out the actual materials or products. For instance a broken machine or defected product.
Take temporary countermeasures that get the job going again, but don’t stop there,
Find the root cause by examining the problem on the spot and for instance applying the 5 why’s a root cause can be identified. Five why’s is asking why five times in a row to uncover the root cause.
Standardize to preventStandardization is not meant in the sense of finding the best way to do something and freezing it. It is impossible to improve any process until it is standardized. If the process is shifting from here to there, then any improvement will just cause another variation that is occasionally used and often ignored. When you have a stable process, it is easier to improve it.
Standardization is often the result of a big kaizen event that is planned due to root cause analysis during gemba kaizen.
Now this is a great example of Go to gemba
The gentleman on the far left sitting at a small desk right out in the open between the registration desk and the bank of elevators, where every one of the thousands of guests has to walk by him multiple times a day is the General Manager of the hotel. There's a large sign saying "General Manager" and he welcomes questions and concerns. He works at that desk all day, and if he has to leave his assistant general manager immediately steps in (and changes the sign to "Assistant General Manager"). Keep in mind this is a very large urban hotel with multiple restaurants and meeting rooms - it's a complex place to run. But if your business lives and dies by customer service, what better way to know what's going on and to immediately address concerns?
In software development we all know things like lessons learned meetings, or project post-mortems, which are planned moments in which a team looks at a period of time and discusses the issues they ran into.
The goal is to keep themselves from making these mistakes again in the next project.
With iterative or phased development becoming more popular, these lessons learned were held more frequently, after each phase or iteration. And with agile methodologies, the term retrospectives became well known.
In fact, whether or not it is the right approach, a project postmortem, a lessons-learned and a retrospective all contribute to the same thing, Continuous improvement. Just on a different scale.
Who of you is familiar with agile software development? And who knows what retrospectives are?
Let’s take a quick look at the iteration process of Scrum and see where a retrospective fits in.
Forgive me for going through this quickly, but our goal is not to explain Scrum here.
An iteration starts with the planning of a sprint backlog, which remaining items on our product backlog or most valuable to our stakeholders. How much can we as a team think we can do in the next sprint?
After planning and committing to this set of items and breaking them up in tasks, we start our delivery cycle.
Each day our team re-focuses by holding a 15 minute standup meeting in which they discuss progress, possible issues and layout their battle plan until the next standup.
This goes on every day until we reach the last day of our iteration when a demo is given to all stakeholders. They have the opportunity to see the new functionality integrated as working software in the system. Feedback is captured and re-prioritization of the product backlog can be a result of that.
After the demo, the team starts with a retrospective on the previous iteration. It’s this meeting we’re talking about here.
A scheduled moment which is dedicated to look at what we’ve done, how we’ve done it and if we can do it better. And by taking the time to do this, improving ourselves continuously so that we deliver more and more value to our customer.
Let’s do another exercise before we dive into the structure of a retrospective.
Ok, time to move on.
Let’s look at the structure of a retrospective. How do we start, what do we do and when do we end?
First we set the stage and then we gather information after which we try to gain insights. Then we define actions and close the retrospective.
Looks a lot like any other meeting, right? There are some important differences that are necessary to make it a success.
It’s important to start slowly, by setting the stage.
Not only the first time a team is holding a retrospective is it important to restate the goals of this meeting. Like every other meeting, it is held for a special reason, we want to look at our process as a team and use the brainpower of the group to improve ourselves in the future. We try to improve the way we work together, the things we use, the things we make, the interactions we have with the rest of the organization, improve quality, boost productivity, …
Make sure that everyone is reminded that the retrospective is a meeting in which everybody is free to share his views, without judgment or ridicule. Corporate hierarchies do not exist, every issue must be addressable. It helps to create a set of rules together that need to be respected during the retrospective. It is an intense meeting, in which we need full attention and commitment. For instance by agreeing to shut down our phones we can avoid unpleasant interruptions. You can repeat these rules briefly at the start of every retrospective to make sure they’re not forgotten. Sometimes it may be necessary to review these rules and update them.
If that’s clear and everyone agrees, try to get everyone relaxed and open them up to speak. You can use the check-in exercise we did in the beginning of this session where everyone just answered a random question. It breaks the ice and affirms that everyone’s participation is welcome and appreciated. It also opens up shy team members. If you’ve spoken once, you are more likely to speak again.
Another thing to do at the start is to explain the structure of the meeting. Explain the agenda and timing so people have something to hold on to. Structure helps to keep the meeting going, so that it doesn’t wonder off into thin air. If you’re working with a new team, people might not know each other very well and are not aware of each other’s different views and backgrounds. That’s why it is a good idea to do some exercises in the first retrospectives to create a mutual understanding. The exercise two truths and a lie can trigger a group to get to know each other better which makes it easier to understand each other and overcome their differences. As a last thing before jumping into the retrospective, you can try to build up the energy level by using data or artifacts that show the results of previous improvement actions. It’s very energizing to see that your effort made a difference and is acknowledged.
You already notice by the length of this slide that starting a retrospective takes some preparation and customization.
Although an iteration of a couple weeks might not seem a lot of time, people often have very different perspectives on this period.
Gathering data helps to create a shared picture of what happened. Not only for those who weren’t present during a part of the iteration, for everybody. We can do this by gathering facts, what happened at what time? Look for data, events, features we worked on, issues we ran into.
A common method is to draw a timeline and create post-its for all these things which we place on the corresponding moment on the timeline. The visual aspect is very important and acts as a guide during the rest of the retrospective. You can even try to capture the emotions that were experienced with each event on the timeline. For instance by giving them color codes. Green as happy, pink as sad, yellow as neutral.
Before we can start by searching for actions for improvement, we need to identify the problems areas with the highest priority.
In most cases, certainly at the start of a project, teams don’t have a problem with creating a list of improvement candidates. The list can get very long, so we need to commit to a set which is doable in a next iteration. Things like dot voting are a democratic way to prioritize your list and agree to subset. Then we need to get to the bottom of these improvement candidates. It’s easy to jump onto the first idea that is thrown into the group. The problem is that this often isn’t the best. Instead, we try to use the power of the group to come up with several ideas. Combined with root cause analysis or other exercises to get to the origin of the issue, a group can work out the best possible solution to an issue.
The work is not finished. Solutions might be on the table, but you will find that they are often not very concrete. In the end we need tangible actions. Actions to which we can assign owners and that can be planned into the next iteration. If we would skip this step, you will notice that things remain untouched and the issue would be brought up again in the next retrospective.
The same way a team commits to a sprint backlog, we need to be able to commit to the action points that are distilled in a retrospective.
Now what do we do with action points that aren’t hands-on, but are more like agreements, for instance: “try the pomodoro technique for the next iteration”. I found it very usefull to already agree on how and when we are going to evaluate this agreement. This will often lead to concrete actions for the next iteration.
Like any other meeting, we need to close the retrospective properly. We can go over the results one more time, just to make sure they’re all sticking in our brain. Then recap on the practical stuff: Who will capture the artifacts of the retrospective, who will make sure our action points get into the next planning meeting, etc. Why not do a retrospective on the retrospective, this way we can also improve that part of our process. And finally, end with a positive note and appreciation for the hard work.
It’s time to hold our 1st mini-retrospective.
What is our goal? Can someone give me a really brief summary? [action : write down goal]
First let’s look at what we‘re talking about. What is the period we evaluate and what happened? [action : create visual timeline on flipchart] [TODO : create speaker note with topics done] Now let’s use the trigger method to see what area’s you think we can improve.
The process is simple, someone who wants to share a post it, stands up and shares it with the group. You post it on the timeline and we discuss as a group.
Laurens and I will facilitate so we end up with a number of action points. If there are too many action points, we will use dot voting to select a workable set me and Laurens can implement during the remainder of the session. [action : trigger method] [action : dot voting if necessary]
The word facilitate comes from Latin and means: “to enable, to make easy”.
The facilitator role is very old. It existed even in ancient times when tribes stood around a fire.
Meeting facilitation started to appear as a formal process in the late 1960’s and early 1970’s. Since then it evolved from learning facilitators to task oriented group facilitation especially in industrial and information richsocietieswhere time is a key factor.
Their role is designed to help minimize wheel spinning and dysfunctional dynamics and to enable groups to work more efficiently together. He or she is content-neutral and takes no sides.
Now how can we define the role of a retrospective facilitator?
Basically, I believe it comes down to these 5 responsibilities. Trigger communication, asking questions when things are not clear, encourage open discussions. Keep energy level up. Guide the team through exercises. Record truthfully, visualize and write down objectively. Help the group to run the meeting themselves.
I once read a book where it was described as helping a group with participatory decision making.
The book is built around a model called 'the Diamond of Participatory Decision-Making'.
It visualizes a journey that teams take in many meetings, and I believe this is also the case in retrospectives. Let me go over it quickly.
We usually start a retrospective in the business as usual zone where the team comes up with obvious solutions to the problem. They refrain from taking risks or being ambitious.
A facilitator should pay attention to the quality and quantity of each person's participation. If not everyone supports the proposal, the facilitator can help the team to break out of the business as usual zone and move into the divergent zone.
In contrary to the business as usual zone, feelings are different in the divergent zone. People can be playful, curious and nervous. The facilitator has to help the team in expressing their divergent points of view by using brainstorming or go-arounds. He has to help each person to express their thoughts clearly by using mirroring or paraphrasing. Everyone should feel comfortable expressing their point of view.
Once the team has expressed all points of view, often conflicts come forward due to not understanding each other's perspectives. They have entered the groan zone. It feels uncomfortable and stressful. People don't see the light at the end of the tunnel anymore. The task of a facilitator is not to prevent teams from entering the groan zone, but to support people in their effort to understand each other's perspectives. He has to assure the team that by going through this painful stage, they will eventually be able solve the problem as a group. The team can start on working on a shared framework of understanding which will lead them to the convergent zone.
Now that everyone has a shared framework of understanding, discussions go smoother. Everyone gets the feeling that they are making progress again. People are enthusiastic and committed. The facilitator should let the team use their renewed energy to the fullest and get out of their way. Nonetheless he should guard that every proposal is one that covers everyone's interests.
Finally, a decision has to be made in the closure zone. The facilitator has to guide the team in making that decision. It has to be clear to everyone what the decision embodies and how it is supported by all. An agreement scale can help to poll the support of a decision.
You recognize the similarities with the structure of a retrospective? A good facilitator helps a team to navigate smoothly through this diamond model and reach group decisions that are sustainable.
I think it’s always fun to hear stories about failure, right?
I wouldn’t say I’m an expert on that matter, but I can assure you I’ve had my share. Although it may be painful or embarrassing to talk about it, each failurehas a great benefit. We learned something valuable, we got an insight.
Hey, who would have guessed that you can’t microwave an egg?
So let’s take a look at some cracks in the foundations of retrospectives.
An unstructured retrospective can lead to much discussing, no convergence, people who don’t understand the purpose. In other words a chaotic meeting. This can be avoided with a little preparation, not much, but a little. You should at least be able to write down the major parts of the retrospective on a white board.
Putting pressure on the team to get it over with as soon as possible. This often is the case when your facilitator is not convinced of the benefits of retrospectives.
He sees it at a waste of time and money and tries to cut as much corners as possible. The result will be a retrospective that has not used its full potential.
Issues will not be fully analyzed, action lists will contain random thoughts, etc.
For instance making jokes about people’s ideas. This is a dangerous anti-pattern.
To experience the full benefits of continuous improvement, each team member has to feel comfortable to share his thoughts and ideas.
Even more, we want to get people excited to bring up as many improvement ideas as possible.
Making jokes or dismissing someone ideas as irrelevant gives the opposite signal.
Instead, a mindset needs to be grown that every suggestion, no matter how little can contribute to the company success.
I’ve seen facilitators abuse their role by categorizing some people’s remarks as irrelevant. Instead of enabling, he is controlling the session, deciding which topic the group can discuss and which not.
Again this will give the wrong signal, that some people’s opinion is less valuable than others.
What happens when you bring up an idea in the group and the facilitator moves on to the next without giving it the time it deserves?
I would get frustrated.
It’s the facilitator’s task to record whatever topic the group brings up. His own interests must be put aside, otherwise he can’t be neutral.
He must facilitate the group in a way that each topic gets as much time spent as the others.
Because a team is a group of people with different roles in the organization, you will often find employee – boss relationships present in this meeting.
Some might try to abuse their corporate hierarchy to steer the meeting in a certain direction, or avoid issues they don’t want to invest in.
This will lead to frustrations and people shutting down.
Leading by example is still a very powerful concept.
By giving the good example as a facilitator you get people on board. Walk the talk. Join in on the exercises.
If you are an external facilitator, then this is a different situation. You can’t actively participate in most cases and can focus 100% on facilitating.
Just as daily standups and sprint planning meetings, retrospectives require effort.
Preparation and energy is required to organize this. And it is always tempting to skip one.
Most of us are lazy by nature. C’mon be honest. We tell ourselves that we will do a big one next time!
But, when you’re in the cycle of planned improvement sessions, skipping one can result in a month of improvement stagnation. Do you really want that?
Imagine this …
You’re in the middle of a retrospective exercise and Jefleaves the room. Ok you continue. Then suddenly a cell phone starts to ring and Jack starts talking to his wife. What do you do? Continue or wait until Jef returns and Jack stops calling?
All these things are distracting and reduce the success of the retrospective. In fact, they turn every kind of meeting into chaos.
Make sure that you agree on a set of rules, that are respected during the meeting and reviewed once in a while.
A lot of agile coaches warn that daily standups can turn into status reports very easily.
If the project leader plays a too controlling role, everyone will talk to him instead of each other. They will tell what HE wants to hear instead of figuring out how they can get through the work together.
The same applies to a retrospective. It can turn into a status report when for instance the project leader takes a controlling role, instead of a facilitating role.
It is easy to note actions for the team as a facilitator, but it’s not easy to make them tangible.
For instance an action point ‘Estimate in story points’ is more likely to have follow-up than an action point ‘Plan Better’.
‘Plan better’ is actually not even an action, it’s more likegoal, it doesn’t tell us what or how. Using the SMART acronym can help you to define better action points.
You know Specific, Measureable, Achievable, Relevant and Timeboxed
Continuous improvement will lead to a lot of improvement actions. And no doubt that some will fail.
Not everybody is keen on change and some will use these failures to criticize the value of continuous improvement.
You can easily counter this by showing the results of other improvement actions that did have a positive effect. Preferably from a company viewpoint. How did this little thing contribute to our entire value chain, what benefits does our customer get?
Yes, thank you Nick, especially for that last bit about anti-patterns. I think I’ve seen most of them in real life. In fact, I’d like to start by telling a true story about retrospectives gone wrong. Pay close attention because there’s a quiz afterwards. He who can identify which anti-patterns are present in the story will receive this gorgeous Scrum ball I’m holding in my hands.
As Esther Derby and Diana Larsen point out in their excellent book “Agile Retrospectives, Making Good Teams Great” [show image of book cover], an effective retrospective is structured as follows: Set the Stage;Gather Data;Generate Insights;Decide What to Do;Close the Retrospective. Nick has discussed this already, so I’ll dive right into a proven set of techniques for each step. This set can serve as your base recipe.
Set the Stage. Check-In: to help people put aside other concerns and focus on the retrospective, I use the check-in exercise. After welcoming the participants and reviewing the goal and agenda, I ask one brief question. Each person answers in round-robin fashion. The question I use most is: “what’s one thing that’s on your mind right now and what do you need to do to put it aside?” I ask participants to write this down and literally put it aside.
Gather Data. Timeline: [show image of timeline and explain part 1].
Generate Insights. Patterns & Shifts: [show image of timeline and explain part 2]. Capture insights using The Good, The Bad, and The Ugly: [show image of GBU and explain].
Decide What to Do. SMART Retrospective Planning Game: Team members work individually or in pairs to brainstorm all the tasks necessary to complete an experiment, improvement, or recommendation. After brainstorming, team members eliminate redundant tasks and fill in gaps. The task are arranged in order, and team members sign up for tasks they will complete.
Close the Retrospective. ROTI: [show image of ROTI and explain].
Adding variation and flavor to the base recipe keeps things fresh, and can help you avoid the anti-pattern of making your retrospective a status report. You know, a retrospective that follows the same agenda over and over again and thus gently rocks you to sleep. There are seven techniques I use on a regular basis keep retrospectives from going stale: Record Truthfully;Process Concurrently;Chickensoup For The Soul; Conclude Coalescently;Try Appreciative Inquiry;Analyze Recurrent Themes;Start Your Own Cookbook! Let’s discuss the seven techniques to show you what I’m talking about here…
Record Truthfully. Write down what they actually say, not what you think they say.
Process Concurrently. Work on solutions in small groups.
Chickensoup For The Soul. Include outsiders, a.k.a. chickens, not just pigs.
Conclude Coalescently. Make sure they reach conclusions.
Try Appreciative Inquiry. Look at what’s working well and how you can build on that.
Analyze Recurrent Themes. Challenge eternal recurrence: "All this has happened before, and all of it will happen again."
Start Your Own Cookbook! Get a Moleskine, start a tag in Evernote, whatever.
Using this base recipe and seven techniques to create variations on that recipe, you'll be able to fix and/or fire up your retrospectives when you get back to work on Monday. Now, let’s have a retrospective! Nick, back to you my friend…
Right, it’s time to do oursecond mini-retrospective.
First of all, are thereanynew improvement suggestions ? … Let’stry to categorizethemtogetherwith the existingones, sowecanprioritizethem. … Nowlet’sapplydot voting to prioritizethislist. Everybodycan place 4 dots on the topicshefindsmost important.
For the next part of ourexerciseweneed 7 topics. So let’stake the top 7 of ourlist.
Nowlet’sdivideintogroups of three. ....
I willgiveyoueach a ‘wasknijper’ thatyoucanhang on yourshirt or ear, or somewhereelseyouprefer. Just keepit visible please.
The exercisewe’regoing to do iscalledscramble. All the groups take one topican divideaccros the room.
After2 minutes I willask certain colors of wasknijpers to switch to groups in a certain direction. And wewillkeepdoingthiseveryothertwo minutes. This waywe all get to see all topics, but youget the opportunity to work out suggestions in small groups.
Pleaserecord anyideason the flipchart, sowecan go over eachtopicafter the scrambleexercises.
OK, each group cannowtake a topic an choose a place. Let’stry and keepitprettymuch a circle or square, sowhen I sayclockwise, it’s not toocomplicated. …
OK, it’stime to finishthis mini-retrospective. Can wego over eachtopic and seewhichideasweresuggested ? Group 1…
We have reached the last topic of this session.
I will explain some of my favorite retrospective exercises, which you can take home (or to work)and try out for yourself.
This image gives an overview of their place in the structure of a retrospective. You can use it as a reference later.
If you feel that your team is stuck in the same discussions over and over again, you might want to try brainwriting.
This technique has a bit of anonymity to it that often helps people to share their true feelings.
I often apply it like this. When you have distilled a number of improvement areas, write each one of them on an index card or large post it.
Then we hand over one to each team member. For 2 minutes everyone reflects and writes down his idea on the post it.
Then we each hand over the post it to our neighbor and do the same for the new post it, over and over again until we have seen each improvement idea.
You will be amazed by how many different ideas are written onto the post it at the end.
Different views lead to different opinions, which in group are not always discussed.
Then, one at a time, we go over the post-its, and discuss as a group.
This is an exercise I haven’t tried out myself, but which I certainly will use in the near future.
By giving people a chance to complain about their situation, they have a chance to say things that are normally not accepted.
This can reveal really interesting information which remained hidden before. Sometimes it just acts as a relief, expressing the bottled up feeling, and you feel more energized to move on. How do you facilitate this? It is a good exercise to do when you have an issue that is complex enough and where the group has clearly personal feelings about. Explain that everybody can write down 3 complaints on a piece of paper and throw it in a hat.
When everybody is finished, ask someone to randomly pull one out and read it out loud. Then ask for comments.
After the comments fade out, pull out another one and repeat the process.
Afterwards close by asking people to share how they experienced the exercise.
Each team member has the opportunity to stand in front of the team and has his 5 minutes of fame.
He can use that time to zoom in on a particular issue or something that came out of a previous exercise. When his 5 minutes are passed the team can start a discussion on that. Everyone has got the chance talk for 5 minutes non-stop on a topic that is most important to them.
Even the most shy team members will try to make the best of their 5 minutes.
It even doesn’t matter if it doesn’t last 5 minutes at all. If you don’t need them, you don’t use them.
We all know the classic exercise where we have two categories ‘what went well’, ‘what can we improve’.
Team members write ideas on post-its and place them in the appropriate category.
It is simple and during the first retrospectives generates a lot of improvement candidates.
Actions centered is a variation which uses a different perspective. The categories are slightly different and force us to think in a different way. What did we appreciate?What puzzles us? What are you wondering about? This can reveal stuff you never could imagine. What do you see as risks?What are your wishes? These categories are a lot bolder and I’ve experienced that it can help you to get to improvement ideas you would otherwise not discover. The square in the center is where you can put your actions in. Since I couldn’t come up with a creative name for this exercise, I just called it actions centered.
Fishbowls are used to help build mutual understanding among team members with different backgrounds or roles.
For a fixed time, one like-minded group sits together in a circle in the center of the room and talk among themselves while others listen in on the discussion.
When the time is up, the whole group continues for a short period with the discussion.
In this way like-minded participants have the opportunity to discuss a topic publicly without being interrupted or having to defend themselves.
In most cases the others will discover insights they wouldn’t have if it were an open discussion.
Continue by inviting another group of like-minded people to the circle and repeat the process.
Let’s use this exercise to do a little exercise to get 2 know each other a little better, so you’ll be able to experience it yourself. May I ask you to move 5 chairs in a cricle. ... Who wants to take place in the fishbowl? You all get one post it Try to come up with 2 truths about yourself and one lie, and the lie must be a bald-faced lie, for instance...
Now we move all others in a circle around it. Please take a seat, so we can get started.
Chech by raising hands in the fishbowl.
The gallery tour applies the concept of breakout groups.
It is useful when you have to facilitate a large group or you have a lot of topics to cover and want to do this in parallel. It goes like this: divide the group into breakout groups.
Give each groups flipcharts, markers and post-its and send them to a space of their own.
This could be the corners of a meeting room, or different small meeting rooms if you have that luxury.
Then have each breakout group work out their topic and record their findings on their flipcharts.
When time is up, return to the central meeting point and form tour groups. Each tour group contains one member from each breakout group.
Tell the group to take a 10 minute tour of each station.
When the tour group arrives to a new station, the person who was in that breakout group explains the recordings of that group.
Ok, that’s it!
We thank you for attending our session and helping us to make it better.
Can I ask you to show your general feeling about the session by writing a number between 1 and 4 on a post it and dropping it in the hat.
1 means disappointed 4 means enthusiastic.
Again thanks for having us, and if you want to discuss further, we’ll be here a little longer.
Fostering Continuous Improvement Through Retrospectives
Image by inajeep at http://www.flickr.com/photos/inajeep/6293310/
in which FORM?
Image by bcymet at http://www.flickr.com/photos/bcymet/3564484236/
Image by ciana13 at http://www.flickr.com/photos/ciana13/1987634535/
can lead to this:
LEAN manufacturing - TPS
Image: The Toyota Way - Jeffrey K. Liker
Image by lenaibojcdruz at http://www.flickr.com/photos/chaos/22725966/
WHICH business ACTIVITIES
need to be IMPROVED?
On the workfloor
Image by Mr Thinktank at http://www.flickr.com/photos/tahini/4048650596/
Image by ro_buk at http://www.flickr.com/photos/ro_buk/309023740/
GO to GEMBA first
STANDARDIZE to prevent
5 golden RULES
Workingat the Gemba
Image at http://www.evolvingexcellence.com/blog/2010/08/working-at-the-gemba.html
MORE FREQUENT with
Image by code_martial at http://www.flickr.com/photos/code_martial/4145914957/
Image by Sean Dreilinger at http://www.flickr.com/photos/seandreilinger/474738506/
Image by Jason Carter at http://www.flickr.com/photos/jcarter/1425422404/
Image by Thruthout.org at http://www.flickr.com/photos/truthout/4479979191/
Image by opacity at http://www.flickr.com/photos/opacity/3655692497/
Image by Dread Pirate Jeff at http://www.flickr.com/photos/justageek/2358182341/
Image by ubikwit.net at http://www.flickr.com/photos/ubikwit/368938106/
Image by bsabarnowl at http://www.flickr.com/photos/bsabarnowl/4935829383/
Image by Eleaf at http://www.flickr.com/photos/eleaf/2536358399/
Image by dresmall at http://www.flickr.com/photos/dresmall/149081654/
Image by DorlingKindersleyat http://www.dorlingkindersley-uk.co.uk/nf/Book/BookDisplay/0,,9780751351217,00.html
RETROSPECTIVES GONE WRONG
Image by NickiSymingtonat http://www.bigsaucer.com/i/reuben.jpg
• No structure
• Putting time pressure
• Dismissing remarks
• Flying over uninteresting topics
• Status report
• No concrete actions
• Referring to failure
DID YOU SPOT?
Image by PragmaticProgrammersat http://www.pragprog.com/images/covers/original/dlret.jpg
Set the Stage
DecideWhat to Do
Close the Retrospective
Image by ZsuzsannaKilianat http://westofpersia.files.wordpress.com/2010/04/ground-spices.jpg
Chickensoup For The Soul
Image by Dudeat http://www.dude.com
FOR THE SOUL
Image by Clark &Vizdosat http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/