Agile Meets Pragmatic Marketing

Posted by Kurt Christensen on Nov 10, 2007

Sections

Process & Practices,

Architecture & Design,

Enterprise Architecture

Topics

Agile in the Enterprise ,

Agile ,

Business

Tags

Business/IT Alignment

Pragmatic Marketing is a product management methodology for the technology industry which seeks to apply values and principles similar to those of agile software development. So what happens when the pragmatic marketers meet the agile developers? In a recent article, Stacey Weber writes that the meshing of cultures is often less than perfect:

Acrimonious is a pretty accurate description of many companies’ experiences with agile methodologies. This approach basically gives in to rapidly changing requirements. In fact, I believe that Agile was created because engineers needed to figure out how to deal with constant and inconsistent changes from executives and product managers. These engineers are dealing with executives who can’t decide which is a top priority and product managers who are too busy thinking about requirements to actually visit the market and learn the real requirements... For engineering, agile seems to be the answer—their teams can stay focused on a very small set of requirements. They can basically ignore the executives and product managers… and any changes more than a few weeks down the road.

False premises aside, one thing rings true: agile methods do not magically solve fundamental problems within the business. Specifically, agile methods won't help the business if the business can't decide what it should build, or at least prioritize among competing concerns. This theme was elaborated on by Barbara Nelson and Stacey Mentzel in an article titled Extreme Product Management:

If agile methods by themselves were solving the problem of building products people want to buy, we wouldn’t need to write this article. We’d say, “Be agile!” But over and over again we hear that agile has helped deliver something sooner, but without some planning and overall vision, what is being delivered (let’s call it user stories) may not actually help us sell more software.

In response to their perceived shortcomings of agile methods, the authors advocate "agile waterfall", which is essentially agile software development with a stronger emphasis on long-range planning. In one respect, this seems both reasonable and necessary - give the business some ability to make long-range plans and commitments in order to make sales; to help them "create products people want to buy" - the mantra of Pragmatic Marketing. However, an overemphasis on long-range plans doesn't enable the business to capitalize on the feedback provided by incrementally-developed, working software. After all, building the product should be helping the business better understand what sort of product can be built, and for how much. Ironically, the target industry for Pragmatic Marketing is technology hardware and software, and true technology innovation involves more than simply listening to the market; it involves showing the market that which they did not know was possible. One doubts that the iPhone was born of a marketing focus group.

Nevertheless, Pragmatic Marketing should interest advocates of agile methods both because it shows that agile values and principles can be applied with success on the business side, and more importantly because - in some cases - it is attempting to address situations where agile development practices are failing the business. Why is this, and what can be done?

1. Back to top

   Pragmatic marketing techniques can be helpful

   by Steven Farley

   I have had first-hand experience with the use of pragmatic marketing techniques in an agile development environment. One of the instructors (Jim Foxworthy) worked with us to define formal requirements and user personas at the start of a product release cycle. We then "mined" the requirements for user stories and executed the release using agile practices.
   
   Without formal requirements, and without the input of real customers, agile development can be chaotic because the user stories are driven internally without knowledge of what users really need. Having a requirements document that was created using traditional marketing techniques made the agile development process much more acceptable to management.
   
   The persona descriptions were particularly helpful. When there is no access to real users, many developers design the software for themselves. The personas helped us to design the product with specific types of users in mind.

   Reply

2. Back to top

   It was only a matter of time

   by Bruce Rennie

   When Toyota starting working with lean they quickly found that they weren't able to get the maximum advantage from their new practices because their suppliers weren't able to keep up. Agile/lean thinking radiates outward and, if you are aggressive in pursuing it, you'll eventually run into a barrier at the interface between agile and non-agile teams.
   
   Since marketing is supposed to be feeding product development requirements, I'd suspect it's probably the first challenge agile development organizations are going to meet. I've certainly experienced situations in the past where we were able to release far more frequently than marketing could handle.
   
   I think there's hope. If you Google Boyd's OODA loop you'll find some of the biggest adherents are marketing firms. There is a definite business advantage in being able to get a requirement into product and out to the market in the shortest time possible.
   
   I would say that the biggest pain point for sales and marketing organizations trying to keep up with agile development teams is that market research is going to become more important and poor research is going to become embarrassingly obvious rather quickly. It's no good having a weapon that fires really fast if you're pointing it in the wrong direction.

   Reply

3. Back to top

   If influence flowed just one way, then long-range planning would be fine

   by Michael Nygard

   The reason that waterfalls never work is that there's not a clean, one-way flow from market analysis to requirements to design to implementation.
   
   Instead, as development progresses, particularly agile development, it exerts an influence upstream. Development changes the space of "possible".
   
   The biggest example of all is the Web itself. No development happens in a vacuum. When TBL created the first web server and browser, he built them in the context of "online cross-referenced documents". After that, though, every new development project---web-based or not---exists in a context where marketers and developers have to deal with the Web.
   
   On a much smaller scale, as you go through iterations on an agile project, things that looked hard or impossible may become plausible, even easy. This force can cause tension. (E.g., "Last planning meeting, you told me this would cost 6 clicks. Now you say it's 1. Were you lying then or now?") Or, it can enable very rapid adaptation.
   
   The key part of the Boyd cycle is recognizing that your own actions change the context in which you operate. Agile development underscores that. Product management can take advantage of it, or they can throttle it back to meet a long-range (i.e., six month) marketing plan.

   Reply

4. Back to top

   Pragmatic=good, Agile-Waterfall=Unnecessary

   by Deborah Hartmann

   I recently took the "Requirements that Work" course from the Pragmatic Marketing organization, to see how it fits with what I teach software teams, and whether it could help their product owners. I was pleasantly surprised.
   
   How many teams have out-run their product owners? We have good practices for the developer-side rhythms of product creation. But we don't (can't) always offer the product group similar help with the preceding cycles necessary to prepare for release planning. Unable to keep up, Product Owners start coming in with less and less well-formed ideas about what they want, and why they want it.
   
   In "The Five Levels of Agile Planning" Hubert Smits identifies: Product Vision, Product Roadmap, Release Plan, Iteration Plan, Daily Plan. The Pragmatic Marketing approach includes multiple processes to help with the first two or three "levels" leading up to the point where a product backlog and release plan could be created/maintained. They offer a coherent system of thinking tools like Business Case, User Personas, Roadmap and Scenarios to help the Product group get a handle on what's really needed, before they even start talking to developers.
   
   As with the Agile practices, where each one is kind of obvious and useful in itself, thinking tools are more powerful when used in combination. I am hopeful that this approach offers an integrated system of tools and practices to help Product Owners and other business stakeholders keep pace with their Agile teams.
   
   Yes, planning is definitely needed: but not big-upfront system planning. Rather: Product Visioning and Planning, done at the appropriate level of detail in relation to the horizon of predictability, in the same way we sketch out out future user stories in less and less detail as we look further into the future. This is the exact approach recommended in the Pragmatic class I took.
   
   Let's keep an eye on this and look for opportunities to build synergies with users of Pragmatic Marketing, since the organization itself is generally open to Agile development, if still sometimes lacking in expert input.
   
   deb

   Reply

• Older >