When You Are Agile and Your Client Isn’t. Side B: The Playbook

This document continues the reflection on the two worlds, Agile and Waterfall, that need to communicate, focusing on strategies to integrate them.

In the first part, we tried to frame the basic elements of these strategies, providing an example of mapping requirements into user stories. Now, we will examine some practical aspects of this common scenario.

From the Requirements Document to the Backlog

At this point, we have two options, plus a third one.

Option 1

We convince the client that our user story list is equivalent to, or even more comprehensive than, the initial requirements document. The arguments for this are twofold: the informational equivalence of the two tools and the ability to better manage subsequent changes. Because one thing is certain in a project: it will undergo changes during development. If we have correctly mapped user stories to requirements, we have a good chance of succeeding. This scenario provides us with all the tools for change management. From now on, we and the users will speak the language of user stories. A change? We create a user story. A modification of priority? We change the order in the backlog. A release? Here are the released user stories. Voilà.

Option 2 (Plan B)

If we can’t or are not able to fall into the first scenario, for whatever reason, we must try to divide the project into tranches of about two months. This allows us to negotiate the content of each tranche in detail only when the next one is about to start. The transformation into user stories will remain an internal matter for the group. However, by keeping planning and release times short, the need for changes during the tranche will be minimal. Should these needs arise, they would require the integration of the backlog but also of the traditional requirements document.

Third Possibility

If neither of these strategies is feasible, we must be prepared to deal with extra work to keep the necessary documents updated in the customer’s language. We should take this into account in our estimates. From our side, let’s manage it as an additional release requirement, within the team’s definition of done.

In any case, it is beneficial to have points of contact within the client organization. These contacts should be used for promptly reporting any feedback coming from development (problems, but also opportunities) and to expect any changes in priorities or specifications.

Transforming Touchpoints

Every traditional project has pre-established touchpoints with the client: kickoffs, progress meetings, and requirements validation. These moments can be transformed into valuable opportunities for agile collaboration.

• The classic requirements validation meeting can become a refinement session. Instead of just asking “Is this correct?”, we can explore use scenarios and edge cases. This enriches our understanding of the actual needs.
• The monthly Work Progress Report can become a mini-review. In addition to presenting completion percentages, we show the evolving product. This gathers valuable feedback and helps the client grow in their understanding of the product’s purpose and use.

If the client has agreed to Plan A and has learned the language of user stories, these meetings will not be too different from the ceremonies we are used to. We may follow the client’s rituals, but the content and effects will not differ much from our usual practices.

If we had to switch to Plan B, these meetings would probably take place towards the end of each tranche. Ideally, leaving some room to make changes following the feedback received.

In any case, we must do everything possible to gather feedback as early as possible, also thanks to our contacts in the client organization. We manage changes through negotiation and the ability to identify win-win solutions. Are you thinking you’d need a good Business Analyst for this? Yes, you do.

Tangible Benefits for the Client

This approach to integrating Agile and Waterfall brings concrete advantages that the client can appreciate without necessarily mastering the underlying methodology:

1. Continuous visibility: Instead of waiting until the end of the project to see the product, the client can observe its evolution, verifying that it is going in the desired direction.
2. Controlled flexibility: When new needs or priority changes emerge, we can manage them in a structured way, evaluating the impact together and finding the best time to incorporate them.
3. Risk reduction: Continuous verification drastically reduces the risk of developing features that are not aligned with expectations or that, in the meantime, have become less of a priority.
4. Optimized time to market: The most important features can be completed and used sooner, generating value while the rest of the product is being finalized.

Managing Estimates and Budgets

One of the most delicate aspects is managing estimates and budgets in an agile way while maintaining the predictability required by traditional projects. The approach we propose, whenever practicable, is:

• Provide high-level estimates for the entire project, based on the identified stories.
• Assign a “size” to the various stories identified to have a reference to the complexity/amount of work needed to complete it and subsequently negotiate any changes in the client’s priorities.
• Divide the project into tranches of predictable duration not exceeding two months and detail the estimates only for the features being developed in the specific tranche.
• Maintain the willingness to defer user stories that turn out to be non-priority, anticipating others of the same size in the current tranche.
• Regularly communicate the status of budget consumption in relation to the value produced as well as the work done.

This allows us to maintain control over costs while retaining the flexibility needed to maximize the value of the final product.

The key is to always keep the focus on the concrete benefits for the client rather than on the methodology used, negotiating the bare minimum that makes us work well and brings benefits to the client.

Recording and Communicating Progress

Beyond completion percentages

We said we would develop user stories and that we plan to offer the client progress that is based on the actual product, beyond completion percentages. Consequently, it is necessary to demonstrate clearly and structurally how the developed user stories satisfy the initial requirements established with the client, offering a precise picture of what has been completed and what is still pending. And making UAT easier.

In the hospital software example, we mapped the user stories to the customer’s traditional requirements. Mapping allows development teams and customers to stay aligned, and immediately makes it clear which initial requirements have been completed. A document that highlights the correspondences between user stories and requirements, perhaps organized in a synoptic table, can be a powerful tool for laying the foundation for the next steps.

The default option

If we have not had the opportunity to bring the client directly onto the user story ground (Plan A) or to divide the work into digestible tranches (Plan B), we should keep the client aligned by referring in any case to the initial requirements and managing any changes as a change of requirements, on the one hand, and rewriting of one or more user stories on the other. The only other possible strategy to integrate Agile and Waterfall.

Before presenting the release, it will be useful in this case to prepare a summary, which illustrates to the client the completed functionalities compared to the initial requirements. The document presents what will be the subject of the release, in the same terms in which they were initially described by the client.

The summary will accompany the User Acceptance Testing (UAT), a phase that confirms that the features meet the customer’s expectations. This is a formal, but also substantial step, which from a strictly agile point of view should be framed in a review and the work of the Product Owner. From our point of view, we will conduct UAT as an opportunity to gather valuable feedback on the released features and the project as a whole.

In any case, it is very important that, during development, where the need (or opportunity!) arises to make changes to what has been agreed, there is an open communication channel to discuss them before arriving at the release.

Feedback Documentation and Actions for Future Iterations

Once the UAT is concluded, it is essential to collect and document customer feedback, which will then impact subsequent iterations. A log that includes customer comments and change requests can be helpful, but the essential thing is to keep the requirements document shared with the customer updated, and consequently, our backlog. In this way, the feedback received becomes an integral part of subsequent development, ensuring that we meet user needs and preventing the risk of future misunderstandings.

The Challenges of the Agile Mindset in Traditional Contexts

Maintaining an authentic agile approach in a traditional setting is a daily challenge that requires awareness, preparation, and consistency. It is not just about adapting practices and ceremonies, but about preserving a way of thinking that may seem at odds with the surrounding environment.

Daily Tensions

The business analyst often has to deal with situations that test their agile mindset.

• The request for detailed long-term planning clashes with the principle of adaptability: the client asks to know exactly what will be delivered in the coming months, with defined times and costs, while the agile approach would suggest maintaining flexibility to adapt to new information and changing priorities that emerge during development.
• Customer resistance to providing frequent feedback contrasts with the iterative approach: while we would like to frequently show the evolving product to gather feedback and course correct, often the customer prefers formal reviews at fixed deadlines, missing valuable opportunities to steer development in the right direction.
• The tendency to formalize every decision slows down the development process: the need to document and formally approve every minor decision, often through long hierarchical chains, makes it difficult to maintain the agile development pace and respond quickly to changes.
• Fear of change leads to rigidity in the interpretation of requirements: the fear of taking responsibility for changes often leads to a literal and rigid interpretation of the initial specifications, even when better solutions emerge or when the business context evolves.
• The false expectation of organizations, especially larger ones, that there can be a linear development process (I tell you, you do, I pay you) is an illusion that leads to declining responsibility and tends to reject any involvement until the end of the work (If I had to do it myself, why should I pay an external supplier?).
• The organization’s tendency to react to unforeseen events by seeking individual responsibility, instead of addressing them as opportunities for collective learning, hinders transparency and collaboration.

These tensions cannot be ignored or overlooked by imagining that your agile organization will take precedence over the rest. As we have seen, they require a conscious and strategic approach instead.

Agile Survival Strategies

Managing Documentation Without Losing Agility

The traditional context often requires extensive documentation. The real challenge is to keep it alive and useful to the project, preventing it from becoming dead weight.

• Documentation must become a tool for collaboration, not a substitute for dialogue.
• It is essential to keep it updated incrementally, making it evolve together with the product.
• The focus should always remain on the value it brings to the client, rather than its formal completeness.

Balancing Control and Flexibility

Finding the right balance between the client’s need for control and the need to maintain flexibility is a delicate art.

• We can propose verifiable milestones that, however, do not become rigid constraints.
• It is important to use metrics that show the value delivered, not just formal progress.
• Trust is built through frequent small deliveries that demonstrate concrete progress.

Managing Resistance to Change

Resistance to change is natural and needs to be managed with patience and strategy.

• It is important to identify and cultivate allies within the client organization who can support a more flexible approach.
• The benefits must be demonstrated through concrete results, not through theoretical presentations.
• Sometimes it is necessary to accept tactical compromises while keeping the long-term strategic vision clear.

Mistakes to Avoid

1. Hiding too much. We must not mask our agile approach, while we strive to speak the client’s language: transparency builds trust, even when it reveals some complexities.
2. Losing focus on value. The risk of conforming too much to the client’s formal requests can make us lose sight of the main objective: delivering value.
3. Isolating the team. The temptation to protect the team from the complexities of interacting with the client can lead to a dangerous detachment from reality and business needs.

Building Resilience in the Long Term

Indeed, in some cases, we have the opportunity to collaborate for a longer period with a client partner. In this case, certain paths can help us build a more solid foundation for collaboration over the long term.

1. Continuous team training. Team training must be an ongoing process that goes beyond mere technical aspects. It is crucial to openly share the challenges encountered and the solutions found, creating moments of collective reflection. Agile principles are reinforced through daily practice, highlighting how these help us overcome concrete difficulties. Even small successes should be celebrated because they help build a resilient culture.
2. Development of negotiation skills. Negotiation skills are as crucial as technical skills. We need to learn to negotiate while holding our principles firm, building bridges between different organizational cultures. The ability to communicate effectively with stakeholders who have different perspectives and priorities becomes a fundamental skill for success.
3. Creating a community of practice. Creating a strong community of practice is essential for long-term success. Exchanging experiences with other teams facing similar challenges allows us to develop and refine common strategies. Mutual support in daily challenges creates an environment of continuous learning and professional growth.

Conclusion: Agility as a Conscious Choice

Finally, maintaining an agile mindset in a traditional context, and envisioning strategies to integrate Agile and Waterfall, is an ongoing challenge that requires awareness, strategy, and resilience. It is not a battle between paradigms, but a daily exercise in adaptation and growth.

Indeed, the business analyst plays a crucial role in this process, acting as a bridge between different cultures and demonstrating by example that it is possible to be truly agile even in seemingly hostile contexts. As a result, success lies not in methodological purity, but in the ability to generate real value while staying true to the fundamental principles of agility.