Bring the Customer Along

Recently I wrote an article with a rhetorical question for a title: “Are Customers Ready for Agile?” The idea stemmed from the fact that software development organizations have followed Waterfall methodology for so long that they h've even ingrained it into the customer psyche and their PMO and IT departments.

Though Agile is becoming the “new normal,” they won't really help anyone unless the entire ecosystem understands and adapts to them. (Luckily, if it’s difficult to learn, it’s more difficult to unlearn.) So, on dwelling further on the topic of customers, it occurred to me that there might be better ways of engaging with them when we expect them to participate in an Agile framework for managing a project, especially when Waterfall is still more or less engrained not only within their organization but, often, within our own.

Here are four methods of customer engagement that I believe can be of benefit during the course of a project:

1. Engage them early on.

As software organizations transition to Agile, they're always in process of engaging their employees in trainings, both to introduce them to Agile overall and to help them relate to various roles within the practice. It would help if the account management team also collaborated with the customer, inviting the key stakeholders, those who are going to engage with the project team, to these formal sessions. (If these are external trainings that ,must be paid for, the account team will need to discuss this with the customer — some may be interested in picking up the tab for their employees.)

The benefit would be that the role-based training would help the customer become familiar with the expectations and activities of a product owner. The project stakeholders would also begin to understand the Agile process

2. Follow the Scrum process from the word go.

Most projects have an initial “discovery” phase, when high-level requirements need to be understood once the RFP (request for proposal) or proof of concept has been accepted. This phase is generally a set of discussions that, eventually, leads to a tome of a document. However, if the project aims at following Agile methods, it would do a world of good if this “discovery” phase itself followed the Agile process. The idea is to have short sprints, which could center around processes under discussion. At the end of each sprint, the sprint demo would be a presentation to the customer of the requirements, as gathered and understood by the implementing organization.

The benefit would be twofold: First, it would reduce the chances of high-level requirement gaps. Second, the Scrum regimen would be in place right from the start, for both the customers to the implementing team.

3. Make sprint demos compulsory.

This might be easier said than done. And it's not a mandatory step per the methodology. However, it’s human nature that if any piece of code or design has to be demonstrated to the customer or product owner, the Scrum team and the ScrumMaster are bound to give it their best. I'm certainly not insinuating here that otherwise they would do a shabby job. All that I propose is a regimen to demo each sprint-end result. As I have observed firsthand, it's difficult to demonstrate every time. Still, a demonstration can be, for example, the design team's work, including what was considered before the final design was decided upon, the impact of design on the actual development, how this design will compare to any other in terms of scalability or efficiency, etc. We can get creative about what one can demonstrate.

The main idea here is to engage the customer throughout the project, reducing or mitigating any unnecessary surprises late in the cycle while keeping the ball — and customer interest — rolling.

4. Take formal feedback.

Kill me for saying this, but as much as I have read and practiced Agile as a product owner, I've never been asked for formal feedback after a sprint demo or sprint retrospective. But I believe that it would help if the product owner/customer were required to fill in a simple template. Some examples of what such a template could cover:

• Demo topic
• Demo/sprint team
• Assumptions or any caveats
• Feedback section

The idea is to have all the members of the customer team who own the demo topic share what they think was achieved in the sprint, whether it was demonstrated or just discussed in the retrospective.

Just as demonstrations impact the Scrum team’s psychology, being asked to share their feedback sprint after sprint puts a lot of responsibility on the customer. They will have to engage, understand, and own what the team has achieved — or not achieved — in the sprint. Formal feedback can also act as a formal signing off, and it can provide an easy reference for the entire project team.

To summarize, as the software development world is adapting new methodology, it would be in our best interest to bring the customer along. Help them with the changes, and adapt together for better results.