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”


Is the Scrum Master a full time job?

This is a discussion I hear a lot. The Scrum Guide has a list of duties that a Scrum Master performs, and while it is not clearly stated that it is a full time role, it is quite clear to me on reading it that it is intended to be. This is my least favourite motivation for why to do something ”Because Scrum says so”, so let’s look at this question a bit more in-depth and decide if you need a full time role?

What does a Scrum Master do?

The duties and activities of a Scrum Master are many and varied, they will take on different forms depending on what the organisation needs at that point in time. So, listing everything a Scrum Master does would be a very long list indeed. So, for the sake of simplification I am going to break it down to one central responsibility:

”A Scrum Master helps to facilitate change and improvement.”
matrixPeople have a natural tendency to focus on the here and now, and things that need to be solved today, they focus on things that are urgent (time sensitive tasks) but not things that are important (not time sensitive but often more valuable). This is why we have the role of the Scrum Master in Scrum, their job is always to focus on the important, while the team is often occupied focusing on the urgent. While your team might be focusing on implementing new features, a Scrum Master focuses on how we improve our requirements handling to make sure they are easier to implement the next time. While each team member focuses on their own coding, a Scrum Master focuses on how we can help the work together as more of a team, so they can swarm problems rather than fix their own tasks.

We cannot afford a full time Scrum Master!

I think it is looking at the question completely backwards, the question we should be asking ourselves is ”What is the return on investment of having a full time Scrum Master?”

To demonstrate this, I will use some very simple back of the envelop math, nothing scientific just a quick calculation.
The maximum size of a Scrum team is 9 people. Add to this the Scrum Master and Product Owner makes 11.
For the purpose of this calculation we will assume everyone is paid the same.
In this calculation we will use the term ”Improvement” to indicate both efficiency and effectiveness gains.

So, the question is ”How much of a recurring improvement does a Scrum Master need to facilitate to have a justifiable ROI?”

Team time / team size = required improvement
100% / 11 = 9.09%

So, a Scrum Master needs to find and facilitate an improvement of 9.09% in order to break even week after week. Everything over and above that is money in the bank!

Now the question becomes, “Can this person truly find that much of an improvement?”

Some example improvements

As I do not always precisely track my work, these numbers will be fairly rough, but I think enough to show my point.


One of the most normal situations I encounter are teams who are having long and unproductive sprint planning meetings. I find the simplest way to counter this is to have regular refinement meetings where we look at the product backlog and mould it in to usable shape. My previous team was having sprint planning meetings that went on for at least a whole day. After instituting a regular refinement meeting (1 hour every 2 weeks) we were able to shorten that to at the very most 2 hours (often much shorter).

So, we had saved the team 44 hours a month. Or a 2.5% improvement.
This doesn’t even count the less measurable benefits of higher quality output, better requirements, and a happier, more engaged customer.

Quality Cost

Poor quality is a huge source of waste in companies. Bugs are occurring in production, which require immediate attention. The team need to interrupt its ongoing work to focus on fixing the issue. The problem with this is, when an immediate fix is needed the natural human behaviour is to address the symptom instead of the underlying cause. So, we do nothing to prevent the bug from reoccurring the next time and eating more of our time. An experienced Scrum Master will catch this, and work to visualise these issues so that patterns can be found and the most costly issues can be addressed by the team.

Let’s say you get 10 bugs a week, and each disrupts your day for 1 hour (both pretty low estimates in most teams I encounter).
If we identify, and fix the root causes instead of the symptoms, we saved 40 hours a month. Or 2.27%.

Once again, this does not count the less measurable benefits like more satisfied customers, code bases which are easier to work with, preventing technical debt which comes with a maintenance cost, and less cost of task switching.

Helping the entire team pays back fast

These are some fairly simple examples but I think you are starting to get the idea: when you help the entire team, it starts to pay back very fast. And in my experience, the biggest improvements happen in those less tangible areas I mentioned. For an experienced and dedicated Scrum Master, 9.09% is easy!

Can’t this be done in a part time capacity?

So, we are able to demonstrate that a Scrum Master is able to pay for their role, but does this mean they NEED to be full time in order to achieve these results – could they not do the same work in a part time capacity?
Well, yes and no… Or, as they say in Sweden, Nja…

I am not saying you won’t get some value out of a part time Scrum Master, but, facilitating improvement is not work that can always be planned and actively executed. It often involves being around at the right time, or even if you are around, in the correct mental state to identify the opportunity and act on it. As mentioned earlier, someone needs to focus on the important, not just the urgent, because urgent is always treading water, important is where we move forward.

So, ”Can we do this in a part time capacity?” I think is the wrong way at looking at the question. Instead you should ask yourself:
”How much do we lose every time an improvement opportunity is missed?”

With this in mind, I think the central question is not ”Can we afford a full time Scrum Master?” but ”How can we afford NOT to have a full time Scrum Master?”



Som scrum master eller agil coach måste man ha tålamod.

Gruppdynamik är ett spännande ämne, och det har redan skrivits spaltmeter i ämnet. Ändå vill jag dela med mig av en observation här, som direkt påverkar det agila tankesättet; ”inspect-and-adapt” är bra, men det kan ibland vara klokt att skynda långsamt. Jag ska förklara mer i detalj nedan, och ge ett direkt exempel från Projektet nedan.

Antag att du som scrum master kommer till en ny grupp där du direkt kan identifiera ett par möjliga förbättringar. Om gruppen är intresserad av att förändra sitt arbetssätt: bra! Men: tänk på att för att förändringen ska lyckas, behöver alla i gruppen förstå varför och acceptera att förändringen införs. Risken är annars stor att den förändringen i arbetssätt som du själv och förhoppningsvis större delen av gruppen vill införa ignoreras eller rentav motarbetas av en eller flera individer.

Ett exempel:

För ett och ett halvt år sedan arbetade Teamet enligt Scrum i fyraveckorssprintar, med en heldag avsatt åt sprintplanering av hela perioden. Denna dag sammanföll dessutom med en halvdags retrospektiv och demo. Dessa mötesdagar var otroligt energikrävande, långa dagar, som ingen såg fram emot.

Idag arbetar Teamet enligt Kanban med WIP-limits, där vi har retrospektiv, demo och planeringsmöten varannan vecka med ett separat backlog refinement varje vecka. Planeringsmötena är korta och effektiva; nedbrytning och storleksskattning av punkter görs separat.

För att komma dit vi är idag, har vi tagit små steg, finjusterat arbetssättet. Ibland har vi tagit större steg, men vid mer än ett tillfälle har detta ofta lett till ifrågasättande och förvirring.

Det finns ett par poänger i detta, som kanske är självklara, men som är värda att nämna igen:

  • Ge förslag på förbättringar i arbetssätt, men låt teamet själva bestämma vad som passar dem. Alla team är olika. Det som fungerar för ett team behöver inte nödvändigtvis göra det för ett annat.
  • Sök förståelse och acceptans hos alla individer i gruppen.
  • Låt förändringen ta tid. Det kräver tålamod hos dig som scrum master, men kanske också hos vissa av de mer drivande medlemmarna i gruppen. Prata med dem separat, om det behövs.

Hur vet du att alla i din grupp är med på tåget? Är en tystnad samma som förståelse och acceptans?

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.

Visualising your backlog

Far too often the backlog is housed in a tool somewhere, often in purely text form, with no way of knowing at a glance the status of each item. This makes it difficult to manage in many ways, and generally hard to work with. I have found that taking the time to visualise your backlog will not only increase the quality of the output, but make it a lot easier and less time consuming to work with. This is an example from my current project of how that works.

Your backlog as a process:

backlogMost people don’t take the time to see their backlog as an actual flow, but it is. Items usually have a sort of process that they flow through to arrive in a state where they can actually be worked on, and being aware of what that flow is can help a lot in creating stability.

This ”refinement process” is, in my opinion, one of the easiest wins in most teams. Our team went from having 1-2 day Sprint Planning meetings, to usually getting through them in a just a few hours, with a much higher quality of output.

The backlog on its side:

The first step in creating a refinement process, is to visualise it. In the simplest sense this can be accomplished by simply turning the backlog on its side and seeing each section of the backlog as a column in your flow.


The tool we use for this is KanbanFlow. The images you see here are simplified slightly for the sake of clarity, they only show one teams flow, when in reality we have multiple teams working in this flow.

Below you see the complete flow, and we examine each section in turn.


The bottom:

bottomHere sit the totally unrefined items. Some of them may be too big to work on, most are too unclear, and all are only ”lightly prioritised”. We like to visualise the different flows in to the backlog separately. This makes it easier to balance priorities against one another when planning upcoming work.

  • Backlog
    • Full of large, unclear stories.
    • Many of these may never reach the top, we try to clean this out every so often and remove things we are certain will never be top priority.
    • Most of these items come from our Product Owners / Customers.
  • Teknik
    • Holds much of our technical debt.
    • These generally tend to be concise, but somewhat large.
    • These items primarily come from the teams working on the product.
  • Bug list
    • A list of bugs that were not quite important enough to be a priority right away.
    • We try to keep this list as small as possible, but some things do need to wait until they are worth the investment to fix.
    • These items usually come from users who find them in production.

The middle:

middleThis is where the bulk of planning and discussions happen. There is a column where action from the customer is needed, and one for when action is required on our side. Most of what takes place here comes down to regular discussions which bring up question that need to be answered before development can start. Very often, large stories are split into smaller items here, and some of the lesser priority things go back to the bottom of the backlog, and the prioritised items continue forward.

Items do not leave this area without a clear priority.

The top:

topThis consists of items that are ”Ready” to be worked on, and items on which work has begun. Many teams choose to have a formal definition of ready, our team keeps it fairly simple: ”Everyone in the team agrees these items can be worked on now”.

Items which are pulled into the Sprint column are being worked on by the team. At this point, these items are made into smaller and more specific tasks, and are visualised using the physical tool for the team. This is important, because it is the main points where details are obfuscated. Our customer does not need to know exactly what is being done on an item, what matters to them is that the feature or functionality is started, and when it has been completed. This setup allows them the appropriate amount of detail.

The output:

deployAt the moment we have a slightly heavy deployment process, which involves handovers to the customers organisation and wait times. Visualising this helps our customers to understand when things are ”done”, but they still don’t have them due to internal processes. This has aided in our customer driving many initiatives to simplify and streamline this process. While we still feel it could be improved further, it is definitely an easier process today than it was before we started visualising this part of the process.


Being aware of how items flow in your backlog from the initial request to the actual delivery can help significantly in many ways:

  • Clear status of items in process for both you and your customer.
  • A shared understanding by all involved what is in the pipeline.
  • Easier planning session because everyone has more insight when items arrive.
  • Higher quality to items arriving at the ”ready for development” stage.

But be careful not to present unneeded information as it only serves to make the needed information harder to find.

And most importantly, the tools used in the process are much less important than the process itself. Having the discussions regularly and openly, creating the feedback loop as quickly as possible, are the keys to success not the tools being used to present the information.

This process can be tricky at first, but as with all things, the more often you do it the better you will get at it!

Dokumentera det som är viktigt

Hög med böcker

Dokumentation bör inte bli gammal.

Vi producerade tidigare mängder med systemdokumentation, som beskrev varje delsystem i detalj. Produktionen skedde motvilligt och var alltid en nedprioriterad uppgift, eftersom det bara var en textmassa som skulle levereras till någon diffus lagring enligt avtal. Efter bara några månader var dokumentationen inaktuell och behövde uppdateras igen. Det här stal energi och tid, som hade varit bättre använd till att producera bättre kod.

När vi äntligen tog mod till oss och ställde ett antal kontrollfrågor, visade det sig att ingen egentligen läste dokumentationen! Det enda syftet var att säkerställa att man hade någon dokumentation som kunde hjälpa en extern utvecklare förstå hur Systemet var uppbyggt; någon sådan extern utvecklare fanns inte, och skulle heller inte finnas.

Dokumentationskravet togs därefter bort. Istället funderade Teamet igenom vilken dokumentation som de behövde, och kom fram till att en systemskiss räckte, tillsammans med en instruktionsbok för hur man ska installera utvecklingsmiljön och logga in på och hantera utvecklings- och testservrar (kallas även för ”bibeln” inom Teamet).

Dessa dokument är de som utvecklarna behöver, och de underhålls därför kontinuerligt, utan påminnelser. Nu faller det sig naturligt för alla i Teamet att uppdatera dessa dokument så snart nya rutiner tillkommer eller gamla förändras.

Det är en vanlig missuppfattning att Scrum och andra agila metoder innebär att dokumentation inte behövs. Det är givetvis inte sant; i det agila manifestet står det att man bör prioritera fungerande mjukvara *framför* dokumentation, men det innebär inte att dokumentation är oviktigt. Men: det innebär att man inte ska producera dokumentation i onödan, och också att den dokumentation som skrivs ska vara till nytta.