Mixed Agile – Waterfall approach when implementing business applications (aka Agile-like)

In the world of modern IT technologies, when numerous applications from Google Play and Appstore daily inform about updates, hearing from the project team for the implementation of the ERP system “the project will take from 9 (optimistic) to 12 months (realistic)” is quite common. Moreover, there are more complex projects. In one of the companies where my friend worked, only the stage of creating and signing the design of the processes lasted 6 months. The volume of the design document turned out to be quite impressive and, in printed form, could well save the life of a warrior from ancient China (they say that they used paper as material for their armor). The days of ancient China have passed, but today this stack of paper continues to save, if not lives, then at least the nervous systems of consultants at the stage of putting the system into operation. But what the design document does not save from is the shift in the timing of the launch of the project and problems with the quality of the system to the moment of commercial operation. Let's try to figure out why this is happening and whether it is possible somehow differently.

Imagine that you are ordering the repair of your new apartment. Before starting work, the contractor team asks you to sign a text document, usually without illustrations, about how your apartment will look after the repair, including all the details: sockets, switches, furniture, etc. The team leader warns that changes during the acceptance phase are more likely total will lead to additional costs. For this reason, you responsibly approach the task, spend a lot of time and in the end sign the document. Well, suppose you leave for six months from the country. And completely trust the implementation team to do the repair yourself without any control and monitoring on your part. After six months, come back, go into the apartment and see that the finished apartment does not fully meet your expectations. Then you ask the project team to redo some details, for example, move the sockets closer to the refrigerator. The project team says that it will be quite expensive to transfer the sockets and take a lot of time, because you have to hollow the wall, and there are tiles, etc. You go into the bedroom, turn on the already installed air conditioner, and understand that it will blow directly at you at night . Ask the team to move it, but you get about the same answer as with sockets. Nevertheless, this is a matter of principle for you and you say that you will not start living in the apartment until the air conditioner is where you need it, because in your current apartment it is exactly where you need it, and you don’t see the point in moving, if it will worsen the comfort of your daily life. As a result, you call in an apartment 3 months later than the original plan with a 20% budget excess.

The main problem, in my opinion, is that we are trying to foresee and fix all the details at the design stage before starting work. The design phase is delayed, because business users rarely can completely devote themselves to the project, they have to deal with their daily business processes. By the time the design is signed, they have accumulated a fairly extensive backlog of pending tasks and they are no longer ready to get involved in the project until the testing stage. They have already spent a lot of time planning all the details and would like to see a ready-made system. However, the finished result does not meet expectations. One reason for this is illustrated below:

In our company, we are successfully piloting a new approach to projects for the implementation and replication of ERP systems. At the same time, on replication projects, the approach allows you to complete the project even faster than the usual plan with successive phases of design, development and testing (aka Waterfall).

We have moved from this:

To that:

We call this approach mixed (Waterfall – Agile) because we use both Agile elements (sprinting) and Waterfall (commercial operation only begins after the completion of the entire project). The acceleration is due to the fact that, firstly, we work with business users in parallel (work on the design of future sprints and customization, development of current ones), and secondly, we “transfer sockets” closer to the future refrigerator before the tiles are laid and kitchen set assembled. The larger the project volume, the greater the time and quality gains compared to the classic Waterfall approach.

Sample project in Mars using a mixed approach

The main characteristics of the project:
• 5½ periods (22 weeks) from Start to Start
• Full project team – 40 people (business users and IT consultants, developers)
• 4 functional teams within the project team – Finance, Purchasing, Logistics and Sales, Quality Control Department
• 4 cycles of Business testing with 93% of successful scripts on the first try. 5 full-time workshops

At the pre-project stage, we estimated that we would do the project in 30 weeks. In fact, using the Agile approach, we did everything in 22 weeks. For 4 months of operation after launch, we received 1 change request from the business.

Key Success Factors

Internal IT teams. As soon as possible, arrange with key IT teams that will be involved in the implementation. Enlist management support to engage in dialogue with an external contractor.
External contractor. The project team of the contractor should include professionals who are well aware of the system itself and Agile implementation principles. Beginners should not be. Conduct selective interviews with the team before signing the contract.
The business team There should be an opportunity and desire to be regularly involved in the project during all phases of development. This does not mean that the business will have to work more. We redistribute their time from the usual design and testing phase into each segment of the development.

Some frequently asked questions

Question 1: The sales department asks to sign a contract with a fixed-value contractor before development begins. But how to evaluate the cost if there is no completed and signed design?
Answer 1: We sign a Fixed Team contract with a contractor – we fix the team and the project implementation time, for example, 8 months. This is not the same as Time-Material, as we record the duration and total amount of work. At the same time, we remain flexible in changing / adding business requirements if the duration of the project and the team does not increase.
Question 2: What if business users constantly add new requirements during the review and planning of each sprint?
Answer 2: In this case, we ask you to prioritize the requirements and remove those that have the lowest priority and do not fit into the project deadlines. Those. add a new one instead of something existing. All these changes / new requirements will wait for us in any case at the acceptance stage, regardless of the approach. But in the case of intermediate acceptance at the end of each sprint, we have more opportunities to manage these requirements, while when accepting immediately before launch, we risk the timing of the launch and the quality of the system (quality by definition is the correspondence of the final result to the user's expectations, not text design).

If you are interested in this article, you have questions, or you just want to share an opinion about the above, then I will be grateful if you share feedback under the publication or in a personal message. Illustrations and ideological content of the article with the participation of Angelina Abdullaeva angelina.abdullayeva.

Similar Posts

Leave a Reply