Agile undercover - when customers don't collaborate

The other night I attended Rashina Hoda’s totally awesome presentation “Agile Undercover: When Customers don’t collaborate” at the Wellington Agile Professionals Network.

Rashina presented the research she had conducted on the basis of interviewing 30 people across 16 organisations in New Zealand and India. Having delivered a steady supply of Agile teams and individuals over the years I was excited to see the results of Rashina’s research.

Her chosen method of research was grounded theory which basically means that instead of testing a pre-conceived theory the researcher gathers data and generates a theory based on the data collected. A bit like Google Flu Trends ...

Not too surprisingly, one of Rashina’s main findings was that the greatest problem teams were facing was too little involvement from the Product Owner or customer.

What I found most interesting were the coping mechanisms teams employed to work around this lack of customer involvement. While certainly not ideal the following seven patterns emerged as coping mechanisms used in the “real” world.

Coping Mechanisms

1. Changing Priority

When teams didn’t have enough information on a user story they changed the priority and pushed stories that were awaiting customer clarification further down the product backlog until they received the required customer response.

An Indian team used a “definition of ready”: Very much like a Product Owner won’t accept anything that doesn’t fulfill the “definition of done” the team wouldn’t accept a story into the sprint that didn’t fulfill the “definition of ready”.

By “ready” the team meant that the business goals and expected outcome associated with the user story plus implementation details necessary to estimate the story had to be clear.

2. Risk Assessment Upfront

A New Zealand coach used an Agile risk assessment questionnaire to gauge the level of customer availability on the project upfront. The questionnaire included questions such as “What is the commitment of the customer rep in terms of time?”

Answers such as “Assigned to the project” or “Available as a first priority” were the best case scenario while the worst was “Just as time allows”.

The risk assessment before the beginning of the project allowed the team to discover potential problems upfront and to think about possible strategies to improve the situation or, if this wasn’t possible, to discuss strategies to work around the problem.

Sometimes the team could manage to negotiate with the customer to to free up the customer rep’s time to allow them to become a project team member for the duration of the project by providing funding from the project.

3.Story Owners

The practise of assigning story owners was an adaptation to the Scrum practice of allocating a Product Owner. Story owners were responsible for particular stories, instead of all the stories in the product backlog. Every story had to have an owner to get into prioritisation.

The strategy allowed the customer’s organisation to split the workload and time investment across several people and allowed the team to discuss stories in synchronization with the corresponding story-owner’s availability.

4. Customer Proxy

Some Agile teams used a customer proxy - a member of the development team co-ordinating with the customers - to secure requirements and timely feedback.

Most often the team member acting as the customer proxy was a Business Analyst, due to (most) BAs’ proven ability to communicate ideas.

5. Just Demos

Despite their reluctance or inability to attend other meetings, almost all customers were interested enough to attend product demos (show & tells). Often the part where the team showed new functionality would take 15 minutes but then the team and customer would use the full hour to discuss features and feedback.

6. e-Collaboration

Both in New Zealand and India the main cause of lacking customer involvement was physical distance - not only for teams and customers in different countries but also in different cities or even within the same city. Teams overcame this by using Skype, IM, wikis, Google docs and other collaboration tools.

7. Extreme Undercover

To avoid extreme consequences of lack of customer involvement such as business loss, Agile teams chose to follow Agile practices internally at the team level while keeping the customer unaware. Some teams confessed to having a “Don’t mention the ‘A’-word policy”.

I was happy to learn that Rashina had observed a clear decrease in the use of the “Extreme Undercover”-pattern over the span of her research, probably due to the increasing popularity of Agile among customers (yay!).

In an ideal world we wouldn’t have to use any of those coping strategies but having exhausted all other possibilities to convince the customer we sometimes have to use strategies to cope with a less than ideal situation.

Do those strategies make us less Agile? Probably so. But being Agile is not a binary value; it comes in varying degrees and in all forms.

I have used some of the above coping strategies myself, sometimes with greater and other times with lesser success. I found it very helpful to learn from Rashina’s research that other teams often face that same challenges and I have learned some new strategies I can try if all else fails.

Thanks

I’d like to say thank you to Rashina for giving me permission to blog about her research paper and, on behalf of the APN, for presenting. From a practitioner’s perspective I am grateful for her research as it allows us to gain insights into what we Agile practitioners actually do rather than what we should do or say that we do.

On a final note, I really recommend reading the full research paper which will be available on Rashina’s uni site soon (it’s only 14 pages).