ProductMarketing.com

Don’t Solve Half of the Problem

Nice post by Scott Sehlhorst at Tyner Blain on splitting user stories:

User stories were created as lower-overhead use cases that served to better describe chunks of valuable software that could be rapidly developed, delivered, reviewed, used, and improved. Writing user stories that undermine that intent – rapid, valuable, incremental delivery – is a bad way to write user stories.

Source http://tynerblain.com/blog/2010/09/08/sprint-backlog-splitting-user-stories/

In particular, good user stories are about the persona, not the product. Or as Scott puts it: "The right approach is to first solve all of the problem for a subset of the users."

Alas, many of the "roles" definitions we see are not personas but vague titles. "As a provider of IT support..."?? Man! That isn't specific! What kind of IT support? Linux, Mac, Windows, mobile? What kind of organization is supported? Large business, mom-and-pop shop, family, everyone who has met a member of my family?

Agile is supposed to help you make better products faster. Focus on personas and their problems and a lot of the rest falls into place.

Posted via email from Steve Johnson on product management

An Agile backlash

Now that teams have spent some time with agile methods, some are finding it's not the silver bullet they expected.  Agile is a set of principles for writing better software but it's not the answer for every team. 

In a post, Daniel Markham offers extensive remarks to "Agile ruined my life," 

Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up

Source: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php

There's a bunch of anti-agile screed in the mix but to me it seems that agile is imposed on some people--and it's not always the right choice. Yet don't lose sight of the success stories: applying a discipline--agile or otherwise--to the art of development is always a good idea. The real successes seem to be there: from cowboy coding to iterative development. 

My rule is this: friends build products. Collaboration is better than contract negotiation. We need something between a cocktail napkin and an 800-page MRD/PRD. How about a set of index cards with an agreement to discuss. That's the approach we take in Requirements That Work. 

Posted via email from Steve Johnson on product management

A journey of a thousand miles

I’ve just come out of another agile conversation where prospective clients confused “we want to build better software faster” with “we hope that some new processes will instantly catch us up on years of slipped deadlines and missing features.”

So paraphrasing Confucius, “A journey of a thousand miles begins with a single step, but is still a thousand miles long.  Even at twice your normal walking speed, be prepared for a very long slog.”

via mironov.com

Read Rich's article for some great ideas on showing early successes in an agile project.

Posted via email from Steve Johnson on product management

Maniac Attack Newsletter Q2 2010 by Leading Software Maniacs

Funny story... years ago a VP of Product Management wanted us all to go to Austin to set in one of their seminars to prove a point to me and my staff that "being first to market, means everything -- even if you ship software products with bugs. You show customer service by how fast you fix the defects." Well, his plan backfired -- and thanks to Pramatic Marketing's training, we all learned the importance of making the customer your #1 priority. This approach is the hallmark of "agile" thinking and it enables the right, QUALITY decisions to be always made.

via maniac attack newsletter (the q02 issue)

My pal Ken shares this funny story about being "first". First to what? While some advocate having potentially shippable products, we prefer to have potentially sellable products. Our seminar showed Ken's team that focusing on the market generally results in the right decisions. Read more in his quarterly newsletter...

Posted via email from Steve Johnson on product management

Our Divisive Scrum Terminology Needs to be Deprecated | Scrumology

I shudder to think of the newly trained ScrumMasters or Product Owners that return from their courses to label their fellow coworkers as chickens or pigs. How is that in any way going to help foster adoption? You can try to dismiss the scenario, and I’ve listened to CST’s reason through how their trainees could never be that dense. I’ve heard the argument “Well we only use it as an introduction…” however I’m growing tired of us introducing the framework using a joke.

via scrumology.net

I couldn't agree more. The main problem I've have with the "chicken and pigs" joke is that the developers (pigs) have to die, according to the joke. Agile development is great for many teams but it's not supposed to be fatal. Let's all stop using the joke as an analogy.

Posted via email from Steve Johnson on product management

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.