How we seamlessly integrated Agile into a former Waterfall team

The Trustmarque Cloud Team’s journey from Waterfall to Agile, across 2 years, has resulted in zero delivery escalations across 120+ projects. We feel this is evidence that making this journey is proof that the decision was right.

This is how we approached the change.

Transitioning from a traditional Waterfall methodology to an Agile approach can be a transformative journey for any team. While it may present certain challenges, the benefits of enhanced adaptability, improved collaboration, and increased efficiency make it a worthwhile endeavour.

Agile methodologies emphasise iterative and customer-centric development, allowing teams to respond more effectively to changing requirements and deliver higher quality products. To help a team seamlessly integrate Agile practices into their workflow, a systematic and well-planned approach is essential.

Immediate Changes

Trustmarque’s Cloud Practice was embedded in a “Waterfall mentality”. This resulted in a number of key constraints.

1. Resource availability: The Cloud Team resources were booked in advance via a central record maintained on Excel, often provisionally “in case needed”, heavily impacting on availability. Project plans were created around the availability of the resources, rather than the priority of projects. If a project was identified as a priority, time would be spent between project managers negotiating with each other and the Cloud Practice Director, about which was more important (which was naturally skewed by personal investment). If across a number of projects, this was a lengthy logistical and time-consuming process that had to be repeated. In short, a large and unnecessary overhead was created juggling resources for the wrong reasons.An immediate change was to remove the use of the central resource planning, which operated as a calendar for resources. Instead, we moved to a model of the work taking priority, and as a team working on tasks. We brought the work to the people, rather than people to the work – a key emphasis of Agile.

2. Multiple project managers: Whilst work was often undertaken by members of the Cloud Team, different projects had different project managers. So multiple meetings were held, often answering similar questions, and tracking project progress and problems. Too much time was spent in meetings, rather than spending time on project delivery. Projects were operating very much as silos. Information on customers and projects was lost and not shared.A further immediate change was to replace multiple project managers, with a single Cloud Team Scrum Master, who would facilitate and work with the team, helping the team to own the work – rather than the project manager seen as the traditional kingpin of operations. As we were working across a number of projects, the Cloud Practice Director would act on behalf of customer stakeholders, acting as the Product Owner, to prioritise the backlog across all projects in one place – a single product backlog.

Recipe for Change

So, what were the key steps we undertook?

1. Education and Training: We began by providing training on Agile principles, values, and methodologies. This education was vital to ensure that all team members were familiar with the new approach and could actively participate in the transition. The training covered topics like sprints, backlogs, daily stand-ups, and agile project management tools (in our case, Microsoft DevOps). By fostering a shared understanding, team members were better equipped to embrace the Agile mindset. We didn’t expect expertise over-night. We “learned by doing” – improving continuously as we progressed. We constantly reviewed what was working, and what was not. We avoided big changes but instead made small changes over time.
2. Started Small: Instead of implementing Agile across all projects at once, we started with a pilot project. This approach allowed the team to experiment with Agile methodologies while minimising potential disruptions to ongoing Waterfall projects. The pilot projects were used as a learning experience to identify challenges and refine Agile practices before scaling it up to other projects.
3. Cross-Functional Teams: We re-organised the team into cross-functional units, incorporating members with diverse skill sets. In Waterfall, team members often work in silos, leading to communication gaps and reduced collaboration. With Agile promoting a culture of collaboration, the cross-functional teams ensured that all perspectives were considered throughout the project lifecycle, leading to more holistic solutions. Having all team members at the very least aware of all projects, and often involved in several, skills and experience could positively influence the success of the projects.
4. Effective Communication: Rather than operate in “project silos”, we encouraged open and transparent communication among team members. We set up regular meetings and involved all members of the team, such as sprint planning, daily stand-ups, sprint reviews and retrospectives, and through these meetings, embraced a shared ownership of all projects. Effective communication is critical for keeping the team aligned, addressing potential issues promptly, and fostering a culture of collaboration. Beyond all else, having the entire team (which number approximately 8-10 people) on a single stand-up, as opposed to separate project meetings, allowed communication to be shared across all engagements, sharing knowledge, and promoting the team’s self-organisation.
5. Iterative Development: We emphasised the importance of incremental development and frequent deliverables. In Waterfall, projects are typically completed in a linear fashion, leading to lengthy development cycles. Agile’s iterative approach allows teams to deliver valuable increments of the product at the end of each sprint, enabling quicker feedback loops and adaptability to changing requirements. As opposed to lengthy milestones, instead we established regular (two weekly) sprint planning, so we could focus on short term delivery of value to every customer, rather than excepting the previous scenario of lengthy periods of time with no valuable delivery. Changes to project scope and priorities were now welcomed, rather than feared.
6. Empowerment and Autonomy: We wanted team members to make decisions and take ownership of their tasks. In traditional Waterfall teams, decisions are often top-down (often by project managers), leading to reduced motivation and creativity. We found that Agile allowed individuals to have the autonomy to prioritise tasks, make decisions, and adapt based on project needs – all leading to the delivery of the current Sprint goal. Empowered team members take more ownership of their work and are more invested in the project’s success, together with enhanced motivation.
7. Continuous Learning: Waterfall may hold a “lessons learned” session at the end of the project, but we wanted to learn all the time – re-enforcing the good and improving the bad. So, we were keen to foster a culture of continuous learning and improvement. We encouraged team members to seek feedback, attend workshops, and share knowledge within the team. By continuously developing their skills and understanding of Agile principles, the team could enhance its collective capabilities and deliver better results.
8. Feedback Loops: Key to Agile is regular feedback from both internal stakeholders and customers. These insights are invaluable for course correction and ensuring the team remains aligned with project objectives. Rather than being a “slave to the plan” in traditional Waterfall delivery, through crucial customer feedback, where customer satisfaction is the primary focus, the priority of work was continuously reviewed for what was required next. Again, change was welcomed rather than considered bad. The plan was no longer king, it was replaced by the delivery of value and a satisfied customer. Through the regular delivery of value, the customer was satisfied as they knew more was coming quickly, reducing and eventually removing the “When will we get it?” question often posed to project teams.
9. Adaptability and Flexibility: We acknowledged that transitioning to Agile may involve some trial and error. Each team is unique, and we knew and accepted that the transformation process would require adjustments to fit the team’s specific needs and challenges. So, we were open to making changes and continuously improving the implementation of Agile practices. In fact, we welcomed suggestions and changes to improve.

Celebrate Successes: So often overlooked, we wanted to recognise and celebrate the team’s achievements, both big and small. Positive reinforcement reinforces the benefits of the Agile approach and motivates the team to embrace the new way of working. Celebrating successes also helps build a positive team culture and boosts morale during the transition phase. Recognising success became mandatory, rather than viewed as an optional extra.

Wrapping Up

The integration of Agile practices into the Cloud Team who were accustomed to the Waterfall approach required patience, dedication, and collaboration. But by following these key steps and fostering a culture of adaptability and continuous improvement, the team successfully navigated this transition and unlocked the full potential of Agile methodologies.

Embracing agility not only improved the team’s efficiency and project outcomes but also laid the foundation for sustained success in an ever-evolving landscape of customer expectations.