Discuss Agile > Agile Product Management

Best Practice: Naming User Stories (2 Comments)

Mon, 25 Jan 2010 16:31:37 +0000

Question by Su

Do you recommend naming user stories with the full user story text, e.g., "As a <user>, I want to <do something> so that I can <get some value>" or with a short name? What are the risks and/or benefits of either approach?

Number of Product Managers per VP of Product Managers (2 Comments)

Mon, 15 Sep 2008 16:17:57 +0000

Question by LouiseKAllen

I am doing some market sizing - as anyone seen any data on the average number of product managers per Director/VP of PM by chance? I am looking for the same data on the Development side - average number of developers per VP of Development? Thanks very much for anyone's help.

Louise Allen

Parallel Iterations - good or bad? (8 Comments)

Tue, 04 Dec 2007 22:21:13 +0000

Question by Catherine C

1. How good or bad is it to implement parallel iterations using Agile?

Agile Process from Fantasy Interactive (1 Comment)

Tue, 21 Apr 2009 14:57:16 +0000

Tip by Stephen

Today we posted an entry on our experience with using Agile. You can find the discussion here http://www.kontain.com/fi/#entries/entry/25191

When Do You Deliver Acceptance Criteria? (3 Comments)

Tue, 04 Dec 2007 22:07:41 +0000

Question by Catherine C

1. If the user stories are brief enough to fit on a 3x5 card, how can Dev possibly have enough info to give you what you want? It seems like you'd need to define & deliver the acceptance criteria (sounds a lot like Requirements) up front before they start developing, rather than toward the end of the iteration.

Acceptance Criteria vs. "Detailed User Story" (10 Comments)

Mon, 10 Dec 2007 05:15:06 +0000

Question by Catherine C

1. What is the difference between the Acceptance Criteria and a 'detailed story spec'?

Delivering features across multiple iterations (2 Comments)

Wed, 05 Dec 2007 05:22:37 +0000

Question by Catherine C

1. For a feature that will take 3 months to develop, what would you do. Build it over 3 iterations?

Product Management Through The Eyes of a Product Owner (1 Comment)

Tue, 24 Feb 2009 00:08:37 +0000

Question by Luke Hohmann

I’ve finally finished adding two submissions to the 2009 Agile Alliance conference. My first submission is my very popular “Prioritizing for Profit” talk on how a product manager should approach the prioritization of a backlog based on backlog items that drive profit and avoid ROI prioritization schemes. My second submission, Leveraging Collaborative Ideation and Decision Making Technologies, is a new talk about an emerging class of tools that help distributed Agile teams in collaborative ideation and prioritization activities.

Since the selected papers are based on what people submit, and since I care enough about Agile Product Management that I created the leading company on the subject, I thought I’d take a look at the submissions to the Agile Product Management stage that Enthiosys’ own Rich Mironov is producing.

What an incredible disappointment.

Instead of seeing submissions that address the full range of product management issues, I’m seeing submissions that clump into a few small categories, all of which can be summed up as “product management through the eyes of a product owner”. These are:

Lots of talks about the backlog, but not many talks about market research
Lots of talks about the backlog, not many talks about making money from your work (other than mine)
Lots of talks about role definition and team structure (important)

C’mon people—one more time—a real product manager does more than manage a backlog. A real product manager does a whole plethora of things (if you’re confused, visit our partner Pragmatic Marketing).

So, how about some submissions on:

win/loss analysis in Agile and how frequent releases can stop losses faster once patterns are found
sales collateral in Agile and how you need to stop printing materials when faster releases makes them obsolete
market segmentation in Agile and how Agile can help you create finer-tuned segments
buyer personas in Agile and how market feedback (releases) tunes your sales processes
market research in Agile (listen up! there is more than Kano and Innovation Games!)
pricing strategies in Agile (should I raise my price every release? why or why not?)

My main point is that I’m very concerned that the Agile conference is still thinking about Product Management through from the vantage point of a product owner. That’s just wrong. I’ll try to make a few more submissions to compensate for this. In the meantime, if you read my blog, and you’re an AGILE PRODUCT MANAGER, please, submit, on something other than managing a backlog. (And, if you really do think that being an Agile Product Manager is primarily about managing your backlog… submit to another stage).

More at: www.enthiosys.com

How To Sound Smart (But Be Really Naive) About Dramatic Changes in Technology

Tue, 24 Feb 2009 00:07:38 +0000

Question by Luke Hohmann

Adam Bullied posted an apparently naïve question on his blog, inviting readers to take simplistic views of agile product management as identical to traditional product management, or as a completely different animal. Lots of folks piled on, creating a patchwork of comments and opinions that don’t address the interesting question of how product manage has evolved under Agile. I’d reframe his question (“Are agile PMs Baloney?”) into something meatier: “Do radically different ways of building software radically change how software product managers do their job, and how does this change our thinking about delivering value to the market?”

Let’s get warmed up. Suppose I was an industrial designer working in the early 1950’s. My job? Creating new tools for machine shops. My tools? Pencil and paper. Clay and wood prototypes. My development process? Relatively slow. Feedback loops? Long. To compensate, I work as much experimentation into my process as I could, but, let’s face it: there was only so much experimentation that I could try.

Fast forward to today. I’m still an industrial designer making tools for machine shops. Except now I’m not using pencil and paper, I’m using a sophisticated CAD-CAM system. I might be using wood and clay, but chances are good that I’m printing my prototypes. My development process? Fast. Feedback loops? Short. My ability to experiment with alternatives, and to use experiments with customers, is so easy that I find myself naturally collaborating throughout my process.

Now, ask yourself: Has the job of the industrial designer changed?

Think about this before reading further. Has the job changed?

Of course it has! Our “jobs” are inextricably tied to the tools and infrastructure that we use to complete the same. Dramatic changes to the technologies of our tools and infrastructure creates equally dramatic changes in our jobs. In every industry.

Few developers program in assembly language anymore. We have better tools for that. And these tools, have, in turn, changed the job of the developer.
The “job” of setting the price of items has changed dramatically since the advent of sophisticated pricing systems.
Even cooking has changed, as high-tech methods enable the creation of dramatically different kinds of food. (Cryogenic Ice Cream, anyone?)

Which leads us to the main point of this blog. Adam asserted that there is no such thing as an Agile Product Manager, because, well, the job of the product manager is still the same. A good PM has to identify market problems and solve them. Agile is just a different technology for doing that, right? And because of that, there really is no such thing as an “Agile” PM – they’re just a PM using a different technology, right?

Wrong. Naively wrong, at best, but, wrong nonetheless.

However you choose to interpret the meaning of the word “job”, get clear on the following: It is a complex system. And complex systems have feedback loops. Which means…

Your “job” influences and is influenced by the technologies that you use to do the same.
Dramatic changes to these technologies will cause equally dramatic changes in your job.
Your “job” lives inside a larger, even more complex system. So, changes in how you behave shape this even larger system. (Think how markets change when release cycles change from 9 months to 3 months to 3 weeks).

If you find someone telling you that an Agile PM is just a regular PM doing Agile, smile knowlingly, pat them on the head, and walk away, because trying to explain complex, non-linear systems thinking to people who don’t think in terms of systems is just too darn hard, unless, of course, you’re billing by the hour.

And if you’re NOT experiencing dramatic changes in your product management job since you’ve adopted Agile then give us a call – chances are pretty good you’re not doing Agile right.

More at: http://www.enthiosys.com

Important Lessons in Pairing – From a Designer’s Perspective

Tue, 24 Feb 2009 00:05:27 +0000

Question by Luke Hohmann

As part of our blossoming partnership with cooper, I had the good fortune to sit in one one full day of cooper’s Kim Goodwin (recent author of _Designing for the Digital Age: How to Create Human-Centered Products and Services) was the instructor. Throughout the class, she emphasized the importance of pairing in design. Some of her advice is spot on with pairing practice in the Agile community. Some, however, was new to me, and quite profound. Here are some “Kimisms” (or cooperisms) that I picked up in the class.

Start with a pair of peer designers. They may have different experiences, skills, and areas of preferences, but they are peers.
Give them a shared design task. Both are working together to create the design.
One member of the pair is designing and creating and the other is helping. Kim referred to these people in two distinction roles – the generator and the synthesizer. The synthesizer helps in three distinct ways:
- Concept midwifery: The synthesizer works with the generator to help them create a fully formed idea, most often by challenging the design from a narrative perspective informed by the personas, scenarios, and workflows created during the research phase of the project.
- Understanding the concept: The synthesizer confirms their understanding of the idea.
- Critiquing the concept: The synthesizer helps to critique the idea by explicitly asking how the primary persona for which the concept has been developed would use this idea. Once this has been handled, the synthesizer continues to ask how other personas would respond, taking great care to avoid their own experience and leverage their personas experience.
People at cooper pair for a good chunk of time – often a year – but not “forever” as too much time together makes you less effective at critiquing work.Roles are important, and while people tend to fall into common roles that they can skillfully execute, pairs sometimes explicitly switch the roles that they’re playing. This is common in pair programming, too!
One member of the pair can help the other from being bogged down in too much detail at the wrong time of the design.

While I’ve explained this in pretty cut-and-dry terms, the reality is that pairing is always a fluid process. If isn’t so much as there is an explicit role switch as that whomever is leading is generating and whomever is synthesizing is helping. Hand the marker to me, and when I stand up we fluidly change our perspectives and our roles.This is some great stuff, especially the light process reminder about helping others create fully formed ideas before critiquing them, and when critiquing ideas, remembering to critique them from the perspective of your personas, and not your own experience.