How will they solve it?

I’m sure you have all been there. You know, that discussion that does not really solve anything. Perhaps you took part in it yourself, discussing that problem that your organization is having. All of you in that room agreed that it is a big problem for you, for your entire team, for the entire organization. You talk about how wonderful it would be if this problem could go away, you analyze all the terrible situations that will occur if it does not. You leave the meeting with a sense of having reached some profound conclusion, some deeper understanding of what is wrong with your organization, and you wish that they, the people really responsible for fixing what is wrong, could receive the same epiphany.

Here’s an unpleasant truth: unless you act on your new-found knowledge, what you just did constituted waste, and it should be eliminated.

”Come on”, you say, ”we must be allowed to have discussions about our problems. What about our retrospectives? Surely we can have those?”

Yes. Of course. But here’s an easy tell-tale sign if your discussions consititute waste:

  • If you are talking about ”how we will solve the problem”, it is a valuable discussion.
  • If you are talking about ”how they will solve the problem”, it is probably waste.

The difference in only one word, but it it makes all the difference in the world.

Please also see this  video from Jeff on this topic.


Note To Self Retrospective

post-it-notesWe have recently gotten a few new team members, and we started to get to a size where we felt it was no longer practical to be one team. So, we decided to split into two teams.

Because of this split it felt kind of strange to conduct a traditional retrospective as we could not commit to actions as a team. So, I decided to try out a different format which turned out to be one of the best retrospectives I have ever had.

Note to Self Retrospective

I got the idea from this post: which I modified slightly to be more fit to our purpose.

The basic idea is to have people reflect personally, and come up with something they personally want to change in the future.


On the whiteboard I wrote some simple introduction text so everyone would know what this was all about.

Purpose: To improve yourself

Goal: To create one actionable item for yourself and experiment with a new behaviour, practice, attitude, or method in the coming two weeks.

Output: A Post-It note for your screen or laptop to remind you about this change.


Introduction (5 minutes)
I simply showed everyone the into text and agenda for the sessions, and made sure everyone understood.

Reflection (15 minutes)
During this time people think and create their notes.

Discussion (15 minutes)
I made it clear that passing was totally acceptable during this phase so people could feel free to be as personal as they wanted. No one did. We discussed as a group what everyone decided to do.

Feedback (5 minutes)
A quick go around the table to see what people thought about this activity.


The Good

This was a fantastic retrospective! Primarily because people ended up going much deeper than I expected they would, and shared very openly with one another. Results are at the end of this post.

One team member commented that sharing them aloud was very good, because then you felt more committed to achieving it.

It was also super quick, 5 minutes to setup and ended up 30 minutes to execute.

The Bad

Not everyone’s takeaways were actionable. Maybe that’s OK, but I like actionable.

The Output:

People were so open they even said I could post the result here! I had them as a picture but the quality was bad, so I typed them. Some probably require more context to make sense, but I will post them without that.

”Keep Back
Don’t code alone
Don’t offer solutions directly
Wait until asked for help”

”Proactively deal with upcoming issues”

”Spend more time reading up on items and be more thorough.”

”More structure for retro output
Book time for debrief/admin work after each retro.
Document output.
Follow up.”

”Stop worrying about everything”

”Improve knowledge about (component name)
Get to know team members and their roles.
Get to know my own role in the team.
Get to know everyone’s name, role, and skills.”

”Less sarcasm.
More listening.
Better at (component name).”

”Self confidence over all.
Believe in myself and my work.”

”Be focused.
Don’t waste time.
Be more motivated.”

”Listen More”

Agile Practices Retrospective

Our Retrospectives

We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:

Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.

Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.

This is the story of one such retrospective.

Agile Practices

Obviously you can perform many Agile practices, but not be Agile. However, there are a lot practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.

Prep Work

image (1)In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also colour coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.

Special thanks to Jurgen Appelo for providing the initial list I worked from:

Here is a link to a google doc with the prep work I have done, to save you some time:

Reducing the complexity

image (2)With over 50 cards, there was a lot of information. We split into groups and started categorising the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.


  • Doing (Working Well): Things we are currently doing, and quite happy with they way they currently work.
  • Doing (Could be better): Things we are currently practising, but could use improvement.
  • Not doing (By choice): Things we are not currently practising, but have made a choice not to use in our context.
  • Not doing (Not tried): Things we are not doing, and have never really tried.
  • WTF!?!: We have no idea what this is, or what it means.

Deciding what to focus on

We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:

  • We should start and or alter this practice in some way. (Indicated by a dot)
  • We would like to learn more about this practice. (Indicated by a +)

I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.

Discussions and action points

We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:

Root Cause Analysis/ 5 Why’s

We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might revel something we would have otherwise been unaware of.

1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand ups, then we should also consider doing a more in-depth analysis of those items.

Product Vision

We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.

1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.

Behaviour Driven Development (BDD):

This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.

1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.


The Good:

This retrospective was reviewed well by the team, everyone generally liked it.

It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.

Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future we would probably recommend only focusing on these things.

The Bad:

There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully a bit cheaper for you, as we have provided the work we have done. Once again:

It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list before hand.

Despite there being so many items, the list was no even close to exhaustive, and it was hard to leave off some practices that really should have been included.

Ett positivt retrospektiv

Om man varje sprint kör samma typ av retrospektiv med teamet, och dessutom har en förändringsvillig grupp, leder det till två saker:

  1. Teamet blir väldigt duktiga på att delta i retrospektiv
  2. ”De lågt hängande frukterna” blir snabbt plockade, och man sitter efter ett tag och diskuterar småsaker

Det sistnämnda kan uppfattas som gnäll; man glömmer allt man åstadkommit för att fokusera på de mindre detaljer som inte fungerar.

Det kan i det läget vara en bra idé att bryta upp rutinen med en övning som ger energi och som fokuserar på allt man uppnått hittills. Vi kallar det för det ”positiva retrospektivet”.

Denna övning kan gå till på olika sätt, men när vårt Team har provat detta, har det typiskt fungerat såhär:

  • Genomgång:
    • Titta tillbaka sex månader, och gör en kort beskrivning av hur arbetet gick till då
    • Kontrastera detta med hur arbetet fortlöper idag
    • Summera ihop de senaste sex månadernas bedrifter för teamet
  • Retrospektiv:
    • Alla i Teamet – inklusive produktägare – får skriva obegränsat antal lappar med positiva saker om arbetet
    • Be Teamet sätta upp lapparna på en tavla, indelad i tre delar: ”Teamets styrkor”, ”Vad vi är bra på”, ”Saker vi lyckats med”
    • När alla satt upp sina lappar, reflektera kort över lapparna på tavlan.
    • Sortera upp lapparna i namngivna kategorier. Kategorierna bestäms efter innehållet på lapparna, men typiskt är det kategorier som ”Teamkänsla”, ”Kompetens”, ”Buggfixar”, osv.
  • Diskussion:
    • Välj ut en eller två kategorier och använd rubriken för öppen diskussion i teamet, kanske 20 minuter. För att starta diskussionen, kan man ställa frågan vilka som skrev en lapp som hamnade i den kategorin, och om de vill utveckla varför de skrev den.
    • Man behöver inte ta några action points från denna typ av retrospektiv.
  • Avslutning:
    • Låt var och en kort summera sin känsla av retrospektivet.

När vi har använt den här formen av retrospektiv, har det uppfattats som väldigt energigivande och positivt för gruppen. Flera deltagare i teamet har till och med sagt att det var det bästa retrospektivet nånsin!