AGILE IN ACTION: Being an effective Onsite Customer or Product Owner

Friday, August 26, 2005

Being an effective Onsite Customer or Product Owner

Agile projects demand Real Customer Involvement. To be an effective Onsite Customer or Product Owner, you must either be a real customer, or be in a position to accurately represent the real customer. You must acknowledge the elevated status you hold and accept the responsibilities that accompany it (Accepted Responsibility). You must be a stakeholder and a fully integrated member of the team. You must be accessible and you must participate in the project proactively and continuously. You must recognise that through your actions - writing user stories and acceptance tests, prioritising user stories by business value, deciding which user stories are developed next, providing rapid feedback, etc - you are effectively steering the project and are ultimately responsible for the business value that is delivered. As the driving force behind the project your presence must be visible, vocal and objective.

Communication is a value of 'agile' and collaboration is an intrinsic behaviour that contributes to the success of agile teams. As the Onsite Customer, you must demonstrate from the outset that you are an equal team member. Respect peoples time. Do not pass on business related activities, e.g. writing user stories, to developers. The developers may assist you with this particular activity but as the business representative and the authority on what is valued by the business you should be making the business decisions and ensuring that the requirements are communicated clearly and are understood. Some of the most valuable information is carried in simple conversations that occur all the time in the War Room. You can pick-up these nuggets by osmosis if you are collocated with the team. Communicate the project vision to the team using clear, elevating goals (Larsen, LaFasto) so that the team is better equipped to help realise it.

You should have high expectations and demand completed and demonstrable code at the end of every iteration. Insist on high test coverage (80-100%), automated unit and acceptance tests, automated builds, continuous integration, and clear visibility of progress. Present the team with challenges that will invigorate their efforts. Don't set unachievable goals and always be prepared to listen, negotiate and compromise. Don't set impossible deadlines or expect the developers to reduce the quality of their work. Development that is rushed inevitably needs to be fixed later resulting in a more costly project.

Define clear priorities based on business value and have the team deliver the highest value user stories first. But understand and assess the risks before making judgements. Priorities are relative so if you say everything is 'top priority' you are not doing your job properly. In this situation you can expect to receive an arbitrary set of completed and incomplete user stories at the end. Insist on knowing the cost of a user story before prioritising. Have the developers estimate the user stories using a unit of magnitude such as story points (this technique provides relative estimates quickly but appreciate that there is a larger tolerance for inaccuracy given the size and potential ambiguity of the user stories at this stage). You're entitled to change your mind but be decisive and avoid making random changes. Changes will occur for many different reasons so regularly assess your priorities and reprioritise quickly.

To facilitate adaptive planning you must express the features you want as user stories so that the team can estimate them. Learn how to write user stories properly and practice evolving their details through discussions and conversations with the developers. Practice expressing those details as acceptance tests.

Provide support, encouragement and recognition to the team both through your words and actions. Use every opportunity and don't save it up until the end of the project. This will motivate the team to do their best for you as the project progresses.

Tags: agile, scrum