Contrary to popular belief, Waterfall is still alive and well (yes, even in software development). True, Agile as a delivery model has been winning “the battle” for quite some time now, and it is even making a name on its own in industries other than software, and making a noticeable impact  Forbes agrees btw.

Despite the downfalls of Waterfall that came to light when technology irrevocably disrupted the business landscape, it was hard turning our backs to something we ve gotten so used to.

Many organizations have fallen into a trap of thinking they have implemented Agile simply because they ve introduced a few Scrum ceremonies. Realizing the approach of choice was in fact only Waterfall in disguise, and not Agile, was the hard part.

As a Professional Scrum Master and a Project manager for almost a decade, when I look back, the things that started to make me believe that we are doing Waterfall in disguise were directly related to the things I disliked about the Waterfall approach. The teams lacked flexibility and room for trial/error, preventing delivery on newly introduced, but crucial requirements that emerged mid-project. Long-term, this affected the quality of work and led to delays and unwanted disruptions. Not to mention that testing wasn t continuously executed, but only done at the end of the process. Going back to fix bugs was extremely difficult and time-consuming.

While embracing Agile promises that hold so many attractive advantages like faster product/features delivery, increased productivity, better capacity to manage changing priorities, to name a few, this was still a tough decision for our time. Especially when you have questions like this one hanging over your head:

How could we transition to Agile when we have Legacy? How to make a decision about transition when we are already so successful in our work so far?

The transition to Agile is such a complex process compared to starting off Agile in a green field. However, when the time comes, it s important to have a strong vision and strategy, and the right team to help you along the way.

The Big Decision: Going Agile

I ll share our team s experience with the client to whom we suggested the long-dreaded but necessary transition, including the challenges we faced and how we overcame them.

The client: A large multinational company offering device insurance and financing to telecom, retailers, and enterprises. We are engaged in building the next-generation platform that gets the value users have to a new level, as well as providing sustainment services for its legacy platform.

The goal: Identify the most suiting and simple process to motivate 100+ experienced professionals to get out their starting blocks and start working differently to improve operations together.

It s crucial to find time to talk to people who are going to be affected by this change. According to research, the biggest detractors of organizational agility are longtime employees (29%) staff who are comfortable in their current roles and staunchly resistant to change. Take time to talk to them, make it clear that yes, there will be challenges, but yes, there s a plan in place to confidently overcome them. And of course, highlight the expected benefits thanks to which it will all be worth it in the end.

The strategy: As our team was well-organized and integrated with the client s teams, we had clearly defined roles, and our collaboration was running smoothly, we came to a conclusion that an external Agile Coach will add value and help us achieve our goal in an efficient manner.

Although the strategy seemed simple, the tactics and going through with this journey was definitely not. There were infinite workflows to be created and implemented during this transition. We kept thinking “How do we carry the momentum forward and how will this actually look like, once the process rolled out?”

Going Agile survival kit

Our role during transformation became even more important than before: we had to keep the momentum going even through the turbulent times ahead. Below I listed out the things that helped us drive change successfully. If you re working with distributed teams, feel free to use this like a check-list for the transition period:

• Analytical mindset – don’t forget to pay even more attention than usual to how activities in different roles are interconnected and how they affect each other
• Good communication – review current communication procedures and tools to assess if they will support the team throughout the process
• Courage – it s hard to adjust the team s mindset to do something disruptive when things are going smoothly as they are. Keep reminding everyone that what awaits, brings more rewards than the process undergoing at the moment

Challenges and Solutions

Roles:

With the waterfall approach, we had one manager role, which was not sustainable in terms of continually delivering quality work in the long run.
This role was split into two: product manager, who was fiercely focused on managing the overall product value, and a delivery manager who ensured that everyone on the team is delivering their best work and was managing CI/CD pipeline. The result was improved organization capabilities, a stable, quality codebase, which brought us one step closer to the feedback loops.

Planning and Estimation:

Trying to accurately estimate upcoming development activities before each phase is complete has cost us a lot of time and wrong expectations. And no, extensive experience in estimating doesn t make you better at it when planning that far away into the future.
The new, agile approach allows us to plan in reasonable chunks (sprints or increments). This made the estimation process much more reasonable and considerably increased accuracy. Additionally, when we finish a successful iteration and get the stakeholder buy-in, we used our worn team velocity as a predictive measure.

Daily Scrums:

Having daily, brief and efficient in-person interaction with the team is extremely convenient and sounds like such an obvious activity. Unfortunately, this wasn t the case when we started out. The waterfall cycles demanded weekly status from developers, who were updating the estimated schedule. The communication was slow and caused important information getting lost. Instead of speeding up to get behind schedule, we had to set aside time to re-plan and still get back on track with our tasks. Since teams who are behind their schedule at multiple milestones rarely get delivered on time, other options had to be introduced. Daily Scrums entered our daily routine, skyrocketing productivity. Listening to developers tasks and impediments every day benefited the entire team, because this way we avoided multiple interpretations of a status report, and we also get a daily confirmation that the entire team is on the same page.

Communication:

Communication of the daily status to our peers was motivating as each member had to articulate what they did yesterday, what they plan on doing today and what the impediments they have that hold them from completing their assignments. During a long 6 +month waterfall development cycle, slipping a week or two seemed harmless, but when you look at it from an Agile perspective, that very same number of weeks sounds alarming (well, because it is). Whether the challenge was technical or non-technical nature, any impediments are brought to the surface and addressed on a daily basis. Open and continuous communication flow highlights and supports accountability and dramatically improves efficiency.

Product Design:

Designing, reviewing, and finalizing dozens of deliverables in the waterfall quality gate irrefutably pushes stress to harmful and destructively high levels. Then it stops being a design problem and becomes the whole team s problem. In the Agile approach, designing and testing became well-integrated with the rest of the development activities, which led to better solutions and outcomes, leaving the team more content since this way seemed to everyone much more logical.

Feedback loop:

No matter how great the starting idea, there is always room for improvement. Especially after getting feedback from the stakeholders and end-users. The sooner you become aware of this feedback, the better. The problem was that the UAT testing happens at the end of the traditional waterfall lifecycle.
I still recall the overwhelming stress when we had to do the end product all at once after the feedback came too late. In the end, the significant changes cost us a lot of time and effort. When operating with agility, getting feedback from a fully empowered product team/UAT team in the course of each sprint allowed the developer to make the correction as part of the sprint, provided more insight to the testing team before they tested the feature/enhancement and eliminated the risk of acceptance testing.

Looking back & assessing the transition end-results

In our case, the transition helped our organization fully harvest the benefits of an Agile methodology by addressing the technical, managerial and organizational components of moving to a new approach. We ve only decided to embark on this journey after assessing the benefits of the Agile approach vs. Waterfall and analyzing how it will affect the product quality and team.

There is no definite list of tasks to be executed in the exact right order that guarantees a successful transition. It is crucial that you have a crystal clear understanding of the current state of things and a vision where you want to take the team. Managing expectations and later on listening and talking to the team will help everyone act more positive about the change.

The communication with the Technical Leads was one of the most important components of this endeavor. They were the main drivers in transforming operations by finding the right risk appetite in the organization, and afterwards the perfect timing for the important leaps that would ease the pains of the transition.

You can expect and should be ready to manage behavioral shifts such as moving from managing individuals to building and leading teams. We went from manual routines to automated standards and from minimizing risks to an experimental mindset and exploring opportunities, thus boosting team creativity and productivity.