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. 

Wartime

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.

Sheepherding

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

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!

The 5 levels of team dysfunctions

I recently attended a scrum master training, where we were discussing the five dysfunctions of a team. This model has been introduced by Patrick Lencioni and it explores the dynamics of teams. The model describes in a pyramid the five dysfunctions of teams and offers solutions to help teams perform better.

The model of the 5 team dysfunctions gave me a couple of “AHA” moments and I immediately tried to find out, at which level my team stands. If you are not already familiar with this pyramid, then I bet you can find some useful insights about team dynamics.

Continue reading “The 5 levels of team dysfunctions”