Why digitalization should start with agile transformation
It is more effective to first consider the "how" of a digitization project – and then the "what"
The competition produces more cost-effectively or has found a way to transfer the business model to the digital world. Technologies that are hyped but only partially understood threaten to be the necessary tool for newcomers in the market segment to massively lower the barrier to market entry and achieve rapid success. In extreme cases, the company's own core product clearly no longer has a long-term future and the search for new ways of creating value has begun. These are some examples of the reasons that prompt a company to launch digitalization projects. Agreement is quickly reached on the "what" – the technical project objective and framework. There is a certain amount of uncertainty about the "how", as the environment reports that things should be done "agilely'' nowadays in order to be able to react flexibly to future market requirements.
Focussing on the “How”
As a result, an agile transformation is proclaimed downstream, which fuels the digitalization project according to one's own wishes and contributes to its success. The minimum consensus here is that the development teams should work with Serum. I am convinced that this approach – especially the sequence – significantly increases the risk of the digitalization initiative failing. Knowing "how" to carry out digitalization projects is more important in the initial phase than "what" to implement. Focusing on the "how" creates the conditions for sustainable organizational development and protects the company from (at least financial) damage.
Agile software development does not prevent a wrongly defined "what". Following the traditional way of thinking, companies typically invest a lot of time and money in defining the "what" of the digitalization project. Specialist and technical architectures, project plans and cost estimates for budget applications are drawn up. At the end, there is more or less an outline of a functional result artifact and perhaps a new process landscape (with savings ... ). Budgets are drawn up - in the worst case for years - and responsible persons are appointed. The fate of the company is tied to the success of the initiative.
Beware of the agile scaling trap
Then the agile development organization is set up. The professional path is prepared and the internal pressure is high. The motto "a lot helps a lot" is often used to fall into the agile scaling trap, even though agile thinking is not yet anchored in the individual teams. The focus of agility is therefore on the teams. The product owner role is truncated in terms of real customer contact and serves more as a proxy for the technical translation of what a still largely classically thinking product/portfolio management has come up with.
In such an environment, the true beneflts of agile working cannot unfold. This is because the self-learning cycle in the teams is limited to the "how" of software development, not the "what" that should ultimately make the company successful. As a result, significant strategic corrections are also excluded: They are not supported methodically and the sheer size of the apparatus that has been created out of thin air immediately develops forces of inertia.
Agility also provides answers in the development of the "what"
Before I start thinking about the "what", it is much more expedient to take a look at the "how" – based on methods that build on the agile mindset. Using agile methods in software development is only half the battle. A core aspect of the agile mindset is customer orientation, and that's exactly what I need if I want to be able to talk about the "what" in a valid way. Following this insight, an entire ecosystem of innovation and product development approaches based on the agile mindset has developed, which sharpen the actual needs and make the digitalization ideas plausible in small steps, self-reflectively and, above all, in exchange with real customers.
Such agile design approaches are seamlessly linked to agile software development. Preto-typing, proto-typing, proof of concepts and minimum viable products always provide new insights into the actual requirements and the necessary direction of the product at different investment levels. We start small, validate, check plausibility, experiment, pursue successful approaches and discard misguided ones. The full potential of agile thinking is exploited and the well-known principle of the agile manifesto "Responding to change over following a plan" is practiced holistically (and not just in relation to the technical component of software development). I can still define budgets. 1 start with small tranches that get bigger and bigger depending on the maturity of the development step. After each technical iteration, I validate the potential anew. The basic principle is the willingness to drop action lines as early as possible (and thus actually write off the investments made so far) rather than staying on an unpromising path. In this way, I secure the investment in the long term.
A suitable error culture is essential
Starting with the “how” means starting with agile transformation. lf I really want to start the digitalization project in the way described, I must have already anchored agile thinking in the organization. What is needed is a suitable error culture (in the sense of a willingness to make mistakes, see also LinkedIn post), a willingness to experiment, a self-organized working environment that promotes creativity and, ultimately, knowledge of methods in modern product development. This is no coincidence. lt is the result of an agile transformation – even if only in a localized cell. Once I have built this up, the foundation is also laid for a slowly scaling, increasingly agile development organization. At the same time, I avoid methodological disruptions that could potentially arise from classic market approach and product development strategies interacting with agile development.
Even if this – possibly local – transformation costs time and money, I am firmly convinced that such an approach is immediately worthwhile. The resulting product will better reflect customer needs and the time to market will be earlier - despite the supposed loss of time due to the transformation!
