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!

Netherlands biggest interest in Scrum worldwide

How interested are people in Scrum? Is it´s popularity growing or declining? What about the interest in Agile or DevOps?

A few days ago I stumbled upon the website from google, called https://trends.google.com, which tells you what people search for on the Internet using the Google search engine.

It´s amazing how the Internet works today. Google alone currently receives about 60.000 search requests per second! Yes, per second!

I was actually curious to see what people, who are interested in Agile and Scrum, are looking for.

So I clicked a bit around and found 3 interesting results, which I would like to share with you:

“Scrum” most popular in the Netherlands

It turns out that people from the Netherlands searched for “Scrum” the most compared to any other country in the world. I looked at a time range of the previous 12 months (November 2016 to October 2017).

Google Trends: Scrum

The numbers are calculated on a scale from 0 to 100, and represent a search interest relative to the highest point (for the chart in the middle of the picture) or relative to the location with the most popularity for the search term (for the list on the end of the picture).

A higher value means a higher proportion of all queries, not a higher absolute query count. This means, the numbers are relative to the size of a country and therefore you can compare a very small with a very big country easily.

The result is very interesting for me, because I (still) live in the Netherlands and I know that Scrum and Agile is big here.

But I didn´t know that people in the Netherlands are leading the ranking and have the highest interest in Scrum worldwide.

St. Helena and China are (to my surprise) on the second and third place in the ranking. I will revisit both of them in a minute.

If you compare the Dutchies to Switzerland and Germany, which are on the 4. and 5. place in the ranking, then the interest there is just about 50% compared to the Netherlands.

I expected the U.K. and the U.S. somewhere in the top places, but I found U.K on rank 20 and U.S. even on rank 25.

 

Another interesting result:

“Agile software development” most popular in St. Helena

If you are like me, then you might ask yourself: Where the f*ck is St. Helena?

I had to look it up in Google maps as well, it´s a small Island somewhere in the middle of the Atlantic Ocean. It probably sounds familiar to you as well, because this is the Island, where Napoleon was banned after he lost the Battle of Waterloo in 1815.

Anyway, there live around 4500 people on the Island and they are obviously crazy about Agile software development.

If you go there for holiday you probably find agile people all over the place. 🙂

Google Trends: Agile

As you can see in the graph, the popularity of “Agile software development” was quite stable throughout the year, but started to increase since August 2017 (until today November 2017).

So, either Agile software development is really getting more traction since the last 3 months, or google made changes in one of their algorithms.

This is just interesting for me, because the amount of page views on my blog increased as well. It actually follows pretty much the same pattern as above – quite stable throughout the year, and then a linear increase within the last 3 month.

So I thought, maybe the graph in google trends is actually caused by my blog?

Well. I wish 🙂

Anyway, here the last interesting result I found:

“DevOps” is very popular in China

Come on!

China?

That´s weird!

Google Trends: DevOps

If you look at the numbers, then the Chinese interest in DevOps is way ahead. St. Helena again, on second place, has only 55%. And then we have India on the third place with only 40%.

 

But anyway, I think Google trends is a very interesting and powerful tool. And it is really fast.

It gives you insights in what people are searching for on the Internet using the Google search engine.

And the cool thing is, that Google gives you access to this information for free.

So have a look at it and play around. There are quite some nice features to discover.

Btw: if you were wondering why the graph has its minimum always at the same time in all of the three graphs, then I can tell you that people don´t want to know about Scrum, Agile development or DevOps at the end of the year. 🙂

It seems, like everyone is at home celebrating Christmas and New Year, and spending no time searching the Internet for these topics.

But that´s happening not only for these three topics, but the amount of queries in general goes down during these days.

If you want to look into this further by yourself, here are actually the links to the queries I used in google trends:

Ok, that´s it for today. Stay tuned and HabbediEhre!

Core Scrum CHECKLIST – Doing real scrum?

The core scrum checklist is a great and easy way to determine whether you are doing real scrum.

The core scrum checklist is an easy way to find out, whether you are really doing scrum.

When I started in my new team we had all the scrum events in place – sprint planning, daily standup, demo session, retrospective meeting.

But it turned out we were still missing some important elements for really doing scrum.

How about your team? Is your scrum process really ok?

Verify with the following simple checklist!

Continue reading “Core Scrum CHECKLIST – Doing real scrum?”

How to choose a reference task

A reference task is a certain task, which has a fixed amount of story points assigned, and which is used as a reference point to estimate other tasks. But how do you choose such a reference task? This post should give you a method and some ideas, how you can find a good reference task.

Continue reading “How to choose a reference task”

Why agile? – The Stacey complexity model

Reading Time: 4 minutes

The stacey complexity model categorizes tasks in four different categories: simple, complicated, complex and anarachy. Then the model explains for each category what is the best approach to solve those tasks.

Did you ever hear the question “What is agile?” and you didn´t have a proper answer right from the top of your head. Or did somebody tell you, that agile is something from the software development world. Then I guess it is not so easy to explain to those people, that agile is a working methodology, which does apply to more than only software development departments. I think I have quite a good diagram to explain, for which type of tasks the agile way of working is the best.

A few weeks ago I attended a great scrum master training in my company at LeaseWeb. One of the first items on the agenda was the Stacey complexity model, which helps you to understand uncertainty in a project.

Continue reading “Why agile? – The Stacey complexity model”