I’ve said before that large enterprises are each unique and have situations that your typical scrum cookbook cannot anticipate. Because of their size enterprises tend to centralise specialist functions. Product Management is one such function.

Before I delve into the issues, I had better define what my company calls a product manager. You will hear names like; Product Manager, Program Manager, Project Manager, and Development Manager used differently even within software companies.

Product Managers are responsible for determining the product direction. They talk to customers to determine needs. They put together road maps and do competitive analysis. They work with sales to find out issues blocking adoption. They work with Engineering to produce product requirements, and determine priorities. I suppose you could say that they are the public face of the product.

That sounds like the definition of a product owner in scrum right?

Yes, and No. Yes they own the direction of the product, but they’re not part of the engineering organisation. At least in Symantec they’re not. They have their own VP who is a more or less a peer with the engineering VP’s who are ultimately responsible for the products they produce.

They’re also not a large group. There would be about one Product Manager for about every fifty developers. Because they need to spend a lot of time with customers, it makes sense to place them all together in whichever region has the most customers. And here is where I get to my point, in large outsourced organisations, that will probably be a different region to the development team.

For waterfall this doesn’t really pose a problem. Product Managers do a lot of travel, and getting them out to the dev team two or three times a year for a planning session works fine. Time those trips right and Development Managers and Program Managers can then run the plan through to release.

But Scrum requires a more week to week involvement from the Product Owner. Planning sessions at the start of each sprint, and handovers at a minimum. Regular backlog grooming needs to be factored in as well. Scrum pretty much assumes that you’ve got the product owner on hand.

Let me tell you right now that we never really solved this issue to my complete satisfaction. But there are some things you can do to mitigate the effects;

• Do not use paper based sprint tracking tools like post it notes or index cards. You need to move to an all electronic form of tracking. Use Wiki’s like Confluence (http://en.wikipedia.org/wiki/Confluence_%28software%29) and requirements tools like Version One or Feature Plan.

• If you’ve got high end video conferencing available, by all means try it.

• Once the backlog is all electronic, backlog grooming can be scheduled as a weekly con call between Development Directors, Architects and Product Managers.

• Do everything possible to get the Product Managers to attend sprint handover meetings via con-call. Handovers are more structured meetings with a fixed agenda and are easier to follow over the phone. They should be less than an hour, and make sure the QA lead prepares a demo and uses screen sharing technology like Webex.

Planning meetings are too long and unstructured for a Product Manager to add value on the phone. It’s possible to get Development Managers and Architects to act as a proxy for the Product Owners for the planning and operational aspects of a sprint as long as they’ve prepared in concert with the Product Managers.

Before I close I would like to make one more observation. Even though the best mapping to the scrum Product Owner seemed to be  Product Managers, I’m still not convinced it was the right one in our case. In their role supporting sales, our Product Managers have never been as available to engineering as we felt they needed to be. Especially as in our case they were not co-located.

I find myself thinking back to the early Altiris days before we’d grown to the point where we needed a Product Management organisation. Our CTO, (later VP) performed that role, and did some coding occasionally as well. He was the very epitomisation of a scrum product owner. Unfortunately CTOs and VPs don’t scale. As their organisation grows they need to create a structure to delegate functions to, and unless that structure is created specifically with scrum or agile in mind we will always have this problem.

So be prepared to map the Product Owner role to several different people. And if you’re a Development Director one of those people will probably be you. Because as far as your VP is concerned you are the Product Owner.