Effective teams: Always releasable

This is the fifth post in a series about what makes a team effective. Effective means, the team does the right thing to reach its goal.

Your code prevents doing the right thing

I often see teams that want to do the right thing but can’t. Their software won’t let them.

This is caused by lots of loose ends in the source code. Everything is begun but nothing is finished. There are simply too many open tasks. Or there is a lot of technical debt present. Before the team can do what it needs to do, it has to pay back a lot of technical debt. And there is often not the time for that. A third cause is lack of automation. Everything has to be done by hand. This is error prone and slow. And all takes too much time to do it right, so just add a shortcut more to get it done. But this makes things even worse the next time a decision has to be made.

In the diagram you see the cost of change should be constant over time (the same change costs today as much as in a year). The responsiveness to change should be high during the whole project.

But technical debt sneaks in. At the beginning this is not noticed, the additional cost is only small. But there come the times when the team realizes that responsiveness goes down. And this happens normally rather fast. The problem is  when you notice a drop in responsiveness then you have already aggregated a lot of technical debt. There is no quick escape. And that is the point were all goes down to hell. It is very very hard to get out of this situation. The only professional way to deal with this is to prevent it from happening at all.

Clean code

The only way to prevent technical debt to sneak in is to write clean code. Code that is as simple as possible and as understandable as possible. Code that is so easy to understand that defects cannot hide in it. Changes can be made easily, with no side-effects.

We started to refactor our code before adding new functionality. First, refactor the existing code in a way so that the change can be added easily. Second, add the new functionality. Third, clean-up the result to be as simple and understandable as possible. When refactoring first, making the change becomes much easier. Easier means less defects, less headaches, less stress, less technical debt.

Continuous everything

Clean code is not enough. In order to get fast feedback about the changes we made, we need continuous integration and continuous deployment on every commit to the source code repository. All stakeholders (including developers, testers, PO, usability experts) can take a look at the current development state. This leads to a software that always works and can always be installed. In other words, your software is always releasable.

This gives you the flexibility to make decisions any time. Even decisions that completely turn around where you are headed can be made and the team can immediately start going in the new direction. No long list of TODOs that has first to be worked through.