Currently, it can be observed that the only thing that counts in agile transformations is the speed with which new functionality is implemented for the end customer. In sprints, increasingly complex structures are thus created aiming to generate immediate added value for the user.
So far, so good – but is this sustainable?
After all, the underlying IT architectures are often used for purposes for which they were never intended. Original use cases are extended and applied to issues that would actually be solved in a completely different way. In order to provide new functionality as quickly as possible, compromises are made in the implementation, resulting in technical debts that accumulate over time.
No one likes those technical debts that are typically the last item on the backlog. Yet they must be managed, maintained, and minimized because their emergence cannot be avoided. Therefore, structures are needed to proactively reduce such debts over time before they prevent the implementation of new use cases. In other words: The technical foundation must also be developed.
But how do you get the person in charge of the budget from the specialist department to invest in the foundation if this does not yield any immediate new functionality?
The goal is to distribute risks evenly
The poor technical foundation is accompanied by another problem. In our role as an IT service provider, we observe that today the client carries the risks in agile projects almost exclusively. The provider only allocates the apparently suitable human resource capacities, but is no longer measured by the work results.
The opposite is true: The provider no longer has any incentive to deliver good quality, because every recorded hour means more revenue.
Many providers have the capability and knowledge to take on more than just project and delivery risks. They are even prepared to be measured against the business success of the application.
Why not share the success of a solution with its creator, making them an integrated part of the value chain? This would also be a consistent implementation of agile paradigms, according to which all stakeholders should care about adding value to the product and services – including the providers.
Killing two birds with one stone
In such a collaboration model, the provider takes responsibility not only for the prompt implementation of new functionality and support in case of problems in production, but also for the foundation of the application. In this way, they ensure that technical legacy systems are avoided or eliminated. This is how comprehensive technology management of an entire application from a single source works!
There is another aspect that is extremely important for the provider: It is becoming increasingly difficult to find employees who are willing to work with the old technologies. However, if they are able to keep the foundation up to date themselves, this has a positive effect on the attractiveness of their work. And for clients, this solves a problem that they are happy to get rid of.
The provider therefore has a personal interest in delivering good quality and using new technologies, while the client can share their project risks. A typical win-win situation.
Remuneration is based on the achievement of jointly defined KPIs that are relevant to the client's business success. These KPIs should also take into account elements of software quality. If the client is successful, so is the provider – and vice versa. In other words, risks are shared and the provider assumes responsibility.
Applying DevOps principles
The provider has a very high degree of freedom in implementing the individual work packages, as long as they adhere to the client's architecture, compliance and reporting requirements. The development team organizes itself in line with DevOps principles. The client acts as the product owner and obtains all rights to the built solution.
This approach has another positive effect: The expenses can be capitalized in the company's balance sheet as operating costs (OPEX) and do not tie up capital there (CAPEX). The balance sheet is reduced and becomes more flexible because no long depreciation cycles are required. In addition, these costs can be directly attributed to the originator, which results in a cost transparency that did not exist before.
At the end of the day, the only thing that matters to the client is that they can use a solidly built, performant and secure application generating measurable added value for them over a long period of time.
