Earlier this year, Machiel Groenveld wrote a post titled, Scrum: The Mythical Product Owner Role. In it he wrote:
"In my experience the Product Owner role is by far the most confusing and hardest role to 'get right' and provokes the most discussion. Even the mere definition of what this person should do is under debate amongst most Scrum practitioners I've talked to."
When I was a Product Manager, I played the role of Product Owner for a number of products at Borland. As Director of Product Management, I now do more coaching and enablement for my Product Managers. While Groenveld's comment applies to Scrum, I think it also applies in a more general sense to anyone who plays the role of "customer proxy". I first heard the term customer proxy from an XP team who needed to accept a compromise to the principle of Onsite Customer. They were developing software for on off-site customer and decided a member of the team would "channel" the customer needs for the rest of the team. In this case, the role rotated through the team. Although my first experience was back in 1999, I have seen many Agile teams accept similar compromise due to the modern reality of distributed business.
A customer proxy's main responsibility is to represent customer needs in planning, implementation, and testing. As the team has questions about what is best for the customer, the proxy provides answers and is accountable to the customer for those decisions.
A common reason for a customer proxy is the mismatch between short, iterative planning cycles for the development team and long, inflexible planning cycles for stakeholders. Scrum and XP push the customer proxy to slice requirements into smaller units of work that can fit within short development iterations. For many customer proxies, this requires new skills in elicitation, analysis, and validation. For elicitation, the customer proxy needs techniques to get smaller requirements from stakeholders at the outset. For analysis, the customer proxy needs streamlined ways to associate value, risk, and effort with requirements. For validation, the customer proxy needs to obtain agreement and commitment on granular requirements without losing sight of larger business goals. Like many other practices in Agile development, the discipline required for these practices is not less but more. All too often, the move to Agile exposes the fact that not enough of these things were happening before the transition.
I have met many people in the role of customer proxy who have previously played a similar role in more traditional development, whether they were requirements analysts or project managers. Unfortunately, many of them did not grasp the essential difference between Agile and the single-threaded waterfall style of development -- the shift in mindset around change. In Agile development, the customer proxy stops resisting scope creep but instead makes the consequences visible and apparent.
This was a big change for me when I first became a Product Manager and started applying Agile principles. The need to shift focus from controlling requirements change to getting good at enabling requirements change is a big one. But it is a necessary one when it comes to coaching coaching stakeholders on their new rights to add requirements, change their minds, and reprioritize.
In my experience, FDD offers much more guidance than Scrum or XP for a customer proxy struggling with these issues. In particular, FDD describes several specific requirements elicitation and planning techniques that bring domain experts and the business into the process itself, while also providing guidance on how to slice things into parts that can fit into iterations. On one hand, the FDD techniques may seem like traditional waterfall in the focus on up-front requirements elicitation and design. On the other hand, the techniques are still performed with frequent iteration. Such up-front activities assure business and developer collaboration, thus reducing the dependence on a customer proxy.
In the end, I'm left wondering about the role of a customer proxy when we say we value "customer collaboration over contract negotiation." How much does dependence on a customer proxy undermine this Agile principle?
Comments