|
SVPMA Presentation, Jan 6 2009 Write-up by Keith Rayner How Product Management Must Change to Enable the Agile Enterprise Aided by her active roles as both a Product Manager and Product Marketer, Catherine gave a very insightful presentation on Agile, as rather than just telling us the mechanics of Agile, she highlighted the all-important business value and, crucially for this particular audience, focused on what switching to Agile means in the day-to-day life of a Product Manager. And surprising, even though Agile is now the hottest topic in town, from a show of hands in the audience, as many product managers were still exclusively using the waterfall process as were using purely Agile. In fact, most people were using a mix of both methodologies. So there’s still a way to go, and Catherine’s talk surely helped us along that path. The Agile folks are so passionate about their approach that they’ve proclaimed an Agile Manifesto:
But what do these statements really mean to the uninitiated? The core business value of Agile is that it rapidly produces software responsive to customer demand, by incorporating customer collaboration, in short cycles. Customer and market feedback and requirements are prioritized into a list, formalized as “user stories”. Those stories are implemented in a series of iterations (sprints) of say two weeks each. With integrated testing and review, several sprints make up a working software release, perhaps every three months. If the functionality represented by a lower priority story doesn’t get implemented within a given iteration or release, then tough. No moving out deadlines, no adding additional resources. So doesn’t the customer risk seeing a reduced set of functionality on the release? Maybe, but they get the essential functionality sooner, and that’s the key business value. Going forward, the customer can now give feedback on that new release, which enables a product manager to respond to changing priorities over following a plan. The vision remains clear but the pathway to that vision is dictated by cycles of customer feedback on working software - development becomes value driven rather than plan driven. So here’s the big change for Product Managers. Gone are the days when all this took place within the ivory tower of the IT department, where months went into writing a huge spec, which was hauled away and interpreted by developers, and the users saw the end result at the end of a year (probably late and over budget), when business requirements had changed in the meantime, miscommunications had been locked in code and the users have to battle with contract negotiation if they change their minds. Product Managers, instead of enforcing the dictates of a document written in stone, become much more active in defining what their product should be and how it evolves. They become owners of the product, keeping the vision of the product clearly in mind, but the old, rigid PRD is now replaced by a prioritized list of stories to be implemented. The Product Manager must decide, always driven by customer value, which stories are implemented, and which are dropped in a crunch. Short sprints of teamwork produce working software, not documentation, and testing is integrated within this. Daily status checks (“daily standups”) on what was accomplished yesterday, what will be accomplished today, and any roadblocks, require closer interaction with the individuals on a team, resulting in a more disciplined and accountable team, greater project visibility, faster development of better software, and ultimately more satisfied stakeholders But if a Product Manager has to work more intensely with your team, has more releases to manage and must also constantly assess customer requirements, isn’t that a large workload for one person? Thankfully, Agile happily accommodates partnering with a Product Marketing Manager who focuses more on market research and launch management while still working closely with the team as a stakeholder. Didn’t RAD, DSDM and iterative development solve those issues years ago, and isn’t Agile just a new set of buzzwords? Definitely not. the essential difference is that with Agile, you get a valuable release of the application much more rapidly, say every three months, whereas RAD iterations are typically within the development cycle itself and customer-facing new software still only sees the light of day after a year, so that main problem of the waterfall model is still there. SaaS is certainly the ideal counterpart of Agile, as publishing an application as SaaS allows the incremental implementation of features much more easily than stand-alone apps that get distributed by CD or at best downloaded by each user. On the other side of the coin, a SaaS portal itself is ideal for capturing the user feedback which guides the next phase of the process, and interestingly, Rally integrates with Salesforce CRM so dollar value of lost contracts due to missing features can be assessed. So how do you get Agile? 1) enroll in a Yoga class, 2) visit www.agilecommons.org, a forum for the Agile Community, and 3) check out Rally’s tools and services at www.rallydev.com/personas/product_manager. Keith Rayner, Kemarra Inc: Jan 2009
|
