Is waterfall sneaking into your Agile? Spot the 7 signs!

Let's be clear: there's nothing inherently wrong with the waterfall approach. In fact, it's perfectly suitable for certain types of projects (like constructing a building, for instance). But when we aim for Agile and end up with waterfall, that's a different story altogether. So, how do we diagnose this hidden waterfall syndrome, and more importantly, what's the cure? That's precisely what we're going to explore in this blog post.

What is it?

In a functional team structure, instead of collaborating on a product or product increment, each team is focused on a specific step in the development process, such as design, coding, testing, and so on. While each team might be diligently following an Agile framework, they inevitably need to hand over work to one another and engage in constant coordination to get the product ready.

Why is it bad?

Unfortunately, this approach introduces several pitfalls. Coordination becomes a Herculean task, often leading to the creation of Gantt charts and project plans to ensure product completion - a hallmark of the waterfall approach. Furthermore, each team only bears responsibility for their specific part of the work, and no one truly oversees the overall customer experience. The end-to-end delivery of every single new feature or product might take months, as it must pass through multiple teams and survive constant deprioritization.

What to do?

The antidote lies in building cross-functional teams that encompass all the skills needed to deliver the product. If the product is too large for a single team, consider setting up teams per product feature or service area, but avoid splitting teams by functions. This way, you can maintain the agility and collaboration that are at the core of Agile, and keep the waterfall at bay.

What is it?

Imagine your end product as a cake, replete with multiple layers representing design, functionality, and testing. Now, even if you can't serve the entire cake to your customers immediately, you'd want to offer them a nice, well-rounded slice (complete with all the layers and frosting), so they can taste it and provide feedback. This "slice" represents a feature, a vertical cut through all the layers of the cake that delivers discernable customer value. Unfortunately, teams often try to economize by breaking down work horizontally—design all the features first, then build all the functionality, and so on.

Why is it bad?

While it may seem like a time-saving strategy, in reality, it's a time trap. Consider spending weeks crafting what you believe is the perfect chocolate cake, only to discover that your customers despise chocolate. Rather than baking the whole cake and then discovering it's not to your customer's taste, Agile advocates for baking it one slice at a time. This approach may appear resource-intensive, but it enables quick testing of assumptions and the flexibility to pivot—key Agile principles.

What to do?

User stories offer a simple solution. While they're not the only way to structure work, user stories are highly effective in guiding teams to break down work vertically. Furthermore, always ensure to clearly articulate the customer value for each work item. For instance, "design a button" has no apparent value, whereas "introduce unsubscribe function" delivers clear value to the customer. By breaking work down into vertical slices, you can ensure that every increment delivers tangible value and fosters a truly Agile environment.

What is it?

Imagine having a clear view of the exact features you need to launch this quarter, and even the precise order in which they'll roll out. The scope of work is determined at the outset and remains unchangeable. While you can plan sprints and prioritize your backlog, the expectation is that your team will deliver a specific set of features. Additionally, dependencies on other teams can put you in a stringent timeline, leaving no room for flexibility.

Why is it bad?

One of the significant advantages of Agile is its ability to adapt to changing circumstances, to learn continuously from customers, to improve, and to pivot when necessary. A fixed scope hampers this flexibility and inhibits the potential for experimentation and responsiveness to a shifting environment.

What to do?

While large-scale planning (yearly, quarterly) is crucial, it should serve as guidance, not as an unalterable decree. Each team should have the flexibility to adjust their plans and manage external dependencies on the fly. In my experience, OKRs (Objectives and Key Results) provide an excellent solution. They shift the focus from outputs (the specific features we want to deliver) to business outcomes (the value we aim to bring to the business and customer), aligning more closely with Agile principles.

What is it?

Suppose you have flexibility around features, but you've established milestones and release dates. In that case, there's a high probability you're unwittingly sneaking waterfall into your Agile approach. Often, managers introduce artificial deadlines under the guise of "keeping teams on their toes" and "motivating faster launches." Ironically, this approach frequently achieves the opposite effect.

Why is it bad?

Striving to meet a deadline places the team in the crosshairs of the project management triangle: scope, budget, and schedule. A tight schedule inevitably impacts scope (or budget, though in reality, budgets are rarely easy to adjust), shifting the team's focus from maximizing customer value to meeting time constraints. The stress of deadlines negatively affects team health and individual motivation. Furthermore, innovative ideas and solutions are often met with resistance because they're perceived as distractions from the pressing goal of meeting the deadline.

What to do?

As counterintuitive as it may seem, consider ditching deadlines and allowing each team to determine their own schedule. Here's where OKRs prove their worth again. By focusing on achieving specific results, teams are held accountable for their performance while retaining the freedom to decide what to work on and in what order. This approach aligns with the spirit of Agile, fostering a more productive and less stressful environment.

What is it?

You might be following an Agile framework and maintaining flexibility around your scope, but do you promptly incorporate what you learn into your work? Teams often conduct customer research and gather testing results, but inertia can lead them to continue on their initial trajectory, regardless of these findings. A clear symptom of latent waterfall thinking is an inability to respond to a changing environment.

Why is it bad?

By not reacting to new insights, you run the risk of missing significant opportunities and potentially wasting time on initiatives that no one needs. Sticking rigidly to an initial plan, despite new evidence suggesting a different direction, is a surefire way to stifle innovation and customer satisfaction.

What to do?

Every new piece of knowledge should influence your planning process, whether it means seizing unexpected opportunities or abandoning features that customers dislike. The quicker you can make these adjustments, the better. Start your planning meetings by reviewing the latest analysis results and ensure your product priorities align with the customer and the market. In other words, let data drive your Agile approach.

What is it?

If a team is more focused on "getting things done" than on "delivering results", they are not setting themselves up for success. In Japan, where I live, this is a significant issue. You could devise an innovative solution that saves the organization a lot of time and money, but the promotion might go to your colleague who spends a few extra hours at work every day (often not being particularly efficient) because they are perceived as "working harder". But in Agile, we want to work smarter, not harder!

Why is it bad?

Prioritizing output over outcome leads to misguided incentives and a preference for quantity over quality. The focus on output hinders creative approaches: why should we think of innovative ways to deliver value to the customer if we can simply shower them with a bunch of inconsistent features?

What to do?

Once again, OKRs have proven to be the most effective tool for shifting focus to outcomes. When team members set individual goals, these should align with team goals and emphasize their contribution to outcomes, not merely outputs. In other words, it's not about how much you do, but the impact of what you do that truly matters in Agile.

What is it?

In environments where there's no psychological safety, team members don't feel like they can freely share their ideas, question the plan, or provide feedback to each other. The team is afraid to experiment because of the risk of failure. Failure is seen as a bad thing that has to be avoided at all costs.

Why is it bad?

A lack of psychological safety means your team misses a lot of great opportunities. Potentially fantastic ideas are never shared, and nobody steps in when bad decisions are made. Learning is limited as experimentation is stifled, and feedback - a critical tool for personal growth - is not exchanged. Moreover, such an environment is not conducive to comfortable and productive work.

What to do?

The development of psychological safety should start from the leadership: lead by example, show vulnerability, and convey the message that making mistakes is okay. Reward the act of experimentation, not just its success or failure. Create an environment where failures are openly discussed and are treated as opportunities for learning, not as something to be avoided.


As we wrap up this post, I want to stress again that there's nothing inherently wrong with the waterfall approach when it's consciously chosen for the right context. However, when it creeps into your Agile journey uninvited, it can become a stumbling block. I hope this post has shed light on the ways hidden waterfall can impact your team negatively, and that you now feel equipped with the tools to counteract it.

Remember, Agile is not the destination but the journey. It's simply a way of working that helps you achieve your goals and deliver more value. So, instead of obsessing over becoming 100% Agile, apply common sense and keep asking yourself whether you are maximizing efficiency for yourself and your team at any given moment. Here's to your continued success on your Agile journey. Best of luck!