Document Actions
Five Common Challenges for Product Managers in Agile Teams
Agile is all the rage - developers are using it to deliver products more quickly and more reliably. But many organizations will find that their initial success with Agile is unsustainable unless they address how Agile impacts the rest of the organization, including product management. In this webinar, Sue and Steve will discuss five common challenges faced by newly "agilized" organizations and will propose solutions.
Watch Five Common Challenges for Product Managers in Agile Teams
|
|
About the Presenters
Steve Johnson is a recognized thought-leader on the strategic role of product management and marketing. Broadly published and a frequent keynote speaker, Steve has been a Pragmatic Marketing instructor for more than 10 years and has personally trained thousands of product managers and hundreds of company senior executive teams on strategies for creating products that people want to buy. He teaches several top-rated seminars including Practical Product Management, Requirements That Work, and Pragmatic Roadmapping, as well as many on-site workshops. Prior to joining Pragmatic Marketing, Steve practiced the discipline of product management for over 18 years at a variety of software and hardware firms and served as head of marketing for the leading provider of performance management software.
Steve writes the Product Marketing blog. Contact Steve at sjohnson@pragmaticmarketing.com
Sue Raisty-Egami is a software product management and product marketing consultant based in Silicon Valley. Her work focuses on helping clients identify and understand new markets, using social media in product marketing and product management, organizing and coaching PM teams for success, competitive anlaysis, and "block and tackle" PM/PMM work. Her career includes 30+ product releases, plus time as a startup entrepreneur, software engineer, management consultant, and director of product management. Sue holds a BS in computer science from MIT and an MBA in marketing from Kellogg.
Sue blogs at Sure Product Consulting.
PM=PO
Posted by
Steve Johnson
at
2009-05-26 12:24 PM
We often see product managers taking the role of product owner, and the proxy customer. But not for 12 products! There just aren't enough hours in the day!! You should discuss your role with your teams--surely they can see that you cannot attend 12 daily meetings. I suggest you reorganize the products into a family (or two), and manage the family. Also, you should attend our Living in an Agile World seminar to learn ways to work smarter, by giving more context to requirements instead of being the 24/7 answer guy.
Moving to Agile...
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
12 dev teams! One PM, playing both the role of PO and Proxy Customer! That is ludicrous and highly unrealistic. How can you possibly intelligently understand the problems each of these 12 products address, develop an appropriate backlog, spend time interviewing with customers, write user stories, and attend 12 meetings a day (even if they are only 15 min a piece - that's 3 hours!).
You need more help. I can't say whether it's a real PM or a business analyst or whatever, but there is no way you could do these 12 products justice and still do your main PM responsibility - being the voice of the customer and learning about their problems. You need to have a good conversation with your management.
And if that doesn't work, I recommend you start drinking mojitos. Often.
You need more help. I can't say whether it's a real PM or a business analyst or whatever, but there is no way you could do these 12 products justice and still do your main PM responsibility - being the voice of the customer and learning about their problems. You need to have a good conversation with your management.
And if that doesn't work, I recommend you start drinking mojitos. Often.
Multiple Methods
Posted by
Daniel Cureton
at
2009-05-22 07:04 PM
How do you deal with a management team that is entrenched in Water Fall method and a development team that is Agile from a roadmap and planning perspective?
Waterfall
Posted by
Steve Johnson
at
2009-05-26 12:24 PM
Waterfall gives the 'appearance' of structure and predictability and yet agile teams have found that they deliver more faster and with higher quality. I'm not the "agile is great" guy --it's not religion for me--but I do spend time with product managers and execs showing how to embrace agile.
I suggest the best approach is to start with some baby steps. Show the short-term results of agile on a pilot project. Explain the success metrics and how you can see with certainty what will be delivered when.
Most companies use roadmaps for planning--and you should too. They show our plan but roadmaps are not commitments. That is, if you want to change your direction or accommodate a customer request, the roadmap must be a living document.
For more on roadmaps and agile, come to the webinar by Barb Nelson on June 5.
I suggest the best approach is to start with some baby steps. Show the short-term results of agile on a pilot project. Explain the success metrics and how you can see with certainty what will be delivered when.
Most companies use roadmaps for planning--and you should too. They show our plan but roadmaps are not commitments. That is, if you want to change your direction or accommodate a customer request, the roadmap must be a living document.
For more on roadmaps and agile, come to the webinar by Barb Nelson on June 5.
Waterfall vs Agile
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
Management teams usually respond to results. If you have a successful agile release that comes out faster with higher quality and more predictability, you'll often see management teams change their ways.
That said, as a PM you still have to communicate a long term product vision and roadmap to an executive team. You just have to get more skilled at not saying exactly WHEN each feature will come out and also make sure that they view the roadmap as something flexible and subject to change as you learn more about the market. Hopefully, they will recognize that you are already basically changing your roadmap all the time - but usually it's after a release came out and the results were not what you expected. Agile just gives you the construct to make these changes BEFORE the bad results roll in.
That said, as a PM you still have to communicate a long term product vision and roadmap to an executive team. You just have to get more skilled at not saying exactly WHEN each feature will come out and also make sure that they view the roadmap as something flexible and subject to change as you learn more about the market. Hopefully, they will recognize that you are already basically changing your roadmap all the time - but usually it's after a release came out and the results were not what you expected. Agile just gives you the construct to make these changes BEFORE the bad results roll in.
False Promises
Posted by
Ruud de Keijzer
at
2009-05-22 07:04 PM
How do you deal with the issue of giving off false promises? during development certain features are skipped or modified, resulting that differes from what has been reviewed by customers?
false promises
Posted by
Steve Johnson
at
2009-05-26 12:24 PM
Showing a prototype or an interim build must be characterized as a work in progress; it's not a commitment. We want to get customer feedback at various stages but delivery isn't guaranteed. That's the challenge of sharing roadmaps broadly; a roadmap is a plan, not a commitment.
Too many vendors share too much detail with too many customers. Focus on the problems that you're solving rather than the features that you're building, and tell everyone that your plans are subject to change.
Too many vendors share too much detail with too many customers. Focus on the problems that you're solving rather than the features that you're building, and tell everyone that your plans are subject to change.
Scrum
Posted by
David Bermingham
at
2009-05-22 07:04 PM
How do you see MRDs, PRDs and Product Review Boards (PRB) fitting into the scrum process?
agile adoption
Posted by
Steve Johnson
at
2009-05-27 02:23 PM
The MRD has been replaced by the release backlog. The PRD has been replaced by the spring backlog. The PRB has been replaced by the end-of-sprint demo.
Mostly I would encourage the product manager to serve as the representative of both the customer and the product review board.
Mostly I would encourage the product manager to serve as the representative of both the customer and the product review board.
Scrum
Posted by
Scrum
at
2009-06-01 12:15 PM
I agree with Steve, but I do think that some of the work traditionally done in the MRD still needs to be done - such as segmenting a market, ascertaining which segments are most attractive, forecasting, and how the product should evolve to support the business strategy. So, in my opinion this info moves to a higher-level document that I call the product strategy. Others call this a product vision doc or product consept, and some adapt their roadmaps to accomodate this content that used to be in the MRD. Whatever you call it, this document spans multiple releases (not just one, like an MRD), but provides the rationale for WHY you are taking the product in this direction.
Question
Posted by
Alex McCarthy
at
2009-05-22 07:04 PM
How do you handle "we can't do x feature" or "we can't meet that requirement"?
Trust but verify
Posted by
Steve Johnson
at
2009-05-26 12:24 PM
When developers say they cannot do a feature, you need to drill down further. Is it because the problem is not well understood? Do they need to do further research? Or is it just that they don't want to do it? I've found the last case is often because they don't believe the product manager. "Build me feature x" isn't a good requirement. If they don't believe it, they won't want to do it. Focus on the problems that you want to solve and support those problems with market evidence. Prove to the developers that you know more about the market than they do and that this problem isn't your whim but a market requirement.
Learn more about supporting requirements with evidence in our Living in an Agile World seminar.
Learn more about supporting requirements with evidence in our Living in an Agile World seminar.
Interface Design
Posted by
Brandon Kunz
at
2009-05-22 07:04 PM
How does user interface design work best within agile ... like other longer-term consideration like architecture? How do you police design decisions to ensure consistency across stories, iterations, releases, multiple product lines?
Interface Design
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
This is another one of those challenge areas. Like PM, user interaction design was not explicitly addressed in Agile methodologies. What I've seen work with some limited success (no home runs here) was having a UI designer on each team that sits in the room, attends Scrums, etc... But these designers also have a weekly pow-wow with the other UI designers on other products. They show off their work to each other and review it (much like a code review), and they spot a lot of areas to more holistically improve usability.
Architecture is another thorny one. Some companies have an architecture team that lives together and is exempt from the entire Agile process and does the traditional design docs. On the other end of the spectrum, some companies an architect per team, and during the weekly "Scrum of Scrums" the architects are among the attendees and seek areas of synergy, consistency in stories, etc...
Architecture is another thorny one. Some companies have an architecture team that lives together and is exempt from the entire Agile process and does the traditional design docs. On the other end of the spectrum, some companies an architect per team, and during the weekly "Scrum of Scrums" the architects are among the attendees and seek areas of synergy, consistency in stories, etc...
Question
Posted by
Chuck Weir
at
2009-05-22 07:04 PM
I didn't hear 'conceptual nor detailed' design as a phase discussed between 'requirements' and 'coding'...was that implied in the discussion? Getting the design down (by a solutions architect) and signed off by the product mgr and then used as a tool to get the developers 'on board' and then using an 'agile' approach works for us.
Question - Architecture
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
Not all features will require a conceptual architecture between requirements and coding, but most anything of substance and real value will. I've seen approaches similar to what you describe work - in fact the smoothest Agile process I've seen was at a company with a similar approach.
Product Owner or Business Analyst
Posted by
Chaminda Jayasekara
at
2009-05-22 07:04 PM
I have a business analyst working with me to define requirments for the products. So in Agile world do you think PdM should be the product owner or BA?
PM=PO
Posted by
Steve Johnson
at
2009-05-26 12:24 PM
Different roles are needed in different teams. Generally, we see the business analyst taking the role of product owner while the product manager continues in the business and strategy role as described in my free ebook, The Strategic Role of Product Management.
Instead of worrying about titles, consider the activities of the Pragmatic Marketing Framework and assign responsibilities for the activities. It's easier than navigating the mess of titles.
Instead of worrying about titles, consider the activities of the Pragmatic Marketing Framework and assign responsibilities for the activities. It's easier than navigating the mess of titles.
Question
Posted by
Steve Hessian
at
2009-05-22 07:04 PM
Susan, many companies claim to have agile. In your opinion, where does the waterfall end and agile begins?
Question - Where does waterfall end and agile begin
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
Yes, everyone claims they are doing Agile even if most Agilistas would disagree.
I personally think the nomenclature and exact definitions are not important as long as you are doing better with your new "agile" process than you did before with waterfall and you are making further attempts to continually improve.
That said, in my mind the "bare minimum" Agile has 2-6 week iterations where a semi-usable product comes out, documentation and needless process are kept to a minimum (not eliminated, just kept to a minimum) in favor of building, and there is a way to get customer/stakeholder feedback into the release at several points prior to release.
I personally think the nomenclature and exact definitions are not important as long as you are doing better with your new "agile" process than you did before with waterfall and you are making further attempts to continually improve.
That said, in my mind the "bare minimum" Agile has 2-6 week iterations where a semi-usable product comes out, documentation and needless process are kept to a minimum (not eliminated, just kept to a minimum) in favor of building, and there is a way to get customer/stakeholder feedback into the release at several points prior to release.
Sprints
Posted by
Bob Williamson
at
2009-05-22 07:04 PM
In our company, we have implemented a new entity called the Product Review Board which is comprised of members from sales, marketing, PM and engineering. Product Mgrs take MRDs to the PRB fpr approval for they are taken to Sprint Planning Meetings. Have you seen this before and do you have any comments on how to make it effective without slowing down the process.
sounds like waterfall
Posted by
Steve Johnson
at
2009-06-02 12:51 PM
This sounds like your company is doing waterfall but calling it agile. Nonetheless, if it's working, keep doing it. In the end, you want to have a prioritized backlog that is longer than the next few sprints. You need to have a vision beyond the next iteration.
Having a corporate team evaluate the priority of individual items makes you a secretary, not a product manager. Instead, I suggest that you work with this team to define a formula for priority and let the formula prioritize the backlog.
Having a corporate team evaluate the priority of individual items makes you a secretary, not a product manager. Instead, I suggest that you work with this team to define a formula for priority and let the formula prioritize the backlog.
Managing Product Backlog
Posted by
Steve Bestvater
at
2009-05-22 07:04 PM
Thoughts on managing a product backlog that has 200+ items?
Managing Product Backlog
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
Sure - I've done that. Basically, I kept this spreadsheet that listed each feature in the backlog, with a 1-2 line description of each (otherwise, with 200 items you forget what each item means), the "category" (example: "disaster recovery", "user interface), and a priority measure (I used 1-10). I could then sort the thing relatively quickly in different ways to come up with features for the next iteration based on priority, grouping similar items together, etc.
Best thing about the spreadsheet is it is really just for YOUR use - not the entire team's. You can thus adapt it to whatever you need to do your job. If you can avoid it, try to resist the temptation to over-engineer this and use a full-blown requirements tracking system to manage your backlog. I find these systems are too much for prioritizing a backlog and add the very overhead to the process that you are trying to avoid with Agile.
Best thing about the spreadsheet is it is really just for YOUR use - not the entire team's. You can thus adapt it to whatever you need to do your job. If you can avoid it, try to resist the temptation to over-engineer this and use a full-blown requirements tracking system to manage your backlog. I find these systems are too much for prioritizing a backlog and add the very overhead to the process that you are trying to avoid with Agile.
Adapting Agile
Posted by
Mary Steele
at
2009-05-22 07:04 PM
What accounts for the explosion in adopting agile methodologies in the recent past?
agile adoption
Posted by
Steve Johnson
at
2009-05-26 12:24 PM
We've seen a continuous evolution over the years from waterfall to spiral to iterative to agile. In a world that thrives on continuous improvement, agile is the latest in helping development teams focus on the most important stuff and making sure they get it right by getting customer feedback early and often. The industry has always been frustrated by the effort to get it right for the customer, particularly with too many competing voices in the planning process. Scrum seems to strike the right balance between too much process and not enough.
I'm convinced that developers want to deliver the best product. They've correctly seen that 300+ page tomes of requirements don't get the job done. Agile is the latest method for getting the right product in the market fastest.
I'm convinced that developers want to deliver the best product. They've correctly seen that 300+ page tomes of requirements don't get the job done. Agile is the latest method for getting the right product in the market fastest.
Loss of Team Members
Posted by
Jayakumar Mogenahalli
at
2009-05-22 07:04 PM
What if the team members leave the company while project still going on and how do we manage this situation in agile envoirnment?
Loss of Team Members
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
I assume you are talking about a developer leaving?
First, either cry and mourn the loss, or cry and do your happy dance if you are glad to be rid of the dude/duddette.
Second, look on the positive side - in an Agile environment you have more flexibility to deal with this loss. Because your team was meeting daily (or close to it) and the iterations were much shorter than waterfall release cycles, it is unlikely that this guy retreated into his cave for months and created a morass of spaghetti code that no one can figure out - he wouldn't have had the chance. With Agile, it's more likely that someone else can pick up his/her critical projects.
Third, accept that you're going to have to either extend the release schedule or reduce the functionality in each iteration and, ultimately, in the release - even if there was a replacement team member tomorrow.
First, either cry and mourn the loss, or cry and do your happy dance if you are glad to be rid of the dude/duddette.
Second, look on the positive side - in an Agile environment you have more flexibility to deal with this loss. Because your team was meeting daily (or close to it) and the iterations were much shorter than waterfall release cycles, it is unlikely that this guy retreated into his cave for months and created a morass of spaghetti code that no one can figure out - he wouldn't have had the chance. With Agile, it's more likely that someone else can pick up his/her critical projects.
Third, accept that you're going to have to either extend the release schedule or reduce the functionality in each iteration and, ultimately, in the release - even if there was a replacement team member tomorrow.
Timeframes
Posted by
Jeffrey Davidson
at
2009-05-22 07:04 PM
What is the typical timeframe to go through the stages in an individuals companies "hype cycle?" Does Gartner give any guidance on this?
Timeframes of Hype cycles
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
Virtually every technology or new approach worthy of notice goes through a hype cycle, but the time spent in each phase really depends on the technology and the overall cultural environment. For example, the phases lasted a lot longer a few decades ago - witness the invention of the Internet as an example. It took decades to reach the "height of inflated expectations" and then we hung out in the "trough of disillusionment" for a year or two post-bubble collapse. For newer technologies and newer approaches, we now move through the phases more quickly. But for most it will still take years to make it through the hype cycle.
Release Dates
Posted by
John Westerveld
at
2009-05-22 07:04 PM
When should release content and date be defined? Beginning of release or end?
Release Dates
Posted by
Sue Raisty-Egami
at
2009-06-01 12:10 PM
Most commercial software vendors seem to use a time-boxed approach with Agile, meaning they specify a target release date up front. The PM should have light-weight "release plan" at the beginning of the release, meaning a list of features from the backlog that he/she wants to ultimately see in that release. This would be a flexible list and subject to change as iterations proceed and more is learned, but it should provide an overall goal for the release and idea what it is about ahead of time. As iterations proceed, you usually see the release plan / feature list scale back and evolve to address mid-release feedback and the realitites of the release date.
So, that's a long-winded way of saying you do define both the release date and release content up front. The date is usually the firmer of the too. As the interations evolve, the release content usually changes.
That said, I really try very hard not to make any public declarations of release date or features until we're at least half way through.
So, that's a long-winded way of saying you do define both the release date and release content up front. The date is usually the firmer of the too. As the interations evolve, the release content usually changes.
That said, I really try very hard not to make any public declarations of release date or features until we're at least half way through.
Embracement
Posted by
Bruce Alter
at
2009-05-22 07:04 PM
What is a good way to tell if the team is embracing the benefits of Agile or just being lazy in gathering and defining requirements?
agile adoption
Posted by
Steve Johnson
at
2009-05-27 02:23 PM
Agile is about brevity and collaboration. Your product manager and/or product owner should be bringing problems to solve with evidence that the problem is pervasive in the market. Agile is about teams working together. Coding without requirements isn't agile by anyone's definition.
How do you approach writing user stories?
Posted by
Leslie McKay
at
2009-06-01 06:19 PM
My company moved to agile about a year or so ago. I was product manager/product owner on the first team to "go agile." In my experience, I find it is difficult to write user stories. In our implementation of agile, develoers see user stories as a way to break down their work. They assign them points and they strive to have them represent work they can begin and complete in one iteration. I tried writing user stories, only to have them rewritten by developers. The end features don't change, but the work breakdown does. As a result, I've backed off user stories. I write small documents that cover (a) the problem to be solved, (b) why we want to solve the problem, (c) use cases to show how the user should interpret the problem as solved, and (d) boundaries or requirements that must be met in the solution. The developers have really liked this format, and they write user stories based on this. Really, my small documents comprise a theoretical PRD for the release.
But I'm curious to know how you've addressed this.
Leslie
But I'm curious to know how you've addressed this.
Leslie
communication is the key
Posted by
Steve Johnson
at
2009-06-02 12:51 PM
I like your approach. We advocate a similar approach in Requirements That Work and Living in an Agile World. Like yours, our focus is on personas and their problems. It forces us all to talk about problems to be solved instead of features to be delivered. In my experience, good developers are problem-solvers--so let's give them problems to solve!
Moving to Agile...