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, Agile 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 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.

In this final installment, I'll provide some case study "vignettes", which illustrate how some specific agile enterprises found the right people necessary to fill this role, along with some of the unique challenges they faced, as well as the solutions they applied.

Roles, Titles, and Responsibilities Vary by Software Business Type

Since the business mission, organization, operating methods, roles, titles and responsibilities differ dramatically across industry segments, it follows that the patterns of agile adoption vary across these segments as well. In this post, I'll provide real world examples of how this challenge was addressed in three primary software business types:

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.

ISV Example 1 - TradeStation Technologies

TradeStation is the premier brokerage trading platform for rule-based trading. They note: "whether you trade stocks, options, futures or forex, TradeStation offers uniquely powerful strategy creation and testing tools, customizable analytics and fully automated trading technology in a single trading platform."

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."

BMC Software is a leading provider of IT Infrastructure Management Solutions. In 2006 and 2007, the Infrastructure Management Group (IMG) transformed their development organization (gt;100 practitioners) using agile development practices to deliver "a major product to the market in less time and with higher quality than previously possible" (see BMC Case study). Israel Gat, then VP of Infrastructure Management at BMC and now a Cutter Consortium consultant, led the transition. Recently, he described how they filled the Product Owner role (which they re-titled as "Requirements Architects") as follows:

"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."

Other Thoughts on Larger Scale ISVs
When I was a VP at Rational Software, where we employed 900 or so software development types, we had a specialized role titled something like "Technical Marketing Specialist". This role was dedicated to working with the teams in defining and positioning the technical aspects of the solution to the marketplace. These individuals were typically collocated with the teams of their business units and they spent about half their time working with the teams in defining the solution and about half their time working with customers, training field engineers, etc. While this was a RUP, rather than agile shop, it occurs to me that the Technical Marketing Specialists were filling a role roughly equivalent to a Product Owner in agile. I mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV.

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 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.

Embedded Systems Example - Symbian Software Limited
When it comes to embedded systems and an even much larger enterprise scale, Symbian Software (now a part of Nokia) develops and licenses Symbian OS, the market-leading open operating system for mobile phones. Symbian initiated an agile transformation in 2008 that will ultimately affect many hundreds of practitioners.

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."

IS/IT Examples
When it comes to IS/IT, I have observed that the role/title of the Business Systems Analyst (someone responsible for analyzing the business needs of clients to help identify business problems and propose solutions) is often a reasonably good fit for the Product Owner role. In a couple of cases, I've seen that role directly fulfill the Product Owner responsibilities, (if not the title) and many such individuals have even be collocated to live with the team as part of the agile transformation.

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.

Discount Tire is America's Largest Independent Tire Dealer. Chris Chapman, Application Services Manager and his teammates are driving a phased agile transformation that will ultimately affect the entire IS/IT team. Chris noted how they addressed the Product Owner challenge:

"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).

Series Summary
In summary, an agile implementation will be no more effective than the enterprise is at filling the critical Product Owner role with people who have the right mix of skills and interests to help agile teams reach their full, productive potential.

In this three part series, we've described first, why the enterprise must take a nuanced approach that empowers both agile product managers and product owners 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.

About the Author: Dean Leffingwell is an entrepreneur, executive, consultant and technical author who provides product strategy and enterprise-scale agility coaching to large software enterprises. Mr. Leffingwell has served as chief methodologist to Rally Software and formerly served as Vice President of Rational Software, now IBM's Rational Division, where he was responsible for the RUP. He was also the founder and CEO of Requisite, Inc., makers of RequisitePro. His latest book is Scaling Software Agility: Best Practices for Large Enterprise and heis also the lead author of the text: Managing Software Requirements: First and Second Editions, both from Addison-Wesley. He can be reached through his blog at http://www.scalingsoftwareagility.wordpress.com.

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.