Why are we so slow in delivering software?

Why are established companies so much slower in delivering software compared to a startup company? I will give you four reasons.

About ten years ago we had that crazy time in the office. We were this small startup company with a couple of young guys. And we were delivering new software like hell. We were close, not just colleagues, but friends. 

And we were having a massive amount of fun in the office. 


There were these situations when it was very silent in the office, everyone focused on coding. Suddenly, somebody threw one of the small, colored plastic balls and within a few seconds, the whole office transformed in a war zone. People running around, trying to hit each other with the balls. Hiding in the toilet and then sneaking out to get to the other colleague from behind hitting him hard in the back with a plastic ball.

This whole scene lasted for about ten minutes, then everyone was back at their desk, trying to catch a breath and continuing with the coding.

Every now and then we had to replace a broken plant, but all the other equipment and office supplies miraculously survived the wartimes.

It was crazy, it was great.

And we were working our butfs off. We were doing a lot of overtime. Before a tight deadline, people were sometimes even coming to the office on weekends, without the boss even asking for it. It was a normal thing to do.

We were fast…

Back then, we were creating new features in our software on a daily basis. And these were delivered to the customers very quickly. The quality was not perfect, but it was not bad either. And in case there was a bug, we were fixing it within a couple of hours or maybe a day.

Since then, the company has grown to more than 50 people and those crazy times are gone. There are now also other important things in life, we have families, we got older, other responsibilities. We don’t want to do this crazy overtime anymore.

Recently I was having a beer with one of those guys from back then. We were wondering why we were able to deliver new software on such a fast track. Now, if you plan to create a bigger feature or a new module in an existing application, it takes weeks or even months to finish it. 

So why were we so much faster as a small startup company? Why does it take us so much more time when we are 50 people?

I came up with the following reasons:

1. Software is more complex

An established software company has their software products already placed on the market. There are many customers using the software on a daily basis. 

Especially in the business-to-business (B2B) market, different customers often want your software to work slightly differently because their businesses are unique and a bit different compared to their competitors. 

So what you build in your software are configuration options to allow the customers to configure the way the software works. 

Many configuration options

And the more configuration options you have, the more complex the software gets. If you are going to implement a new feature, then you have to take all the possible configuration options into account and make sure that the new feature works for all configurations of your customers.

If you compare that situation to a startup, then this part is way easier to deal with for a company just starting out. 

There, you have a very small amount of customers at the beginning. Therefore you know all your customers and their setup and configuration. So, during coding, you can focus to cover only their use cases. And at the beginning, you provide only basic support in your software for these use cases. 

That’s why a startup company will be much faster with adding new functionality as the software is much simpler, with little configuration options and a limited amount of features, compared to the complex software of an established company.

2. Technical Debt

You could argue that you will be faster to add new functionality in an established software because you can leverage existing functionality.

That is correct for some cases, but not for every situation.

An example is cross-cutting concerns, like authentication, authorization, logging, database access, etc. as these things already exist in an established software. Then it is rather easy to add an additional permission option to an existing authorization system or write something into the logs when a log provider can easily be injected wherever you need it.

On the other side, the more established your software is, the longer people were working on it. The older the software and the bigger the code base, the more possibilities the programmers had to accumulate technical debt. And the more technical debt you have, the slower the team will become when it comes to implementing new functionality.

In theory, this should not happen, but even with the best architecture, the team will accumulate technical debt over time. In practice, there is some time pressure to meet the deadline. Or you have to fix a critical bug as soon as possible. Then you are forced to do some quick fixes without paying much attention to whether this is in line with the proposed architecture.

When you compare this to the startup situation, then technical debt does not play a key role. This is because you develop your software from scratch and you don’t have to deal with existing code and its quirks.

All in all, technical debt plays a key role in established software, while it does not have a relevant impact on the software you write from scratch.

3. Support for existing customers

In the B2B market, you usually have a close relationship with your customers. They pay a lot of money, therefore they also want to have individual solutions and proper support.

So what happens is that you will get frequently contacted by your customer. You have to discuss new feature requests or help them with an existing issue in your software. These things are usually handled by the support department or the Product Owner. But often it is faster to directly involve the developer, who built the whole feature. 

This happens quite often in my company, and the customers really appreciate the direct interaction with the developer because the developer has the best knowledge about the modules he built by himself and therefore can give competent answers to the customer.

On the flip side, this means that the developer will be involved in activities that have nothing to do with coding. On a bad day, the developer might be interrupted multiple times to support one of the many customers and therefore his productivity in adding new functionality in the software will decrease.

In the startup world, these issues don’t exist. A startup company has a very limited amount of customers. Therefore the interruptions in the day-to-day business don’t have a notable impact on the coding progress of the developer.

4. Internal Communication

When talking about startups you have a picture in mind, how a handful of skinny, pale-faced, young guys work with their computer toys out of a garage. While this is probably not the common scenario these days, the amount of people and available space in a startup is indeed rather low.

In my case, ten years ago the four of us were sitting in one small office, bearly having enough space to stretch your feet. As we were sitting so close-by and working on the same project, it was really easy to communicate with each other. We didn’t have daily standups, but these were also not necessary as there was a constant communication flow throughout the day. 

Nowadays, with around 50 people in different physical locations, communication is much more difficult. You have to plan ahead the regular meetings to synchronize, this makes communication very slow.

Communication flow vs. distance

And also the barrier to call someone in a different location is much higher than asking the colleague sitting next to you. I recently read “The culture code”, where they explain the relationship between physical distance and communication frequency in detail. The closer you sit to someone, the more often you communicate with that person. This is kind of obvious. 

The surprising part is that at a distance below 8 meters the frequency of communication increases exponentially.

So if another person has their desk 20 meters away or sits on a different floor is basically the same. Heck, there is no relevant difference whether a person sits on a different floor or in a different country.

Development process

In a startup, the formalized information and processes are rather low. We were using a bug tracking system, but it was not necessary to write down every detail. We shared this information on the go and writing it down would just have been overhead.

These days with 50 people we have a lot more information in our bug tracking system. We keep track of customer-relevant information, for instance from which customer the feature was requested, what delivery date we promised, etc.

The support department requests approval from customers to deploy an update. This needs to be managed. 

We have formally defined processes to guarantee software quality. These consist of partly automated testing but also manual regression testing. And then there are approvals from different team leads before new software releases are published.

So the whole development process is more complex and therefore more formalized in an established company compared to the startup. As a result, the company is also slower in delivering new functionality to the customer.

Agile, Lean and DevOps

So what can we as an established company do to be faster? Is it even possible to be as fast as a startup?

It should be possible, but I think it is difficult. 

You need to organize the company into small teams responsible for a specific, enclosed part of your service. Every team should be able to work independently from other teams. Each team is empowered to decide every important matter around that service. It is responsible for designing, building, testing and running that specific service.

So basically, you need to organize your company so that it works like multiple small startups within your company. 

I believe the difficult part is to find the line where you make the cut. It is hard to separate the responsibilities for each team so that they have as little dependencies as possible. There is no silver bullet, this is unique to every organization.

How does your organization handle these challenges? Let us know in the comments.

See you around, and HabbediEhre!

How to lead self-managing teams – Book review

To my surprise, there are a lot of parallels between leading self-managing teams and managing beehives.

I recently read a great book called “How To Lead Self-Managing Teams?: A business novel on changing leadership from sheepherding to beekeeping” (affiliate link) by Rini van Solingen. In this novel, the author tells a story about the IT manager Mark, who wants to introduce self-managing teams in his organization to make his life easier. 

During a vacation, the grandfather of Mark tells him how he switched careers from being a shepherd to a beekeeper and what he learned during this journey. Mark realizes that he manages his teams mostly like a shepherd, but he must think and act more like a beekeeper in order to develop self-managing teams.

Let´s outline the most crucial takeaways from this book.


If you want to develop self-managing teams, then you need to stop treating your people like sheep.

Command and Control

A shepherd tells the sheep exactly in which direction they have to go, where they eat, what they eat and so on. Then he regularly checks on them to make sure everything is the way he expects it to be.

Similarly, traditional managers often tell their people exactly what to do and maybe even how to do it. Then they ask for constant status updates and results.

So they follow a command and control pattern. They tell their “sheep” what to do and check up on them regularly.

Dogs bark

When there are too many sheep then the shepherd gets himself a dog to help. He trains the dog to listen to his commands and then bark to the sheep accordingly in order to steer them in the right direction. 

A manager higher up in the hierarchy often has more sheep than he can manage by himself. For instance, the manager of the department has multiple team leaders reporting to him, while every team leader manages their own team. The department manager trains the team leaders to think and act exactly like himself. And if necessary the team leaders bark to their team if the department manager demands it.


Beekeeping is fundamentally different from sheepherding. Bees manage themselves. Bees just want to do their work and they do it as good as possible. 

The better the environment and the surroundings, the better the taste of the honey and the more honey they produce. For instance, when there are a lot of flowers they can produce more honey. If the flowers are far away, then the bees have to fly a long distance and therefore it takes longer to produce a certain amount of honey.

Trust your team

The key to develop self-managing teams is to trust your team that they do their work as efficient and effective as possible. They are all experts in their role and know what is best. And even when they don’t know, it provides a learning opportunity so they will know it the next time.

The important thing the self-managing team needs is a defined goal and transparent results. That´s what the manager of the team is responsible for. He needs to define a clear goal and make the ongoing results transparent to the team. Then the team by itself will fill in the details on how to get there.

Blame the process, not the team

When the bees don’t produce the expected honey, then the beekeeper does not blame the bees. In such situations, there is something wrong with the environment. Maybe the location of the beehive needs to be moved to a better place or there is something else wrong with the setup.

When your team does not deliver the expected results, then don’t blame the team. This is a problem with the environment or the process. You need to look into what is wrong there and fix it.

This is easier said than done. Because if there is a f*ckup then it is way easier to identify one of the people as the reason for the problem. But we need to look a level deeper and find the root cause of the issue. Most of the time the people tried to do their job as good as possible and the root cause of the issue is the environment or the process.

Change yourself first

In order to develop self-managing teams we as managers need to start with ourselves. We have to unlearn the old habits of managing people like a shepherd manages his sheep. We need to think and act more like a beekeeper.

I urge you to read the whole story of Mark and his grandfather. There are a lot more lessons in there for leading self-managing teams. It is a worthwhile read and the 140 pages take only a few hours to get some inspiration about leadership. You can get the book here (affiliate link). 

That´s it for today. Stay tuned and HabbediEhre!

Mad Glad Sad Retrospective

The Mad Glad Sad Retrospective is a format to gather data in the Scrum Retrospective meeting.

Here I am going to explain how you can use the Mad Glad Sad activity in your Retrospective meeting. I will describe in detail in which situations you should use it, how you introduce it to your team and what pitfalls you should look out for.

The Mad Glad Sad exercise clearly belongs to the second phase of the five phases of a Scrum Retrospective meeting. These five phases are:

  • Setting the stage
  • Gather data
  • Generate insights
  • Decide what to do
  • Close the Retrospective

If you are not familiar with these five phases of an Agile Retrospective then I recommend to first read my blog post series about the five phases of a Scrum Retrospective. This will help you to get an overview and set the Mad Glad Sad activity in context to the other parts of a Scrum Retrospective session.

Ok, now let’s get down to it.

Mad Glad Sad Retrospective

The goal of the Mad Glad Sad activity is to gather data about the sprint.

Within the gather data phase you go through following steps for the Mad Glad Sad Retrospective:

  1. Explanation
  2. Silent writing
  3. Assemble and group
  4. Pick a topic

Let’s have a look at each step in more detail.

Step 1: Explanation

You begin the exercise with an explanation. Therefore you draw a table with three columns on the whiteboard and name them Glad, Sad and Mad.

Then you explain the team that they should grab some sticky notes and write down silently what made them Mad, Glad or Sad in the previous sprint. They should use for each item a separate sticky note and only need to write down some keywords rather than full sentences.

You also tell them to take 3 minutes of time to write down the points. If somebody is done earlier they should stay seated and wait until everyone else is finished. This will help other people to not get interrupted in case they take a bit longer when writing down their points.

It is a good idea to put the columns Mad and Sad next to each other, because sometimes it is not clear whether a negative experience made you mad or sad. Therefore a person, who had both feelings about a certain event, can place the sticky note in the middle of those two columns.

Step 2: Silent Writing

3 minutes of silent writing is usually enough. But you can shorten or extend the time a bit depending on how many participants are already finished. This is usually just a gut feeling and changes from team to team and Retrospective session to Retrospective session.


If you know from experience that people tend to write down too many stickies, then you can limit the number of stickies per person.

For instance you can tell them upfront to create a maximum of five sticky notes. So they focus on the five most important items from the previous sprint.

On the other hand, if you are dealing with a non-active group you may encourage them to create a minimum amount of sticky notes. For instance, you can ask them that you would like to see at least three stickies per person.

And you can add, that you think that everybody in the group had at least three situations when he or she was happy or sad about anything at work.

In such a situation I also realized that most of the people just write down exactly three items. So, therefore I hardly ask for a minimum amount, because this often limits other persons to think further after they created three sticky notes.


I often get the question whether or not the scrum master should participate in the silent writing.

My opinion about this is the following: If I know the group very well and I was actively involved in the work of the sprint, then I do participate.

However, this is tricky, because it is hard to wear two hats at the same time — one as participant and another as facilitator. Therefore, in general I don’t participate in the activity and focus on the role as facilitator.

Step 3: Assemble and group

When everyone is finished you explain that everybody, one after another, should walk up to the board and put their stickies on the board. While placing the sticky note on the board the person should explain to the group what each sticky means.

Then you ask for a volunteer to start. If nobody is eager to start, just ask one random person whether he or she is up for it. Until now nobody said “No” to me, when I asked this question.

If there are similar topics, then these topics should be grouped together. You want to have the same thought on the board at the same place.

I have seen that sometimes people are very focused on their explanation and therefore forget to group similar topics together. That’s when you as the Scrum Master assist to cluster similar stickies on the same place.


People can ask clarifying questions when a person is explaining his or her sticky to the group.

However, the role of the Scrum Master is to make sure that these questions don’t trigger a whole discussion. For instance, when people are discussing reasons why a certain event occurred or even offer solutions, you just ask them politely to hold their horses.

At this point we just want to gather the data and we will pick the most important topic for a deeper discussion in the next step.


After a person is finished with putting their stickies to the board you thank them for their effort. It is important to value everyone’s contribution and also say it out loud in front of the whole group. This helps to build a good culture and encourages to really put effort in the exercise.

Especially when somebody gives constructive feedback or opens the door to discuss a sensitive topic it is fair to thank him for his honesty.

Because in the end this is exactly what you want to achieve with this exercise—talk in a safe team setting about the hidden conflicts within the team. And if somebody has the balls to start such an uneasy discussion the least thing the facilitator can do is to thank that person.

Step 4: Pick a topic

At this point we have all the ideas grouped by similar topics on the board.

Now you walk up to the board and give a summary by stating the obvious.

For instance, you describe that there are many stickies in the glad column and that this is in general a good sign.

Or you say that it is obvious that the major bug the team had in the software last week made a lot of people sad.

If there is a particular topic that stands out, then you decide that this is the topic you are going to pick for a more in-depth discussion in the group. In such a case there is no need to consult the team, but you take the decision for the team.

On the other hand, if there is no particular topic that stands out, then you can use dot-voting to select a topic.

Dot-Voting is a great tool to come to a quick, democratic decision about a certain set of options.

In this case the team should vote on what is the most important topic to discuss. And the topic with the most dots will win and will get discussed in more detail in the next phase.


First you explain to the group that everybody gets for instance three dots and can put those dots on the stickies on the board. People can put all their dots on the same topic or they can distribute them over multiple topics as they wish.

Therefore, everyone assembles in front of the board and places the dots on the stickies. This shouldn’t be done one after another, but rather at the same time. It is faster and keeps the energy level up.

Waiting time in a Retrospective meeting—or in any meeting in general—is bad and just distracts people. What happens is that they lose their attention and focus.

You also explain to the group that if they vote for a topic, which consists of multiple stickies that have been grouped together, then they should put the dots on the top-most sticky of that cluster.

In general it does not matter whether the dots are put on the top-most sticky or not, because it gives the same results as the votes are summed up. It is just easier for the Scrum Master to count the dots when they are on the same sticky.

When everyone has placed their dots, you ask the group to sit down again. Then you sort the stickies and put the topics with the most amount of dots to the top. While doing that you comment on what topics has the most dots and how many votes each topic got. This is just to keep the attention of the group.

At this point you created with the group a prioritized set of topics and therefore you complete the “Gather data” phase.

The next phase is to generate insights about the most important topic from your list. Use the Retromat to find some possible activities for the next phase or read this post to get some ideas.

Required tools

For the Mad Glad Sad Retrospective there are following items required.

First of all you need sticky notes—quite a lot of them, because you want to capture each thought on a separate sticky.

You might even bring stickies in different colors and instruct the team to use different colors for the different columns. For instance, green stickies for the Glad column, blue for the Mad and red for the Sad column.

Then you need a board where they stick. A whiteboard works quite well, but anything made out of glass is ok here. If there is nothing else, you can use the window as your board and place the sticky notes there.

Bring a set of markers instead of pens, because the group should be able to read the text on the stickies from a few meters away. Have at least one marker per person.

When to use Mad Glad Sad

The Mad Glad Sad Retrospective is a very well known and easy format and works in a lot of situations.

It works especially well, when you had a lot of unusual events happening during the Sprint, because then it generates a lot of results from different viewpoints of the participants.

However, if the team had a “boring” sprint without any special events, then this is not the recommended format. Because then there is nothing that made the team particularly mad, glad or sad and you will end up with some “artificial” results.

For instance, if the sprint was working out according to the plan, there was no downtime of the application, no serious bugs, , then what should you write on the stickies?

For such situations the Start Stop Continue Retrospective is usually a better fit.

However, you can steer the group in a specific direction by modifying the original question for the Mad Glad Sad session.

For instance, let’s say your team has a lot of dependencies with another team—let’s call it Team B. Team B is not delivering as planned and this results in a lot of blockers and frustration within your team.

As this is the biggest obstacle for your team at the moment, then in the Retrospective you can ask your team: What made you Mad, Glad or Sad in the cooperation with Team B?

This way you can steer your team and put the focus on a very specific topic instead of making it generic. This also delivers better results for the next phase.

Ok, that’s it for today.

Let me know in the comments, which format you prefer the most. When did the Mad Glad Sad Retrospective work out well and in which situation do you think it should not be used? Please share your thoughts below!

Well then, stay sharp and see you around. HabbediEhre!

Migrate From TFVC To Git – 5 Simple Steps

I talk extensively why you should migrate from Team Foundation Version Control (TFVC) to Git in my guest post at simple programmer, which will be published soon. In this post I am going to explain the more technical procedure on how you migrate from TFVC to Git.

But before I will describe the five migration steps in detail, I would like to give you a short introduction why this whole topic even matters.

Why Migrating To Git

Many teams are using Team Foundation Server (TFS) to support their software development process. There are a lot of features included in TFS, like source control, build server, work item tracking, reporting—basically all the features that are necessary for a professional team to develop software.

TFS also supports two types of source control systems, which are Team Foundation Version Control (TFVC) and Git. While TFVC was supported since the first version of TFS, Git has been added in TFS 2013.

Many software projects have been started before 2013 and therefore are using TFVC. And although there are many benefits when using Git, people who started with TFVC did not migrate yet. They didn’t want to invest the effort.

Here I would like to show you that the migration is quite straightforward compared to the effort you might imagine for such a project.

TFVC to Git is quite easy

Each project in TFS is organized in so called Team Projects, which is the container for a repository, the builds and the work items.

The great news is that you don’t have to create a new Team Project when you migrate to Git. You can create your new Git repository in the same Team Project. This means that a TFVC and a Git repository can live side-by-side in the same Team Project.

This also means, that you don’t need to migrate your work items, your backlog or your kanban boards. You can keep using them the same way as your team is used to.

Even the builds can basically stay the same. Of course, you have to modify them slightly to pull the source code files from the new Git repository instead of the TFVC repo, but the rest of the build steps don’t require any difficult modifications.

Another fact that works in your favor is that we can migrate the whole commit history of the TFVC repo to the new Git repo. Even though there are some rumors that you are able to migrate only the commit history of the previous 180 days (see here), this is not true. You can migrate the whole commit history from your TFVC repository to the new Git repo.

Ok, now let’s see how this migration can be done.

TFVC to Git Migration Steps

You simply need to go through the following five steps to migrate your TFCV repo to Git.

Step 1: Install git-tfs

There are multiple tools to migrate from TFVC to Git. The one with the most features and the best support is git-tfs. You can find some download and installation instructions of git-tfs here.

When you have Chocolatey installed, then you simply need to run following command:

choco install gittfs

Step 2: Export to local Git Repo

After you have installed git-tfs you can run following command to connect to your TFVC repository and clone it into a local Git repository.

git tfs clone http://your-tfs-server:8080/tfs/your-collection $/your-tfvc-repo --export --export-work-item-mapping=C:\temp\git_migration_mapping.txt

This command creates a new local Git repository in your current folder. It migrates all files including the whole changeset history of your TFVC repository your-tfvc-repo to your Git repository.

Let’s have a more detailed look at the parameters of the “git tfs clone” command from above.

Migrate associated work items

By default the associated work items in a changeset are not migrated to Git. However, as we don’t want to lose any information while migrating, we would like to have this info in the commit messages of the new Git repository as well.

Therefore we can use the parameters “–export” and “–export-work-item-mapping={mapping-filepath]”. With the latter parameter you specify a file, which contains a mapping of work item ids.

The work item mapping has been implemented for the scenario when you want to migrate from one Team Project to another. In such a case you also migrate your work items to the new Team Project.

During the work items migration the work items get copied and re-numbered in your new Team Project. With the mapping file you can tell the tool how to map the old work item ids to the new work item ids.

In our case we don´t want to migrate to a new Team Project, but stay in the same. Therefore the work item ids stay the same as well. So our mapping file is quite simple:  

Mapping of workitem Ids

As you can see, we map work item with id 0 to work item 0. Work item 1 is mapped to 1, etc.

My list goes up to 100000, and it will work as long as I don´t have more than 100000 work items in my Team Project.

Finally, our migrated commit messages will look as follows:

This is my original TFVC commit message.
Workitems: #9764
git-tfs-id: [http://my-server:8080/tfs/my-collection]$/my-team-project;C35615

As you can see in this example it also contains the information that this commit is linked with the workitem #9764. So you also have migrated the information about associated work items from your TFVC changesets to the Git history.

Wait for some time…

When you run the “git tfs clone” command with the parameters from above then it will take a while until the new Git repository has been created. The tool has to go through every changeset of your repository and build up the history for the new a Git repo. For me this took about 2.5 days to migrate all information for a single TFVC repository.

If you have additional requirements, for instance you have multiple branches, then this is supported by git-tfs as well. You can find more information in the documentation.

Ok, now we have created a local Git repository. The next step is to manually tidy it up a bit.

Step 3: Cleanup New Git Repository

You can remove the information about TFVC source control binding from your solution. Then you add a .gitignore file.

Each solution file (.sln) should have a .vssscc file, which contains source control binding information. Simple delete all of the *.vssscc files, we don´t need them anymore.

Similarly, each project file has a .vspscc file, which is not necessary and can be deleted as well.

Then you make a small edit to the solution file. Therefore open the .sln file in your favourite text editor and remove all the text between GlobalSection(TeamFoundationVersionControl) … EndGlobalSection.

This removes the information about the connection to the TFVC repository.

Finally you create a .gitignore file. This file tells git, which files it should not monitor for changes, but simply ignore. It is a text file containing a list of files or pathes, which git shouldn´t monitor.

I created a new project in Visual Studio using one of the default project templates and from there I copied the .gitignore file. This is a good starting point, because it excludes many of the files, which we don’t want to have in our repository. For instance, the build output in our Debug folders or user-specific files, like the .suo or .user files.

Ok, now we have a clean Git repository. The next step is to make the local repository available to our team members by pushing it to TFS.

Step 4: Create new Git Repo in TFS

First of all we create a new, empty Git repository on our TFS server, of course within the same Team Project. Therefore open the “Code” tab of your Team Project in the browser and click “New repository”.

Create a new repository

Then specify a name for the repository and click “Create”.

Don´t add a README and don’t add the .gitignore file at this point. We already have a gitignore file and we can always add a README file later. By skipping these steps here you avoid  some conflicts in the next step.

Create a new Git repository without README nor .gitignore file.

Now you have created an empty Git repository on your TFS.

Step 5: Initial Commit to Git Repo

Ok, at this point you have a new, empty Git repository on your remote and a migrated Git repo on your local machine. Now let´s link these two together and push everything to the Git Repo on your TFS.

First of all change into the root directory of your local repository. Then you begin adding all files to the staging area and finally you commit all changes to your local repository.

git add .
git commit -a -m "initial commit after migration"

Then you add the Remote repository by specifying the URL to the remote Git repo you created on the TFS earlier. You can find the URL in the webpage of the newly created Git repository on your TFS server.

git remote add origin https://your-server:8080/tfs/your-collection/your-team-project/_git/MyNewGitRepo

Finally you push all your local changes to the Remote.

git push -u origin --all

Voila, you have now migrated your TFVC repository to a new Git repo!

Now the only task let is to lock your TFVC repo to make it readonly. When you officially switch to Git, then people shouldn’t be able to commit changes to the old TFVC repository anymore. They should only commit to the new Git repo.

Next steps

Now you have a new Git repo and from a technical point of view you are ready to switch to Git.

However, from a organizational point of view there are a couple of more steps required. You have to teach your team how Git actually works. There is quite a difference compared to TFVC, but when you get your head around some concepts, Git is quite easy.

A great tool to teach your team the concepts of git is http://git-school.github.io/visualizing-git/.

With this tool you can easily explain how commits are always linked to a parent. You can also show that a branch is just a pointer to a specific commit, how tags work, what the HEAD pointer is, how to push/pull from/to the origin, etc.

When people understand these concepts, then the rest is quite easy to grab.

Ok, that´s it for today.

If you have any specific questions or insights about the migration from TFVC to Git, then please let me know in the comments.

Take care and HabbediEhre!

Scrum Retrospective 5 – Close The Retrospective

This is the fifth and last post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 5— Close the Retrospective.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage.

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each Retrospective meeting, which I lead as a Scrum Master.

In the previous four phases we have decided what we are going to do about the problems we identified earlier. Based on that we have created action items to improve our process.

Now, let’s finish off our Retrospective with the last phase.

Close the Retrospective

The goal of this last phase is to sum up the results of our Retrospective and generally leave a good feeling behind for the participants of the meeting.

Everyone should leave the room with the feeling that we achieved something useful and that the meeting was worth it.

How do we do this?

I usually take following steps:

  1. Sum up the results
  2. Perform a Retrospective of the Retrospective session
  3. Thank everyone and let them go

Step 1: Sum Up the Results

You want to recap the whole meeting in just a few sentences and remind everyone what problem we have tackled, how we are going to solve it and what we achieved in this meeting.

I keep this very short, like two or three sentences. And I use this recap as the introduction for the next step.

Step 2: Perform a Retrospective of the Retrospective Session

Here you would like to have an input from all participants what they liked about the Retrospective and what could be improved.

There are again a couple of different formats of how you can do this.

For instance, you can ask everyone to name one thing what they learned in this Retrospective. Then you give the word to each participant in the group. This way 

Another option is to ask everyone to write down on a sticky note the one thing they like and one thing they would change about the Retrospective. Then everyone, one after another, puts the stickies on the board explaining what they mean.

With these activities you generally put the team in a spot to celebrate the results of the retrospective. By letting everyone explain their feelings about the meeting you make the results even more important for the team.

In my experience this bonds the team closer together and adds to the team pride. At the end of this step the participants are mostly in a good mood and that´s exaclty how you want the people to leave the room.

Step 3: Thank Everyone and Let Them Go

At this point you can end the Retrospective and let the team go back to their work place and continue with their tasks.

Therefore your final step is to thank everyone again for their time and their effort and close the meeting.


Ok, now I have walked you through the five phases of a Scrum Retrospective.

Keeping these phases in your mind while planning your next Retrospective will give you an organized way of approaching and structuring the session.

The tips I have been describing for each phase should help you to become a better Scrum Master. And the suggestions in each section should help you to avoid some common pitfalls.

But there is a lot more to learn, when you want to become better in leading a Retrospective meeting. As menioned at the beginning of the post, I highly recommend the book Agile Retrospectives – Making Good Teams Great.

It contains a tremendous amount of useful experience provided by the experts Esther and Diana. They walk you through a virtual Retrospective meeting with a virtual team and give you a lot useful insights with many example situations you might face.

In addition the book also contains a list of possible activities for each phase. These activities will help you to keep your Retrospective meeting diversified. They will also help you to avoid that your team gets bored by doing the same activities over and over again.

I can tell you from experience that, when you have read this book, you will be much more confident when planning and hosting a Retrospective session.


Another great online resource to get inspired with ideas for activities for the Retrospective meeting is the Retromat. It contains more than 100 activities and they are categorized in those five phases. You can even choose from a couple of different languages.

The Retromat is a tool I use quite regularly when I plan a Retrospective meeting, because it gives me a lot of ideas for specific activities that can help my team to become even better.

If you know any other great resources that are helpful when preparing a Retrospective meeting, please share them in the comments.

Ok, that’s it for today. I hope you have enjoyed this series of blog posts about the 5 phases of a Scrum Retrospective.

Stay tuned, and HabbediEhre!

Scrum Retrospective 4 – Decide What To Do

This is the fourth post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 4— Decide What To Do.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each Retrospective meeting, which I lead as a Scrum Master.

Until now we have covered the first 3 phases. After Phase 1—Setting The Stage we spend a considerable amount of time in Phase 2—Gather Data to identify the most crucial problems of the team.
Then I covered Phase 3—Generate Insights in my previous post. At the end of that phase we had a list of possible root causes and potential solutions for a problem.

Now, let’s go on with Phase 4 and decide what we are going to do about the problem.

Decide What To Do

The goal of this phase is to create action items to improve in the next iterations.

You identified a list of possible root cause of the problem and potential solutions. Now you want to decide what you want to do differently in the next Sprint.

Therefore you create a list of action items what you exactly want to do differently.

When creating action items there are a couple of things you want to keep in mind:

  1. Make action items actionable
  2. Make action items small
  3. Don’t pick too many action items
  4. Make action items visible

Let’s look at each bullet point of this list a bit more closely.

1) Make action items actionable

You want to phrase your action item in a way that it is completely clear what needs to be done. Be as specific as possible. It shouldn´t require a discussion with the team whether an action item can considered to be completed or not.

An example for a bad action item is “Improve team collaboration”. Phrasing it like this does not tell you what you need to do exactly. It leaves a lot of room for interpretation.

A better example would be “Pair programming on Monday and Wednesday from 10:00 to 12:00”. This tells you exactly what you need to do and when you need to do it. And only if you have really worked together in pairs for those two hours it is clear to everyone in the team that you can mark the action item as completed.

2) Make action items small

You want to make action items small enough so that they don´t have an impact on the amout of planned work for the upcoming Sprint. At this point in the Retrospective you don’t want to commit to work on a big action item.

Planning and prioritizing is done in Sprint Planning, but not in the Retrospective meeting.

If the action item requires a couple of days effort to be completed, then it is definitely too big.

For instance, “Implementing 2-factor authentication for the web application” is too big for an action item of a Retrospective.

If your team is sure that they want to work on that with high priority, then the action item might be “Create a user story for 2-factor authentication and put it on top of the backlog”.

Big action items contain the risk that they are not worked on or cannot be finished in the Sprint. Or something else might be considered more important in the next Sprint planning.

If that happens regularly, then your whole Retrospective meeting has become just a meeting where you commit to things you wish to improve instead of actually improving them.

Having small action items makes sure that they will be completed. Then your team will be consistent in making sure that action items are always finished.

3) Don’t pick too many action items

If you have too many action items it is likely that the team will forget about some of them. It is easy to remember 3 things, but it is a lot more difficult to remember 7 or even more things.

Therefore I make sure that my team creates a maximum of 3 action items per Retrospective so we can keep the focus on the few most important items.

4) Make action items visible

Another method, which proved to work very well, is to make action items visible to the team.

You place the stickies with the action items at a place where the team can see them. Usually I put them on the physical scrum board, which is at the team area. Additionally, you can use some “screaming” colors, like pink or orange, so that they stand out on the board.

Then, a couple of days after the Retrospective meeting, when you see that an action item is not marked as done yet, you can ask the team during Standup about the status. You make the action item “visible” in their mind by pointing it out during the Standup.

So, by making the action items visible to the team in different ways, you can do your best to make sure they will be worked on and completed until the end of the Sprint.

Try-Measure-Learn Loop

There is one more important thing, which you should keep in mind when creating your action items:

Make clear to the team that you are dealing with complex problems here.

Each problem does not have just one root cause and exactly one solution. There might be a combination of circumstances, which lead to your specific problem and therefore there are also multiple things you need to do in order to solve it.

So mostly there is not one obvious thing what you can do to fix the problem. Make clear to the team that Scrum is an empirical approach—you are working with a try-measure-learn loop.

If you have identified a possible solution, you cannot be sure whether this solution might really work. But you can decide to give it a try for a couple of Sprints and measure its outcome.

Then based on what you measure you can learn that this is a good solution and you keep it. Or you might measure bad results and decide to drop that solution, because it didn’t help to fix the problem.

If this is not clear to people, I noticed that some respond very negative to certain action items.

For instance, imagine you have a big issue and you have an action item to tackle that problem. Then, one simple action item is often just a drop in the ocean. This means that even if it is completed it will not have a big impact.

Therefore it is not surprising that some people will react like “That’s not gonna help anyway! We are just wasting our time here with trying to solve a problem we cannot tackle anyway”.

So, making clear to the team that we are working with a try-measure-learn model is a good way to make clear that this is just the first step in the hopefully right direction. This might shift their mind to a more positive attitude regarding the created action items.

Last Step

Ok, so at the end of this phase we have created a few, small, actionable items to improve our process. Now we can continue with the last phase.

You find continue reading about the last phase here: Phase 5—Close the Retrospective.

Meanwhile, if you have any additional remarks about action items, then please share them in the comments section below.

Ok, that’s it for today. See you around, HabbediEhre!

Scrum Retrospective 3 – Generate Insights

This is the third post of my blog post series about the five phases of a Scrum Retrospective.In this post I cover the Phase 3— Generate Insights.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage.

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

We have covered Phase 2 —Gather Data in my previous post. At the end of that phase we had a list of subjects for further discussion.

Now, let’s go on with Phase 3 and generate some insights from those subjects.

Generate Insights

The goal of this phase is to dive deeper in at least one of the subjects from the previous phase. We want to uncover the root cause why certain things happened. And then we want to find options for a possible solution.

We can split this phase up in two steps.

At first we decide which particular subject we want to select. So we have a focus point on one specific subject rather than talking about multiple topics at the same time.

In the second step we dive deeper into the selected subject to find the root cause.

Step 1: Decide for a subject

The decision, which is the most important or valuable subject to pick is sometimes obvious. Often there is a topic, which bothers the team the most. So you as a Scrum Master will obviously decide for that particular subject.

For instance, if the application, which is managed by the team, had a big outage during that sprint, then this is probably the most important topic for the team.

In case the team didn’t already have a separate Blameless Post Mortem for that outage, you as the retrospective leader will obviously decide for that topic.


But sometimes it is not so obvious. In such a situation I usually make a pre-selection of possible candidates and then ask the team to vote.

The pre-selection is just done to make the voting easier, because there are often some subjects that you don’t need to dive in deeper.

For instance, if somebody mentioned that he is so happy that he finished his Professional Scrum Master certification, then this is really great to share within the team. But you probably don’t want to dive deeper into that subject.

After the pre-selection I usually use dot-voting, which works as follows.

Everybody gets a set of virtual dots and can place them on the sticky notes on the board. The sticky note with the most dots wins.

For instance, everyone gets 3 dots. Then they can go to the board with the sticky notes and place their dots there. Afterwards you count the dots and the topic with the most dots will be selected.

Ok, now as we have a selected topic, we can dive deeper.

Step 2: Dive deeper

The goal of this step is to find the root cause of the selected problem.

There are different activities to get to the core of a problem. The retromat can help you to find a lot of possible activities.

My favorite options are to have a discussion with the team or to use the 5 Whys activity. Let’s have a closer look at both of these options.

Facilitating a discussion

Having a focused discussion on a specific issue is a very natural and simple approach.

I have made the experience that people, especially very analytical persons like software developers, don’t like to participate in “weird” activities. One developer once asked me why we are doing these “Montessori” games while we could use our time much more effectively by writing some code.

So I tend to keep the amount of unknown activities low—especially with a team, which is not very familiar with retrospective meetings. Therefore just having a discussion feels very natural to everyone involved, because you have discussions all the time. And a good discussion can create very good results as well.

In order to have a good discussion you need some facilitation skills.

During a discussion some people might be very outgoing and talking and talking and you can hardly stop them. Some other people like to stay in the background and don’t say much. They just give their opinion when you ask them directly.

As a good facilitator it is your job to notice such behavior and do something about it.

For instance, you might interrupt the talking Mary and throw the ball to introvert Tom like this: Thank you Mary for your opinion. Now, Tom, you didn’t say much. What do you think about it?

Another thing I tend to do during discussions is to make some notes about the most crucial points that are discussed. I try to identify possible reasons for problems and possible solutions.

Then I put them on the wall, so the group can use that information in the next phase to take a decision.

To be honest this is very hard to do. Because on the one hand you need to facilitate the discussion and on the other hand you should make notes.

While practicing you will get better over time, but at the beginning I think it is not necessary to make notes. It is more important to properly facilitate the discussion.

Ok, so having a good discussion is a nice way to find the core of a problem. Another option to achieve the same result is the 5 Whys activity.

5 Whys

The 5 Whys activity is a method to drill down to a problem by repeatedly asking Why?

The name comes from the fact that often you often find the root cause of a problem with the fifth answer.

For example, let’s imagine the team struggled with an outage of their product during the sprint. And we want to identify the root of the problem with the 5 Whys activity.

Why was there an outage? Something went wrong during deployment and so the application didn´t start anymore.

Why went something wrong? Because Tom, who started last month, made a mistake. He did it the first time and didn´t have the experience.

Why did he do it the first time? Because Mary was on holiday so somebody had to do it. Unfortunately he didn’t get a proper training before that.

Why was there no training? Because it is not part of the onboarding process.

So we identified the root cause of that problem. And the solution might be to add a proper deployment training to the onboarding process.

So by repeatedly asking Why? you can drill down to the core of a problem. And after identifying the root cause you can look for possible solutions.


Ok, let’s quickly recap the important things of the Generate Insights phase.

The goal of this phase is to drill down to the root cause of a specific problem and find possible solutions.

In the first step we decide on a specific subject, which we want to analyze. For instance by using dot-voting.

In the second step we dive deeper. Among a list of possible options I prefer to have a discussion or use the 5 Whys activity to get to the core of the problem.

When you are done with one problem and there is enough time left for your retrospective you can also try to tackle another subject.

Ok, so at the end of this phase we have analyzed the root cause of at least one specific problem. Now we can continue with the next phase.

You can read about the details of the next phase here: Phase 4—Decide What To Do.

Meanwhile, let me know in the comments about your favorite activities for the Generate Insights phase. Maybe you have something you absolutely love to practice with your team?

Ok, that’s it for today. See you around, HabbediEhre!

Scrum Retrospective 2 – Gather Data

This is the second post of my blog post series about the five phases of a Scrum Retrospective.In this post I cover the most crucial ideas for Stage 2—Gather Data.

If you haven´t read the previous post in this series you can find it here: Stage 1 —Setting the stage

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

Ok, let’s get to the meat.

Gather data

The goal in this phase is to bring the facts of the sprint to the table, so that every participant has the same picture of what happened during the iteration.

I usually split this phase up in two steps. First I announce the hard facts and statistics based on the data the team generated during the sprint. Secondly, we want to get the insights and personal opinions from each individual to generate a complete picture.

Step 1: Hard facts

The idea of this step is to make the status quo transparent, based on the facts you already have. This type of data is usually generated during the sprint and does not reflect any personal opinions, but hard facts.

It is the responsibility of the Scrum Master to get this information before the meeting starts. Even though the Scrum Master doesn’t have to get the data by himself, he is responsible to make sure the data will be available for the meeting.

This data includes: the sprint goal and the amount of planned and delivered story points. Next to that it also includes any other hard facts, which are measured during the sprint.

Sprint goal

First of all I name the sprint goal and we figure out whether we did achieve our plans. Most of the time it is obvious whether or not we made the sprint goal, but sometimes there is a short discussion within the team. This is fine, because I want a collaborative decision if we did or did not make it.

I use this information also to keep track of how the team is doing over time. And you can mention in the retrospective that the team achieved the sprint goal for instance 5 times in a row.

Story points

I mention how many story points we initially planned for the sprint and how many were successfully finished.

Here it is a good idea to have an excel sheet with historical data prepared and show in a graphical overview how the team is doing over time. Keeping this historical data in a diagram can give you insights easily in how the team grows over time, is more productive, finishes more work etc.

Other measured data

You can mention at this point any other important data, which has been measured during the sprint.

For instance, if your team struggles with too many open bugs and too little of them are solved and closed during the sprints, then this is important data to keep track of. This data is usually available easily by having a look at the bug-tracking tool you are using.

In such a case you can announce the amount of open bugs before and after the sprint.

If your team has constantly problems with the high amount of incidents during the sprint, which prevents the team from making good progress with the planned user stories, then this is also important data to keep track of. This data is also usually available in a bug-tracking tool and you can bring this data to the group here as well.

Basically any interesting data, which is measured and might be important to the team, is welcome at this point to share with everyone. This is because it helps that everybody has the same picture of what happened during the sprint.

Data you don’t want to show

But there is also some type of data, which you don’t want to show to the team. This is any kind of data, which might put a specific person on the spot—unless you specifically intend to do so.

For instance, showing how many story points were delivered by each person brings the lowest-scoring person in an uncomfortable situation and doesn´t help the team. Therefore this should be avoided.

You should also make sure to just bring data, which has been measured and therefore is a fact. Don´t bring data, which you think is a fact, but actually is just your personal opinion.

For instance if you know that people didn’t do as much pair programming as initially planned, but you didn’t measure how often they actually worked together in pairs, then don’t mention it at this stage.

At this point it is important to just give the hard facts, which have been measured, to the team so that everyone knows what was going on in the sprint.

Step 2: Personal opinions from each individual

When the hard facts are on the table, the second step in the Gather Data phase is to collect the personal opinions and feelings of each individual.

Here it is important that everyone has a voice. Therefore I always use a format, which gives each individual some time to think on his own and express his or her own opinion.

Silent writing

In order to achieve this I always use a couple of minutes of silent writing, where each person writes down the items on sticky notes. So everyone has to think about his or her own experience, feelings and events during the sprint.

If you don’t use sticky notes, but just start a discussion where everyone shares his or her thoughts, then you usually end up with a very unbalanced set of data. Because more confident people will take over the floor and express their opinions while other participants won´t be able to contribute their thoughts.

Especially if there are a few introverts in the team, these people are not going to speak up while for example the senior developer taking over the floor. Even though the opinion of the introverts might be very valuable, they want have the chance to contribute them to the discussion.

Therefore, for the gather data step I always use a format, which starts with a few minutes of silent writing followed by a round of explanation, where each person explains his or her stickies to the group.

Formats for the gather data step

There are many different formats for the gather data step out there, which basically all work the same way with just slight differences in asking the questions. For instance, there is the Start Stop Continue format, or the Mad Glad Sad retrospective, or you can use the Sailing Boat.

Some of these formats work better than others in different situations. For instance, if the sprint went really well and there is almost nothing to complain, then the Start Stop Continue retrospective is a good way to generate some ideas for improvements.

If you use the Mad Glad Sad retrospective to gather data when a sprint worked really well, then it will basically work, but in my experience you will get much better results using the Start Stop Continue format. If you want to know more about that check out my post about the Start Stop Continue retrospective.


Ok, let’s quickly recap the important things of the Gather Data phase.

The goal of this phase is to bring all relevant data to the table so that every participant has the same information about the sprint.

This data consists of the hard facts, which have been measured during the sprint. These are the Sprint goal, the amount of planned and delivered story points and any other relevant facts, which have been measured.

The second step is to get the opinions and feelings from each individual by a few minutes of silent writing. After that each individual presents them to the team and clarifies what he means.

At that point you have all the important data ready and can continue with the next phase, which is Phase 3—Generate Insights.

You can read about the next post in this blog post series here: Phase 3—Generate Insights.

Meanwhile I would be interested in formats you mostly use to Gather Data in your Scrum retrospective. Leave a comment if you have any interesting insights, which formats work well in specific situations!

Ok, that’s it for now. See ya in a bit, and HabbediEhre!

Scrum Retrospective 1 – Setting The Stage

This is the first post of my blog post series about the five phases of a Scrum Retrospective. I will cover the most crucial ideas for Phase 1 — Setting the stage.

These five phases are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Setting the stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each of the retrospective meetings, which I lead as a Scrum Master.

In this post I will explain what the leader of an agile retrospective needs to know and should do in order to have a successful start of the retrospective meeting.

Setting the stage

The goal of the first phase is to bring the mind of the team to the retrospective meeting so they have their focus on the work at hand.

You want to set an environment where everybody feels save to speak. Everyone should be in a state that he feels like he wants to contribute his thoughts and ideas as much as possible.

People have been working on other tasks just a few minutes ago before they had to stop and go to the retrospective meeting.

Their mind is still filled with the thoughts of their previous task. For example, one colleague might still be thinking hard on how to solve that bug he is currently working on.

The goal for you as the leader of the meeting is to bring the focus of the team to the work at hand.

What, Why, When

In order to set the stage for the meeting you are starting with a short introduction giving some facts about the meeting itself.

You mention the goal of the meeting, which is to reflect on the previous sprint. And you announce the available time for the meeting, giving the participants an outlook on what they can expect how long they will be locked up in this meeting room.

For instance you might say something like this:

Here we are again at the end of our sprint—this time we completed sprint number 56. Let’s look back together and figure out what went well and what didn´t so we can improve our process and become even more productive. Now it´s 4 minutes past 2, so we have exactly 56 minutes to come up with some results.

After this announcement you should have the groups attention.

I learned that there is another important part of Setting the stage, which is to get everybody to say a few words.

Get everybody to speak up

At the start of a retrospective it is important that everyone says something out loud. If you speak out loud at the beginning of the meeting the chance that you are going to join the follow-up discussion increases drastically.

I couldn’t find where I have read about this fact, but I remember that it was packed with some awesome statistics. Since then I always perform this little exercise at the beginning of a meeting.

There are a couple of possible activities in order to give everyone the chance to speak up.

I usually just ask a simple, open-ended question and ask the people to answer shortly one after another going around in a circle.

The question might be: How do you feel about the previous sprint on a scale from 1 to 5?

Another example is to ask the participants to state in one sentence what they want to get out of this retrospective meeting.

And another example might be: Tell us how you feel about the previous sprint in maximum of 3 words!

The retrospective leader has to make sure that the statements are really short, which means just a few words. You want to avoid that people start a discussion at this stage. You just want to get everybody to speak up to generate the mind-shift and enable maximum contribution of everybody in the next phases.

When everyone has put some thoughts to answer the question then the group should have the focus on this meeting. Everyone has put his previous task on hold and put his attention to the work at hand. The mindset of the group is in a state of getting some work done.

Next: Phase 2

At this point you are finished with Setting the stage and you move forward to the next phase, which is: Phase 2—Gather data.

You can read about the next post in this blog post series here: Phase 2—Gather data.

Meanwhile I would be interested in how you kick-off your Scrum retrospective meeting and what you do differently. Do you have any interesting insights, which you can share in the comments?

Ok, that’s it for today. See you in a bit, and HabbediEhre!

5 Major Problems With Synchronous Code Reviews

Reading Time: 8 minutes

If your teams does not use git as a source control system then you should continue reading. Because then you most likely use the synchronous code review type and that’s giving you 5 major problems.

But even if you do use git as a source control system then you still might use the synchronous code review type. If so, then you still have these 5 problems—even though you use git.

With synchronous review I mean a code review, that is performed together in front of the coder´s screen immediately after the coder finished coding.

In contrast, the asynchronous review is done by the reviewer on his own screen, on his own schedule. The reviewer uses some tools to write comments, that are then forwarded to the coder to improve the code.

If you want to know more details about the differences of code reviews I recently wrote a separate blog post about the 4 types of code reviews.

At the time of this writing my team uses Team Foundation Server (TFS) and its built-in source control TFSC (Team Foundation Source Control). Most of the time we also use synchronous code reviews and I found a couple of problems with that approach.

Ok, so what are the downsides of synchronous code reviews?

5 major problems with synchronous code reviews

Synchronous code reviews produce following problems:

  1. Direct dependencies
  2. Forces context-switching
  3. Not done consistently
  4. Time pressure
  5. Lack of focus

Let’s have a look at each of these issues in more detail.

1) Direct dependencies

A big problem for the synchronous code review is the fact that the reviewer has to review based on the coders schedule. Immediately when the coder is finished, the reviewer is expected to stop with his task and start the review together with the coder.

In such a situation the coder depends on the reviewer and has to wait until the reviewer is available. And it is not worth for the coder to start with a new task, because the reviewer should be available soon.

There is a direct dependency between the reviewer and the coder.

And direct dependencies are not good because the more direct dependencies you have in your process flow the higher the chance of blockers.

When the coder is requesting a review the reviewer might be busy with something else, maybe with something more important.

He might tell the coder that he will be available for the review soon.

And the coder is waiting, and waiting, and waiting.

5 minutes, maybe 10 minutes later they finally start with the review. During that time the coder was just waiting doing nothing, except maybe checking his facebook news feed.

In contrast, when using asynchronous code reviews the coder does not depend on the reviewer. When the coder is finished he will use some tools to create a review request and continue with his next task.

With asynchronous code reviews there is no direct dependency between the coder and reviewer and therefore no potential blocker.

2) Forced context-switching

Imagine you are working on your own task and are in the middle of implementing a complex algorithm.

Then your teammate is asking for a review because he just finished his task.

This means that you have to stop working on your own task and review the task of your coworker.

Because of this you are dragged out of the context of your own work.

This has some negative side effects: context-switching is exhausting and frustrating. And it will take you a few moments to focus on the new context.

I have been in the situation as a reviewer by myself a couple of times and I don’t like it.

When the coder started to explain his code to me I had to ask him to repeat the last one or two sentences once more. My brain was still processing the work I had been doing just before and therefore I hadn’t been able to listen to the new context.

After the review is finished you have to switch the context again. It will take you again some time to come back to your own task and the context, where you left off.

In contrast, when using asynchronous code reviews the reviewer can review the code when it fits his own schedule. He is not forced to switch the context based on the the coders schedule

The reviewer can finish with his task first and only then start with the review, reducing the amount of required context-switches to a minimum.

3) Not done consistently

Imagine you are starting to work on a new task.

At the beginning you start to investigate the existing code base to figure out which of the existing methods and classes can be reused.

Let’s assume that a lot of the required functionality is already there and you only have to put the pieces together by calling a couple of methods.

In the end there are just a few lines of code that you had to change to achieve the goal of your task.

Then you wonder whether it is really necessary to ask your colleague for a review. The code changes are actually so simple that it is almost impossible that a review might lead to any improvements.

Therefore, you decide to skip the review and just go ahead and commit the changes. You save yourself and also your colleague some time.

This is a natural and understandable behaviour, but it is dangerous.

How do you decide when a code change is simple enough so it does not require a review?

It is very hard to define rules for that.

Review everything

So the best rule is to just review everything, no matter how small and simple the code changes are.

But even then you most likely have a problem that people are not going to follow this “review everything” rule.

It is just additional effort to get a reviewer to your desk for such a small code change. You have to ask your colleague whether he has time for a review, wait for him to roll over, explain what you were doing, etc.

The barrier for performing a review is actually quite high when using a synchronous code review approach.

In contrast, when the team uses an asynchronous code review approach, then it is quite easy to create a pull request and assign it to your colleague. So requesting a code review is way simpler when you use an asynchronous review approach.

Therefore, the likelihood that a code review actually happens is also higher when using an asynchronous code review compared to a synchronous one.

This argument is implicitly also supported by a survey conducted with 550 developers in 2017.

One finding of this survey was that developers who use a code review tool are four times more likely to review on a daily basis than those using a meeting-based approach.

This result is definitely not a perfect proof for the claim that asynchronous reviews happen more often compared to synchronous ones. But I think you can safely assume that you need additional review tools for an asynchronous review type to give feedback to the code. In contrast, for a synchronous review you don’t need that much tooling, although it might help.

Therefore, the likelihood that code reviews are done consistently is higher for the asynchronous approach compared to the synchronous one.

4) Time pressure

Let’s assume your team is using synchronous reviews and your coworker just finished his task and asked you to perform a review.

So you join him at his desk and he starts to explain about the task and the complex problems he had to solve as part of his task.

As he was spending the last couple of hours to analyze that problem and to find a solution he has a lot of insights and knowledge about that task. Therefore the explanations are very sharp and right to the point.

But it is quite difficult for you as a reviewer to follow. You didn’t invest the last couple of hours to analyze the problem. You didn’t put that much thought into finding a good solution.

Therefore it is very hard for you to decide within a few moments whether the presented solution is the best or not.

But your colleague wants to get his code approved as soon as possible.

This puts you, as the reviewer, in a situation of pressure. On the one hand you want to take the time to think the solution through because you want to validate, whether it is really a good solution. But on the other hand you want to approve the solution so your colleague can move on.

In this situation you are not encouraged to question the solution too much. Even if you don´t understand exactly how the new code works and why it has been implemented that way, you are not going to ask too many questions.

Why? There are three reasons for this:

Trust in coder

First of all your coworker might explain his solution in a very self-confident manner. This builds trust and you might think, that he knows what he is doing. He was working on this for the last couple of hours and the solution seems to be solid and sound.

However, trust is good in a team in general, but not for a code review.

Actually the whole point of a code review is to distrust your colleague and double check everything to make sure the code is really doing what it is supposed to do.

Avoidance to ask questions

Second of all, you as a reviewer don´t want to ask too many questions, because it might look like that you are not able to follow the explanations—or you are just too slow to understand what is going on.

Therefore it is easier to not ask too many questions, because you don´t want to look like a fool.

Avoidance to review same code lines multiple times

Third of all, you don’t want to look through the same piece of code multiple times, when the coder is sitting next to you. Even if you review a complex algorithm that is hard to understand when looking at it for the first time, you are not going to switch back and forth between different code files for a couple of minutes while the coder is waiting next to you.

Because then it might appear that you are not able to grasp the solution. And your mind is just to slow to understand the problem and figure out the solution.

So what happens is that you are not going to look too close into validating the solution. You don’t have the time to think everything through, because of the pressure of having the coder sitting next to you.

Naturally, this results in worse code quality because the review is performed under time pressure and therefore you might miss some potential issues in the code.

In contrast, with an asynchronous review you work on your own schedule and are not under time pressure. You can take as long as you need to understand and review the solution. Therefore it is more likely that you find the bugs before you approve the code.

5) Lack of focus

Let’s say you are in the middle of coding—working on a new complex feature and you are totally focused to implement this new algorithm you have in your mind.

While you are highly concentrated your team mate next to you just finished his task and asks you for a review of his code.

Of course, you are not happy about this.

But you cannot decline the request because your colleague is waiting. He is blocked until you review  his code. Only when the code is approved and committed he can start to pick up the next task.

As you are a nice person you will roll over with your chair to your teammate and do the review.

But you are frustrated.

You want to get back to your own work as soon as possible.

And this feeling has an impact on the quality of code review you perform. You want to get it done as fast as possible, so you can continue with your complex algorithm.

Therefore you don´t look too close and just do a quick and dirty review without putting a lot of effort in it.

This has the effect that you might miss some defects in the code, which you normally would have spotted.

As a matter of fact nobody likes to get interrupted while working on a complex task that requires highest focus and attention.

However, when the team performs asynchronous code reviews you don’t have these problems.

You perform the review when it fits your own schedule, when you have the time and the full mental capacity, then you can put all your attention to the code to review.

How to fix these problems?

Ok, so now I hope I convinced you that synchronous code reviews are bad, if they are used as the default code review type within a team.

There are of course some cases where the synchronous type works best, as I described here, but these cases should not be the norm.

As I mentioned at the beginning my team uses at the time of this writing the synchronous approach as the default review type as well. And we do face all the above mentioned problems.

What are we doing to solve these issues?

Well, we are in the process of moving our codebase to git. With git in place and with the tooling provided by TFS we will be able to use asynchronous code reviews.

I am really looking forward to that, but it will still take some time to prepare the move.

Ok, that’s it for today. Let me know in the comments section if you have any remarks. Take care and HabbediEhre!