Building a start-up: What founders need to bear in mind
NeoCargo celebrates successful go-live
Agile software development - where are the advantages?
Hagen Buchwald talks about agile software development and the advantages of this system in an interview.
For decades, the plan-driven, closed approach was considered the measure of all things in software development, but it has now been superseded. The trend, which we at NeoCargo AG are also following, is towards a benefit-driven, open approach: agile software development with scrum. Our Supervisory Board member Hagen Buchwald talks about the use and the advantages.
Mr Buchwald, you are on the supervisory board of NeoCargo AG and for over a decade you were the CEO of andrena objects, a consultancy specialising in agile software engineering with more than 400 employees today. In this role, you introduced agile software development to your clients. What exactly does that mean?
Buchwald: Software systems are invisible at the beginning of development. The customer does not see what is being created and what benefits will arise from the system. The goal of agile software development is to achieve executable software as quickly as possible in order to make the software system visible and tangible for the customer. Executable software allows the customer to be actively involved in the development process. In the case of NeoCargo, we succeeded in doing this after the first sprint, i.e. after 14 days of development. Five months later, we put the first version of the NeoCargo platform into production. This speed is crucial for the success of the overall project.
Why?
Buchwald: So that we can ask our customers this very question as early as possible: Why? Why do we need exactly this functionality? What benefits does the customer hope to gain from it? And do our experiences in operation show us that the new functionality actually provides the hoped-for benefit?
Are such questions not rather the task of the technical advisors in the analysis phase?
Buchwald: In the plan-driven approach: Yes. In the benefit-driven agile approach: No. There we rely on findings from our experiments with real users, not on assumptions made in advance in an analysis phase.
So is there no longer an analysis phase in the agile approach?
Buchwald: In the agile benefit-driven approach, the analysis - in contrast to the plan-driven approach - does not take place in advance as a separate phase, but continuously in the form of regular events every sprint. Just like design, implementation, testing, going live and operation. All within a sprint with a duration of 14 days. And all within a team that is cross-functional for this reason.
What is the argument against a sound analysis phase at the beginning of the project?
Buchwald: Digital product innovations are complex projects. Complexity means, among other things: Everything is networked with everything else. And many of the assumptions we make in advance about the complex problem or its potential solution in a plan-driven approach in an analysis phase turn out to be wrong in implementation. And force changes to the plan. The basic assumption of the plan-driven approach that changes are the exception does not stand up to a complex project. Changes to the plan are not the exception, but the rule. The agile approach makes this its own.
Changes are welcome. They show that assumptions were flawed and need to be corrected. Correcting faulty assumptions means learning. The agile approach is a learning approach. Learning in small steps, day by day. Therefore, it is wise to slice the elephant - the complex problem.
Sprint für Sprint wird die am höchsten priorisierte Scheibe gemeinsam mit dem
Kunden analysiert, eine Lösung designt, umgesetzt, getestet und in Produktion genommen.
Aus der Art und Intensität der Nutzung durch die Endanwender lernen wir, ob
unsere Annahmen zu Beginn des Sprints zutrafen und korrigieren sie, bevor wir
nach dem gleichen Schema die nächste Scheibe angehen.
What is the advantage of this salami tactic?
Buchwald: We talk about just-in-time redefinition, which is typical for Agile Requirement Engineering. What exactly is to be implemented in the next sprint and how we should implement it is clarified as late as possible. This increases the likelihood that we could already uncover and correct faulty assumptions before we get down to the actual implementation. The closer the analysis and design of the next slice is to its actual implementation, the more time we have to learn what really needs to be implemented from the user's point of view and how best to go about it.
The salami tactic as a kind of continuous analysis to learn more about the actual benefits?
Buchwald: Yes, you can sum it up like that. It is important to realise a real benefit for the end user. Anything that does not promise a benefit is not even developed. On the basis of the executable software - we talk about a product increment - we can discuss the benefit of a new function with the client much better than on the basis of document-based specifications that are based on assumptions that are already outdated. The client and the software development team embark on a learning curve together: What does the end user really need? Is this new functionality technically feasible? And is the effort involved worth it economically?
How do you get such a process going?
Buchwald. With the right starting question: What is the core benefit that the digital product innovation should provide? This question is at the heart of the project. And we approach the answer to this question iteratively and incrementally. Iterative, because each sprint follows the same pattern. Incrementally, because each sprint delivers a new product increment, i.e. an extended functionality of the software system. This new product increment allows us to conduct new experiments with the end customer. And the experiments help us to correct our assumptions and set the right priorities for the next sprint.
Experiments with the end customer? An empirical approach?
Buchwald: The agile approach calls it empirical process control. Scrum promotes joint, continuous learning through regular events that specifically challenge and promote communication within the Scrum team and with the customer. We talk about Inspect & Adapt - i.e. keep checking and adapting, a highly effective learning approach. Scrum teams identify risks early on through regular Inspect & Adapt, correct faulty assumptions and maintain the focus on the benefits for the end user. How do they use the features put into production? Which of our previous assumptions do we need to correct? What should we focus on in the upcoming sprints? If you keep asking yourself these questions, you will get to the goal of a digital product innovation that delivers real value faster and with a much higher probability of success.
The benefit for the customer as the guiding star of the project team?
Buchwald: You could indeed say that. Agile software development defines the project in terms of benefits. Time and budget are the answer to the question: What is this benefit worth to us? And by when do we want or need to put this benefit into production in order to be able to achieve the value? Through regular feedback loops and sprints, course corrections can be made more quickly. And thanks to feedback, both sides learn from each other and keep an eye on the benefits.
Is the focus exclusively on the benefits? What about economic efficiency and technological feasibility?
Buchwald: In fact, the agile approach is a permanent balancing process between three seemingly competing goals: The user as the user of the system wants to have an attractive, easy-to-use software system as soon as possible that makes his work noticeably easier. The client, as the business owner, wants the product to be highly economical and thus the development costs to be as low as possible. And the development team as the owner of the technological feasibility wants to maintain the inner quality of the software system in order to keep the software young and malleable and thus to continue to be able to implement change requests quickly and easily.
Why are they seemingly competing goals?
Buchwald: Because high speed helps to keep costs low. And because a high internal quality of the software forces simple solutions, which in turn help to keep costs low and the implementation speed high. One of the difficulties in introducing agile software development is to bring about this "aha" effect, that the goals of speed, cost-effectiveness and quality are not antagonists, but - if you approach it right - mutually reinforce each other. This is also the reason for the experience of many customers that Scrum is easy to understand but difficult to implement.
Wie leicht oder schwer war die Einführung von Scrum bei NeoCargo?
Buchwald: NeoCargo hat eine ideale Ausgangsposition. Als junges Start-Up schleppt NeoCargo keinerlei organisatorischen oder technologischen Ballast mit sich herum, kann also frei agieren. Es herrscht eine familiäre Arbeitsatmosphäre, mit direkter, offener Kommunikation und klarem Fokus auf ein spannendes Ziel. NeoCargo tickt also schon von sich aus agil. Da passt Scrum perfekt als Arbeitsmethode.
So is it possible to implement agile software development according to Scrum without any external help at all?
Buchwald: It was important for NeoCargo to consistently live all three pillars of agility right from the start: methodically with Scrum. Technically with agile requirement engineering. And technologically with agile software engineering. This agile triad does not fall from the sky. It requires guidance and role models who exemplify how Scrum works, what a productive Scrum team feels like and how to consistently maintain the inner quality of the software from day one. To this end, we have enlisted the support of andrena objects. Especially in the technological field, learning Agile Software Engineering quickly is important.
Why?
Buchwald: One of the core problems of young start-ups is the lack of know-how in the field of Agile Software Engineering. The result is an unconscious accumulation of technical debt. Technical debt slows down development. The former speedboat becomes a lame barge. Agile software engineering helps to limit these debts to an acceptable level. It keeps the resulting software young and malleable. Exactly what we need to be able to deliver a new product increment every 14 days.
It stands to reason that such software development is a good fit for a start-ups that are themselves flexible and agile. Does this also work in large corporations?
Buchwald: For this, you need the will to consistently align yourself with the agile software development model and to train your software developers to become agile software engineers. One of the companies that changed in this direction in Germany was SAP from 2009 onwards. By downsizing its teams and maintaining a close exchange with customers, the software company reduced the development time in product development from 15 to less than eight months in the following years. Or as Jim Hagemann Snabe, the SAP CEO at the time, said: "Almost as fast as a start-up". Since this turning point, agile software development has arrived in the mainstream.