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!

Nexus – the scaling Scrum framework

Nexus is a framework, which builds on top of the scrum framework and is designed for scaling. It focuses on solving cross-team dependencies and integration issues.

What is Nexus?

The Nexus framework has been created by Ken Schwaber, co-creator of the Scrum framework.

Similar to the scrum guide, there is also the Nexus guide, which contains the body of knowledge for the framework.

It has been released by scrum.org in August 2015.

You can find the definition of Nexus in the Nexus guide as follows:

Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.

The Nexus framework is a foundation to plan, launch, scale and manage large product and software development initiatives.

It is for organizations to use when multiple Scrum Teams are working on one product as it allows the teams to unify as one larger unit, a Nexus.

Scrum vs Nexus

Nexus is an exoskeleton that rests on top of multiple Scrum Teams when they are combined to create an Integrated Increment.

Nexus is consistent with Scrum and its parts will be familiar to those who have worked on Scrum projects.

The difference is that more attention is paid to dependencies and interoperation between Scrum Teams.

It delivers one “Done” Integrated Increment at least every Sprint.

New Role “Nexus integration team”

The guide defines a new role, the nexus integration team.

It is a Scrum team, which takes ownership of any integration issues.

The Nexus integration team is accountable for an integrated increment that is produced at least every Sprint.

If necessary, members of the nexus integration team may also work on other Scrum Teams in that Nexus, but priority must be given to the work for the Nexus integration team.

Event “Refinement”

In Nexus the refinement meeting is formalized as a separate scrum event.

In the cross-team refinement event Product Backlog items are decomposed into enough detail in order to understand which teams might deliver them.

After that dependencies are identified and visualized across teams and Sprints.

The Scrum teams use this information to order their work to minimize cross-team dependencies.

Event “Nexus Sprint Planning”

The purpose of nexus Sprint Planning is to coordinate the activities of all Scrum Teams in a Nexus for a single Sprint.

Appropriate representatives from each Scrum team participate and make adjustments to the ordering of the work as created during Refinement events.

Then a Nexus Sprint Goal is defined, an objective that all Scrum Teams in the Nexus work on to achieve during the Sprint.

After that the representatives join their individual Scrum teams to do their individual team Sprint Planning.

Event “Nexus Daily Scrum”

The Nexus Daily Scrum is an event for appropriate representatives from individal Scrum Teams to inspect the current state of the Integrated increment.

During the Nexus Daily Scrum the Nexus Sprint Backlog should be used to visualize and manage current dependencies.

The work identified during that event is then taken back to individual Teams for planning inside their Daily Scrum events.

Wrap up

This is a very highlevel overview about Nexus, you can find more information in the Nexus guide or in this nice introduction.

I am practicing Scrum for quite a while now, but I have never heard about Nexus before. Only last week I stumpled upon it on the Internet.

Therefore I also don’t know anybody who is actively using the Nexus framework in their daily work.

But from this point of view it looks like Ken Schwaber did a very good job again when defining this framework.

I hope that I will have the chance some time to work with Nexus in real life. Of course, for that you need to have the environment where it would make sense to give the Nexus framework a try.

Ok, that’s it for this week. Have a good day and HabbediEhre!

Scrum values – new section in scrum guide

The scrum guide, the official description of the scrum working methodology, has been recently extended with a new section: the scrum values.

Before we dive deeper in what the scrum values are about and what they mean, I want to give you a quick overview on the history of scrum, and especially about the history of the scrum guide.

Then it should be easier to understand the big picture, when and why the scrum guide has been created and updated over the years.

History of scrum

Scrum is now about 21 years old.

Jeff Sutherland and Ken Schwaber, the fathers of scrum, presented their paper “SCRUM Software Development Process” the first time in 1995 at the Oopsla conference in Austin, Texas.

But the name scrum was not their invention. They inherited the name from the paper The New New Product Development Game published by Takeuchi and Nonaka a few years earlier.

Scrum is used to solve complex problems. It uses an empirical approach and solves problems based on experience and facts.

Until today scrum has been adopted by a vast amount of software development companies around the world. But scrum has also been successfully applied in other domains, for instance manufacturing, marketing, operations and education.

History of scrum guide

Jeff and Ken published the first version of the scrum guide in 2010, which is 15! years after their first presentation of scrum at the conference. I don’t know why it took them so long nor what has been used by the community before that.

Jeff and Ken made some incremental updates to the scrum guide in 2011 and 2013. Together they established the globally recognized body of knowledge of scrum, as we know it today.

Recently, in July 2016, a new section has been added to the scrum guide: the scrum values.

The scrum values

Successful use of Scrum depends on people becoming more proficient in living following five values: commitment, courage, focus, openness, respect.

Let’s have a look at each of those values including the one sentence of description from the scrum guide.

Commitment

People personally commit to achieving the goals of the Scrum Team.

I am personally very happy that this value has been added to the scrum guide and is now officially recognized as an important value for a scrum team.

It is a challenge to get the team to commit to the goal of a sprint, but it is a cruicial part in making the team successful.

Courage

The Scrum Team members have courage to do the right thing and work on tough problems.

People should stand up for their beliefs and for what they think is important to put the team to the next level.

People in a scrum team should not be afraid of though problems. They face even the thoughest problems and try to solve them together.

Focus

Everyone focuses on the work of the Sprint and the goals of the Scrum Team.

People are not picking up work outside of the committed sprint. They focus on the work, which has been agreed upon in the sprint planning.

Everybody works on what is good for the team, not what is good for themselves. The goals of the team have a higher priority than the personal goals.

Openness

The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.

There is no hiding of facts or not telling the whole truth about what is going on. There are no political games played.

Everybody is honest about the problems they face and for instance explains why things are delayed to give the stakeholder insights of what is happening within the team.

Openness in the team as well as openness to the stakeholders builds trust and a better working environment.

Respect

Scrum Team members respect each other to be capable, independent people.

Respect is one of the key elements of building a good culture within the team and in the whole organization.

Treat people as you want to be treated!

Why has the scrum guide been extended?

How were those changes in the scrum guide implemented?

Ken and Jeff built a community around the scrum guide and they are running an online platform, called users voice, where people can make suggestions for changes in the scrum guide.

Other people can vote for those suggestions, but the final decision for making changes in the scrum guide is still taken by Ken and Jeff.

Wrap up

Today scrum is recognized as the most applied framework for agile software development.

The scrum guide plays a very big role in the success of scrum, because it is the first reference point for people wanting to learn more about it.

The newly added section containing the scrum values are a very welcome idea to improve the scrum framework even further.

I will definitely present those scrum values to my team to make them think about this topic and get a discussion rolling. Let me know, if you did the same and share your experience in a comment.

That’s it for this week. Stay tuned and HabbediEhre!

Definition of story points

Story points are all about effort and only about effort. A story point has nothing to do with complexity or uncertainty of a user story.

The definition of story points is not obvious.

Many scrum teams use story points in their daily job, because they are better for estimations than hourly estimations for many reasons.

But it is not clear how a story point is defined.

If you ask google, then you get a couple of different definitions.

Continue reading “Definition of story points”

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?”

Traditional vs empirical process

What are the differences when you implement a project using the traditional approach vs an empirical way of working? During a scrum workshop, which I attended recently, this question has been answered in a very descriptive and visualized way, which I want to share with you.

Continue reading “Traditional vs empirical process”

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”