In prior posts in this blog series and in the Agile Journal, I’ve described the critical role the team-based agile Product Owner plays in helping achieving enterprise agility. Indeed, the role, originally defined by Scrum, is now so comprehensive in agile methods that the role is hard to separate from the practice of agility itself. I’ve also described the larger challenge of scale, noting that it is no trivial task to identify and train 10, 20 or 100+ individuals to effectively implement this role in the larger software enterprise. I also promised to describe some best practices as to how some larger enterprises go about filling this role. This is that post.
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 also. 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 below, 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. (Keith has already opined on the dual-roles of agile Project Owner and agile Product Manager in a prior post). 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.”
ISV Example 2 – CSG Systems
CSG Systems is a customer interaction management company that provides software- and services-based solutions that help clients engage and transact with their customers. Today, CSG’s solutions reach more than half of all U.S. households each month and manage over $36 billion in transactions annually on its clients’ behalf.
In 2007, CSG began transforming their ACPx product development (>100 practitioners) efforts using enterprise agility best practices. One of the leaders of the effort, 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 , moved them to other slots, and then 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”
ISV Example 2 – BMC Business Performance Manager Project
BMC Software is a leading provider of IT Infrastructure Management Solutions. In 2006 and 2007, the Infrastructure Management Group (IMG) transformed their development organization (>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 a similar thoughts when he commented on a prior post 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.
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 solution. 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 assigned to 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 other cases, I have seen the role filled by “Project Managers” in the larger IT shop. 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.
IS/IT Example—Discount Tire.
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).”
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 one or more agile teams reach its productive potential. While, as we have seen, the sources for the pool of candidates vary from company to company and across industry segments, the challenge is being successfully addressed in even the largest software enterprises transitioning to these more productive, and more personally fulfilling, agile enterprise methods.
Looking Ahead
I suspect that this completes the Product Owner portion of this blog series. In the next few posts in this series, I’ll be moving on to describe some of the ways the Product Manager role also must evolve as the enterprise successfully transitions to agile methods.
Scaling Software Agility 