Part III- Seeding the Agile Product Owner in the Enterprise

Note: This is the final installment of a three part series on the critical Product Owner's role within the agile software enterprise. Indeed, the role, originally defined by Scrum, is now so comprehensive in agile implementations that the role is hard to separate from the practice of agility itself.

In Part I, On Agile Product Managers and Product Owners: A Scalable, Nuanced Approach , I described why enterprises need to adopt a dual approach to this role; one which empowers both agile Product Managers AND agile Product Owners to drive the enterprise to its objectives. In Part II, I described the Responsibilities of the Agile Product Owner in the enterprise setting. I also described the larger challenge of scale, noting that it is no trivial task to identify and train 10, 20 or even 100+ individuals to effectively implement this role in the largest software enterprises.

Roles, Titles and

Responsibilities Vary by Software Business Type

Information Systems/Information Technology (IS/IT) -teams of teams who develop software to operate the business; accounting, CRM, internal networks, sales force automation and the like. Customers are primarily internal to the enterprise.

Embedded Systems (embedded) - teams of teams who develop software that runs on computers embedded in other devices - cell phones, electronic braking systems, industrial controls and the like. Customers may be either internal or external to the enterprise.

Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.

When it comes to agile adoption, each of these business types has a unique set of challenges, none more critical than the successful implementation of the agile Product Owner role. In the examples that follow, we'll look at some specific case studies that may serve to guide others who head down the agile enterprise adoption path.

At TradeStation, Keith Black, VP of Product Development, and John Bartleman, VP of Product Management, have been driving a comprehensive, all-in agile transformation that affects 100+ practitioners. John described their approach to filling the Product Owner role as follows:

"Before transitioning to Agile, our Product Management team was made up of ten product managers who reported into Development. In general, we have always had an internal/technical focus as opposed to the traditional external/marketing focus. When we transitioned to Agile, seven of the ten Product Managers became full time Product Owners; the other three now focus on the market-facing Product Manager role. This separation of labor and concerns has helped us bring additional focus to both the market and technical aspects of our solution."

John then comments on the staffing challenge:

"When staffing the Product Owner role, I would have preferred to use a few lead developers and/or testers since they have the domain knowledge and technical expertise; however, we are reluctant to do this because of the impact on development resources. Therefore, I am hiring a few additional Product Owners from outside the company. I am finding that these people need to be technical, but also need to have good industry specific experience, and that is a difficult combination to find. So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.

For example, one Product Owner we hired was a former developer/development manager with specific industry experience. Another was a very tech savvy developer/project manager who knew our technology, but was from outside our domain. This demonstrates that, in my view at least, technical skills are mandatory, and domain experience is a plus whenever I can get it."

In 2007, CSG began transforming their ACPx product development (>100 practitioners) efforts using enterprise agility best practices. Mauricio Zamora, Executive Director at CSG whose team is responsible for defining the ACPx vision, roadmap and agile processes leveraged to deliver the vision, noted that they established product owners through a series of phases:

"We first had to leverage a combination of Product Analysts originally responsible for waterfall requirements, Architects originally responsible for designing our software and a few Product Owners already experienced in agile execution. Over the course of a few releases, we leveraged the really good Product Owners to set the standard for others. In the process, we discovered candidate Product Owners that weren't a good fit for the role fit, moved them to other slots, and replaced them with more appropriate internal resources and a few additional external hires."

Mauricio (Mo) went on to note that the transformation wasn't easy and it took time to help people see all that needed to change.

"We first educated everyone on the differences between the traditional Product Management, agile Product Owner and Architect roles. We then had to convince management that the Product Owner role required dedicated focus. The visibility agile provides made the increasingly obvious gaps in Product Ownership easier to see and address. Finally, we had to revisit and revise organizational titles and compensation because the new Product Owner role didn't map well into our existing organization."

"Between the product managers and the requirements architects we had enough "hands on deck". We must have needed half a dozen architects to become requirements architects, and we were able to generate them. We might have borrowed a little from the project leads, but the architects were our #1 pool. We did not borrow any from the project office."

When I pushed Israel on how he would envision a transition that involved 20-50 or more teams, he commented:

"A principle I would suggest generating 50 or 100 product owners must be done through apprenticeship (in addition, of course, to good training/consulting). If you accept this premise, you need to factor in a fair amount of time and grow the numbers gradually."

Ryan Martens, founder and CTO of Rally Software and formerly a Product Manager at BEA, had similar thoughts when he commented on this topic:

"At BEA, we had a certain class of product managers called Technical Product Managers. They were exactly Product Owners."

Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:

"After we acquired CrossGain, there was a tremendous amount of pressure to adopt the Microsoft titles of Program Managers - see http://blogs.computerworld.com/at_microsoft_program_managers_dont_program_or_manage who filled a comparable function. "

In the post above, Microsoft describes a current operating model for Program Managers which is somewhat equivalent to the Product Owner role as defined in agile today.

Clearly, the development of a mobile phone operating system is a highly technical endeavor and one where the ultimate user (mobile device user) is fairly far removed from the major technologies (OS, device drivers, media players, etc.) which are the primary focus of the implementation. As such, the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.

Mathew Balchin VP of Multimedia, PIM, CBS within Symbian Software Engineering was integrally involved in the design of the agile rollout model for Symbian. The scope of the challenge, (i.e. finding lots of product owners) was daunting. Matthew described their approach this way:

"We applied the product owner role pretty much out of the box (per Scrum training) and defined the interaction at the outset with our traditional product management functions. We have had some pretty good debates about selecting them. We have so far applied a skill -based selection process rather than an open recruitment approach. All our POs come from engineering teams and are senior engineers with product or customer experience. We have a one PO to two team mapping typically, rarely 3 teams, sometimes 1. It was flagged as one of the pivotal roles in success by pretty much all senior stakeholders and early on we identified the need for role-based soft skills training in addition to the standard agile training."

In the larger IT shop, I have also seen the role filled by Project Managers. In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.

"In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business (it's not always designed that way, but ends up being that way due to not always having business representation on the teams). Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests (which is still a major "cheese moving" event for us).

In this three part series, we've described first, why the enterprise must take a nuanced approach that empowers both agile Product Owners and agile Product Managers to distinctive roles; secondly, the attributes and responsibilities of the agile Product Owner in the Enterprise; and now finally, how and where the enterprise can find the talent to fill this critical, transforming role.

Accomplishing this successfully is one key to unlocking the full quality, productivity and time-to-market benefits of the increasingly agile enterprise.

Bibliography
Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. New York: Addison Wesley Professional, 2007.

Schwaber, Ken. Agile Project Management with Scrum. Redmond Washington: Microsoft Press, 2004.

Comments (0)

Write comment

Show/hide comment form