A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
Durstexpress
Agile Software Development In Complex System Landscapes
Gunnar Obst
Nowadays software development is characterized by continuous change, rapid adjustments and increasing complexity. Serving the customer in the best possible way is the greatest goal, along with efficiency. To achieve this, there are always new technologies, an ever-increasing amount of data to use and various agility methods available. Agility is indeed imperative today to develop requirements in line with the market. During development or change, it is necessary to check whether requirements are changing and react accordingly. However, one must not lose sight of the big picture and the dependencies.
In organizations, agility in software development is becoming more important. Almost no development team today does not work in an agile manner. There are cross-functional teams in which developers, designers, product managers, quality assurance work together with Scrum masters or agile coaches. The development process is organized in sprints and software is built and extended iteratively, piece by piece.
The number of software components and techniques used has increased, for example, due to microservices or the use of cloud technologies. System landscapes have also changed accordingly and offer a high degree of flexibility, for example with continuous integration. No more waiting for a release every 6 months, but new versions or bug fixes every 1-2 weeks or even continuously.
In addition, product teams e.g. in e-commerce have become more specialized and there is not only a store team, but one for the home page, the product detail page, the recommendations and the checkout. The coordination efforts increase accordingly. Due to the bigger complexity of the systems and system landscapes, it is also becoming ever more challenging to think of every single aspect.
My observations and experiences in practice taught me that the agile way works well across teams. These changes have significantly accelerated the speed of development and delivery. Varying customer needs can be responded to quickly, so the products gain a high level of acceptance.
What is missing in some cases, however, is a holistic view of things. Only a few members of the organization are aware of the significantly more complex system landscapes and their dependencies - especially the technical and business view in combination.
Sometimes the checkout in the store is modified and the corresponding team is forgotten to be informed to adapt the data and tracking concept. Or a manual credit note process is partially automated, but the interface to the ERP, accounting and reporting system is overlooked- to name just two examples.
To ensure the success of large and comprehensive development initiatives or system changes, Durstexpress has established a small, powerful team of in-house consultants. These colleagues are experts in the individual value-stream processes and support all business and tech colleagues. The goal is to ensure the business processes are integrated holistically in the software applications and data flows. In doing so, all stakeholders must be involved accordingly, informed about changes or trained.
In the following example from last year, I describe how at Durstexpress we successfully met the challenges mentioned - introduction of delivery windows.
The requirements were extensively analyzed by Business Development and researched in the market. In the further course a project was set up, in which an in-house consultant supported. During the project initialization phase, it quickly became clear that a number of development teams (including the design team) would have to be involved. In addition to the pure integration of the functionality into the web shop and the warehouse management system, Operations and Customer Care applications had to be provided. Furthermore, Purchasing had to rethink its inventory limits in the procurement process to ensure sufficient stock levels in the warehouse.
Integration phase:
During the analysis of the dependencies, the current software products, and the current technical infrastructure, doubts arose about incorporating the new functions into production. There were too many dependencies to the payment process and to the order handling. The result was the development of a new order processing service (the Order Engine), and the connection of a new payment service provider. These efforts were not yet apparent at the start of the project and were integrated into the ongoing project.
Rollout phase: As the integration progressed, there were also (as is often the case in larger projects) small delays here and there. Thus, we took another detailed look at the go-live planning and decided to take an iterative approach. First, we enabled the new payment provider. The pure backend functionality of the delivery windows went live in advance and ran in shadow mode. Then, when the store integration was ready, we went live for individual cities first and later
Initialization phase:
The initial requirement that came from the business was the need for the delivery window functionality. It should be possible to choose a defined delivery window within the following 3 days in addition to the immediate delivery.
for clusters of cities. This allowed us to better ensure the stability of the individual services. In addition, we were able to quickly find small bugs and fix them without major customer impact.
Overall, the project was a great success. The newly released delivery windows were very well received by customers and helped us improving our operations’ planning.
Takeaways: To be fast, not every detail needs to be defined at the beginning of an initiative or project. It can be worked out in parallel along the way. It helps to reflect regularly and make adjustments to, for example, the scope or process if necessary. A governance structure should be set up according to the project, its scope and the assigned team. It does not matter who takes the overall coordinating role. The important thing is that somebody with overarching knowledge impersonates this role - regardless of whether it is a business owner, product manager, project manager or in-house consultant.
