When You’re Agile, But Your Client Isn’t: Side A: Laying the Foundation.

As Business Analysts, especially those working for software companies that have implemented agile methodologies, we inevitably face a significant challenge: reconciling our agile organization – painstakingly implemented to drive quality, efficiency, and adaptability – with the need to interact with clients who work according to traditional models, rigid processes, and established waterfall approaches. In essence, it’s about Agile Management of Waterfall Projects.

This article continues the reflection on how agility fits into contexts or among people who don’t always have a trained mindset. See, for example, my other article on managers and agile.

The Daily Dilemma

While the idea of proposing an agile transformation to the client might cross our minds, it’s naive. Organizations have their own pace of evolution, and we probably don’t have the means to suggest cultural and organizational change. At the same time, completely adapting to the client’s traditional model would mean giving up the benefits of the agile approach, compromising our ability to deliver value effectively.

Why We Can’t Just Be Traditional

While we’re wondering why we bothered adopting an internal agile organization, the limitations of the traditional approach come to mind.

• When you wait until the end of the project to show the result to the client, feedback arrives too late, when making changes becomes costly and complex.
• Moreover, the market and business needs evolve rapidly: a plan defined at the beginning of the project may no longer be valid after a few months.

The lack of continuous checks can also compromise the quality of the final product, as any misunderstandings or misinterpretations of requirements only emerge in the final stages of the project.

Not to mention that, paradoxically, a rigid approach makes it more difficult to provide the client with a clear view of the project’s actual progress, often limited to completion percentages that say little about the value actually produced.

The Need for a Balanced Approach

That’s why the real challenge is not to choose between agile and traditional, but to find a way to make the two approaches communicate, maximizing the benefits for the client.

When talking about agile management of waterfall projects, this requires:

1. Pragmatism: accepting that not everything can be perfectly agile.
2. Flexibility: adapting agile practices to the specific context.
3. Gradualism: introducing elements of agility in a natural and non-invasive way.
4. Transparency: maintaining clear processes for the client.
5. Value Focus: focusing on tangible benefits rather than methodologies.

The Hidden Opportunity

This apparent dichotomy between agile and traditional approaches can be a real opportunity for both. Operating in an agile mode in-house, while maintaining a traditional interface towards the client, opens up several strategic and operational advantages.

• For the client, this approach provides controlled and progressive access to changes, without the need to disrupt their structures or complicate internal dynamics. Our agile methodology allows us to absorb and manage the complexities and requests that arise quickly, without downloading them directly to the client. In doing so, the client perceives the tangible benefits of the change – in the form of ready and well-implemented solutions – without necessarily having to confront the challenges of the methodology.
• From the supplier’s point of view, this way of working allows us to highlight the concrete advantages of agile, such as the speed of execution and the ability to adapt to evolving needs. Thanks to more frequent release cycles and predictable results, the team can show the value of their work continuously, consolidating the reputation of a reliable and responsive partner. Cadenced and transparent deliveries strengthen trust, fostering a positive relationship based on consistent results and the absence of surprises.

Furthermore…

…this collaboration encourages the client’s gradual familiarization with more agile practices, which can be adopted naturally over time. The client thus begins to perceive the value of agility in the results achieved, which can lead to greater openness towards this approach and, in some cases, a gradual evolution of their way of working.

Ultimately, even though integrating two such different methodologies can be a challenge, addressing it in the right way creates a more effective and solid collaboration, bringing significant benefits to all stakeholders involved.

We have outlined the themes of this challenging coexistence. In the following sections, we will explore some techniques and practical tips to implement this hybrid model with an adequate degree of success.

From Principle to Practice: How to Be Agile Without Asking Others

How can we concretely apply agile principles while maintaining a traditional interface with the client? The key lies in focusing on aspects that bring immediate value and adapting agile practices to the specific context. Let’s see how to do it effectively.

Preparation is Everything

The first step in the agile management of waterfall projects is a careful analysis of the specification documentation provided by the client. Instead of simply reading it sequentially, we need to “translate” it into tools that allow us to work in an agile way. This means:

• Grouping the requirements by functional areas and business value.
• Transforming the requirements presented linearly into user stories and acceptance criteria.
• Identifying the main user journeys, even if not explicitly stated in the document.
• Creating a story map that helps us visualize the product as a whole.
• Highlighting areas of ambiguity that will require more collaboration and in-depth analysis.

This preliminary work, invisible to the client, allows us to organize the development in an agile way while maintaining traceability with the original requirements.

The basic idea…

…is that a series of requirements can be remapped into user stories with one or more acceptance criteria. The transformation of requirements into user stories is essential because only in this way do we define manageable work blocks for an agile team, able to describe effective increments of value that can be developed and released to the user. At the same time, we create the prerequisites to allow two different ways of describing the work to communicate with each other.

A Concrete Example: Patient Anamnestic Data for Hospital Software

Let’s see how it is possible to transform a classic paragraph from a long document, provided by the client, with the requirements of the software to be developed, into user stories. The business analyst has inserted numbers in the text to map the requirements.

The example, set in the context of agile management of waterfall projects, makes it clear that the need to write user stories will have led to the need to investigate with the user the purposes of the various aspects of the requested function, as well as to explicit and clarify “hidden” functionalities, such as the modification of data, just mentioned in the waterfall text received from the client.

The acceptance criteria will also include non-functional requirements, which are often lacking in traditional documentation: how many users must be able to access simultaneously? What response times are expected? How fast is the data growing? …

So Let’s Leave It at That…

We have broadly outlined the problem and imagined how, at the most basic level of requirements, to lay the foundations for creating the interface between the two worlds and allow the agile management of waterfall projects. But to make such diverse cultures speak to each other, other important elements are needed. In the second part, we will try to visualize some of them.