Agile Customer Validation Vision

[article]

Motivate Customers to Attend
Establishing customer profiles is fairly straightforward compared to motivating customers to participate in validation activities. Start by inviting customers to just one end-of-sprint review or demo session and getting their input. Customers who have not experienced something like this before typically are impressed to see working software so early in a release lifecycle. If they like the first validation session, then invite them to the next end-of-sprint review and excite them by highlighting where you’ve incorporated their input.

At this point, ask the customers if they want to participate periodically at a per-sprint cadence. (They usually are more receptive to this approach than if you had asked them to attend a bunch of meetings up front). Also, find out what customer outreach and validation sessions the product owner already has in place—e.g., a customer advisory board or user groups

Some additional tips:

  • Educate customers on the agile approach (e.g., an agile overview with a focus on the importance of customer validation).
  • Explain that their participation will give them more direct input to the product under development.
  • Potentially establish a reward system for initial participation, like a $50 gift card. Note: It must be lower than the company’s gift policy but enough to motivate them.

Consider Various Types of Customer Validation
While there is significant benefit to the end-of-sprint review or demo, the customer is, in most cases, only viewing the working software at that point. Let us review the potential types of customer validation sessions and their attributes in more detail.

End-of-Sprint Review/Demo —This is a type of validation that demonstrates the working software completed during the sprint, shown to customers in order to both highlight progress and gain the all-important customer feedback.

  • Activity—viewing the working software
  • Primary benefit—to get immediate feedback of newly created or changed functionality to ensure the team is directionally correct.
  • Frequency—regular cadence per the sprint/iteration cycle. Sometimes, two or more end-of-sprint reviews may occur when there are fairly different sets of customers (e.g., customers representing different industries, competing customers, etc.).
  • Who participates—a group of customers selected via the prepared customer profiles. If a customer advisory board or user group exists, it may include these folks.
  • Variations—One-on-one demos specifically to one customer or one company. This will occur as needed if you are targeting a particularly valuable customer.

Hands-on Experience —This is a type of validation where customers will exercise the software in a hands-on manner in a simulated or pilot working environment.

  • Activity—hands-on exercise of working software. Requires an Internet-accessible installation of the working software for the customer to use. This is sometimes referred to as alpha testing.
  • Primary benefit—to get customers’ feedback from hands-on use of the working software, which aids in human interface and ease-of-use feedback. This is particularly useful for cloud-based applications where customers may easily access and exercise the software.
  • Frequency—typically initiated where there is enough working software for the customer to exercise. Because of the customer commitment, this usually occurs only once or twice within a release. It is beneficial to establish several use cases for the customer to walk through, although ad-hoc use is welcome.
  • Who participates—several fairly committed customers selected via prepared customer profiles.

On-premise Installation Validation —this is a type of validation where customers physically install the working software into their environment.

  • Activity—validation of installation process running within the environment and hands-on exercise of working software. Requires an established installation and configuration process. This is sometimes referred to as acceptance testing, user acceptance testing, or beta testing.
  • Primary benefit—to get feedback to ensure that the software will install and run within a customer

About the author

Mario  Moreira's picture Mario Moreira

<strong>Mario Moreira</strong> is a Columnist for the CM Journal, a writer for the Agile Journal, an Author, an Agile and CM expert for CA, and has worked in the CM field since 1986 and in the Agile field since 1998. He has experience with numerous CM technologies and processes and has implemented CM on over 150 applications/products, which include establishing global SCM infrastructures. He is a certified ScrumMaster in the Agile arena having implemented Scrum and XP practices. He holds an MA in Mass Communication with an emphasis on communication technologies. Mario also brings years of Project Management, Software Quality Assurance, Requirement Management, facilitation, and team building skills and experience. Mario is the author of a new book entitled “<strong><a href="http://www.amazon.com/dp/0470746637?tag=cmf06-20&amp;camp=213761&amp;cre... Configuration Management for Agile Teams</a></strong>” (via Wiley Publishing). It provides an Agile Primer and a CM Primer, and how to adapt CM practices for Agile Teams. Mario is also the author of the CM book entitled, “<strong><a href="http://www.amazon.com/Software-Configuration-Management-Implementation-R... Configuration Management Implementation Roadmap.</a></strong>” It includes step-by-step guidance for implementing SCM at the organization, application, and project level with numerous examples. Also consider visiting Mario’s blog on CM for Agile and Agile adoption at <a href="http://cmforagile.blogspot.com/">http://cmforagile.blogspot.com/</a>.
&nbsp;

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03