Why I advise my clients against agile software development today

Almost everyone was sceptical, but – kudos – they tried it anyway. Two years later, there was only Scrum in this company.

Rightly so. Scrum and other agile methods and frameworks do not solve all problems, but some essential ones. In most projects, agile approaches are clearly superior to the traditional waterfall approach. If I were to have software developed today, I would also do it agilely.

So why do I advise my clients against agile software development?

Because the people I look after today are not customers of software, but providers of software services.

The fact that “agile” is usually superior as a software development method does not automatically apply to the business model around it.

When IT entrepreneurs tell me today: “We offer agile software development as a service” I ask: “Are you sure that’s a good idea?”.

Most of them are sure that it is a good idea and stick to that opinion after I have made my arguments.

That’s OK, because in fact the business model “agile software development as a service” has many advantages.

If these advantages are more important to you than the disadvantages, you are well advised to go with the business model and stick with it.

The advantages:

• It is a simple business model (most customers and employees understand it),
• it is robust (because it does not require a lot of roles and organisation in the company),
• it is safe (as long as you have clients, it is not hard to make profits) and
• it is efficient (gets by with little “overhead”).

But the model also has disadvantages, from an entrepreneur’s point of view even some serious ones.

In the end, every founder must decide for themselves whether the advantages or disadvantages outweigh the disadvantages, and depending on what is particularly important to them personally, the result will be one way or the other.

To make it easier to weigh up the pros and cons, here are the disadvantages of the business model “agile software development as a service”:

Disadvantage #1: It is almost inevitably a time-for-money business model

Anyone offering agile software development charges hourly or daily rates. Anything else takes a lot of imagination and regularly stumbles with the agile mindset.

The problem is that nothing scales worse than time. Now that the labour market is making it very difficult for IT companies to scale with more and more employees, companies are in line for growth. Those with big plans have a hard time with this business model.

Moreover, hourly and daily rates allow for easy and secure profits, but rarely particularly high ones.

Most software companies can proudly tell you that their software helps a client save millions of euros every year. However, the software was sold for half a year’s work, for example, for 80,000 euros. With a different – value-based – business model, the customer would certainly have been prepared to pay 150,000 or 200,000 euros – and that every year.

Profits almost always multiply when a software company switches from time&material to value-based. But value selling and a business model that prefers to sell Scrum teams by the week do not mix well.

Disadvantage #2: The company owns … nothing

The knowledge and skills belong to the employees and they work remotely or in a home office – and tomorrow they might work for another company. The code belongs to the customer. The processes are agile, i.e. standardised and identical to those of all other software service providers. The developed frameworks are only used (and understood) by the people who built them. The Product Owner is an employee of the client, the leadership in the team is self-organised, the Scrum Master is a freelancer.

What exactly does the software company still contribute?

Or put another way: if the company were to close its doors today, what would be missing tomorrow? In quite a few cases, the answer is: nothing. The client would take over “his” employees and everything would continue as before.

In fact, I now regularly hear of situations where clients and employees have decided to settle directly with each other. Mostly with the argument: the service provider has now cut along long enough without any visible service, from now on “cut the middleman” applies.

Disadvantage #3: It is very difficult to stand out from the competition

In times like these, when the demand for software development capacity is greater than the supply, good positioning may seem an expendable luxury.

But there may come a time when you have to compete for customers and they will want to know what makes you stand out from the other providers.

After all, they also have great developers, excellent references and good code quality. At least that’s what they all claim, and it’s hard to prove. They all work in an agile, standardised way anyway.

So what exactly remains as a distinguishing feature apart from the hourly or daily rate?

Disadvantage #4: What’s the point?

“Hey, we have nice colleagues, a fruit basket and table football, alternatively 100% home office. We code agilely and earn quite decent money doing it. What more could you want?”

Well, some people do want more.

You could also say: after the 60th sprint, you’ve seen it all. The customer may change and the app you build, possibly even the technologies you use to do it.

But the idea of a working life as an endless chain of sprints in which you work through inexhaustible backlogs does not motivate everyone.

As a developer friend of my age said the other day: “180 more retrospectives until retirement.”

If you start doing the maths like that, you might start to look a little enviously at your colleagues who are building some cool sh**** in their crazy start-up, working on improving the world in a visionary company or tinkering with their own product in an innovative shop.

In other words: Recruiting is getting even more difficult.

Conclusion

Of course, there are major differences between agile software service providers and for many none of the disadvantages described may apply. In this case: Congratulations, your company is a prime example of the industry.

Everyone else might want to think about their business model. About positioning, developing your own assets and new pricing models. Operationally, little changes for most employees. Because of course it is a good idea to continue to develop software in an agile way.

Notes:

Alex Rammlmair describes in his book “Das Ende der Tagessaetze” (The end of daily rates) different pricing strategies for IT companies that want to scale. Here you can find a short description of the book and a hint which time investment could be particularly valuable for IT companies.

If you like the post or want to discuss it, feel free to share it with your network.

Alex Rammlmair has published two more posts on the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.