Bring the Customer Along

30 April 2012

Shweta Darbha
CA Technologies Lid

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.

Article Rating

Current rating: 0 (0 ratings)

Comments

Bruno Eduardo Andrade de Carvalho, CSM, 5/1/2012 11:32:33 AM
Very good article!
Ruud Rietveld, CSM, 5/2/2012 10:00:57 AM
Hi Shweta,

I like the article in general, and will certainly add it to my list of useful articles to remember and use, but I have one question about method 3. You write that sprint demos should be compulsory. I thought that they were a part of the framework and therefore must be performed in order to call it Scrum. The example you use to describe why it might be hard, seems to hint that the team only made a design in a sprint, which insinuates to me that the team is using a waterfall-ish way of working. What did you intend to tell us with this method?


Kind regards,
Ruud Rietveld
Shweta Darbha, CSPO, 5/8/2012 11:16:30 AM
Thank you Bruno Eduardo for your positive feedback
Shweta Darbha, CSPO, 5/8/2012 11:26:49 AM
Hi Ruud
First of all I would like to thank you for your positive feedback.
Now I do not completely disagree with what you state , that if a team does only design in a sprint doesn't it become waterfall.
Let me explain:
We have experienced that many stories require a large design change which needs to be whetted by senior and more experienced team members (who are in different scrum team, we have distributed scrum team across three geographies) and eventually it has to be presented to the customer for sign off. These are complex technical solutions which need to be aligned to customer architecture. The product owners consciously create stories in such scenarios which require the tech team to come up with best design solution or multiple options. This might be not be completely be in tune with purist form Scrum but these are practical manifestations that I have observed.

Regards
Shweta

You must Login or Signup to comment.