Can a Waterfall company work with an Agile one?

Sometimes, a client using a Waterfall approach asks if we can work together. They usually work in a fixed-price, fixed-scope type way. Or in an industry where planning and design typically only happen at the start. Good news—we have made this work before!

You can still get some Agile benefits while mainly working in a Waterfall (or V-model) way. The more Agile you include, the more Agile benefits you can gain. So, what are the benefits, how can it work, and what can you do to make it work well? Read on.

Benefits of integrating some Agile

We like Agile. It brings improvements both in building the right thing (that users want and need) and building the thing right (good quality).

Agile code quality

Agile technical practices used during implementation give benefits to the software:

• Continuous integration runs the regression tests when developers submit their code. Defects are corrected promptly.
• Automated testing is more efficient than manual testing. Including this from the start builds a regression suite. It gives confidence that the product is high quality.
• Pair programming involves two developers coding together. Pairs brainstorm ideas to solve problems, spot mistakes, and share knowledge.
• Code reviews are when one developer checks the code written by another. They consider code quality and look for errors. Reviewing improves the quality of the code.
• Test-Driven Development (TDD) involves writing a test (that fails) before adding the code that makes it pass. Refactoring the code improves the quality and makes it more maintainable. Developers focus on the intent of the task before starting. Writing only the minimum code to pass the test reduces complexity.
• Reducing technical debt. Improve code quality using practices like TDD, avoiding bodged fixes, and refactoring.

Emergent knowledge

Agile ceremonies and shareable releases allow us to listen to users and get feedback. The evidence of what users need prompts updated requirements. Successful projects must fit the user and market needs.

Project managers can use the knowledge to prioritise pending work, even with fixed specs.

Additionally, sales and marketing teams can use early versions for publicity.

UX practices

UX practices benefit from Agile. A person thinking about user experience cannot improve much if the product specs are fixed. They need to adapt the designs based on the research they discovered along the way. It is easier to apply this evidence to an Agile transformation pathway.

Agile project management techniques

You can add value using Agile project management activities:

• Road mapping is an activity to visualise the project goals (that deliver value) and milestones. Which features are needed first? It does not include how or when these occur.
• Story mapping is an activity focusing on the user’s goals and tasks. Feature details emerge and task priorities. Story mapping often brings more benefits if done earlier.
• Sprints focus a team on the work for the next 2-4 weeks. At the end of each iteration, the product is releasable. You might not release the version, but users and stakeholders could try it.
• Adaptive planning means updating plans as priorities change. Teams plan work at the start of a sprint. Planning only the most relevant tasks reduces wasted effort. Established teams often work at a steady rate, allowing some prediction.
• Task management is how you manage the backlog of work. Teams work on the top-priority tasks first. User stories describe the user value and prompt discussion.
• Behaviour-driven Development (BDD) is excellent for collaboration. Product owners, developers, and testers write tests that describe the new feature’s behaviour. Automating BDD tests creates a verification test suite.
• Ceremonies support knowledge-sharing. Planning sessions help teams understand the work, daily standups share status and highlight struggles, and retrospectives find improvements and encourage a growth mindset. Demo meetings share progress with stakeholders and create a feedback loop.

Project more likely to be successful

Agile development practices and Agile communication improve quality. The software contains fewer defects and better code quality. Faults found early are easier to fix.

With versions created each sprint, you can release one early if deadlines change urgently. Such as four months into a six-month project if a competitor launches a new feature.

Agile project management can shorten release cycles. For compliant projects, a regulatory release cycle might take 12 months. But you could still do user trials and get internal feedback with a shorter development cycle. The extra testing and feedback will improve the success of the regulatory release.

Supports a multi-disciplinary team

You might also have a hardware or engineering team in a multi-discipline project. With regular software releases, the hardware team can have an early software version to assess.

Waterfall-Agile boundaries

So, how do we integrate some Agile with our Waterfall processes? Often Waterfall follows a V-Model approach:

There are various levels on the V-model where you can picture a boundary between where we do Agile or Waterfall. We can use Agile practices below that level, and anything above it remains Waterfall.

Level 1: Technical implementation level

At Level 1, most of the project uses Waterfall processes. You confirm the product vision and all specifications at the start.

The main benefit for Level 1 is the Agile technical practices that improve the code quality. You can also get some early feedback.

Working with clients doing Agile at Level 1, we effectively integrated with their Waterfall processes.

Agile collaboration also produces benefits. Teams share knowledge in planning meetings, daily standups, demos, and retrospectives.

Fixed specifications make it hard to act on feedback from each sprint. Waterfall project managers delay updates until the end of the Waterfall process.

Even at this level, using Agile builds trust and confidence. It can take time to adjust if you have never used Agile before. You can expand the Agile cover to higher layers after seeing the benefits. Any Agile is better than no Agile.

Level 2: Software specification level

At Level 2, software specifications also become Agile. We can use Behaviour-Driven Development (BDD) techniques to create and iteratively update the software specifications. Emergent knowledge benefits the product, and the software specifications are updated.

The project management follows a Waterfall path—with a Gantt chart and milestones. These milestones are not flexible, and the project risks overrunning in time and budget.

User testing creates quick feedback loops. However, release cycles will still be slow.

For compliance, fixed and unchangeable product requirements prevent early release due to having unimplemented requirements.

Level 3: Product specification level

The implementation, software, and product specifications are Agile. The project benefits from a better project lifecycle.

User testing of early versions ensures that the product specifications update to best meet the user’s needs. The results give stakeholders confidence that they are building the right solution.

Because the product specifications match the implementation, early release is possible. They evolve together as new features are added.

Level 3 is essential for regulated products. You might not want to release a version every two weeks, but the docs would match if you did. Keeping them aligned gives you the flexibility to release it early.

Level 4: Full product level

With Level 4, we also use Agile project management to manage the business, market, and user needs.

Users and stakeholders receive regular releasable versions that they can try out. Feedback and evidence become incorporated into the product vision, business, and user needs. Key decision-makers require an Agile mindset to update requirements at such a high level. Decisions that might have been made long ago benefit from adapting to emerging knowledge. This is an evolutionary lifecycle; user needs might not be fully known or understood at the start of the project. Teams expect that they might evolve.

Challenges and Tips

During our experience with Waterfall-Agile projects, we have found ways to make things go well.

Planning-stage conversations

Some conversations are worth having before you begin:

• What are the initial user needs, requirements, and priorities?
• What level of requirements can be updated following prototyping or user testing?
• Which documentation is fixed, and which can be adapted as you go?
• How do you plan to manage emergent work?
• When, how, and how often will you communicate?
• Which people need to collaborate regularly?
• How will you divide the responsibility for making decisions?
• How often will you reflect on how the processes are working?
• How much do you understand Agile? Agile coaching can help to boost team knowledge. Ensure you know how iterations, 3-Amigos, sizing, and so on, work.

Planning challenges

Planning everything up front can slow you down overall. By sprint ten, you have likely forgotten the context from when you wrote it months ago. It takes additional time to refresh your memory. Or, you never get to all the features you had planned, wasting that effort. Where possible, plan more details shortly before you are ready to implement them. Investigate the risks early as part of Agile’s “fail fast” concept so that you can mitigate them better.

Having lots of planned cards in your backlog can overwhelm you with detail and quantity. It makes it hard to spot gaps and themes. Using epics can help with this, tracking them on a journey map. This journey map helps those familiar with Waterfall, even if priorities or routes change. You can specify the story details nearer the time of implementation. Tentatively assign them to sprints, with a shared understanding that they might move. Suppose you plan to only work on “must-have” (required for MVP) priority work for the next sprint. In that case, it is easier to avoid putting “nice-to-haves” (valuable but not essential) in it.

Deadlines

Often, Waterfall practitioners worry about sticking to deadlines. If this is a big concern, it can help to include a buffer zone for contingencies. A buffer sprint might be the final sprint before the deadline or a regular sprint every four weeks. Teams can perform quality improvements, training, or as a buffer for delayed work.

With an Agile mindset, you understand that fixing the time and scope can compromise the quality or prevents focus on the most valuable features as you learn more.

Most projects have emergent work popping up along the way. As you learn more and get user feedback, you might want to change the requirements to improve the project. But, emergent knowledge risks scope creep and delays, so you must prioritise effectively. Evaluate each emergent feature to compare its value against the other features as part of the big picture. You might not be able to implement everything in time, but you can implement the top ones.

If you have a specific deadline for logistical reasons, work out the essential tasks to meet that deadline and prioritise those.

Efficient Three-Amigos

Three-Amigos can set the tone of a sprint. They are a kick-off meeting between the key stakeholders and the development team. Unfortunately, they can become long and less productive.

To make it go smoothly, prepare. Before the meeting, a Product Owner can identify the top priority stories you need to discuss. For each, they can write an initial user value statement and add the initial acceptance criteria. Having a starting point makes it easier for people to spot the bits that need changing. Focusing on the pre-prepared top stories in the meeting also reduces divergent conversations that might slow the meeting down.

During the meeting, spend the first 15 mins doing a brief priority assessment of any emergent work. It can be tempting to try and sneak it in for the next sprint but keep the focus on the big picture. What are the most important things if you had to be selective?

Then spend about an hour planning the top priority work. Discuss the story and get enough detail for the developers to develop it and the testers to test it. How do the users benefit from the feature? What is needed to achieve this?

Too many large or high-priority tasks in a sprint

Putting too much high-priority work into each sprint can lead to unrealistic expectations that you might complete all of it. Accurate sizing can help manage these expectations. Keep sizing based on relative effort, not time.

You can use a team’s historic velocity to predict how many points the team usually achieve. For example, if a team is averaging around 24 user story points per sprint, and there are 35 points in the sprint backlog, you likely won’t get through them all.

Make sure there is a range of priorities on the user stories. You might feel like everything is urgent, but which ones are essential for an MVP? And which are “nice to haves”? Which are the riskiest? You need to be able to choose between them. A scoring system can help or ordering the backlog into a list of descending priorities.

User stories with large sizes might need splitting into smaller ones. Where possible, write user stories that are vertical slices. Vertical slices are a narrow cross-section of the codebase that makes a tiny but complete bit of functionality. A “working” small feature adds more user value than a broken, broader one and enables users to try it out.

If a card is unfinished at the end of the sprint, split the card and adjust both sizes to reflect the work done and the predicted remaining task.

Communication

Communication is vital for projects to work well. It helps to have a Product Owner or Analyst on both the client and development side to stay in touch and keep an eye on the big picture:

• Discuss the impact of emergent work with feedback such as “This adds an extra half sprint of work. Which features should be pushed back?”
• Keep priorities up to date.
• Mid-sprint check-ins provide an update on progress. You can discuss any changes or clarifications that need to happen.
• Be transparent if card sizes change as more is learned (whether sizes go up or down).
• Quickly resolve requirement clarification questions.

Additionally, have a project retrospective at regular intervals to assess communication, progress made, and improve processes.

Testing

Instead of delaying testing until the end of a Waterfall project, test new features each sprint to find and fix them early. Include testers in your development teams and encourage automated testing like TDD and BDD. You can prioritise critical defect fixes alongside the new feature work.

Demo meeting

To have effective demo meetings, identify the information that needs to be communicated. What are the goals? What are the metrics they need to see? What level of technical detail do they want? What format do they prefer the information in, such as a live demo, report, or video?

Relate the work completed back to sprint goals. Doing this helps to show the progress and the value delivered.

Be honest about unfinished tasks and why. These things could impact the work for the next sprint or identify risks and areas to learn more about.

Provide a chance for feedback and listen. Features for future sprints might need to be updated and any corresponding specifications.

Working together

Waterfall and Agile can work together to varying degrees – the amount of Agile you want to include is up to you. When you set the boundary for the level of Agile you want, we can work with you to add as many Agile benefits as possible.

Written by Jane Orme.