Measures for a change of the project approach in an ongoing 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 already very accurately described the causes for the considerable conflict potential that the introduction of agile methods holds in their article “Taming the Trojan Horse: Preparing Agility Effectively”: 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 understood – especially if the participants lack actual experience 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 actual people involved, but also – especially in strongly hierarchically organized companies – all stakeholders understand what agility actually is before the project begins. 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. Its 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 predictions of poor quality and would thus above all be an act of self-deception.
Of course, in agile projects it is also 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 approach 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 approach in an ongoing project is also associated with considerable risks and challenges.
Such an adjustment is therefore definitely not recommended. However, if there is no alternative, there are two ways to limit the risks associated with the change. 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 approach while the project is running – 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 the project approach in an ongoing 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 the project approach 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 able to carry out an analysis phase that is cleanly separated from the development phase during a change of procedure in the ongoing 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 an ongoing project
If, despite the arguments raised in the risk analysis, the stakeholders still decide to change the project approach, the second step is to carry out the analysis in parallel with the development. 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 a reliable forecast as to when the software can be delivered with all documented requirements, the development efforts should be estimated conservatively in the analysis phase 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 actually agile project even after changing the project approach. 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 even after the 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 estimation. 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 approach into the daily project routine
The third step is to transfer the newly selected approach to everyday project work. In this context, the project team concerned naturally plays a key role. True to the motto ” Transform those affected into those involved”, informing employees and discussing 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 approach 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.
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 he or she 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 approach 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.