The Heretech

Agile adoption study now published

The research that Dave West and I did on the state of Agile adoption is now published. Here's a link to the actual document, and here's a quick snippet about it from InfoWorld. The short version: If the odds that you'll wind up on an Agile team in your next job is at least one in three, Agile has certainly gone mainstream.

I'm writing a separate piece on the implications for technology companies separately. Meanwhile, the research on requirements in the tech industry is in the final editing queue.

[Cross-posted at The Forrester product management blog.]

Against a grand theory of PM, part 2

[You can find part 1 here.]

Most fields of study start with classification. The important precursor to any theory, middle-range or grand, is putting what you're studying into conceptual buckets that help organize the topic in meaningful ways. That's where the study of product management and product marketing started, and that's where it has stayed for the last several years. (For more discussion on that point, click here.)

Those conceptual buckets are important, for a variety of very practical reasons. For example, any theory of PM needs to exclude things that are not PM-related. As any of us who have been in the PM profession knows, defining the boundaries of PM has been difficult. The specialized consulting firms, such as Pragmatic Marketing and Sequent, have done a good business helping their clients sort out what their PMs should and shouldn't be doing.

It's a long stretch, however, from classification to grand theory. It took centuries for people studying the natural world to figure out that the classification of matter into four substances (earth, air, fire, and water) wasn't leading to any great insights into physics and chemistry.

On the other hand, when classification hits on something important, it can lead to important insights. The Victorian world's passion for sending researchers to distant lands, to add to the catalog of botany and zoology, led to Darwin contemplating the variation among finches in the Galapagos Islands, which led to the theory of evolution.

However, Darwin's short path from classification to theory is the exception, not the rule. In the PM world, it's important to recognize that someone needs to focus on requirements, and product managers, not product marketers, are the right people for that task. But how much work is necessary to do requirements well? What are the risks of doing a sub-par job with them?

And those are just the obvious questions. Here's a less obvious one: Is there a single correct template requirements? If so, PMs are just experimenting with different collections of content, until they collectively discover the equivalent of double-entry bookkeeping, the format on which all accountants standardized.

On the other hand, requirements might be a medium of thinking and communication that organizations use in whatever way makes sense to them, much as they treat e-mail. Some companies prefer to use e-mail sparsely, keeping more detailed discussions out of the message threads. Others like being chatty in e-mails, and expect their employees to contribute generously to these conversations. In the same fashion, some tech companies prefer detailed product plans to define the contents of the next release, while others create more minimalist documents, with other details to be found elsewhere (or not written down at all).

The answer to that question has profound consequences for the efficiency of development teams, the accuracy with which they guess what customers really want, and the larger organization's ability to bring new products and services to market. Peering into any periodic table of PM responsibilities, or roles, won't reveal the answer. That classification scheme, as useful as it may be, also does not how to measure PM's essential contribution to the company, which impediments put that contribution at risk, and how to resolve these issues.

[Next: So what kind of insights should we be trying hardest to achieve?]

[Cross-posted at The Forrester product management blog.]

Against a grand theory of PM, part 1

When you're start working in an unexplored field of study, such as PM in the technology industry, it's tempting to propose the Grand Theory Of Everything (GTOE). It's also the worst possible time to develop a GTOE.

Opinion is cheap
Two years ago, when I started this job, I knew I'd have a full research agenda. Very few people took on the job of pundit, arguing for a particular vision of how the PM function should work. Even fewer had any hard data on how it actually does work, in practice. Before making any sweeping statements about the profession, I needed to fill in some big empirical holes.

How diverse is the PM job description, across companies? Which sort of requirements do PM teams give priority? Does moving from an on-premise to a SaaS model have an effect on the PM role? Moving at an Agile pace must have some effect on the rest of the company—but what is it? Without answering these questions, it's next to impossible to give advice.

For example, some aspect of technology companies has made the PM job description different across teams. Unless you understand the forces that have conspired against a consistent job description, there's little point in telling PMs what they should and should not be doing. It's almost as useless as your doctor telling you, "If you're not feeling well, just get better."

Research is hard
Nevertheless, as you're doing the research, you can make important observations specific to the topic that you're currently investigating. Sometimes, the answers are obvious. For example, when I was researching social media as a new source of customer and market intelligence, it was pretty obvious from the start that there was real work involved in using social media in this capacity.

Other times, it's harder to find the patterns. Sorting through the reasons why PMs in one Agile teams is the product owner, and in another team the PM and PO are two different people, took a lot of head-scratching.

You also discover that your initial hypothesis can be completely wrong. I had expected that the companies that invest in requirements tools would be bigger and older, and therefore relatively more capable of affording the purchase and implementation. Unfortunately, the opposite was the case: on average, it's the smaller, newer companies, who feel they can't afford not to invest in these tools, that lead adoption.

Important conclusions are still possible
Consequently, anyone trying to figure out how to make PM work in the tech industry is going to be working primarily on middle-range theory, not the GTOE. If middle-range theory doesn't sound important, it's worth remembering the significant role that this level of work has played in the hard sciences. Observations like, Gravity bends space-time, or, These hitherto unnoticed chemical sequences are the reason why you're a human and not an antelope, are major steps forward in our understanding of how the world works.

If someone can figure out why even the most meticulously written and reviewed requirements don't stop some tech companies from making products that their users don't like or can't understand, that's a big contribution to our little field of study. Best to have more middle-range theory before even thinking about the GTOE.

Next: The difference between theory and classification.

[Cross-posted at The Forrester product management blog.]

The PM job calculator: validation

[Last in this series about the Tech Product Management/Marketing Job And Department Profiler. Previous posts cover its origins, the design decisions that went into it, and the job specializations it profiles.]

From my grad student years, I know that a lot of mathematical models fall flat on their simulated faces because they don't get the testing they should. In the case of the PM job calculator/department profiler, I had to apply three different tests.

The tasks are many and varied
Last year, when I did the survey research on the state of the product management/product marketing job in technology companies, I vetted the list of tasks with a lot of PMs. Using their feedback, I added tasks, rethought others, and even merged a couple. The resulting list represented everything that PMs might be doing, depending on where they work.

That was the easy part.

The tasks define the jobs
A major goal of the Profiler is, as I explained in an earlier post, classifying PMs according to their specialization. A requirements-focused PM is not a product manager, who is not a release manager, who really isn't a product owner, who can't find the spare time to also be a community manager...You get the idea.

Consequently, the next test involved showing these job categories—defined by the tasks these roles perform, and the priority each task receives—to people who run PM departments. That group included the heads of product management teams, product marketing groups, and combination product management/product marketing departments.

Since no one's job description for any of these roles exactly resembles anyone else's, the goal wasn't to find perfect agreeement among job categories as they're defined in particular organizations. Instead, I did a version of "ideal type" analysis: does this definition offend your sense of what's essential about this role? Over the course of several conversations, I managed to develop a set of ideal types that everyone found more or less acceptable.

The jobs define the department
When I started this project, the stretch goal was finding a way of using the job-level results to help define what mix of people you might need at a departmental level. Surprisingly, that stage of the project was easier to complete than the job descriptions.

Perhaps that's because every senior director or VP of a PM organization focuses first on the type of person needed to perform a job, steps back a bit, and then figures out how many people, at what level of seniority, need to appear in the group portrait.

The most important choice was, which variables mattered? There are dozens you might consider, from the type of product to the size of the company. While all of these variables have some influence, they don't all have the same weight in determining what kind of team you need to build.

Once again, tasks proved to be the right starting point for this project, for a variety of reasons. For example, the degree to which someone can focus on their core responsibilities has a definite impact on how many of those people you need.

This last stage of validation revolved around the question, "You put this information into the black box, and out comes this picture of the kind of department you need. Does this picture make sense?" The results had to be good enough, since a perfect calculation is probably not possible. (Again, many variables have relevance, but it's necessary to focus on the ones that matter the most.) Perhaps not all of these people in this hypothetical department, in practice, report into the same group, but they have to exist somewhere in the company to provide adequate support and leadership for the product or service under development.

Don't let the perfect be the enemy of the good
Even though perfect accuracy in the prediction of staffing needs—how many, in which roles, at what level of seniority—may be impossible, the "good enough" picture has definite value. For example, during the validation discussions, some PM department heads were interested in showing the results to their management to (surprise!) justify their staffing needs. Others spent time discussing the things they hadn't considered, such as tuning their organization to better support the sales team. Someone else spent a long time talking with me about where to shift particular tasks, if you take them off the shoulders of PMs.

In other words, the Profiler provides a starting point for a discussion about organizational changes. Without it, you might not be able to have that discussion, since the proverbial devil is truly in the details. Making a particular task, such as maintaining the product roadmap, a higher or lower priority affects other PM responsibilities. It also begs a lot of questions about skills, time management, deliverables, and compensation.

However, if you didn't have some kind of detailed portrait of what PM does and doesn't do, it's difficult to get to these second-order questions, such as professional development. If you don't force yourself to be specific about PM priorities, then there's always a case for something else to get added to the to-do list. Unfortunately, that often leads to the situation in which, if everything is a priority, then nothing is.

[Cross-posted at The Forrester product management blog.]

PMs know that requirements are flawed

The workshop next week, "Using Social Media To Make Smarter Product Decisions," was a good occasion for me to jump into the data we've been collecting about requirements in the technology industry. It's one thing to claim that there are problems that need fixing, and that social media can help fix them. It's another to put that claim to the test.

The requirements survey has produced a lot of interesting results that will see the light of day in a research document to be published later this quarter. The questions we asked build a composite picture of both the content of requirements and the process of creating them. For example, we asked, ""How much time do you dedicate to requirements work at each stage of the development cycle?" Doing a weighted average of the responses, here's the answer:

This picture should be familiar to any PM: lots of requirements work at the beginning of the project; less and less as the project proceeds. Which begs the question, how effectively can the organization make mid-course corrections? When does the "after action report" kind of analysis happen, when PMs look back on the work they just did to figure out what they could do better the next time?

While this spike of requirements attention at the beginning of a project makes sense in bureaucratic terms, it doesn't make sense in research terms. You might pretend that the requirements you build at the beginning of a project are everything that the development team needs to proceed, but at best, that's a comforting fiction. You always need to fill in gaps, provide more detailed explanations, and validate the results.

If requirements are the information that technology teams need to avoid making costly mistakes, then requirements gathering and analysis should be an ongoing activity. While that's certainly true in some PM teams that I've met during my time as a Forrester analyst, in the aggregate, these peaks and valleys of activity still define the requirements landscape for many PMs.

There are plenty of other signposts to deficiencies in product requirements. For example, there's a big mismatch between the skills needed to do requirements, and the opportunities to put these skills to work. While the rest of the story will come later, I thought this one result was interesting enough to now, instead of waiting for the final report.

[Cross-posted at The Forrester product management blog.]

The PM job calculator: specializations

[Continuing the "behind the scenes" discussion of the Product Management/Marketing Job And Department Profiler, a.k.a. the job calculator. Here are the links to the first two parts, covering the origins of the calculator, and the design decisions behind it.]

As discussed in the last post on this topic, I decided to define product management roles through the tasks that those roles perform. The maxim, "You are what you do," made it easy to define different job categories for product managers and product marketers. A task -based approach also helped make a more convincing argument why particular specializations are necessary.

Tasks—what are people doing, and how much attention or emphasis does each task receive—make the difference between, say, the canonical product manager and the archetypical product marketer clear. Realistically, you never have enough time to do everything that's on the massive List Of Things For Which PM Might Be Responsible, nor are you necessarily good at all these tasks. Plus, if everything is top priority, then nothing is top priority.

From single-cell creatures to complex animals
If you add up the tasks that product managers do to ensure that a particular product or service meets its design and business objectives, you already have a pretty big list. Just working with the development team is going to consume a lot of time, without adding product marketing tasks like developing messaging, or even the project management tasks related to the development cycle, such as ensuring company readiness for a new release.

If you keep pushing the question, What should I be doing, and how important is it that I do it? it's easy to see the further specialization beyond just the product manager/product marketer distinction. I've already alluded to the separate job function of release manager, who's responsible for project management. There are also sales enablement specialists, whose job it is to support the customer- and partner-facing parts of the company. Sure, PMs have a role to play in sales enablement, but it's dangerous to have them spending too much time focused on the field. Even though the average PM crafts product strategy through the media of requirements and roadmaps, a user experience professional is contributing to the product's success in a different way.

In many companies, these roles report into different parts of the org chart. Whether or not they're centralized into the same PM organization is a question of execution.

Evolution creates new differentiations
In recent years, we've seen the emergence of other job specializations. The difference between product owners and product managers may not be completely clear, but the roles aren't exactly the same. (We heard that issue discussed a lot at the Agile 2009 conference. The role of PM in an Agile team turned into a much bigger research project than I ever expected, because there are no clear-cut right and wrong ways of defining it.) The explosion of social media has inspired a new job category, community manager, responsible for product management- or product marketing-like activities exclusively within social media outlets.

During the validation phase of this project, when I showed the calculator to heads of PM groups, no one blinked at these job specializations. It's clear that the day of the generic PM is over. What we call a product manager now is someone who is focused on product and service development. That person often works side-by-side, in the same group, with product marketers, technical product managers, release managers, and in some cases, even sales enablement. Or, these functions are scattered across the organization.

Nevertheless, the increasing specialization of product management and product marketing seems to be a fact of life. The to-do list—how big it is, and how much priority each task receives—has made that conclusion inescapable in any organization serious about the PM role.

[Cross-posted at The Forrester product management blog.]

"Nice going, Maslow!"

Anyone in the research business should appreciate this edition of Dinosaur Comics.

The PM calculator: tasks

[Continuing the discussion of the PM Job And Department Profiler from the previous post.]

The most fundamental decision for the Profiler was the choice of how to depict the PM role. I might have chosen functional areas, such as Pragmatic Marketing's famous diagram of PM responsibilities, or something skill-based, such as Steve Haine's efforts to define product management and product marketing as a corpus of knowledge that people in that profession need to master. Instead, I decided to use tasks to build the picture of what PMs do.

There's nothing inherently wrong in the other depictions of product management, but they weren't the right raw materials for what I wanted to do. If I accomplished nothing else, I wanted to depict the volume of work that PMs do, and the degree to which that work is focused or unfocused.

The Pragmatic Marketing periodic chart of responsibilities tells you how to categorize the work, but the categories don't point directly to the amount of work. A skill-based approach tells you how many different skills you need to acquire, and might even suggest how challenging some of those skills are to learn. However, that doesn't tell you, in hurly-burly of daily work, how much time the tasks that require those skills will take, or (again) how challenging it is to juggle competing priorities.

From zoology to ecology
The closest analogy I can think of is biology. As my graduate adviser said, "Every science begins with classification." That's what the Pragmatic Marketing framework does very well: define the different species of responsibilities that constitute the family tree of product management and product marketing. However useful and necessary classification may be, it doesn't answer all the questions of biology, such as, "Why do these species dominate, and these other ones don't?"

To take this analogy further, job descriptions are like ecological niches. Many different species might fill each niche; not everyone is equally well suited to do so. (By the way, the number of niches keeps expanding, but that's a topic for another post.)

Tasks, therefore, are the essential traits that determine the success of a PM in each niche. If the PM is doing the wrong activities, or is too busy to perform the essential activities, then that PM won't do well within that niche.

The ecology of vital business activities
Classification tells us what species have evolved to fill these niches. Skills, like DNA, define what the species is capable of doing. However, if the question at hand is, What kind of PM should we have? the answer depends on what the PM is actually doing within a particular niche, a.k.a. job category.

Or, to look at it another way, classification of PM job categories is interesting, but it's not a very convincing argument for why a company should adopt one species over another. On the other hand, discussions of skills is sometimes premature, because it begs the question, What's the vital business function for which these skills are necessary? Tasks, as it turned out, were a better starting point for defining the vital business functions in a way that might lead to a fruitful discussion of, We need this many PMs in these specializations to do the job right.

The PM job calculator: genesis

The Product Management/Marketing Job And Department Profiler is finally, finally available (Forrester account required). This project was unusual in  a lot of respects, so it's worth spending a little time explaining it. You might also get some insight into how research gets done at Forrester, which might be a little mysterious to the outside world.

What is it?
Here's the short version: You enter the priorities for a particular PM, and you get a recommended job description. If you want to go one step further, you can also get a picture of what your department should look like: how many PMs, in which specializations, at which level of seniority for their positions.

In other words, it's a tool designed primarily for the people who run PM groups. The Profiler is also useful for rank-and-file PMs who might want to gauge where their priorities and skills are, and where they should be.

I'll get into more details about the tool and how it works in a later post, but let me first explain why I created it.

What inspired it?
Last  year, I ran a survey to find out what PMs were doing in their jobs, versus what they thought they should be doing. The results, released in the document "Product Managers Were Working On The Wrong Things," were very interesting.

For example, we saw in stark terms how product managers struggled to stay focused on their core work, helping the development team make good products and services, because they were pulled into many tasks that were not directly relevant, such as marketing support and sales enablement. At the same time, product marketers had their own version of "the urgent defeats the important" principle, with too many conflicting priorities and too few resources to address all of them.

Of course, the next question is, "Now what?" The point of this study wasn 't merely to commiserate, but to suggest a course of action to fix what is perhaps the core problem with product management and product marketing in the technology industry: vagueness about roles, responsibilities, skills, and deliverables. Research that dramatized the problem was necessary, but not sufficient to do more than generate broad recommendations (for example, run your department so that product managers can focus on their requirements).

Why this approach?
After having defined a problem area, the standard analyst response is to dig more deeply into each part of it. And, to a large extent, that's what I've been doing. Natural topics for further research included:

• How the development and delivery processes shaped the job description, which led to work on product management for SaaS products, and the role of the product manager in (or adjacent to) development teams that have adopted Agile methods. 
• What PMs produce, which inspired some work on serious gaming and product requirements.
• Where new opportunities to improve product management exist, such as the multi-part series on the role of "inbound" social media as a new source of requirements. Again, in this case, we circled back to the question of how the nature of the work—in this case, collecting information from social media channels—affects the definition of the job.

In fact, nearly everything that I've written points back, to some extent, to the roles and responsibilities of product managers and product marketers. Are they really two different roles, or one? If they're separate, should they be part of the same department, or different ones? What are the important adjustments in a PM's to-do list, based on the type of product they're working? How do these changes dictate the skills necessary to handle these tasks? What kind of authority should PMs have, over which kinds of product-related decisions?

Rough sketch, not paint by numbers
Even if I did the best job imaginable in each research document, I still felt that something was missing. Tech companies want baselines against which to measure their own PM organizations, and they want best practices for getting the most from these teams. Ultimately, however, they want a picture of what the PM team should be.

Individual pieces of research fill out some details. However, these details don't always add up to the complete picture. Or, to look at it another way, you need a rough sketch of the family portrait before you fill in the details for each person.

That rough sketch is vital for answering many common questions, such as the PM's relationship to an Agile team. If you choose the "PM as product owner" option, that won't necessarily tell you everything you need to know about the tasks that person performs, who takes care of the PM-like tasks that are now off that person's plate, and what skills and experiences the hybrid product manager/product owner needs to succeed. While a snapshot of the individual PM might be useful, a family portrait that includes other roles and responsibilities is even more helpful.

The Profiler provides that rough sketch. You won't find many (or perhaps any) tool like it, which is why it took a long time to build. It was worth trying to build one, even if the experiment turned out to be an utter failure.  If we know that you can't create the rough sketch, you'll continue working on separate pieces. It's then up to the reader to build a mosaic of the pieces, in no particular order.

On the other hand, if you can build the rough sketch, you can tell right away which areas will need the most attention, and how they affect adjacent pieces. If Rembrandt hadn't the whole composition of The Mill worked out in advance, he would have wasted time on sections of the canvas that, in the end, make the central subject as striking and interesting as it is.

[Cross-posted at The Forrester product management blog.]

Teleconference on Agile adoption next week

Next Monday, August 31, Forrester colleague Dave West and I will be presenting some of our preliminary results from our Agile adoption survey. (Which is still open, if you're interested in participating.) We'll be covering Agile adoption in both IT departments and technology industry companies, including the differences between the two.

Of course, everyone wants to know how many development teams have adopted Agile. My sneak peek for you is, "Substantially more than we had originally estimated." If you want to hear the full answer, here's the link for the teleconference.

[Cross-posted at The Forrester product management blog.]

Survey links: Up, and to the right

For your convenience, I've put links to the Agile adoption and product requirements surveys to in a box in the upper right quadrant of this blog.

Going to Agile 2009? Got a question?

Forrester colleague Dave West and I will both be at Agile 2009 later this month. If you, Dear Reader, are also attending, I'd be delighted to meet you in person. Drop me a line to let me know that you're attending, and maybe we can figure out how to connect in Chicago.

Chances are that you have questions about Agile, the state of PM in the tech industry, social media, or other topics that I cover. If you're a Forrester analyst, let's turn the conversation into an official inquiry! I always prefer to have conversations in person than over the phone, and Agile 2009 may be a good opportunity to do so.  Some sample topics from recent inquiries include:

• How does the rest of our company need to adjust to Agile adoption in the development team?
• How can we revamp our requirements process?
• How can we use social media to help capture and assess good ideas?
• How can we add product management discipline to our IT organization?
• What's a reasonable estimate for the size of the R&D organization (including QA and PM) in a SaaS company?
• Do tech companies apply product portfolio management discipline to Agile teams?
• What's the relationship, if any, among tools designed to help with requirements, portfolio management, and innovation?

Announcing the Agile adoption survey

Hot on the heels of the requirements survey (which is still available, if you haven't participated), we've launched the Agile adoption survey. Colleague Dave West and I are looking into the state of Agile adoption, looking for answers to commonly-asked questions like...

• What aspects of Agile are getting stronger or weaker adoption?
• How important are tools, coaching, and other aids?
• How important is the flavor of Agile you select?
• What types of organizations or projects seem to have the best chances of success with Agile?

If your organization is at any point in the Agile adoption curve, from an initial evaluation to a fully mature implementation, we'd love to hear how's it going. Here's the link that will take you straight to the survey.

All responses stay strictly confidential. If you're wondering what's in it for you, we'll provide you with a copy of the research, once Dave and I have finished writing it up. And please feel free to forward the link to other people who might take the survey.

[Cross-posted at The Forrester product management blog.]

Best practices for requirements

We're doing a major research project on the state of product requirements in the technology industry.  To make this project as successful as possible, we need your participation in either or both aspects of it, the survey and the examples. (Whichever works for you.)

What's in it for you? When the final research document is done, we'll give you a copy. We also promise to keep any information you provide confidential.

The survey
We just launched the survey at the following link:

http://deploy.ztelligence.com/start/survey/survey_taking.jsp?PIN=15TQ9CMTFTDDZ

If you have approximately 20 minutes to spare, we're interested in hearing how you collect, write, review, and circulate requirements in your organization. Also, please feel free to forward this link to anyone you think would be interested in participating in this survey.

The examples
We've been building a library of examples of requirements documents. (And thanks to everyone who has sent us their samples already.) We don't need to see the actual words, just the structure of the document. In other words, we want to see your template, not the actual contents of a completed requirements document. Fake or redacted data is good, too, if you use a requirements application.

We're being deliberately vague about what a "requirements document" is, since we don't want to lead the witness. Your examples will tell us what you think the fundamental requirements documents are. What do the key stakeholders and consumers in your organization need?

If you're willing, please send your examples directly to me, tgrant@forrester.com.

[Cross-posted at The Forrester product management blog.]

The Heretech, episode 14: Israel Gat on Agile adoption

In this episode, Israel Gat illuminates the ways in which Agile adoption depends on organizational and cultural factors. We also muse about Helmut von Moltke, 19^th century military Agilist. (Go look it up!)

Plus, a brief review of an even briefer document about innovation in “knowledge-creating” companies, and a heads-up about some upcoming survey research about product requirements and Agile adoption. Copyright (c) 2009 Tom Grant

The extended family of Agile

While the actual document about Agile usage in the technology industry slowly but majestically navigates through the final editing and production process, I thought I'd share an important bit of data that didn't make it into the report. Shown in the diagram below is the percentage of survey participants who said that they used particular Agile methodologies. We also asked the respondents about other methodologies that often come up in discussions of Agile, either as complementary approaches (for example, Lean), or as points of comparison (Waterfall being the most obvious one).



How many at each table in the Agile seating chart?
As you can tell, there's no clear winner here, other than Scrum, which overshadows every other Agile methodology in adoption. There's another way to look at the same picture: whenever there's a family photo of Agile methodologies, the participants almost always make sure to invite their poor cousins to attend. There are both good and bad sides to that earnestly ecumenical approach.

Someone once told me, "If you want to learn about Agile, read a book." Most of these references have an earnestly ecumenical approach to Agile. For example, Craig Larman's Agile And Iterative Development: A Manager's Guide gives equal time to Scrum, XP, UP, and Evo. Peter Schuh's Integrating Agile Development In The Real World covers a different set of methods, but with equal egalitarianism. Sure, these books are a few years old, but they're representative of what teams interested in Agile will find when they scan the bookshelves.

We don't need to declare a winner. A methodology that's in the minority may shoot forward tomorrow in adoption. Scrum might become so commoditized that it becomes the basis for a new set of tailored approaches, in which case the original meaning of "Scrum" winds up submerged in other things.

However, I can tell you from first-hand experience that many development teams are having  a tough time figuring out if they'll find a healthy community of fellow adopters for particular Agile methods. That's a very legitimate question, particularly since the success of Agile implementations often turns on what lessons learned a team can apply from other people's experiences . (Which is one reason, perhaps, why Agile coaching seems to be as important as it is. Among other things, a coach is a storehouse of vicarious experiences with Agile implementations.)

Everyone is welcome at every table
Actually, the survey results shown in the diagram tell a different story about methodological pluralism. In practice, teams mix and match different methodologies. The pluralism of methods within teams may be just as interesting, and maybe more interesting, than pluralism across teams. My Forrester colleagues Dave West, John Rymer, and Mike Gilpin wrote an excellent piece on using Lean to complement Agile, and vice-versa. The diagram shown here indicates that a lot of other methodologies (Six Sigma, ISO, etc.) occasionally wind up in the mix, too.

My upcoming research document, which covers a lot of other aspects of Agile adoption, provides some more information about this mix-and-match behavior some additional teams. The real topic of the study, however, is how Agile changes the way that groups interact with Development, and the effects these changes have on the company at large. I'll post when it becomes available. There's a second document in the works, too, which I'll talk about later.

[Cross-posted at The Forrester product management blog.]

Traditional requirements stink on ice, continued

First, let me belatedly acknowledge Luke Hohmann, who ranted eloquently about traditional requirements at his P-Camp session several days before I started this current screed. His observation was Hemingwayesque in its pithiness: "Requirements suck." Mine is more Faulkneresque, using an idiom ("stink on ice"), undoubtedly with a colorful origin that no one remembers.

The second reason why traditional requirements stink on ice is, ultimately, a question of perspective:

• Development teams build technology for people who are wholly unlike themselves.

• No team has the resources to live side-by-side with the people for whom they're building the technology. The users don't have the time or inclination, too.

• Most development teams rarely interact with people on a different floor in the same building, so living side-by-side with the target users wouldn't be an automatic mechanism for osmotic transmission of insight.

• Therefore, development teams generally view requirements in their own terms, and not the world as the end user sees it.

By necessity and habit, development teams think and speak in terms like features, projects, and releases. Occasionally, users may use this language to make themselves understood to you, but it's not the terms that define their world. They want to do their jobs more quickly and successfully, and  then go home and think about something other than inserting a table of figures into a Word document.

Traditional requirements both reflect and reinforce this language barrier. Obviously, at the end of the day, you do need to go back to your cubicle and work on features. However, at some point in the process of designing, building, and releasing technology for people unlike you, you need to speak and understand their language, not yours.

To illustrate, here's an archetypical exchange between an ISV and a customer:

Customer: "We've been asking for this feature for a while. When will we get it?"

Vendor: "Very soon now. Meanwhile, what do you think of this feature? We think it's a great idea."

Customer: "Sure, it looks interesting."

Vendor: "Cool, because we're hoping to get it into the next release. We thought you might like it."

While there are many, many things going wrong in this conversation, for our purposes, the chief problem is linguistic. Both parties are guilty of speaking the vendor's preferred language, without making it clear how it translates into the customer's. Asking where the ion flux regulator appears in the product roadmap doesn't clarify why it's important to have one in the first place. Nor does it help understand whether the etheric vortex stabilizer helps solve the same problem for the customer, or anything at all.

Here's when some Agile aficianados are jumping out of their chairs to say, "Oooh! Oooh! Let me tell you about personas and user stories!" I largely agree that these Agile-approved requirements media can go a long way towards understanding the customer. However, they're not complete solutions for two reasons:

• The medium often constrains the understanding. For people whose Agile approach involves a lot of Stickie notes or index cards, it should not be a shock to hear that minute tiles of information, as useful as they are, do not always automagically transform into a beautiful, accurate, or complete portrait of the target user. At least in practice, that is.

• The sources of information still deserve some skepticism. You might drop the jumbo Word and Excel documents for personas and user stories, but you still may be extracting information from an unrepresentative sampling of users.

Social media are not a panacea for this language problem, or any other congenital defect that afflicts traditional requirements. Nonetheless, there are ways to use social media to help crack the language barrier.

Mandatory caveat: As in other situations, it's possible to use social media badly here. For example, giving users the ability to vote on feature ideas is a wonderful thing. However, keep in mind that this new channel of communication you are allowing them to speak your language more clearly, without necessarily improving your ability to speak theirs. In fact, some vendors' parochial use of social media resembles what many Americans do when confronted with someone who doesn't speak English: "Maybe you people will understand us IF WE JUST SPEAK MORE LOUDLY."

[Cross-posted at The Forrester product management blog.]

Traditional requirements stink on ice

I've had to put blogging on the back burner for the last week because one research document, covering how product managers can use social media (blogs, Wikis, forums, etc.) as a new source of product requirements, underwent mutation, and then mitosis. Now, it's three separate documents, each of which demands all the empirical and stylistic discipline that Forrester demands. In short, I've been busy.

However, now that two of the three documents are drafted and in the capable hands of my research director, I need to vent. The target of my ire isn't the tribble-like spawning of new documents, which at the end of the day, is the right call, and has made the author much happier with the final product.

No, what's really churning in my guts is the inevitable outcome of talking to people about product requirements, writing about how to improve them, and re-visiting the topic during the editing process. Let's be honest: usually, they stink on ice.

I like that idiom because it evokes a truly epic scale of odiousness.If, in the depth of winter, when everything liquid or semi-solid freezes, and the great slab of ice on which you're standing leeches all the warmth and life out of you, slowly killing each of your senses in turn you're smelling something foul, it must be really foul.

No single post can hope to capture the complete odiousness of traditional requirements. I'll space this philippic across at least a couple of post, but let's start with the most obvious problem, and  the destruction that it wreaks on sensible product decisions, not to mention the working relationship between product management and development.

Wandering in the informational desert
What are the most frequently used sources of requirements in the technology industry? According to our surveys, the results are anything but surprising to us veterans: (1) customer meetings, either face-to-face or over the phone; (2) bug database entries; (3) enhancement requests transmitted through e-mail, often via mailing lists. Customer meetings are also the most trusted source of insight, because they provide far more information than a vague "I have a customer" e-mail from someone in Sales, or a bug report that conveys more frustration than information.

Of course, as "useful" as customer meetings are, they're hardly frequent enough to create a statistically significant sample. People should be skeptical, when the N is small, of how representative the customers are of the larger market, and how reliable the conclusions based on this information can be. Scheduling a few more conference calls, or getting leave to visit another customer on-site, will not provide enough empirical fuel to launch to slip the surly bonds of skepticism.

All of which leads to statements we've all heard before:

"He strongly

• holds the opinion of the last customer to whom he spoke."

• "This customer is full of spurious requests. How much can we trust their judgment?"

• "I've spoken to as many customers as you have. What makes you a greater expert on customers than me?"

• "We don't have time to keep going back to these people to see what they really want."

And so on, truly ad nauseum.

Therefore, one of the virtues of social media as a new source of insight into product decisions is the sample size. Would you rather base the next 12 months of development on an hour's conversation with five key customers, or information collected from hundreds of customers posting on discussion forums and blogs?

Certainly, there are lots of potential ways to misuse social media in this fashion. Aggregate information may be miles wide, but inches deep. Collected sloppily, the sample may be just as skewed as the handful of customers with whom you normally deal.

Still, it's hardly a courageous leap to say that social media provide some useful information that can bear on product decisions. At the very least, these other sources of information can supplement the traditional stuff.

When we return, be prepared to hold your nose as we wade through the other problems with traditional requirements. 

[Cross-posted at The Forrester product management blog.]

Calling all PMs: Sample requirements documents

What we're doing
The research into a research piece on best practices for requirements documents is underway. As anyone who has ever been responsible for requirements knows, there are two sides to this question:

• The requirements process. The overt part of requirements is the process of writing them. The subtler part of the process is figuring out the information needed for the audience. Development (including QA and documentation) might be the primary audience, but they're hardly the only ones.
• The work product. In other word, the actual requirements document. Or, in many cases, documents. For example, while there might be a template for feature requirements, it may link to related or supporting documents (personas, customer feedback, etc.)

How you can help
As with any type of research, the larger and more representative the sample, the better. Which means that you, Dear Reader, can help make this research project all that it can be. In this case, we need your help with that second aspect of requirements, the work product.

If you're willing to share your template for requirements, please send it (or them) along. We're definitely not interested in the content--just the template. We promise to keep the source of any archived requirements documents confidential.

• Samples of what you might have that we'd love to see include the following:
• The Word document for feature requirements.
• The data model for requirements maintained in a fancy-schmancy requirements tool.
• The standard format for use cases and user stories.
• The mock-ups used to depict requirements, if you don't keep traditional requirements.

You can send this information directly to me, tgrant@forrester.com. If you're not sure what to send, just ask.

Plus, if you're willing to be interviewed for the requirements process part of the story, please let me know,

What's in it for you
As always, we'll share the final report with you, once it's published.