On Customer Participation in Agile Projects
By Andy Hayward
Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:
“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”
This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:
“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”
I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Business people and developers must work together daily throughout the project
Agile requires consistent and constant collaboration between the development staff and the customer, and in my experience, veiled threats and extortion do not foster teamwork. This approach undermines the relationship between development and the customer, and it is about as effective as sitting two quarreling children next to each other and telling them to play together. At best you’ll end up with people attending the meeting who either are too junior, too distracted, or too angry to contribute.
As I said, getting customers to be more involved in developing software is a very common challenge, but there are usually reasons for their resistance. The three most common are:
- The customer cannot afford the time – This is a common challenge in organizations where participation is needed from multiple stakeholders with conflicting priorities. Meetings stretch out while people discuss and come to agreement, especially when the organization is first experimenting with Agile and not comfortable with the format. Weekly Sprints may offer greater agility, but only if weekly Sprint planning meetings are sustainable for the business. In Kanban, David Anderson describes several scenarios like this, and outlines solutions which are applicable in all Agile practices that can alleviate some of the coordination and transactional costs
The customer doesn’t see value in the meetings – Meetings that extend beyond the scheduled time, that frequently get side-tracked, or that end without clarity on the decisions and the actions planned do not provide incentive for customers to participate. It surprises me how rarely people define a meeting’s purpose and itinerary, other than a few words in the subject line in the meeting invitation. I can’t remember the last time I received a summary of the meeting’s decisions afterward that I hadn’t written myself. I intend to dedicate a blog entry to managing successful planning meetings, but for now if you do find this to be a problem, think about bringing in an impartial and experienced facilitator to lead the meeting
The customer doesn’t trust the development team to deliver – Agile measures success through delivering valuable software because that’s how customers measure success. If for whatever reason the development team has a reputation for not delivering value, whether the reputation is deserved or not, it can be very difficult to build the level of trust needed for customers to invest their time. Threatening the customer with poorly made software is only confirming their beliefs. In Ken Schwaber’s Agile Project Management with Scrum, almost every case study describes how the customer’s level of trust in development’s ability was very low, and it was won back gradually by choosing and delivering small, valuable improvements.
I’ve found it to be a common attitude in failed or struggling Agile implementations that Agile is something that IT does. Agile is about improving collaboration between development and the customer in order to deliver value to the customer more frequently and more consistently. In order to ensure that the customer can and will meet his or her responsibilities to achieve this, that collaboration has to include the process of selecting, defining and refining the Agile practices to be applied. Make sure your customers are involved in the decision to adopt Agile practices and in the decisions in how and what to adopt. Also, ensure your customers are involved in retrospectives and when improvements to the process are proposed.
In short, you attract more flies with honey than vinegar. Offer your customer valuable software, productive meetings and a schedule they can work with, and you’ll find they’ll be more available. Think of the customers as members of the development team, and consider their needs on equal footing to those of your development team. If that fails, I’ve also found that providing donuts at the meetings helps too.
Andy Hayward has worked in the software industry for over a decade providing software development consulting, writing software, and installing and configuring software products for clients. He has worked for almost every industry you can name, from government to cell phone manufacturers to banks to apple juice producers. You can read more from Andy on his blog.