First, why make the change? While Waterfall works for some projects, our team experienced more challenges than benefits using this methodology.

A Waterfall approach means users create a complete set of requirements before handing it over to IT for system design and development. Users often work in isolation from other functional teams and from IT. Their thinking is often limited to what they know about the current system plus some features they’d like to enhance and bugs they want to eliminate. The process simply doesn’t facilitate the kind of holistic, critical and creative thinking that drives transformational change. Additionally, requirements gathering consumes about 30% of the project timeline. By the time the requirements are shared with IT and other functional groups, it is too late to make significant changes. Often this causes delays in our projects.

I’m sure some of these issues sound familiar to you, yet it can feel incredibly daunting to move your team into a new approach.

Despite knowing the change would be significant, we needed to adapt to an iterative process and allow for full team conversations throughout its steps. We wanted to create space for creativity and innovation from our users and to empower them to think about new possibilities, especially in potentially transformational projects. Equally important, our IT team needed to develop and test the solution properly. We went into this unsure if Agile was the solution for our issues, but eager to find a better way to deliver projects with greater efficiency and success.

It’s important to make the transition in a way that makes sense for your team. Rather than moving directly from Waterfall to Agile, we developed a hybrid development approach, combining components of the two.

We had quite a few obstacles going into it: in this project, our system implementation partner didn’t support Agile, and it was new to our business users and IT team. It is important to make sure your full team has time to adjust to the new approach, and the hybrid model allowed us to move at the pace we needed. We utilized parts of Agile that we could implement immediately, while keeping components of Waterfall to ensure a successful project completion.

This is not a one-size-fits-all solution, so pick the parts that will work, especially when you’re starting out. We followed Agile by creating epics, user stories, tasks/activities, and defined personas. We had scrum leads and assigned Agile Team Roles. We maintained the backlog in JIRA and used JIRA for tracking.

However, we did not have user acceptance testing at the end of each sprint. This was partially because we are a global company with users spread across multiple time zones, making it very challenging to add a testing cycle every two weeks. Instead, we did big-bang UATs at the end of the project. Additionally, we did not do product demos at the end of each sprint simply because it took us multiple sprints to deliver a capability that we could demonstrate to the users.

We maintained daily stand-ups, as part of the Agile approach. However, there was so much to catch up on as a team that those lasted longer than the recommended 15 minutes. As a project manager, if I were to put my foot down and force the time limit, the team would end up dropping off from the daily call, to have another call where they could continue their conversations thus defeating the purpose. So, our stand-up meetings ran 30-45 minutes, sometimes an hour. (It takes dedication, discipline, and practice to stick to the 15-minute rule, which we will continue to perfect.)

One of the most important parts of our transition was engaging an Agile coach. We were very fortunate to have an experienced Agile coach in our department who is familiar with our teams and the nature of our project. He coached us through the process and provided support throughout. Having his leadership was instrumental to our successes.

Agile helped us build a tight feedback loop. One of the huge selling points of an Agile approach is the Joint Application Design (joint requirements workshops), which our Agile coach helped us facilitate. Users were previously developing their requirements in isolation and then delivering them to the IT team. With this joint approach, we had a week-long session with users, system analysts, developers, and the IT team. We built 4 scrums, and each scrum worked to create their user stories as a group.

What I really loved about this is it created transparency between the users and the system analysts. Previously, that relationship was defined by a “them and us” mentality of two separate groups, and our internal customers had the sense that the IT team was resistant to their ideas. However, when the users were present throughout the discussions, it created a better conversation where users could advocate for their goals and IT could give an immediate sense of what is possible.

The trust that was built through this new approach was immense. The users felt that IT was on their side, both understanding and caring about their needs. They were able to understand that if IT pushes back, it’s because their ideas really aren’t feasible. And, on the other side, for IT to witness the users’ discussions of issues and requirements, they got a better sense of the reasoning behind their needs, helping the IT Team to better translate that into solutions.

Although there was a lot to love, we still had challenges in this approach. The key driver for sprint planning was the project timeline, rather than the effort to deliver assigned scope. We weren’t honest with ourselves that the project timeline did not match the amount of work required. Because of that, we were not able to sustain the 2-week sprint schedules. This had a cascading effect of falling behind on one sprint, which continually impacted the full timeline and caused project delays. Unfortunately, because of these delays, our IT team and business users lost some confidence in the process.

We learned a lot through these missteps, which I hope will help you and your own teams. Before you embark on the Agile journey, I strongly recommend to first get the full buy-in from both your leadership and your teams. Agile must be a shared goal because, as problems arise, you’ll need support to carry on and not to abandon the journey halfway through.

Don’t give up on Agile if it doesn’t meet your expectations the first few times. Agile is the methodology, but it requires you to experiment and find a process that fits the needs and techniques of your organization and team. If you’re looking to improve your customers’ satisfaction, the end-to-end experience, or your ability to be more responsive to change, you need to be bold and fearless and invest the time in moving to Agile.