Navigating Agile in a Waterfall Enterprise

Agile teams may find it challenging when product development spans both waterfall (traditional) and agile teams. Agile and traditional Waterfall methodologies differ in the most basic ways:

When agile and non-agile teams work together, it is common to face obstacles. Challenges may come from an internal leader who has not worked in an agile environment or from vendors who use a non-agile development process. Or perhaps your organization is adopting Agile in a hybrid environment where different teams have varying degrees of agile maturity.

Below are five common scenarios you may see when navigating the blending of agile and traditional waterfall processes in an organization.

Communication

When teams work together in a hybrid environment, it is not easy to talk apples to apples. However, it is essential the teams agree on how they will interact, set touchpoints, and outline responsibilities to improve communications.

Align on guidelines to understand which team is responsible for what work. Set regularly cadenced touchpoints between the teams to eliminate potential issues, ensure a synchronized effort, and promote transparency. Be inclusive: invite the traditional project team to the agile ceremonies such as the Sprint demo and a retrospective. These meetings will validate the right thing is being built early in the life cycle and foster an environment for continuous improvement between the teams.

Efficient communication relies on engaging the right people. For example, daily communications between the project manager and the scrum master can help keep blockers at a minimum and optimize flow.

Dependencies and constraints

Teams often face challenges as they work together to coordinate delivery. If the teams are a mix of agile and waterfall teams, it’s necessary to identify the teams’ dependencies and constraints as soon as possible. Be sure to agree on clear expectations to remove overlapping responsibilities or missed assignments. Everyone needs to be confident they won’t be waiting on another team to progress.

For example, to add copy to a website, a content team (traditional waterfall team) needs to provide the content before the web development team (agile team) can publish a web page. The content team and development teams need to synchronize as one delivery team.

They can do this by setting a regular meeting cadence to discover dependencies and constraints and then map the two teams’ dependencies. During these sessions, identify assumptions and then work to reduce or eliminate them. Both teams can then feed this information into their agile backlog or their traditional project plans. Teams will find success when they are not working off assumptions.

When dependencies and assumptions seem overwhelming, consider utilizing mockups. Mockups can be a critical tool to see and communicate dependencies between teams. In addition, mockups will reduce assumptions by helping the teams envision the product and validate the right thing will be built before too much effort is expended. The least amount of effort should be used to validate the path forward and achieve alignment between the teams.

Agile status reporting in a traditional workplace

Regardless of a team’s methodology, management will want to know what program objectives their teams are achieving. Agile teams often need to report metrics to traditional waterfall management.

To successfully communicate the required information to management, first, identify the intent of the metrics requested. A quick analysis of the purpose of the measurement will help you select the correct data to present. Then, determine the status of this intent and communicate it in the requested format.

For example, leadership wants to understand what a team completed in the previous sprint. The agile team shares that it met its Sprint objectives by delivering fewer stories. The team communicates these savings when reviewing the Sprint burndown chart. Traditional managers will understand these savings and ask what the team did with the time saved? Agile teams should be ready to tell that story too.

When possible, leverage other people or teams. If you have access to a PMO, it can utilize its relationships to translate and communicate between agile and waterfall stakeholders. Many PMOs also have tools such as Jira or Tableau to aggregate agile and non-agile team metrics together.

Maximizing gated processes with Agile

Agile teams in a hybrid environment will often be constrained by the organization’s waterfall methodology, including a gated process. Have an agile mindset as you approach these constraints. While straightforward, avoid thinking of the product as the gate completion criteria and the customer as the gate process approval committee. The agile team’s end product is the value they bring to their customer, not the gate process requirement.

Start by defining the critical success factor requirements for each phase “gate.” In the agile team’s backlog, consider gates as a constraint on the Features. Create user stories that bring value to the customer while providing the required gate criteria. Prioritizing the backlog will enable the team to meet sequential completion dates that align with the traditional gates.

Agile teams should seek exceptions when possible if they believe a gate’s requirement is not valid or in line with their work. Be prepared to defend your exception request. For example, a requirement may include non-agile deliverables such as excessive documentation, which the team does not believe will bring value. While not easy, the organization needs this valuable input to perform optimally.

Comparatively, the release gate is trickier than the other gates. Traditional waterfall teams deliver a predicted product in one planned release. Agile teams deliver increments of potentially releasable product often, adapting the release content as the work informs the team. As the agile team iterates, the exact content of multiple releases evolves. The team may need multiple streams of potential product features in the gate queue. Each item can move ahead independently of the others as your team chooses which has the most value to deliver and when it should be delivered.

Managing change is critical for successful delivery, and each organization manages change differently. It can vary from a Change Management Board using an online form with field options to verbal signoffs earned through informal negotiations. Each has its pros and cons. Learn early how change is handled within your organization to master the process.

Budgeting Agile in a Waterfall organization

In a Waterfall organization, funding is not agile. Until the organization changes to lean budgeting, it remains challenging for their agile teams to navigate funding.

One successful mitigation strategy is to form a team to request a large bucket of funds for a group of initiatives. The solution intent is specified only on a generic level (e.g., digital transformation of customer-facing applications). This funding team then distributes the allocated funds to the agile teams throughout the year as new development is discovered. This process works well when traditional finance teams fund agile software teams on an annual cadence. Until finance embraces Agile itself, this can be a helpful strategy.

Agile teams succeed in Waterfall environments

These five examples offer solutions for agile teams to navigate a traditional waterfall environment. Of course, each organization differs. Sila Agilists can show your agile teams how to manage specific constraints or traditional requirements while reaping Agile benefits.