Measures for changing the project procedure in the current project

It is hard to imagine software development without the agile project approach. Since the signing of the "Agile Manifesto" some two decades ago, numerous companies have gained experience with agile working methods and thus contributed to establishing agility as an alternative to the classic waterfall model. Despite the many years in which agile methods have been and continue to be used successfully in numerous projects, there are still conflicts - especially when agile projects are located in traditionally oriented organizational structures. How can such controversies be effectively countered?

My colleagues Ulrike Fuchs and Benedikt Jost have identified the causes for the considerable conflict potential which the introduction of agile methods holds in their article "Taming the Trojan Horse: Prepare Agility Effectively" already very aptly described: At first glance, agility appears to be an easily understandable concept, the main features and advantages of which can be grasped in the twinkling of an eye. For this reason, the concrete effects on the processes and structures of a company are often underestimated or not fully penetrated - especially if the participants lack actual experience values in agile work at the beginning of the project.

This problem becomes even more acute when an agile project is located within a company with a traditional organizational structure. While the classical project management often practised in such organisations is based on the maxim of planning projects in detail and being able to predict the course of the project on the basis of this planning, such approaches are not transferable to the agile methodology. In contrast to classical project management, which is predestined for stable business environments, agility can be understood as a reaction to business environments that are becoming increasingly complex and dynamic due to digitalization, globalization and increasing networking. In such environments, it is hardly possible to define concrete, long-term goals. Instead, projects must be driven forward iteratively and incrementally in order to give them the necessary flexibility and capacity to act in the contexts described.

If stakeholders lack an understanding of the characteristics of complex business environments and the resulting need for agile methodology, conflicts are inevitable. If the agile project has not previously been granted sufficient degrees of freedom, friction points can quickly arise, especially at the interfaces to the traditional organization - for example, if long-term project plans and analyses are expected in controlling or reporting.

Agile projects should be prepared intensively

Due to this problem, it is of crucial importance for the success of an agile project in a classical organization that not only the direct participants, but also - especially in strongly hierarchically organized companies - all stakeholders understand what agility actually is before the start of the project. The first step should therefore be to analyse the business environment, the characteristics of the envisaged project and the previous structure and culture of the organisation. If this analysis comes to the conclusion that the project operates in a complex and highly dynamic context, it should be made clear to all project participants that the agile methodology is the only way to work successfully in such an environment. Their introduction is therefore not arbitrary, but a necessity. If this context is understood and accepted, attention should be paid to the concrete consequences of the introduction of agile working methods on the processes within the company. In this phase, both the different empirical values with agile methods should be collected and different expectations formulated. On this basis, the exact framework conditions and degrees of freedom of the agile project within the company can be determined and defined.

The commitment of all stakeholders achieved in this way is an important step in preventing conflicts in the course of the project. However, it is not a guarantee that there will be no difficulties at all. For this reason, signs that key stakeholders within the traditional organisation are dissatisfied with the project's progress and associate this dissatisfaction with the agile methodology should not be lightly ignored. Instead, the conversation should be sought as soon as a conflict becomes apparent. In such a discussion, it should first be made clear once again that the transparency regarding project costs and progress, which is difficult to guarantee and often causes displeasure, is not a consequence of the agile methodology itself, but of the complex environment. In such a project context, even waterfall planning, however detailed it may be, could only provide poor quality predictions and would thus be above all an act of self-deception.

Moreover, in agile projects it is of course possible to make statements about the progress of the project to a certain extent. However, a stable project environment is a central prerequisite for this. If a project team can work together in constant size and composition over several sprints, the velocity of the team can provide information on how many functionalities can be developed during an iteration. On this basis, it is possible to make predictions about the further progress of the project - provided that at least a rough definition of the objectives of the application is available.

If such solutions do not satisfy the stakeholders and they insist on detailed long-term forecasts of the project progress, agile work is hardly possible anymore, so that a change of the project procedure from agile to waterfall seems necessary. But is such a turn at all meaningful? The honest answer to this question is no. There are several reasons for this. On the one hand, by turning away from the agile methodology, companies deprive themselves - as already indicated - of the only effective way of working in complex business environments. On the other hand, a change of the project procedure in the current project is also associated with considerable risks and challenges.

Such an adjustment is therefore definitely not recommended. However, if there is no way around it, there are two ways to limit the risks associated with switching. From a project management perspective, the preferred option is certainly a clear cut: In this case, the development would be stopped for the time being in order to carry out a full analysis of the requirements. The project could then be continued as a pure waterfall project. In reality, however, it is unlikely that any of those responsible will get involved in such an approach. After all, a development freeze usually does not only lose time, but also money. In view of this, it is often only possible to adapt the project procedure during the course of a project - and thus, metaphorically speaking, to cause a horse that is already galloping at full speed to turn around with all the consequences.

Three steps to enable a change of procedure in the current project

Step 1: Risk analysis

It goes without saying that such a turnaround is not completely risk-free. Nevertheless, the risks associated with the change of project procedure should be analysed in a first step and pointed out to the stakeholders so that they can make competent decisions regarding the further progress of the project.

The risks associated with a change of approach are manifold: For example, the advantages of agile software development tailored to the peculiarities of complex business environments, such as the high development speed, the flexibility resulting from the short development cycles and the early and continuous creation of value - i.e. precisely the reasons why organizations usually opt for an agile approach - can usually no longer be guaranteed when switching to a waterfall project. As a final consequence, stakeholders must expect that fewer requirements will be implemented at the end of the project term than would be the case if the agile approach were to be maintained, or that the term might have to be extended. The probability that the project will fail completely also increases significantly as a result of the changeover. In addition, the project team is not in a position to carry out an analysis phase that is cleanly separated from the development phase in the event of a change of procedure in the current project, during which the requirements can be collected and analysed and documented in the necessary depth of detail. This creates the danger that the requirements and complexities of the resulting software will not be fully penetrated and that challenges and difficulties may develop in the course of the project which could have been avoided in a project planned as a waterfall right from the start.

On the one hand, it cannot be ruled out that the project team did not correctly understand all customer wishes due to the comparatively quick analysis and incorrectly implement something that does not fully meet the requirements (such an erroneous development would be detected and adapted early in the agile process). On the other hand, it can happen that a requirement is incorrectly assessed in its scope and therefore the budget may not be met.

Step 2: Estimation of effort in the current project

If, despite the arguments raised in the risk analysis, the stakeholders still decide to change the project procedure, the second step will be parallel to the development of the analysis. For this purpose, all requirements that have not already been implemented in an agile procedure are collected and assessed within the project team in terms of their complexity and the time required for their implementation. Based on this estimate, the further course of the project can then be planned up to the targeted go-live.

In order to be able to give stakeholders as reliable a forecast as possible as to when the software can be delivered with all documented requirements, the development costs in the analysis phase should be estimated rather conservatively for two reasons. On the one hand - as already described above - there is a high risk that the effort will be underestimated due to the lack of intensive analysis.

On the other hand, the lack of a clear cut between the agile and the waterfall project phase can lead to stakeholders regarding the project as an essentially agile project even after changing the project procedure. Due to this hybrid position, it can easily happen that project participants from old habits continue to introduce new requirements into the project or change their opinion on decisions that have already been made. However, this attitude deprives the established waterfall methodology of its strengths. A clear estimation of effort and costs is difficult to make when requirements change from agile to waterfall.

In order to be prepared for such difficulties, it is advisable to work with so-called T-shirt sizes for the effort estimation, which allow the project team to create a certain range instead of a concrete estimated value in person days or story points for the development effort of a certain feature. For example, the T-shirt size M can span from 5 to 8 person days, while the T-shirt size L can span from 13 to 21 person days. In this way, best and worst case scenarios that may occur in the further course of the project but cannot yet be predicted in the estimation can also be taken into account in the effort estimate. For reasons of transparency and acceptance, however, stakeholders should be informed about this procedure and ideally actively involved in order to avoid misunderstandings later on.

Step 3: Integration of the new process model into the daily project routine

The third step is to transfer the newly selected process model into everyday project work. In this context, the project team concerned naturally plays a key role. True to the motto "Make those affected into participants", the information of employees and the discussion of backgrounds should therefore have top priority. Possible criticism should be accepted and discussed honestly and appreciatively. Those responsible should therefore not try to convince critics of the correctness of a step of which they themselves may not be convinced, but should persuade them to support the change of project procedure despite their understandable reservations.

Since every project and every team is different, there is no magic formula for this communicative work, so that tact and individual approaches are necessary to take the team along the new path and to search together for new practicable processes. Finally, several variants are conceivable at this point. Thus, in addition to the option of fully switching to the waterfall model in the project team, there is also the option of retaining the agile methodology to a certain extent. For example, developers and QA, whose direct contact with stakeholders outside the project team is usually limited, could continue to be enabled to work agilely in sprints. In this case, the interface between the classical organization and the still agile core team would be the project management and the business analysis, which would translate the classical project requirements and the agile results for the other side. This also accentuates the role of the project manager to a certain extent: not only does he have to be able to endure and moderate the different interests at the interface between the classic organisation and the agile core team, but he also has to see himself increasingly as a communicator and motivator.

bottom line

The answer to the question whether a project should be implemented agilely or faithfully to the waterfall methodology still seems to many decision-makers to be the result of an arbitrary decision-making process. Accordingly, in many organizations the misbelief is widespread that one can decide on the basis of soft criteria such as personal preferences or the previous corporate culture for one of the two variants and change to the other if one does not like it. But it is not that simple: it is not personal inclinations or cultural considerations that determine the choice of the appropriate approach, but the given framework conditions that influence organisations and projects.

Organisations should therefore pay more attention to the analysis of these framework conditions before the start of the project in order to make the right choice for their situation. Especially in times when more and more business environments are becoming more complex and dynamic as a result of digitalisation, globalisation and networking, this decision would have to be made more and more frequently in favour of agile methods. Nevertheless, the introduction of agile working methods - whether due to personal preferences, pressure from superiors or incomprehension - is frequently withdrawn. Especially in an ongoing project, such a change of project procedure is associated with considerable risks and challenges and definitely not recommendable. However, if such a change is unavoidable, the measures presented in this article can help.