ProductMarketing.com

How Product Management Must Change to Enable the Agile Enterprise

Nice article by Catherine Connor in How Product Management Must Change to Enable the Agile Enterprise. She writes:

When development teams adopt agile practices, product management is often caught off guard by the amount of work added to their already overflowing plate. Agile calls for new product management skills and traditional staffing models do not typically accommodate the new product owner role. Given that most product managers are already overworked, how can they manage these new activities to derive more value from software projects and products?

The product owner role is a full-time job. Catherine notes that the folks at Enthiosys have estimated the product management workload to rise by about 50% when software teams adopt agile. In fact most companies are assigning a full-time product owner to each project. Do you have responsibility for 3 or more products? No wonder you're so exhausted.

The solution for many has been to implement the product management triad: one product manager for strategy; one product owner for technology; one product marketing manager for go-to-market. Learn more about implementing the triad in my (free) ebook The Strategic Role of Product Management.

Join me later today for Role of Product Management When Development Goes Agile with Rich Mironov of Enthiosys on November 6, 2009 at 10am-11am PST (1pm-2pm EST). We'll explore the new Pragmatic Marketing framework with focus on agile teams.

Some old material and some new stuff. Maybe even some new jokes!

Friday Fun: The Waterfall Manifesto

Just for fun:

The Waterfall Manifesto for Realistic Software Development.

New White Paper on Business Agility

Too many agile teams are limiting their adoption to just the product development, missing the bigger opportunity. Scott Gilbert and the Enthiosys team have written a white paper called “Business Agility: Harness the Power of What’s Possible” that explains the role of strategic and vision in your agile process. 

The white paper explains:

Ultimately, by investing in Agile adoption and transformation efforts, executives seek bottom line business benefits such as access to new markets, new innovative products and increased revenues and profits. These benefits can only be achieved if leaders work at building, empowered, whole teams and give them the context and boundaries to freely execute.

Download “Business Agility: Harness the Power of What’s Possible” to help spread the business value of agile in your organization.

Agile 2009, Chicago

It's only a month until Agile 2009 in Chicago. The conference has hundreds (thousands?) of sessions on various aspects of agile development including product management. I'll be leading a panel with Laureen Knudsen titled "product owner or product manager or both?"

Be sure to look for me and the folks from Enthiosys at the conference.

6 Lessons for Non-Dev Executives at Agile Companies

Rich Mironov offers 6 Lessons for Non-Dev Executives at Agile Companies. In particular, Rich writes:

The bottleneck is moving elsewhere. As Development catches up with its backlog – shipping twice as much software with higher quality – other parts of the company are being stressed. Channel Marketing has to brief resellers twice as often, Marcom must revise collateral every quarter, Support needs training on the latest update, Operations has new bundles to create and price lists to change. Finally, Sales has to deliver real revenue against the improvements it demanded. (“I know I told Engineering that we could close $16M if we added Finnish and Swedish versions…”)

It's been my experience that Agile adoption reveals broken processes elsewhere, particularly in product management. If product managers are busy supporting sales and marketing and whomever else, how can they provide a continuously prioritized backlog? (And if you've been following the principles in Requirements That Work and Living in an Agile World, you may indeed have a continuously prioritized backlog as well as an updated roadmap, business case, positioning, sales process--all the artifacts that define the business of the product).

As developers deliver more faster, the rest of the company struggles to keep up. Where once we heard sales and marketing people say, "if they could just deliver faster," now we're hearing them say, "Whoa! Slow down! We haven't the bandwidth to launch and learn all the new stuff."

Improving the effectiveness of any one department in isolation reveals broken processes elsewhere. Your company is an organism, each part inter-related with the others; it's not a group of silos. Although some people think Agile is just about development, it also impacts--positively or not--the departments that work with development. When optimizing one group in your organization, think of how the change will affect the others.

Another introduction to Scrum

Here's a great Introduction to Scrum by Andy Brandt. (Thanks to my friend Jon Gatrell for sharing this.)

After viewing, check out my Living in an Agile World ebook for more on the distinction between product owner and product manager.

Friday webinar: Roadmaps, requirements and agile

Join us on Friday for Agile, Roadmaps, and Requirements: Are They Mutually Exclusive? Barb Nelson and I will discuss the importance of having a long-term vision as well as short-term deliverables.

Living in an Agile World webinar

Sue Raisty-Egami of Sure Product Consulting joins me today for the Living in an Agile World webinar series. She'll discuss Five Common Challenges for Product Managers in Agile Teams while I provide sarcastic remarks. Join us!

Product management and agile

Product managers and product marketing manager are adopting agile--some are embracing it, some are suffering it. We've long been supporters of agile methods but want to ensure that the market plays a primary role in product definition and backlog prioritization. So what is the role of product management in an agile environment? This week we begin a series of webinars to answer this question, and also to promote our new Living in an Agile World seminar.

Our schedule is:

• May 8: The Strategic Role of Product Management in an Agile Development Environment with Rich Mironov, CMO at Enthiosys
• May 22: Five Common Challenges for Product Managers in Agile Teams with Sue Raisty-Egami, Sure Product Consulting
• June 5: Agile, Roadmaps, and Requirements: Are They Mutually Exclusive? with Barb Nelson, Pragmatic Marketing
• June 19: Interest Goes Where Money Flows: Creating a Market-Centric "Voice of the Customer" Program with Luke Hohmann, CEO at Enthiosys

I'll be hosting each session. Join me this Friday for The Strategic Role of Product Management in an Agile Environment.

Living in an Agile World

We've been working with our friends at Enthiosys to create a new seminar on agile product management and it's now ready for market. We announced it on Twitter today and we've prepared an ebook on the topic in concert with the launch.

Living in an Agile World is available now for onsite sessions and is on our public seminar calendar beginning in June.

Learn more about the seminar on our Living in an Agile World page.

ten tips to know if your agile team isn't really agile

Alistair Cockburn offers these ten tips to know if your agile team isn't really agile:

1. The team is co-located, but people are not sitting within the length of a school bus to each other.
2. They’re distributed, and there is an absence of microphones and webcams and one or two meetings a day.
3. They have not delivered anything to real users in the last three months. Some of my agile friends would say that’s much too long, but I’m being generous there.
4. If no user has seen real running software inside the last month.
5. They don’t have the output of last month’s reflection workshop or retrospective on the wall.
6. They don’t have fully automated unit tests, and a large number of acceptance tests aren’t automated.
7. They’re not having a build integration at least once day. Good groups do it every half hour; there are groups that get away with it every other day.
8. They write big requirements documents, and they don’t know how to split those up into smaller pieces so they could deliver a piece of software every month.
9. They have itty-bitty requirements on the order of “here’s what happens when you click here,” but they don’t have long-term vision for what they’re trying to accomplish.
10. People keep saying, “It’s not my job.” One of the things about proper agile development is that there is group accountability for results. Very specifically, if the requirements are not coming in fast enough, whoever has a bit of spare time (programmers, testers, etc.) drops what they’re doing and helps gather requirements; if tests aren’t getting done, people with some spare capacity help test and so on.

Want to learn more about product management in an agile world? Go to Pragmatic Marketing's Living in an Agile World resources.

It's always about the problem

In our training classes, we emphasize the importance of solving market problems. Describing problems encountered by our target personas. It's the problem that drives product requirements. Yet we've become an industry of feature-speakers. "I want this and this and this and this!" Wait! What is the problem??

My friend Luke Hohmann wrote about this in his post "Market problems are still THE problem — even when you’re Agile!"

As teams embrace agile methods, some seem to have jumped backwards a decade, getting back to the thinking that opinions drive feature decisions; this is just wrong. Use market facts to uncover problems that customers are willing to pay to solve. Perhaps it's the pace of agile development, needing new items for the backlog every other week. Or perhaps it's a shift in the power of the "team" over the power of market facts.

If you're a product manager, you need to be delivering quantified market data to your product team; if you're a developer, you should demand it. Otherwise, the team will use their opinions of what they think people want. After all, in the absence of market facts, he who owns the compiler wins.

more on the product owner role

In The product owner and the product-shaped hole, Jeff Patton writes:

Product owners learn lots of agile process but scant product design and product management practice

In our work in Living in an Agile World, we've seen product managers struggle with the role of the product owner. Jeff does a good job of describing his view of the role. Call it product owner or product manager or technical product manager, it all comes to the same thing: vendor products need a market-based view of the product, not just a prioritized backlog.

Product management is a comprehensive role that covers strategy, technology, and marketing as defined by the Pragmatic Marketing Framework.

Going Agile? Consider This

My friend Stacey shared this:

Companies are like machines. Each department plays their part, and together the thing somehow works. People within one department don’t always have to understand the entire operation – Sales people, for instance, are not required to understand how coding actually happens.

Certain organizational changes happen, and force the departments to understand a bit more about the machine. For instance – if Sales people are asked to begin selling a product that is delivered as an API, they’re probably going to have to learn something about coding (even if it’s just enough to explain the benefits of their solution).

Usually, Development can make adjustments to their process without needing the support or understanding of other departments. They change the process for controlling source code – but no one else has to deal with that, so it’s an isolated change within their department. Or, they go from manual testing to automation. Again, no one else needs to understand that change (as long as quality is positively impacted).

In most companies, changing to agile is not isolated. When the process for receiving requirements and estimating work changes, lots of areas in the company are impacted and must be brought on board. Basically, this change can cause stress in other parts of the company. If Product Management was having a hard time keeping up before, the change to agile will highlight that weakness, and sometimes stretch our process so far that it actually breaks.

If your development team is thinking of going agile, you have to stop and examine your requirements process. Are you ready to live in an agile world?

How are you preparing requirements? Do you constantly update the prioritized list of market requirements? Or, do you get to a point where you realize you have to deliver requirements, and quickly scramble your schedule so you have time to write stuff down before the team wants to review?

If I asked you to give me your top two requirements tomorrow morning, could you do it?

This is what Product Managers have to be prepared for! When your team goes agile, you have to constantly maintain the prioritized requirements, so you can give development more work at any time.

An agile team is going to ask for requirements more frequently, since they’re organizing their work into short sprints rather than a long waterfall release cycle. If you are constantly seeking market input, and organizing that input into a prioritized list of market requirements, you should be able to handle the transition fairly easily.

If your developers are transitioning to agile, take a look at your machine. Oil as needed, so that your team is enabled to succeed in an agile world.

Got Scrum?

If you haven't heard about it, Scrum is the most widely adopted development planning method in use today. (Well, actually, "hybrid" is the most commonly used method; that is, a hybrid of XP, Scrum, waterfall, and others.) Usually about half of the people attending our Requirements That Work seminar are adopting Scrum. Requirements That Work focuses primarily on requirements and the artifacts of planning, product managers are also interested in the mechanics of agile development.

If you want to know more about Scrum, there are many books and websites available with information--often too much information for what a product manager needs to know. This video does a very good job of introducing Scrum in a very short ten minutes.

Take a few minute to learn more. You may find that these techniques can be used in your product planning regardless of whether your company has adopted Scrum or not.

PO & PM: controversy?

Dean Leffingwell pointed to our white paper on agile product management and has generated tons of interest, both pro and con. He writes:

...this whitepaper does the best job to date of describing the yin and yang of APO (Agile Product Owners) and APM’s (Agile Product Managers).

See his post Still More on Agile Product Owner vs. Agile Product Manager- A New Whitepaper for his review and comments. Read the original whitepaper, Living in an Agile World: the Strategic Role of Product Management when Development goes Agile.

on distributed teams

It's challenging to build a great product even when you have a small team working in a single office. The bar is already high enough! But let's make it even harder, shall we? How do you build products with a highly distributed team?

In my first job as product manager, I had a team located in LA while I was in DC. Once a month, I traveled to LA on the Monday morning flight, spent the week with the team, and then came home on the Thursday red-eye flight. After a while I started to resent it. I know, I know; they were a team of ten and I was just the one person, so it made logical sense that I go to them. When we added offices around the world, it seemed that I was the one who stayed up late to talk to one office and woke up early to deal with another office. I was burning the candle at both ends.

It makes logical sense. You know, “The needs of the many outweigh the needs of the few… or the one.” But logic doesn’t always work, does it?

Luke Hohmann of Enthiosys may have the answer. You can distribute teams successfully but only if you also distribute the pain. Read his solution in Distribute the team? Distribute the pain!

Feedback on Agile issues

I'm playing with a new tool called UserVoice that brings your customers into the conversation in a clever way. The glob of ideas can be reviewed and added to but most of all, they can be prioritized by customers. I see this being a great benefit to any product manager without overwhelming the IT department. (You'd think we'd have more advanced tools by now, eh?)

Anyway, as you may know, we're creating a new seminar for Living in an Agile World. You can find details here. I've started a User Voice forum for it.  In fact I created a forum for these classes:

Living in an Agile World

Practical Product Management

Requirements That Work

Effective Product Marketing

Pragmatic Roadmapping

New Rules of Marketing

I'll use this feedback to revise and extend the classes and I'll also keep you posted of my success with the tool.

Now go vote! and then consider how you should use this concept for your product.

Friday fun: Agile vs Waterfall

This clever youtube video explains Agile and Waterfall from an agile respective. "Well, I have to go to a meeting to plan our meetings." LOL. For a more serious take, check out Agile vs. Waterfall: A Tale of Two Teams.

I'll be speaking about Agile and product management at The Business of Software conference in Boston on Sep 4. See you there!