Tag Archives: retrospective

How to facilitate a lightweight project retrospective

Posted on by

room-setupLarge group retrospectives are long, large, unwieldy facilitations. So much so that they’re typically done only at the end of a project. Holding a 1-2 day retro every few weeks for a large project is neither practical nor responsible, but continually improving the project is also important.  So, how do you hold light-weight retrospectives for large groups, while making sure that you:

  • Have a common understanding
  • Identify issues and strengths
  • Reach a group agreement on action points
  • Ensure that the group feels that they received a high return on time invested

This retrospective combines different techniques and technologies to achieve these results. read more »

Constellation retrospective

Posted on by

constellationThis is a strong retrospective for bringing issues up to the surface. Instead of just one person expressing an issue as a positive or a negative, the whole team feedbacks about the importance of the issue. The team then decides which issues to tackle. The retrospective also exposes issues where there is not common view, and highlights areas of alignment. It also allows the team to ask tough questions in a safe environment. read more »

Slides från session Agila Arbetsmetoder @ SAST Q20

Posted on by and


Otroligt kul att se hur många som fick plats i ett konceptrum i Aula Magna under våra presentationer under SAST Q20! Vi pratade först om kontinuerlig förbättring och sedan om working agreements. Slides hittar du nedan.

På Crisp har vi en hel del gratis material och guider, bland annat en Toyota Kata mall, som Martin nämnde under sin presentation.

Vi pratade också om Mobprogrammering, och den främsta källan till information finns på mobprogramming.com.

Tack till er alla som kom och lyssnade och vi ber om ursäkt för att alla inte fick plats.

/Martin & Mikael


Facilitating from the Back of the Room at Spotify

Posted on by and

Last week Jimmy Janlén and I held a shortened version of our course Training from the Back of the Room for our former colleagues at Spotify. Actually it is not “our” course, but Sharon Bowmans. It’s based on her books about how create a more engaging learning experience in the class room, especially when training adults.

“I really liked the whole setup of this course – a really well organised and inspiring day. Wow :-)”

Jimmy and I are certified trainers of this course. We use the techniques when we do training. But we have also experienced how useful they are in other coaching and facilitation situations, such as workshops and retrospectives. Almost any meeting can be made more engaging and with longer lasting result with the set of tools TBR provides.

We have chosen to call the shortened training Facilitating from the Back of the Room, since that is what we agile coaches do most. 16 persons from the Spotify Agile Guild showed up this beautiful day in a corner room on the 17:th floor in High Tech building with amazing views over Stockholm city. We have to admit we were a little nervous at first. Would this actually make sense to coaches? It did.

read more »

Team barometer (self-evaluation tool)

Posted on by

Sometimes it’s hard for a team to know if they get tighter and better as a team over time. This is a tool that allows a team to learn just that.

Team barometer (self-evaluation tool) in a nutshell

The barometer is executed as a survey in a workshop. The survey consists of 16 team characteristics, packaged as a deck of cards. Team members vote green, yellow or red for each card in the meeting (or before the meeting as an anonymous survey). Once all cards have been run through, the team reflects and discusses the results. You can, if you want to, run through the exercise in thirty minutes, but I recommend to set aside an hour.

Click here to download the cards.
read more »

Ett upplägg för en heldags affärsplanering

Posted on by

Nyligen så hjälpte jag till med att planera och facilitera en affärsplanering hos en kund. Då jag tycker både utfallet och genomförandet var väldigt bra så kommer här en beskrivning av vad vi gjorde och de olika övningar vi hade. Det var en relativt stor grupp som samlats föra att genomföra den årliga affärsplaneringen, vilket syftade till att utifrån företagets övergripande mål finna vad denna avdelning skall göra under året som kommer. Alla som varit med på dessa tillställningar vet att de kan vara rätt tunga och inte alltid kopplade till medarbetarnas vardag. Jag känner dock att detta tillfälle bröt traditionen, mycket på grund av att de aktuella cheferna fokuserade på att jobba kring det positiva och möjligheter i stället för problem och hinder.

Det var en grupp på 30 personer fördelade i två olika linjegrupper, och huvudmålet var att finna förändringsåtgärder för året som kommer. På vägen mot det målet, en väg som var lika viktig som slutmålet i sig, jobbade gruppen kring sin historia, arbetade fram en mission och sedan en framtidsbild om var de vill vara fem år framåt i tiden.

read more »

Retrospective using Jimmy Cards

Posted on by

I had taken on to facilitate a retrospective for my colleagues’ team. They wanted a different retrospective than the usual. So we borrowed Crisp’s office and used Jimmy Cards!

The group was around 15 persons from two teams. They all knew each other well which I believe is crucial as the questions on the cards can be challenging.

In this post I’ll give you the recipe which Jimmy and I came up with for this particular retrospective.

read more »

Guest blogging at TV4 Digital Media

Posted on by

I have just, as a guest blogger, posted a new post at the blog owned by the development team at TV4 Digital Media; “Några övningar vi gjort under retrospektiven”. It´s a post, in swedish, describing a few retrospective exercises we have done during the last sprints.

I’m contracted by TV4 Digial Media as an Agile coach to help them improve the collaboration, both in the development team as well as between them and the business side. It is very fun that they let my write a post as a guest blogger 🙂

Micro agile

Posted on by

When we develop using agile principles we have learned to "do the simplest thing that can possibly work". What happens if we apply this thought to agile methodology itself?

What is the minimum number of principles and processes that we need, to be able to benefit from agile? Finding them should help us know what to focus on when introducing and using agile methods.

In my experience the three most important components in a successful application of agile methods are:

  • Joy
  • WIP limit
  • Regular retrospectives


When striving for high productivity and a sustainable pace, I have found that joy is the key factor. It’s simply not possible to work really really hard for a long time if you don’t enjoy what you do. In addition, things that make the workplace and the work situation more productive also improve the mood of the team. It’s a positive spiral, people like the feeling of being productive and if you have fun it’s easier to become more productive.

So, sometimes when to choosing which way to go if you want to improve productivity, look at the joy factor too. Things that work in favor of a joyful workplace are for example: high spirits, control over your own work situation, recognition, trust, humbleness,…

WIP limit

Nothing in my experience can increase a team’s focus more than limiting the amount of work in progress (WIP). A natural reaction when a team feels pressed for time is to start working on more tasks. Probably it feels more productive to do something else if you for some reason are blocked, but it has the opposite effect since you start more work that you might be able to finish and thus wasting man hours.

With a WIP limit you are forced to address the issues that prevent you from finishing tasks, because you are simply not allowed to start a new task until the present one is finished if you have reached the WIP limit. This reveals obstacles faster and focuses on fixing them before moving on.

In my current team, we would never have automated so many tests unless we had reached the WIP limit and found that testing was the bottle neck that prevented us from starting new development tasks. The immediate solution was to have the entire team dig in and do testing, but soon some developers (who hated testing) decided to automate as many tests as possible to remove the bottle neck so that they could go back to coding. The testers found this to be very helpful, since they were so busy testing that they never found the time to automate the tests…

Regular retrospectives

Inspect and adapt. Without the possibility to change the work process itself, improvement isn’t possible. Since we never get things right the first time (we continuously learn things we didn’t know before) and the world keeps changing, we need to regularly evaluate our way of working. Can we change something to increase productivity, joy, focus?

Again, I have seen teams pressed for time going the wrong way, skipping retrospectives in order to save time (why put the whole team in a room discussing things when we already know what we have to do – deliver code?). But skipping retrospectives means cementing the way you work and you may never get out of the trouble you’re in.


Posted on by

If you coach a scrum team but you’re not around to observe them during the sprint, how do you know how they felt about it?

Ask them.

You can interview them individually or as a group. Both approaches have their problems and limitations. Individual interviews take a lot of time, and sometimes you can’t share the results without breaking confidence. If you ask them as a group you usually only get answers from the most outspoken people because:

It’s hard to talk about your feelings among strangers.

One of the teams I coach had mixed feelings about Scrum. Some were healthily skeptical, and some positive. The first sprint went very well, with a good sprint planning, a lot of initial energy and a demo that actually showed customer value. But I felt that some of the team members were not too sure how the others felt about the whole thing. I wanted to help them with that and also get some feedback myself (I admit I was a bit nervous about not being around).

I used Emo-lines.*

Here’s how you do it. First draw a time-line representing the whole sprint and ask everyone to put up notes, marking memorable or unusual events. The team’s looked something like this:

Then you prepare for the Emo-lines, start by drawing a line directly underneath the time-line. The line represents neutral feelings, with feeling good above, and feeling bad below:

Next, have each person draw how they felt during the spring using different colored markers, starting at the sprint planning and ending with the sprint demo. Here’s a simplified version of the team’s chart:

The team members’ feelings varied greatly, you can see from the chart that the sprint demo went well though because everyone felt pretty good at the end.

The next step is to ask each person to comment on his/her line. Here’s what the team said:

Mr Green – a skeptic at first.

Mr Green is a very influential person in the group and the architect, he was the first to go. He said that he was a bit skeptical at first (as everyone had noticed during the scrum training right before the sprint started). He was worried that sitting and working in a team room would interfere too much with his flow and his privacy. As the sprint went on, he came to appreciate how quick and easy communication was with the new setup and realized that it was rather fun working that way. And when the first demo went well, well…

Mr Blue – a scrum advocate who got lonely.

Mr Blue was one of the driving forces in introducing Scrum to the company and the only one who was a certified scrum master. So I was a bit surprised and worried that he had such a dip after the first week. As it turns out, during the second week he had to work from home because his kids were sick, so he felt isolated and unproductive.

Mr Orange – an enthusiast both when skeptical and when not.

Mr Orange was also one of the skeptical-at-first but enthusiastically so. At the beginning of the sprint he felt that it was fun and that it worked for him. The problem was that they actually completed the whole sprint backlog mid-sprint and he thought that was boring and unproductive. As soon that they got some extra work from the product owner he was happy again.

Are Emo-lines useful?

The team thinks so, and they decided to use them at the next retrospective. The second time they got even more out of the chart, each line showed more variation and the explanations were more detailed.

They are also valuable to me as a coach. Even when I am not with the team during the sprint I get detailed feedback about how the team feels at the end of each sprint.

I also noticed more than one surprised look on the other team members’ faces when Mr Green talked about his line, and I think some team building took place.

Here’s a picture of the whiteboard:

*If someone has another name for these, please let me know, I heard about them from my colleague David Barnholdt, and he didn’t have a name either.

Emo, see http://en.wikipedia.org/wiki/Emo

Perspective of Retrospective

Posted on by

Scrum received some criticism today in Computer Sweden. The article featured an interview of Ken Schwaber and our guy Henrik Kniberg. Tobias Fors from Citerus was giving the comment that Scrum lacked support for retrospective. I am not sure if he was quoted correctly.

I am in the belief that Scrum has three roles, three artefacts and three meetings. Of the latter, there is one you should never skip.

The thing is, if you wish to get any better, you need to start thinking about what you do. If you do not do that, you will just muddle on like before. You probably reflect on your own ways, once in a while, as an individual, but you also need to do that as a group.

The only meeting you should never skip is the retrospective. Yet that is what seems to be happening very often, from what I hear and from the feature I mentioned.

As long as you do retrospective meetings, you can improve. You probably find that planning is also a good thing to do. But if you skipped retrospective and did planning only, you would not have a time to discuss how planning could improve. Except during your coffee break when everyone lets out their frustration anyway.

So how do you do a good retrospective meeting? There are many ways to go about, I’m sure, but let me give you a simple one that I even tried at home on a Sunday.

Divide a board in “good”and “not so good”. Hand out post-it notices and pens to everyone. Let everyone write down anything that springs to their minds when thinking about the last sprint (or last month, if you’re not iterative yet).

As they write down their thoughts, for each note, they place them on the board and states shortly what it is about. Try to refrain from discussion, is there any disagreement, just note that fact.

After a ten minutes, or when all are content, look through the notes and see if they some should be considered duplicates. If so, put them next to each other.

Now each participant is given 3 votes to put on the notes they feel is most important. All votes may be spent on one note or spread on more.

Count the votes and focus a discussion on the top five notes. Make a list of improvements from that and put on the wall visible to all.