I gave this presentation to a SPIN meeting the other day and promised that I would post it. So here it is:
Patterns&Antipatterns in Enterprise Adoption
I’ve blogged on this topic before ( see post) but as agile continues to cross the chasm to the enterprise, new anti-patterns emerge (or perhaps they were always there and I just didn’t see them ……)
It might raise a few eyebrows so comments are welcome. I’ve posted it to the resource page as well.
Note: this is the third in a series of posts on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).
In the last post, Agile Product Manger in the Enterprise (2): A Contemporary Framework, I described a framework for product management and a separation of roles for the Agile Product Owner and Agile Product Manager on the enterprise context. I concluded with a suggested set of agile-specific responsibilities that are different than the activities in a pre-agile world. To reiterate: they are:
1. Own the Vision and Release Backlog
2. Manage Release Content
3. Maintain the Product Roadmap
4. Build an Effective Product Manager/Product Owner Team
In this post, I’ll describe the specifics of Responsibility 1: Owning the Vision and Release Backlog.
—————–
Though the instantiation and delivery models for the Vision (Vision/roadmap/feature set vs. product requirements document) are different, this responsibility is not new to the role. After all, if the Product Manager:
Then having a Vision , which articulates a clear direction for addressing gaps and opportunities, is a logical outcome.
As we have noted, in agile the traditional product requirements documents (PRD), system specification, software requirements specifications (SRS) and the like are typically eliminated. In their place, agile enterprises take a leaner approach better suited to the last-responsible-moment, delayed decision making and artifact-light development practices of the agile enterprise.
However, since the PRD and SRS documents no longer exist to specify system behavior, communicating the Vision to the agile development teams becomes even more critical. Doing so is Product Management’s responsibility, because no matter how empowered and energized the agile teams may have become, it is PM’s responsibility to set strategic direction. The Vision answers the big questions for the system, application or product under development, including
I’ve seen agile teams take a variety of approaches to communicating the Vision. (Note: I covered many of these in more detail in Chapter 17 of SSA– Lean Requirements at Scale: Vision, Roadmap and Just-in-Time Elaboration).These include:
Each of these forms has proven their worth in a variety of agile projects, but it doesn’t even have to be that well structured. In one release planning session I facilitated, there wasn’t an opportunity for the four product mangers to collaborate prior to the release planning session. Even if there were, it’s doubtful that they could have necessarily come up with a harmonized, force-ranked feature set anyway. (Question: what self-respecting product manager wanted their number one feature to be placed fourth on the release backlog?) Instead, we allowed each product manager approximately 45 minutes on stage. Each presented a briefing deck, including a list with descriptions of the top ten new features proposed for their solution component. Based on this context, the teams then went into the more detailed planning session.
Clearly, this was not the ideal forced-rank prioritization we like to see in agile and it was left up to the teams to decide what to do about the fact that four product managers had separate priorities. But software, like life, can be a little messy. Most importantly, this model seemed to work really well, in part because the Product Managers were part of the process and by the end of the session they had visibility into what the teams could and could not achieve in the time box.
No matter the form, the main content of the vision document is a prioritized set of features. In my earlier book Managing Software Requirements , (perhaps attaining agile wisdom means we don’t have to throw out everything we learned prior) we described features as “services provided by the system that fulfill a user need”. Features are “Big Picture” system behaviors that can be described in a sentence or two and which are written so that customers can actually understand, debate and prioritize them.
Of course, in so doing we didn’t invent either the word “Feature” or the usage of the word in that text. Rather, we simply fell back on industry standard norms to describe products in terms of, for example, a Features and Benefits Matrix which has been used traditionally by product marketing to describe the capabilities and benefits provided by our new system. By applying this familiar construct in agile, we also bridge the language gap from the agile project team/product owner to the system/program/product manager level and give those who operate outside our agile teams a traditional label (Feature) to use to do their traditional work (i.e. describe the thing they’d like us to build).
In that text, I also posited that by managing the level of abstraction, a system of arbitrary complexity (from the space shuttle to the spellchecker on this soso editor) can be described in a list of 25 or so features. That still works for agile teams describing a Vision today and features can still be used as the primary placeholder for user value.
In the Big Picture graphic and series and in the Product Owner blog posts, we noted the primary currency of requirements expressions for the agile teams is the user story, which are contained in the Iteration (story) Backlog. (see graphic)
The Agile Team and their Iteration (Story) Backlog.
(Note: click here for more on User Stories. Click here for more on the Agile Team.)
In a like manner, the Release Backlog contains the prioritized set of features that have not yet been implemented.
Product Owners and the Release (Feature) Backlog
Like stories, features can be scheduled (in a release) or unscheduled (waiting for future attention). They are prioritized and estimated. Estimates at this scale are coarse grained and imprecise, which prevents any temptation to over-invest in feature elaboration and estimating. If and when a feature reaches a priority such that it hits a release planning boundary, it will be broken into user stories prior to implementation.
In addition, the enterprise is too large to assume that all the global development teams will naturally understand the various system qualities, i.e. those constraints and “ilities”, such as reliability, accuracy, performance, quality, etc, that are imposed on the system as a whole. Therefore, these non-functional requirements must also be known and communicated via a central repository where all teams can readily access them. (Click here for more on non-functional requirements).
These requirements are an adjunct to the Vision and Feature Backlog and are every bit as critical as the functional requirements. As such, Product managers have a major role in defining them. Your enterprise development practices may now be more lightweight and agile, but the system still has to work when you ship it!
That’s it for the first responsibility: Owning the Vision and release Backlog. We’ll move on to Responsibility 2: Managing Release Content, in the next post.
As a new entry into the software development conference marketplace, (along with all of the implications for potential impact implied by its labels), Lean & Kanban 2008 has created a bit of a buzz in the blogosphere. What follows is a short summary of some of the action:
The presentations for all the speakers from the conference are now available on line here. There is an amazing amount of new content on both topics, Lean and Kanban, and any one interested should check out these presentations.
My, personal, off-the-cuff reactions to the conference and the potential for the impact of the lean movement on software development practices can be found here.
Mike Cottmeyer (Leadingagile.com) has a really pithy discussion of his view of Kanban, specifically on the limitations and potential of this, new team-based agile method (or tool? see below) here.
David Anderson, the conference organizer and a leading proponent of both lean and Kanban practices opines on his view of Kanban and his reaction to the question “Is Kanban just a tool”.
Also, Mike Cottmeyer and Ryan Martens have a particularly interesting discussion on the formation of the Lean Software and Systems Consortium and it’s announced certification “Why a Lean SSC and Why a Certification
You may also wish to check out John Heintz review and perspective on the Lean&Kanban 2009 conference.
I’m sure there’s lots more to come.
Note: this is the second post in a series on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a continuation of the series on the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Manager/Product Owner series on this blog as well as a series in the Agile Journal. (See the resource page for a mapping to the Agile Journal Article Series).
In the first post, Role of the Product Manager in the Agile Enterprise (1): Phases of Disillusionment in Pre-Agile, Waterfall Development, I described some of the dysfunctional behaviors and mistrust that may be built into our system prior to the agile transition. In this post, we’ll move to a more postive and enlightened view of the changing role of product management.
———–
In prior posts, we’ve also described how the role needs to change in agile development. Much is different as the table below illustrates.
| PM Responsibility | Traditional |
Agile
|
| Understand customer need | Up front and discontinuous | Constant interaction |
| Document requirements | Fully elaborated in MRD/PRD | Coarsely documented in Vision. Constant verbal communication to team. |
| Scheduling | Plan a one time delivery, way later | Continuous near term roadmap |
| Prioritize requirements | Not at all or one time only in PRD | Reprioritize every release and iteration |
| Validate requirements | Not applicable. QA responsibility | Involved with iterations and each release. Smaller, more frequent releases |
| Manage change | Prohibit change – weekly CCB meetings | Adjust at every release and iteration boundary |
Adapting to all the behaviors in the right column is a substantial change for the newly-agile, enterprise Product Manager and that is the subject of this series of posts.
In this series, we’ll be describing mostly what’s different with Product management in a pre-and post-agile environment. We won’t be attempting to describe all the behaviors which are common or providing guidance for what product managers do in the traditional software enterprise, Fortunately, many of the product management functions are the same in agile as they are in pre-agile development.
For example, the product managers are still primarily responsible for assessing market needs and creating product strategies (with input from the teams). However, the handoff to R&D highlighted in the last post is strongly mitigated, and the Product Managers take a far more active role throughout the development process.
For a more contemporary view of the comprehensive nature of an effective product management organization, I refer you to the product management framework graphic provided by Zig Zag Marketing below (reproduced with permission, see www.zigzagmarketing.com for more details).
It can be seen in Figure 1 that the early product development lifecycle functions (Assessing Markets, Creating a Product Strategy) remain largely the same, but the product management function continues with more direct involvement in R&D throughout the launch cycle. Of course, this framework is from the perspective of professionals in product management and our approach is more nuanced.
In various posts described above, I described why, at least in the larger software enterprise, the responsibilities of the agile Product Owner (as primarily defined by Scrum) is more typically a set of responsibilities that are shared between a significant number of team-based, agile Product Owners and a smaller number of program-based, agile Product Managers. This dual role approach is also illustrated in the Big Picture Series and graphic as seen below:
Figure 2 - The Big Picture of Enterprise Agility
Within the context of that picture, the Product Manager operates primarily at the Program and Release level, as this Big Picture snippet indicates.
Figure 3 - Product Manager in the Big Picture
In these various articles and posts, I‘ve highlighted the different responsibilities for these two roles, summarized as follows:
|
Agile Product Manager |
Agile Product Owner |
| Market/customer facing | Product/technology facing |
| Collocated & reports into marketing/business. | Collocated & reports into development/ technology |
| Focuses on market segments, portfolio, ROI | Focuses on product and implementation technology |
| Owns the Vision | Owns the Implementation |
| Drives the Release | Drives the Iteration |
In the context of Zig Zag Marketing’s Product Management Framework, the roles fall fairly nicely into the product lifecycle as can be seen in the figure below.
Figure 4 - Mapping the Dual Roles onto the Framework
In many enterprises, adopting this dual-role model has been integral to an effective agile transition and has enhanced operational performance in both the business and technology. As John Bartleman, VP of Product management and TradeStation Technologies recently noted:
“This separation of labor and concerns (into Product Managers and Product Owners) has helped us bring additional focus to both the market and technical aspects of our solution”.
We’ll describe the agile-specific responsibilities of the Agile Product manager in the posts that follows. But first, however, we note that the name of the title of the person who plays this role may vary by industry segment as seen below.
| Industry Segment | Common Title for the Role |
| Information Systems/Information Technology (IS/IT) | Business Owner, Business Analyst, Project or Program Manager |
| Embedded Systems | Product Manager, Project or Program Manager |
| Independent Software Vendor | Product Manager |
Table 1 – Titles for the Role Vary Across Business Segments
No matter the title (we’ll continue to use Product Manager throughout) or the reporting arrangement, when an agile transition is afoot the person playing that role must fulfill the following primary, agile-specific responsibilities:
1. Own the Vision and Release Backlog
2. Manage Release Content
3. Maintain the Product Roadmap
4. Build an Effective Product Manager/Product Owner Team
I’ll describe each of these responsibilities in individual posts that follow.
Note: this is the first post in a series on the changing role of product management as the enterprise transitions to agile development methods. This series in turn, is a follow on series to the Role of Product Manager and Product Owner in the Agile Enterprise which can be found in the Product Owner/Product Manager category as well as in a series published recently in the Agile Journal. (See the resource page for a mapping to the Agile Journal article series).
In this first post, we’ll set the context for need for the transition, and try to shed some light on the Product Manager’s likely perspective on their view of the software development organization prior to the change.
—————————————
Prior to agile, many enterprises have followed a sequential, stage-gated, waterfall development model. In these cases, it’s likely that the Product Manager’s mindset has moved through a series of increasingly foreboding attitudes, as the figure below shows.
Phases of Product Management Disillusionment in Waterfall Development
In this phase, the Product Manager spends their time with customers, interviewing, running workshops, and using whatever other tools they have at their disposal to define and document the requirements for the prospective new system. These requirements are typically captured in a MRD (Marketing Requirements Document (MRD) or PRD (Product Requirements document). After that, the development team typically response with a Software Requirements Specification, or (SDS) System Design Specification, which further refines and documents the intent of the PRD.
At the end of this phase, which may take from 3-6 months to document and gain the requisite approvals, the development effort is launched and there is a hand off to engineering.
This initial, upbeat phase is followed by a period of relative calm. I call this the period of a false sense of security. During this phase, development proceeds apace. The product manager may be uninvolved, or may attend milestone reviews where models, documents and project plans are reviewed and inspected. Towards the end of this period, which lasts typically from 6-12 months, the software is declared to be 90% complete and launch plans are put into place. Customers are notified that the release is impending and external and internal commitments are solidified.
Of course as we’ve discussed in the book and blog, the next phase is a painful one indeed. During system integration, many defects are discovered, some design related (think – uh oh, lots of rework…) , and the dreaded defect triage process begins.
Now it is obvious that the schedule will not be met and communication of that prospect begins. Worse, in the early period, the defect “find rate” exceeds the “fix rate” and the schedule becomes less and less certain and product delivery looks further and further out. Even worse, the customer typically now has their first opportunity to see the actual software and they discover that it is not what they currently need. This is because either a) they didn’t know what they wanted back then, or b) their needs have changed in the last year. No matter the cause, substantive, additional rework will be required before it can be deployed.
This a period of substantial pain for the Product Manager and for all key stakeholders in the process.
Fortunately, we didn’t get this far in the tech industry without most program teams eventually figuring out how to deliver software, so a period of rework and recovery begins. During this period, the scope is typically slashed dramatically, and commitments for schedule and functionality are renegotiated. Of course, credibility has now been lost throughout the enterprise – the development team to its stakeholders – as well as the product managers to their external stakeholders.
What follows is a long, persistent period of mistrust between the development and product management organizations, which is often characterized by cross-department hostility, reduced communication and even complete dysfunction.
Worse, as the Product Mangers have learned that they only get about half what they ask for, they often resolve to ask for twice as much next time, to assure that they get something meaningful delivered. And we all know how well that works out. So the vicious cycle continues.
I describe all this, not to further belabor the pain, but simply to point out this may well be the environment when the agile transformation is initiated.
Clearly, this waterfall development model has not served the needs of the Product mangers or other stakeholders particularly well, so at some point, the lucky enterprise commits to a new, agile development paradigm. Often times, the development teams themselves sponsors the agile initiative and delivers a couple of messages to the Product Management organization:
And now finally, for those developers and managers leading an agile transformation, and in the context of the Phase of Persistent Mistrust, I ask you to perform the following thought experiment.
If you were a Product Manager operating in this environment, how would you react to such a message?
Clearly, we are going to have to approach this change with a more mature thought process and a credible strategy to get these key stakeholders on board with our new model.
Well, that’s a statement of the problem and that is it for this post. In the next post, I’ll move on to describing a more helpful and enlightened approached to the transition, and to the changing role of the Product Manager in the increasingly agile enterprise. But in this post, I wanted to set the context so we will at least recognize the hole we have likely dug for ourselves in the meantime.
Recently. I was interviewed by Michael Cote, of the Agile Executive, to get my perspective on current issues, topics and strategies in enterprise agility. The interview does a pretty good job of exploring some of the larger issues in enterprise level adoption, including the best guidance I can provide on approaching the project office (or PMO) and how to address the various governance rules that are likely to exist.
The full podcast/interview is here.
Michael’s intro comments are as follows:
In this Agile Executive podcast, I talk with Dean Leffingwell. We start out going over Dean’s background both in the software and Agile world (check out his bio for more).
Since Dean worked at Rational for some time (after his company was acquired by Rational, Requisite, makers of RequisitePro), I ask Dean the broad question, what was up with RUP? That is, what went wrong there? In retrospect, it seemed like a flexible enough process, but it got applied as One Big Honking Thing, as The Poster, if you will.
Pulling from Dean’s work at, as his book would put it, Scaling Agile, I ask Dean how large companies go about applying Agile to, large, existing code-bases, like version 10 of a product. Put another way, how does Agile apply when you’re dealing with legacy code. His answer is the usual, crisp and pragmatic Agile approach, “let’s worry about the new code” and then move on to the old stuff when we have time. The other side of that comment is interesting as well: the old code “works” already, so try not to mess with it. At the time, I should have asked him how to deal with developers endless desire to refactor the code, which buts up against the “let sleeping dogs lie,” as it were.
Connected to this, I ask Dean to tell us what the “enterprise” in “enterprise Agile” means. We also discuss what Agile implementations seem to fit in enterprise situations. My perpetual questions here is: how do you fit in product management, sales, marketing, training, support and all that? Dean says that the strength of the Project Office (or the “PMO”) is the lynch pin here. We also get into using a sort of Facade approach to reporting and interfacing with the organization in the old ways while changing to Agile in-flight.
Also, touching on my interest in IT Management and Dean’s experience running a SaaS-y company with Agile, I ask Dean what he’s seeing in the way of “Agile Ops.” Dean points out that while “Agile” as developers know it doesn’t have big mind-share in operations, those folks tend to have very similar structure and goals to their process: quickly running, doing small things, and tracking all that.
Finally, we close out with the never-ending question when it comes to Agile Leadership, how do you get the organization to want to do it? As always, the approach is to use small successes to establishing credibly early on and then snow-ball those successes into larger ones.
On reflection, the Lean and Kanban conference was one of the most impactful events I’ve attended in many years. In addition to Mike Cottmeyer’s blog, John Heintz has done at an excellent summary of the conference. Also, a few of my personal reflections can be found at Israel Gat’s Agile Executive blog here.
I was thinking of posting some summary of the rich content presentations at this amazing conference. But my colleague Mike Cottmeyer (a founding member of the Lean Software and Systems Consortium) is doing a great job of summarizing the presentations on his blog www.Leading Agile.com.
For some time, I’ve been collaborating with some industry leaders about the potential to utilize lean methods and practices as a mechanism for 1) helping scale agility across the full enterprise and 2) providing new tools and techniques to further advance software engineering and management practices beyond the bounds of our current agile constructs.
In days prior to the Lean & Kanban 2009 formal conference program, which I am now attending, we’ve come to agreement on a strategy to accomplish this objective.
I am happy to announce that The Lean Software and Systems Consortium (LeanSSC) has been announced for just this purpose:
Based in Washington, USA, LeanSSC is non-profit consortium comprised of corporate members, academic institutions, and industry leaders who share the belief that understanding and application of the science of lean will be of great benefit to software intensive industries. LeanSSC’s mission is to promote professionalism and create awareness of lean science and associated competencies by creating and promoting a body of knowledge and an associated certification program.
Founding members of the consortium include David Anderson — David J. Anderson Associates, Alan Shalloway and Alan Chedalawada — Net Objectives, Dean Leffingwell — Leffingwell, LLC., Don Reinertsen — Reinertsen & Associates, Karl Scotland — EMC Consulting, Rob Hathaway — IndigoBlue, James Sutton — Lockheed Martin, Mike Cottmeyer — VersionOne, Peter Middleton — Queens University @ Belfast.
The full press release announcing the formation of the new consortium is here:
I’ll be blogging about this more extensively in the near future.
I just posted this presentation, my keynote for the 2009 Lean&Kanban conference, on the resource page. For more on the topic, see the whitepaper (also on the resource page) or the requirements category on this blog.
Scaling Software Agility 