Q&A About Agile Product Management
Below is an online Q&A from a presentation I gave on Agile Product Management. Just wanted to share….
Q: How do you deal with a management team that is entrenched in the Waterfall method and a development team that is Agile from a roadmap and planning perspective?
Sue Raisty: 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 plus make sure that Management 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.
Q: 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, and multiple product lines?
Sue Raisty: 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 assign 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…
Q: Many companies claim to have Agile. In your opinion, where does the waterfall end and agile begins?
Sue Raisty: Yes, everyone claims they are doing Agile even if most Agilistas would disagree. I believe the most common methodology in use now is what the practitioners often call “modified agile,” where the process itself is very waterfall-ish but the releases are pushed out more frequently, an interval between 6 weeks and 3 months. I would actually call these “tiny waterfalls” instead of “agile” because they neglect in-flight customer feedback.
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.
Q: As we are moving to Agile, Development has identified the Product Managers as the Product Owners AND Proxy Customers. In my case, for 12 dev teams. Any suggestions?
Sue Raisty: 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.
Q: Thoughts on managing a product backlog that has 200+ items?
Sue Raisty: 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.
Note that I am not really operating at the user story level. My “features” break into several user stories a piece. Some of the features I track are perhaps at the “Epic” User Story though.
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.
Q: What if the team members leave the company while project still going on and how do we manage this situation in Agile environment?
Sue Raisty: I assume you are talking about a developer leaving?
First, cry and mourn the loss, for at few minutes anyway.
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 your team member retreated into his cave for months and created a morass of spaghetti code that no one can figure out – s/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.
Q: What is the typical timeframe to go through the stages in an individuals companies “hype cycle?” Does Gartner give any guidance on this?
Sue Raisty: 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.
Q: When should release content and date be defined? Beginning of release or end?
Sue Raisty: 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 user stories/features from the backlog that he/she wants to ultimately address 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 / user story list scale back and evolve to address mid-release feedback and the realities 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 iterations tick away, the release content always 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. I’ve pushed out dozens of product releases (all of which required at least 3 months of coding effort), and all kinds of wild stuff can happen — things like acquisitions/mergers, major changes in corporate strategy, massive layoffs and restructuring, etc. In software, these things happen ALL the time and are hardly unusual, but they throw a huge wrench into the release schedules and features delivered by even the most Agile team.