How to protect your startup from being killed by developers. Part 2 – Should I use Scrum or other Agile practices?

I have worked with startups as a tech consultant for over a decade. A tech startup is not just a technical solution. Many important things like investments and marketing make a business successful.

However, it’s hard to sell just an idea. You need to implement it. Right?

Looking back to all these years and all my clients, I want to advise those who are starting their tech business today to help them save their money, go to the market faster, hire the right developers, choose the right software development company, and run the whole process most efficiently.

See also Part 1 – Roles

Part 2 – Should I use Scrum or other Agile practices?

How many times have you heard that Scrum is something that magically helps to get rid of all problems of your development process? I heard it for many years, repeatedly. And that is true sometimes.
But as always, the devil is in detail.
First, you should accept that you have no chance to go any other way except Agile with your startup. Our environment will not allow us to go the waterfall way. So, you are already agile. You don’t need Scrum or something for this.
Then, let’s try to identify possible risks and issues in iterative or Agile software development. First, let’s define what is Agile. Agile development, opposite to waterfall development, is a methodology to develop a product step by step. And make these steps as small as the job that can be done in 2-4 weeks. And after every iteration, the initial goal can be reconsidered and get more details. An alternative product can be developed in the waterfall way when every small detail is defined at the very beginning and then implemented according to the initial plan.
The most crucial reason for Agile to be so popular is that product owners and business executives are just not sure about the details. The time needed to address all unclear details is longer than the time needed for the details to change. The impossibility of clearing all the details at any point in time leads us to need to adapt our vision continuously and act in uncertainty. A good illustration of this could be the excellent book “The Hard Thing About Hard Things” by Ben Horowitz. Developers can work in the waterfall very efficiently in many, if not most, cases, but can you define the project as detailed as the waterfall requires it?
In my opinion, Agile is more about business owners than about developers. Executives should be agile first, accept and address all risks introduced by agile. Below is a list of risks that Agile can introduce.

• Unclear budget and high possibility of failure
• Impossibility to identify stable models in code, database, and other modules
• Technical debt and poor quality because of a rush
• Developer burnout and mental health issues because of continuous stress

I’m sure this list is incomplete. But these are the most critical problems which happen to many teams. Let’s talk about every risk and about how to manage it.

Unclear budget and high possibility of failure.

First, you need to accept it. There are different statistics about startups. Some said that only 40% are profitable, others that 90% fail. It’s a good question how all these things were measured, but in any case, according to the statistics, you most probably fail rather than succeed.
To make this failure just another step on your way and increase your chance of success, you need to have a good go-to-market plan. This plan should include the scope of your first release. You should make this release achievable, and you should be ready to reduce the scope. The best is to define pessimistic and optimistic scopes. Budgets and scopes are much more predictable in the waterfall because of the massive preparation and investigation stage. But we can’t afford this in the modern world. The result of the investigation will be wrong at the end of the investigation because the world will change during this time. But that doesn’t mean that you should not keep your goal in mind. You need to understand what is important and what is not. I would say this understanding is key to keeping your first release within budget and valuable for end-users. Start with something simple and valuable, and when it starts generating income, proceed to additional features. I would say your maximum budget should be 2-3 times bigger than the estimate for the first release.
When developers play scrum, they will start planning improvements on the first retro. It is your duty to keep only the required improvements and avoid all these “refactoring” things for subsequent releases. The idea of “continuous refactoring” can kill your business. But on the other hand, if you are increasing technical debt, you will have problems in the future. But if you do not make the first release, the future will not come. So, you should keep a balance.
Another problem is the stability and quality of 3rd party libraries, frameworks, and services. But this topic requires a separate article.

Impossibility to identify stable models in code, database, and other modules

Models in code are usually a class or other component hierarchy. In the database, it’s tables or other collections in the case of NoSQL DBs. In all cases, we have some abstractions as an equivalent to entities in your domain. Your domain is changing dramatically in the case of Agile. The crucial are changes to the structure and relationship between entities, especially fundamental ones. And here, you never know what your developers treat as fundamental. So many times, I saw how minor changes in requirements led to a complete redesign of the system. Unfortunately, all these Abstract Factories, Mementos, Dependency Injection, Inversion of Control, and other patterns can be so easy. destroyed by slight changes in the structure of fundamental entities. KISS (https://en.wikipedia.org/wiki/KISS_principle), not SOLID(https://en.wikipedia.org/wiki/SOLID), should be your main principle. But that doesn’t mean that your developers can not know what SOLID or Inversion of Control is. They must know patterns and principles but not over-engineer the system, understand and keep in mind the goal of the next release, and put it in the first place. To be fair, in the waterfall, this problem is not so significant as we know everything before the start of the project.

Technical debt and poor quality as a result of a rush

Sometimes, to survive as a business and have a chance for the next iteration, you should force your developers to do really bad things in your code, mainly when you need to add some feature immediately. There is no simple solution to the problem. Just treat your code as an asset. Invest in it when you can and use it when you need it. To do so, you need a way to measure the value of your assets. Here, we can use some automatic code quality measurement tools, bug rate statistics, and other metrics. The question of value and quality of the code is a very complicated question, so don’t rely on simple tools or metrics. Use multidimensional measurement.

Developer burnout and mental health issues because of continuous stress

The unpredictability of Agile leads to overtime, work at night, and on weekends. Tired developers are bad developers. Often, two developers who are working less can produce more from the point of view of money/value, and one developer works overtime. But often, two developers are less productive than one, especially when they have too many meetings and discussions. Developers are for development, not for talking. You should keep meetings productive and developers busy. Good descriptions of tasks are an effective way to get rid of redundant conversations.

So, what about Scrum?

Scrum and similar methodologies allow you to uncover problems and manage risks. It’s a tool to collect information about the development process and apply supervisory control. The scrum master is the one who keeps the system clear, but only you can interpret collected metrics and apply correct control.