One important characteristic of agile development over non-agile processes, such as waterfall, is the presence of an onsite customer. Unlike the Project Manager or ScrumMaster, whose job it is to keep the team healthy, the Product Owner or onsite customer representative’s job is to be a proxy for the real customer and ensure development is moving in the right direction. This doesn’t require coding skills but it does require a deep knowledge of what needs to be built. Here are seven strategies for working more effectively with an onsite customer.
1. Have a single customer representative
Defining software by committee rarely works well. Having a single product owner or customer champion who is responsible for ordering the backlog and available to answer questions developers might have while they are building features is far more efficient and less error-prone than creating longwinded specifications, and it also opens the door to mutual discovery between the product owner and the developers that can yield better solutions.
2. Have the customer help order the backlog
One of the key roles of the customer representative is to answer the question, “What should be built next?” This need not be a technical evaluation, it should generally be based on what the next most important or valuable feature is. In addition to ordering the backlog, the customer representative should have a clear idea of how the features that are about to be worked on should behave.
3. Use stories as a “promise for a conversation”
Stories replace longwinded specifications and use cases but not entirely on their own. A story is a single sentence that describes the who, what, and why of a feature to be built. Stories do not describe how to build a feature. Stories give developers an understanding of what is needed without taking away their freedom to figure out the best way to implement it. But a story is just the starting point for development, it is the beginning of an ongoing conversation between the Product Owner and the developer. In this conversation, the Product Owner should be focused on feature goals and constraints, letting the developers figure out implementation details.
4. Have the customer help define acceptance tests
In addition to the story, it is valuable to define acceptance tests that specify what the feature will do. There are frameworks, like SpecFlow, Cucumber, and FIT that can be used to automated this process. Acceptance tests also help the customer and developer to identify edge cases and other criteria for business rules. This can give the customer and developer a common, unambiguous language to express subtle aspects of a feature’s behavior.
5. Keep the customer available to the team
Sometimes I hear managers say they can’t afford to have a Product Owner or customer representative available to the team to answer questions and provide direction on an ongoing basis, but the truth is usually that they can’t afford not to! Software development is expensive and building the wrong thing or not knowing when to stop building out a feature accounts for more than half of software development time and resources. Building the wrong thing and over-building is not only a waste, it also significantly increases maintenance costs. Save time and money by having the Product Owner available to answer developer questions quickly.
6. Engage the customer in planning sessions
Estimation and planning are a key part of every iteration and the Product Owner should be available and engaged in these sessions to help provide clarity and also to get a better understanding of the technical issues involved in building the requested features.
7. Demo progress at every iteration
Demonstrating the features built after each iteration helps engage the team and lets stakeholders see progress. This not only helps keep moral high but can give management confidence in the team. There is nothing like working software to see how the team is reaching their goals.
Having an onsite customer or Product Owner is almost a prerequisite to effective agile development in all but the most well-understood development projects. They needn’t be a technical position as long as the person doing the job has a good sense for what the product should do and what features are most important to the customer. When done correctly, this approach can eliminate the need for detailed specifications and help the team engage in discovering better ways to build their software, thereby cutting costs and time to market while simultaneously helping to build a better product.
Previous Post: « Seven Strategies for Successful Agile Development
Next Post: Seven Strategies for Remote Teams »