Prostep | Newsletter

Agile methods in projects for major customers

By Norbert Lotter

In today's world, agile methods are the state-of-the-art when it comes to IT project management. Corporations also use them in large-scale IT projects that they implement together with service companies. The most common agile process model is Scrum, which has to a great extent replaced the conventional waterfall model and its variants. It does, however, require a redefinition of customer/supplier relationships.

In the past, large-scale IT projects involving external service providers were usually executed on the basis of service contracts and billed at a fixed rate. This model is incompatible with agile methods in that there is no longer a clearly defined scope of delivery that could be the subject of formal acceptance and billing at the start of the project. Instead there is a rough target (product vision), a timeframe and a team. This means that the customer's management must make an investment decision without a detailed cost estimate, rather like a declaration of intent: We will invest the sum of x euros within a defined period of time in order to achieve a specific objective without knowing the detailed results in advance and without having a contractual basis for demanding the result should this become necessary.

This not only requires a change in thinking when it comes to project controlling but also has a direct impact on the remuneration arrangement as measurable criteria for evaluating supplier performance need to be identified. There are basically two variants: billing for the number of hours worked (time and materials) or for deliverables (agile fixed price). The time-and-materials model is easier to implement from an organizational perspective, but it shifts all the project risk to the client. The deliverables-based model is in principle a fixed-price model with very small billing units (user stories), whose constraints are regulated by a framework agreement. It requires significantly more organizational effort when it comes to acceptance and billing but results in greater transparency and a more even distribution of risks.

Conflicts can become problematic when assessing the overhead of user stories because the parties involved are more or less at an impasse. If the supplier estimates the overhead for a user story to be significantly higher than the client is willing to accept, neither side can force the other to accept their view of the situation. This means that assessment conflicts must be resolved constructively within the framework of the collaboration. A general feature of agile collaboration models becomes particularly apparent here: They require a high level of mutual trust and great willingness to resolve conflicts constructively. Proponents of agile principles will counter that this applies to the successful implementation of IT projects in general and that agile process models such as Scrum merely demonstrate a methodical way of dealing with them professionally and in a results-oriented fashion.

Scrum is in itself only designed for teams of up to nine people. Software relevant to industry such as PLM systems, however, require much larger development teams, thus giving rise to the question of how collaboration between a more or less large number of Scrum teams can be organized efficiently.

The approaches proposed in the literature, such as LeSS and SAFe, are typically based on a multi-level model, with operational work taking place on the lower level and coordination on the upper levels. LeSS, for example, aims to minimize overhead. Here, the operational teams send representatives to the upper level teams and the Scrum process is only modified slightly. SAFe, which is currently the most widely used approach, introduces a total of three levels and numerous new roles and events.

There are differing views on how well Scrum can actually be scaled in practice. There is no simple solution to the main problems that arise when coordinating creative work in large organizations. It is, however, becoming evident that, as the size of the project teams increases, binding content-related and technical definitions that are valid for all actors and a deep, shared understanding of the overall objective become critical success factors. Conveying them is more important than finding the supposedly perfect scaling method.

Using an agile process model poses certain risks if more comprehensive digitalization measures are to be implemented in a company's extensive IT landscape. It could be tempting to launch larger projects without sufficiently clarifying the objectives and constraints and hope that it will be possible to clarify these points during the course of the project. This often leads to expensive dead ends. Unfortunately, the methodology does not provide any clear recommendations as to what should be clarified and defined in advance and with what level of detail. The project participants must therefore make this decision based on their own experience and strike a balance between creative chaos and over-specification à la the waterfall model.

Experience shows that a lack of process knowledge and inadequate analysis of the data model in particular can result in expensive abortive developments, which could be avoided or at least reduced with a little more conceptual preparatory work. It can therefore be concluded that sufficient attention also has to be paid to the process and data model description when using an agile approach in order to ensure that a solid conceptual basis for implementing the desired functionality is available at an early stage. This information should then be communicated to all project participants so that the creative scope that an agile approach creates can also be exploited in the context of the overall objective.