How to Rollout Agile without Failing

Having been in Agile organizations for almost eighteen years, I’ve been in situations where Agile was already fully implemented—i.e., joining an org. that had a dedicated, robust Agile program already in place. I have also joined organizations where Agile was rolled out: twice to be specific. In both instances, the rollouts were quite different from one another. One succeeded, while the other was a bit rocky, taking a while to lift off. But in both instances, the decision to pivot from Waterfall to Agile was top-down, having senior leadership fully behind the idea, and having all teams affected looped into the new ways of working.

The first experience of rolling out Agile was during my time at a software company. The entire department was sent to dedicated training by the Scrum Alliance, which initiated us in a very deliberate way. We learned as a group, participated in activities which helped develop Agile ways of working in our minds, not only learning the terminology, but the best practices as well. We received Agile certifications as Scrum Masters. Once completed, the rollout was gradual, slowly moving towards Sprints, and bi-weekly releases. It was understood that in order to be successful, we all had to be on the same page. Because of the long runway and proper training, we successfully transitioned to Agile teams seamlessly in a matter of a couple of months.

Later on, I was part of another organization that rolled out Agile in a slightly less organized way. We were shifted overnight into Agile teams, which caused some confusion with our stakeholders who weren’t Agile (and as marketing partners, they didn’t have any plans on implementing Agile). It was more challenging to explain our new ways of working, to provide more structured timelines for releases, and convey the importance of roadmaps and planning events. Work was still sent over in the form of requirements which had to be translated into user stories, and dedicated resources were shared amongst all the teams. Because this rollout was less robust initially, it took a much longer team for the organization to become fully capable of running at full speed.

In both instances, there was a top-down push towards Agile. Which was key. Everyone had to get on board the Agile train. We all learned the fundamentals behind acceptance criteria, PI Planning events, and backlog grooming. That initial training took the team far in terms of understanding Agile ceremonies and ways of working.

The wrong way to implement Agile, is if one part of the organization adopts it, while others do not. These are the instances where Agile can fail. If your development team is fully Agile, using JIRA and working on user stories, but say, your creative agency is not embedded within the team, and not part of Sprints, they’re off doing work that may not reflect the team’s goals for the Sprint. If your stakeholders don’t understand the importance of road mapping and planning features/Epics, work can oftentimes show up abruptly, disrupting an entire quarter’s worth of Sprints.

It also places a lot of stress on teams adopting an Agile pilot if the org. is not behind them, supporting them. For Agile to function at its peak, teams require a robust roadmap with features and Epics clearly aligned to KPIs, all of which must be provided from leadership. Without everyone being on board, it’s possible for organizations to function as half-Agile/half-Waterfall, which leads to a lot of confusion. Think about it: you can’t have long, complex requirements documents when the development team is now used to straightforward, concise user stories that tackle work one piece at a time. You can’t expect an external QA team to be part of a process that asks them to both verify Waterfall-style requirements and Agile-style user stories, depending on which team they’re working with. You can’t leverage JIRA haphazardly—as a tool, it’s invaluable for Agile ways of working, making the organization of your Sprints and backlog easy. But in a Waterfall situation, how would one large, convoluted project take advantage of the advantages JIRA can provide?

So, while organizations use Agile in different ways, tailoring it to what suits them best, there is only one right way to rollout Agile: with proper training, top-level promotion, and having all teams involved in development work on board.