Is the Agile Enterprise Product Manager the Agile Product Owner?

One of the primary lessons we have learned from the agile movement, is that in order to rethink the development process from an organizational perspective, it is sometimes easier to start with a blank slate than it it is to “edit down” or “refactor” the existing organization. Scrum does this implicitly with a basic postulate that there are only three primary roles in a development team, the Product Owner, the Scrum Master and the Team. Of these, the Product Owner and Scrum Master are new and unique roles in Scrum/agile and most of us agilists have come to appreciate the power of this over-simplified paradigm.

And yet when we reach enterprise scale, the world tends to look a little different and things are a little more complex. Indeed, when developing software at scale, EVERYTHING is a little more complex and ignoring that complexity may be a recipe for real trouble. My friend and coworker, Jennifer Fawcett has been my collaborator on one particular agile project (see and try the product at www.proquo.com), and she has come to the conclusion that the the traditional product manager role in an enterprise is not particularly well suited to assuming the product owner role. This mirrors my experience in larger scale organizations as well, where we typically find a relatively small team of dedicated product managers who spend their time with the marketing, sales, and customer teams and may have little time or even inclination to assume the dedicated, team-based responsibilities of the product owner role. Recently, Jennifer described her perspective in a blog posting at http://agileproductowner.com. I repeat some of her conclusions here:

“I advocate that are two product-related roles within an agile enterprise:

• The Enterprise Product Manager, who typically reports into marketing, and who owns the RELEASE
• The Agile Product Owner, who typically reports into engineering, and who owns the ITERATION

The Product Manager’s goal is to deliver products to the customer, based on customer needs. While this is an over-simplification of what Product Managers do on a day to day basis (we know they provide the vision, prioritize the work, analyze the market, provide pricing, promotion, packaging, etc), delivering quality product to market is their primary objective.

The Product Owner’s goal is to deliver upon the Product Manager’s commitment to the release plan. The Product Manager represents the customer, and is also the customer to the Product Owner. Product Owners literally “live” with engineering and write and elaborate stories, to make sure the features of the release are met and demonstrable, on a prioritized feature by feature, story by story, and iteration by iteration basis. These two roles have direct impact on the success of a release, and both are needed within an enterprise agile organization.”

She further goes on to describe this paradigm in chicken and pig constructs, with the product owner being the pig at the iteration level, and the product manager being the pig for the release. This corresponds nicely to the two levels of planning described in Chapter 10 of SSA and provides us with further guidance as to how to facilitate and manage the release and iteration level plans and activities. With this construct it becomes clear that the product manager drives the release (all elements-vision, planning event, tracking, roadmap, etc.) , and the product owner owns the iteration (all elements-planning, elaboration, execution, acceptance, etc.).

It’s solid thinking and I suggest that you may want to spend a few minutes reading her blog posting on the topic.

OpenUP/Eclipse EPF Team Comes to Boulder

A week or so back, members of the EPF (Eclipse Process Framework Project) met in Boulder. (learn more about this project at http://www.eclipse.org/epf/general/description.php). Member/attendees included Kurt Sand and Chris Sibbald (Telelogic), Per Kroll and Ricardo Balduino (IBM/Rational), Ana Paula Valente Pereira (Whatever Consulting), Nate Oster and Ken Clyne (Number Six) and Bjorn Gustafsson (GoodSoftware). Guests included Ryan Martens from Rally Sofwtare (day one only), and yours truly (day 2 only). I had worked with Per Kroll and Bjorn Gustafsson back in Rational days, so it was fun to see old friends at work, still advancing software practices.

It was interesting to gain an understanding of the purpose of this project (“aims at producing a customizable software process engineering framework, with exemplary process content and tools, supporting a broad variety of project types and development styles”). I was motivated to attend the meeting as I feel there is a significant need in the industry for a better documented, flexible, and agile-based process that can scale to the needs of the larger enterprise. Hoping that OpenUP will address some of that need, I attended the meeting to learn and provide whatever guidance I could based on my ongoing experiences in transforming some of the worlds largest software enterprises in becoming more agile.

I was not disappointed as I see this team evolving to a more natively-agile, yet enterprise-extensible model. To quote from some excerpts from the meeting:

•    “Agility that Scales” is a tag line that has been used since about May (for RUP and OpenUP) and has resonated in the market place.  There has been some resurgence in interest in RUP of late.
•    The names “StartUP”, “StepUP” or “ScaleUP” had some traction with the group since it captured the minimal, complete, extensible message and avoids the “this is THE process”.  The “StepUP” (or “ScaleUP”) may be different for every organization, drawing on the practice library as required.  The following draft list of practices would be part of StartUP (immutable, must do):
1.    Iterative (plan, assess)
2.    Continuous Integration
3.    Concurrent Testing (Developer test, system test)
4.    Two levels of planning
5.    Agile Team (Define, Build, Test; Self-organize)
It was proposed that we call this base configuration  “The Agile Kernel”.  The additional practices added to get OpenUP could be called ScaleUP.  So, OpenUP is:
1.    Agile Kernel
2.    StepUP which includes the following practices:
a.    Evolutionary Architecture
b.    Evolutionary Design
c.    Use-Case Driven
d.    Shared Vision
e.    Practice Authoring Guidelines

I agree with this team that this could be an interesting future framework for the agile enterprise, and with the process authoring tools and the potential for natively hosting an off-the-shelf- or customized process inside Eclipse on the practitioners desktop, where it could reach the developer with direct, day to day impact, I have resolved to watch this forum for future developments that could be of benefit to the larger software enterprise. I’ll keep you posted.

More on Distributed Teams – Ping Identity’s “Swarm” Model for Remote, Distributed Agile Development

I learned yet another new thing this week while attending a board meeting at Ping Identity, providers of software and services for Internet Single Sign On. Ping’s Development VP, Bill Wood, has been practicing and advancing agile development since 2003, and he always impresses me with his innovations and advanced thinking with respect to agile practices. Agile teams pride themselves on constantly improving their practices, and even after four years, Ping is constantly innovating in order to improve productivity, quality and time to market.

Yesterday, he described, Ping’s “Swarm” model of agile development (which seems to be working well, as exhibited by Ping’s steady stream of frequent, on time releases.) Ping has development teams in the United States, a substantial presence in Moscow, and now a couple of developers in Ireland as well. In Bill’s view, when he finds really talented and highly productive people (we know that some developers achieve 5-10X the productivity of others) with in-depth product knowledge, he is loathe to lose them due to their personal needs for relocation, plus he occasionally leverages the serendipity of hiring an already world-class expert who just doesn’t happen to live in any of the existing development centers. To this end, he has advanced his agile model, which he calls “Swarm Agile”, to use these people productively, even though they are remote and highly distributed. He characterizes it below.

Swarming Agile – Highly Distributed Team with a Working Agile Cadence

n Strongly based on Agile tenants (emphasizing people and working software)

n Applies remote talent with overlap of sync time

n Individual work situations will vary:

o Those largely working from home

o Those choosing to always work on-site

o Those required to work on-site for short period of time

o Those always required to work on-site

n Basics of the Model – Combination of working at home with

o team-wide daily Scrums via telecom plus local standups

o face-to-face (f2f) meetings at least one per iteration

o Large, continuous on-site presence during hardening tails.

The travel model is highlighted in the graphic below.

 

You might think that with the nasty time zone problem, the daily meeting would be impractical, and we all know how critical that is in keeping the teams “in synch”. But remarkably, with a little flexibility on the part of some, he accomplishes this as the graphic below illustrates.

In addition, the need for constant communication is augmented by tools for that purpose as well:

All in all, an interesting agile model that again emphasizes “People over Process” and adjusts the process to leverage the talent the organization needs in order to excel in its marketplace.

Is Distributed Agile Development as Hard as it Looks?

Within the context of the larger enterprise, distributed development is the norm, not the exception. After all, if one has hundreds of developers and testers, the likelihood that they are all in co-located component teams, or that the enterprise could immediately relocate them to be so, is essentially zero. Moreover, scale alone drives distribution as we know that past about 100 ft from ones desk, the opportunity for casual conversation decreases about exponentially, so even if the enterprise is located on a rare “single campus”, they are in fact , highly distributed in agile terms.

Recently, when asked about whether or not distribution alone can be an Achilles heel to enterprise agile adoption, I answered “absolutely not” as I’ve seen it work extremely well even in the face of what some would consider extraordinarily distributed teams. For example, the BMC quality and productivity case study by QSM (see the post at https://scalingsoftwareagility.wordpress.com/2007/09/21/newly-release-quantitative-data-on-enterprise-agility-benefits-at-bmc-software/)contains the following quote:

“Especially noteworthy is the fact that BMC has found a ‘Secret Sauce’ that enables its SCRUM process to succeed in spite of teams being geographically dispersed. Other companies experience higher defects and longer schedules with split teams, but BMC does not. I’ve never seen this before. The low bug rates also result in very low defect rates post-production, which is great news for their customers who demand a high quality product.”

On the long flight home from the enterprise where I was asked that question, I found myself second guessing my own comment, as it flies in the face of so much that is considered critical, or even mandatory, for true team-level agility. And yet, as I reflect on my personal experiences, I feel comfortable in boldly stating that “of all the challenges enterprises face in adopting large-scale agile, the problem of distributed teams ranks fairly low on the list.”

And then I had to ask myself why. I suspect there a number of reasons that distribution alone is not as critical to enterprise agility as I once assumed. These include:

1. The define/build/test team (See Chapter 9 of SSA), even when distributed, is still a TEAM. They have all the skills they need to deliver working software. In addition, agile teams are both empowered and challenged to address their own challenges. If they are distributed, so be it, and they must find their way to communicate to be as effective, or nearly effective, as a co-located team. In other words, it isn’t necessarily management’s problem if it is impractical or undesirable to relocate team members or change technical assignments to facilitate collocation, rather it is the TEAM’S problem, and they will solve it for themselves.
2. Their mission is clear. No matter the distribution, the team’s mission is clear – to deliver working software every two weeks. The clarity of the mission focuses the team on what really matters, that is the state of the actual software, and they will necessarily do what they have to do to help assure the outcome.
3. Individuals live where they live for many reasons. There must be some significant intangible motivation associated with the fact that the team members are in an environment of their own choosing, and yet they are still participating in a high-performance, though distributed, software TEAM.
4. We are in the age of the virtual community, and we have all accommodated to enhanced forms of communication from skype, webex, IM, email, webcams, shuttle diplomacy and the like (see Chapter 19). While everyone understands the virtues of face to face communication – (agile manifesto principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation) – at the same time, no one derides distributed open source communities, which in some facets are paragons of agility, for the fact that team members are not collocated, and no one challenges the quality, productivity or delivery velocity of that model.

So yes, collocated is better, and there is nothing quite like the face-to-face communication of collocated an agile team, and yes, an enterprise should work to facilitate collocation wherever feasible, but no, it isn’t mandatory, and in all probability, it won’t even be the largest challenge the enterprise faces in its agile transformation.

Scaling Software Agility Now Available at Microsoft’s Redmond Campus Bookstoore.

Starting Saturday, December 1, the Microsoft Store on Microsoft’s Redmond campus will for the first time start carrying books from publishers other than Microsoft Press. Scaling Software Agility is one of the ones they have chosen to stock in this initial test phase. The tens of thousands of Microsoft employees who work in Redmond and regularly shop at the store, as well as the tens of thousands of visitors who come to the campus, will now be able to see and purchase the book there.