The Project: A Retrospective


Both of us have left the project – we both received offers from other employers that were too good to pass up – and it is due time to have a retrospective of our time with the Team. (The project itself will continue, with the same Team members as before but with different Scrum Masters.)

It is a fairly long time period that we have been involved with the project – about 18 months – and we would like to summarize the accomplishments, highs and lows, of this time. This (a bit unconventional) retrospective will therefore be divided into three parts:

Part 1 is a look back on all the changes that have been made in the project during the last 18 months.

Part 2 is a reflection on our own effort in the project.

Part 3 is lessons learned, and which experiences we will draw on for future projects.


Part 1 –  A look back

Looking back, there is a long list of positive changes that have been introduced during our time in the project:

  • Test. Two testers are now active in the team. At first, there were questions from the developers why this was necessary (a Scrum team is supposed to be cross-functional, right?), but after proving their value and finding issues that nobody else discovered over and over again, it is doubtful if the team could go back to not having dedicated testers any more. The testers have brought two very important things to the team:
    • A broader knowledge of the system and its rules and how they are perceived by the users (as opposed to the Product Owner or the Developers).
    • A realisation that test on a higher level than the developers usually do is necessary to ensure a good experience for the end user. While testing on that level initially was the sole responsibility of the testers, the whole team now participates in short and efficient ”test races”, where new tests as well as regression tests are performed.
  • Increased quality. In a year, the Team has actively been working with removing technical debt, removing bugs and stabilizing the system. Issues that previously needed manual attention daily have decreased from being almost equivalent to a full time job for a developer to only a few minutes of work every day.
  • Build server with installation packages. Installation packages were initially built by hand for a long time, which was error prone and required a lot of manual work. We struggled for a long while with TFS and its build feature, but never got it working right. When we finally decided to switch to building our own installation software (which took some time to build, granted, but was a good investment in the long run), things got easier. Switching to TeamCity was also a good move, and with the build server up and running with auto-deploy turned on, the time spent for installation related issues are next to zero.
  • Monitoring software. Issues requiring manual attention from developers usually starts with an error in the production environment (typically, these are database or integration errors, with services not responding or timing out). Since we already logged those, it made sense to build software that read the logs and signals the developers if an unusual amount of errors starts occurring. This way, we can immediately counter faults that occur in the system or in the environment, and avoiding manual work related to the issues.
  • Keeping the backlog structured and tidy. The Team had a huge backlog with a lot of stuff that was never going to be built. Cleaning out the backlog, and switching to a more visual tool (KanbanFlow), helped both the Team and the Product Owner to visualise and prioritise what was important.
  • Backlog refinement. When we first came to the Team, the sprint planning meetings could take an entire day. An important reason was that most of the team never looked at the backlog between sprint planning meetings. Introducing backlog refinement meetings, the Team more regularly looked over the backlog together with the Product Owner, and discussed the contents well in advance of sprint planning.
  • From Scrum to Kanban. The Project started off as a standard waterfall project, but later the Team turned to Scrum. Since we joined the Team, we have moved towards Kanban and never looked back.
  • Improved boards. Our task board has gone through several stages of complexity, but are now in a state where it is clear and simple for all Team members to understand priorities and states.
  • The Calendar. The Calendar – a simple matrix with each cell big enough to hold a post-it-note – helped the Team visualize what is going to happen over the next few weeks. Events such as holidays, releases, sprint planning meeting, demo’s – everything goes on this board. Every day in the stand-up, we have a look at it and update it, discussing which events are upcoming.
  • The Event List. The Event List is a simple list with each entry containing a date and a short description of what happened on that date. Every day in the stand-up we discuss if there is anything that should be noted on this list. This list helps the Team remember what happened during the sprint, and works as great material for the sprint retrospective.
  • Breakfast. Introducing a short (30 minutes) weekly team activity, helped the Team function socially. This was important, since the Team was split into two groups with different tasks and locations in different parts of the office.
  • Error List / Task Force meeting. Taking place right after the breakfast meeting, this meeting was for the entire Team to sit down and go through and discuss errors and faults that had occurred during last week. Initially, everyone was invited, but this developed eventually into only having a smaller part of the team, the Task Force, to participate.

The list of all the changes the Team has made during the time is a source of joy and inspiration! The Team is, in many ways, a more harmonic team that delivers better software today than 18 months ago.

The most important factor to having this improvement, is the Teams willingness to change; the Team has tried most of the suggestions that we and members of the Team have suggested.

Part 2 – our contribution


We had very different backgrounds when we joined the project. Christoffer was a system architect recently turned towards project management, while Jeff was an Agile Coach without coding experience. Both of us had dual roles: Christoffer was also project manager for the Project, while Jeff worked as a tester.


My biggest contribution to the Team during this time has been framework and structure. Much of my time has been spent on typical project managerial tasks, dealing with project plans, documentation and meetings. I have also tried to offload other non-developer tasks onto me – making sure equipment and software licenses are ordered, arranging team activities, synchronizing installations, etc. I have always wanted the Team to know that if they need something fixed, they can come to me.

As a Scrum Master, I have forced the Team to think and motivate their decisions, by asking ”why” and ”why not” and making sure that everyone in the Team understand. Again, focus has been on structure; every Team meeting have a purpose and a goal.

As a Scrum Master, I have tried to make sure that everybody in the group gets their say, and that everybody’s opinion is respected. When presented with new ideas, I have been open minded and asked the Team what they think.


I feel my biggest contribution to the team was in the form of the toolbox I brought with me. We had a great team who was eager to improve, which was the key factor in our success, but most of them being new to Agile they lacked some of the tools that can help accelerate that process. A few simple examples of this were how to set-up a backlog refinement process, how to use boards to visually manage your process in a useful and informative way, and how to run effective and productive retrospectives.

I also feel I contributed heavily in my way of thinking, being new to a team who has worked together a long time is helpful because they get someone who challenges the way they work and think, the best way change someone’s way of thinking is to be an example to those around you. I believe I helped the team to understand that they don’t need to accept things as ”just the way it is”, to challenge their beliefs. Also, I brought with me a mentality of experimentation, rather than trying to find perfect solutions, trying things out to see what works. I also focused very heavily on bringing a ”quality focus” to a team who, while writing good code, did not have a lot of focus on the end users quality perspective.

Finally, I brought motivation with me. I believe that people are more productive when they are happy, I am a happy guy, and I tend to make those around me happy. I did small things like try to perk people up when they were down, organised team outings, found small things to brighten peoples day’s, and walked around having off topic discussions with people. Or as one workmate called it ”Jeff’s story of the day”. While these things might seem small, I think they contributed a lot. Also, I was also able to encourage more communication and team work as I was constantly setting an example of this myself.

Part 3 – where do we go from here


Looking back, I am proud of what Jeff and I and the Team accomplished. I can regret that I did not have more time to do scrum master-related tasks, but found myself stuck with management stuff. But, I do think that Jeff and I had skill sets that are complementary: me with focus on structure and rules, Jeff with focus on letting the Team decide and looking for improvements.

I think Jeff and I had very different viewpoints on what ”agile” means before this project, but I think that we have merged our differences so that I, at least, have a much better understanding of the concept.

Perhaps that is the most important lesson here: there is more than one (my) way  of doing things. Do not try to enforce things; ask the right questions and good things will emerge. Let the Team decide, do not make enforce your own decisions. Dare to try something new – it might be the best thing that has happened.


I could not be more proud of the journey we made, whenever we would look back it was always striking how far we had come.

My biggest takeaway from this is a lesson I learned from Christoffer, he always took the time to give me feedback and solicit feedback on himself, even when it was difficult or uncomfortable. While we may not have always agreed, I always appreciate it, and will work to integrate this into my leadership style in the future.

I also learned that people don’t complain when things work, several time I was told a specific tool or method was ”required” (TFS vs TeamCity for example), but if that tool did not suit our needs I encouraged the team to do what they thought was necessary, and never once did that come back to bite me. Because the solutions resulted in a happy customer and Team, and people don’t generally argue with that. So, stop covering you butt, and sort the problem out!

Finally, I learned to keep being myself and leading by example, as this is the best road to change in my opinion.


The Canadian No

Many Scrum Master consider it an important part of their role to guard the team from external interference. Firstly, it is important to note that The Scrum Guide never specifically states this. The closest thing I can find is:

”The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”

This sometimes does involve stopping work from being shoved into the sprint that would affect the sprint goal, but it is important to realise that the Scrum Masters job is not to perform prioritisation and that ”guarding” the team can in itself be a form of prioritisation.

”We are in a sprint, we can’t help you, you need to come back in 2 weeks”

Many Scrum Masters take this duty of guarding the team seriously, and it is a serious responsibility, but the approach you take can make or break you as a Scrum Master. In the above quote, we are actually performing prioritisation on behalf of the Product Owner and The Development Team. We are saying that your item is not important enough to interrupt what we have in the current sprint, and we will not even consider terminating or replanning in order to accommodate it. This may indeed be the right decision, but it is not ours as a Scrum Masters to make! Instead, this authority belongs to the Product Owner.

With this approach we are trying to push people out from the process, not helping them to understand why this interaction is not helpful and how we can change it to maximise value; we are getting into a shoving match. The inherent risk with this approach is that the people who bring us unplanned work often have more authority to push than the Scrum Master does. If we get into a shoving match – guess who wins most often? Also, we have put these people on the offensive, so they will be even more aggressive in their attempts to shove their work into the sprint. Eventually, once we have lost this battle several times, we will become branded as unhelpful and uncooperative and people will stop including us in this process. Also, the team will see us lose these battles over and over again, and won’t even bother asking us to help them because they know it is futile.

”That does sound very important and I would love to help you with that, let’s go see the product owner right away and get it a priority”

By taking a slightly different approach we may greatly increase our success in preventing lower priority items from creeping into our sprint. This method is lovingly dubbed ”The Canadian No” by my co-workers, as I am Canadian and often stress the important of politeness. But it is more than just being polite. This approach includes the person in our process, it helps them to understand that their item might not be the highest priority, but that we take all requests seriously and weigh them against the priorities we currently have. This approach creates transparency into why we make the decisions we do.

Hopefully, this satisfies the exact same goal as the previous approach, but it can have a totally different result.

What if it IS a higher priority?

By looking at the priorities that currently exist we are trying to ensure we are always working on the highest value items, and focusing on them with all our effort. The issue is, we are often disrupting our sprints with items that are not as valuable or critical. But, sometimes people might show up with something that really is more valuable than what we are currently doing. The whole point of practising Scrum is to make us more agile and improve our ability to adapt to changing circumstances. If someone showed up with work that is worth the entire yearly earnings of your organisation, was only going to take a few days, and was time sensitive, would you tell them ”we are in a sprint and we can’t help you with that”? You would be a bit of a fool to do so, and really, it is not your call to make.

Do we always need to see the Product Owner for a priority?

The team of course does have some authority to perform prioritisation. Perhaps the task is small enough, and has no effect on the agreed sprint goals, perhaps it’s something that will help them reach their goal faster, or perhaps it will simply take more effort to get a priority than to simply deal with it. As long as it has not effect of the agreed sprint goal, the team is empowered to make these decisions, but it is still not in the mandate of the Scrum Master…

Say it with me one more time: ”That does sound very important and I would love to help you with that, let’s go see the product owner right away and get it a priority”

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?