Does the term “Agile flexibility” sound redundant to you? To those familiar with Agile project management, it is implied that Agile practices will allow for flexibility… in theory. In practice, there is often resistance to being more flexible after transitioning to Agile. It’s common for teams to push back against modifying Scrum ceremonies to meet a project’s unique circumstances or adding more traditional waterfall approaches in a hybrid approach.
These are real phrases that we have heard at client sites while managing projects using the Agile methodology. However, their projects may actually require a more flexible hybrid Agile methodology. The Agile waterfall hybrid approach allows you to cater to the needs and capabilities of the team working on the project. It also enables you to take advantage of the strengths of Agile and waterfall methodologies while minimizing their weaknesses.
What is the difference between hybrid Agile and Agile flexibility? Agile is, by definition, flexible. It was designed for speed and adaptability, which businesses need to compete in today’s fast-moving landscape.
As businesses struggle with the demands of compiling, scaling, and managing their data, Agile practices offer flexibility that can help them adapt. For example, when a telecommunications firm wanted to incorporate more data-driven processes in their business, they were stifled by constantly changing requirements and business priorities. Kenway took a multi-pronged approach to helping them leverage their data more effectively, with Agile transformation being a key component.
First, we created a more robust data governance process for their reporting applications to minimize data quality and availability issues caused by the high velocity of change in their environment. We called this the “front door.” This streamlined and organized the process for submitting requests for new applications.
Next, we collaborated with their team to build a continual, iterative approach to development. After a request was submitted, we interviewed each client to gather their high-level requirements for each application, with the goal of building out more detailed requirements while setting the expectation that there would be future changes in subsequent interviews. This Agile approach allowed for faster development while prioritizing the firm’s most critical needs first.
Because requirements and features of applications may change from our initial interviews, Agile workflows ensured that our process and applications were built with the idea that there would never be a “final” product. These applications needed to be updated quickly as the business needs evolved. Agile’s flexibility enabled the firm to make requests on a day-to-day basis and achieve quality results in a timely manner without worrying about the effects of continual change.
Despite the success of companies like the telecommunications firm, using Agile alone may not be suitable for every project at every organization. Transitioning from a traditional waterfall to Agile can result in gaps in vision, planning, and coordination, which often bring frustration and an unwillingness to blend approaches in a way that meets the unique needs of the environment. Often, the most fervent Agile evangelists are hesitant to try a hybrid approach due to the belief of regression or the scrum team losing control and being directed from the top. Deviating from tried and true Agile methods in the eyes of the converted presents a cavalcade of risks.
The hybrid Agile approach allows for teams that are currently using Agile to continue using Agile and gradually blend in any waterfall teams or practices to ensure alignment and the ability to stay in sync with the needs and objectives of the organization. This Agile waterfall hybrid approach can be especially useful for large organizations that want to scale Scrum beyond a small team.
For example, multiple longer-duration, concurrent sprints can be used at the onset of a project. This works well with the waterfall-experienced teams. Eventually, these sprints merge into combined sprints as the project progresses, molding into a more traditional Agile structure. With large projects, a “Scrums of Scrums” can be leveraged in the early stages of the project, to keep teams aligned. A “Scrum of Scrums” or Program Meeting is a regularly occurring forum that brings together representatives from the various sprints and scrum teams in the same meeting which allows for information sharing, collaboration, and planning.
Kenway was tasked with implementing Agile on a large, complex project that involved five independent IT teams: two that used traditional waterfall methodology and three that used Agile development. The project was on an 8-month (32-week) timeline.
In order to cater to the different teams that used different development methodologies, the initial sprint structure for the first six months had Agile and traditional waterfall teams on concurrent sprints schedules and a program manager. The three Agile teams used traditional, two-week sprints, and the waterfall teams were allowed to run individual, concurrent sprints with longer lengths of four to six weeks.
This gave the teams new to the process (i.e. the two waterfall teams) time to learn Agile tools, become familiar with daily Scrum and stand-up meetings, and the stakeholder reviews of requirements, retrospectives, plans, and backlogs. By extending sprints to four to six weeks, the learning curve around Agile meetings and tools was much easier to handle. Over the final nine weeks, the last three sprints were positioned as a final merge or blend of all of the teams.
Amazingly, the traditional waterfall teams embraced the Agile methodology about two months into the project (roughly midway through the second sprint), and by the time the sprints were merged, several of the traditional waterfall team members became such strong supporters and became “Agile Evangelists.” That is, instead of taking the expected six months to adopt Agile, the traditional waterfall resources embraced it within two!
By allowing extra time and presenting Agile in small steps, the traditional waterfall teams not only had the time to learn the tools and the methodology, but were also able to experience the value of Agile Development—concise design documentation tools and processes, more rapid QA cycles, immediate feedback, and regular interaction with business teams.
So, what are the benefits of embracing a hybrid agile methodology?
Undergoing an Agile transformation to improve your organization’s processes is no small undertaking. Kenway can help your organization make the transition and ensure alignment between various teams and stakeholders involved in your processes. Our experts can guide you through the most challenging aspects of Agile transformation, including determining whether and where to incorporate a hybrid Agile approach.
To discuss how Kenway can help with your Agile development concepts and Agile transformations, connect with one of our consultants to learn more.
What is hybrid waterfall Agile?
A hybrid waterfall Agile approach combines practices from Agile and traditional waterfall methodologies. The hybrid Agile waterfall can help companies ease the transition to Agile and use development practices that are more suited to their projects and business needs.
Can Agile and waterfall be combined?
Yes, Agile and waterfall methodologies can be combined into an approach called Hybrid agile.