Product Management in an Agile Environment
Many software product teams are either currently experimenting with Agile methods, or have recently moved. I have written elsewhere about the benefits of Agile methods, including Scrum and XP, but I wanted to highlight here the keys for product management in an Agile environment.
Note that this list is meant for product software teams. For custom software there are some very different considerations.
1. The product manager is the product owner, and represents the customer. He will need to be extremely involved with the product development team, helping to drive the backlog and especially answer questions as they arise. Some misguided product managers think they get off easy in an Agile environment; they couldn’t be more wrong.
2. Using Agile is not an excuse for a lack of product planning. As a product manager/owner, you still need to know where you're going, what you’re trying to accomplish, and how you’ll measure success. That said, in an Agile environment, your planning horizon can be somewhat shorter and rolling. You should use the lightweight Opportunity Assessment instead of a heavy MRD (see Assessing Product Opportunities).
3. You and your designers should always try and be one or two sprints ahead of your team. This allows you to validate difficult features with sufficient time to improve them. Insist that the designers (interaction designers and visual designers) are front-and-center in the process, and make sure they don't try to do their design work during the sprint while the implementation is already underway (see Design Vs. Implementation) Make sure, however, that someone from the engineering team is reviewing your ideas and prototypes every step of the way in order to provide feedback on feasibility, costs, and insights into better solutions.
4. Break the spec and design work into as small and as independent chunks as possible, but not too small - make sure you don't try to design a house one room at a time. But remember the emphasis on coming up with the minimal product possible. Note that in an Agile environment, the designers may need to work faster than they’re comfortable with. You’ll find that certain designers, and certain design methodologies, like rapid prototyping, are more compatible with the pace of an Agile environment than others.
5. As a product manager/owner, your main responsibility is to come up with useful and usable prototypes and user stories that your team can build from. Replace heavy PRD’s and Functional Specs with prototypes and user stories. Do prototypes for three reasons: 1) so you can test with real users, 2) to force yourself to think through the issues; and 3) so you have a good way to describe to engineering what you need built during the sprint. So go test prototypes with real users. Try out your ideas and iterate on the prototype until you’ve got something worth building. You still need to make sure that you don't waste sprint cycles.
6. Let engineering break up the sprints into whatever granularity they prefer. Sometimes the prototypes can be built in a single sprint, other times it may take several sprints. You will find that having good prototypes will help significantly in estimating the amount of work and time required to build. Remember that engineering team has considerations like quality, scalability and performance, so let them chunk the functionality into sprints as they see fit.
7. Make sure you as product manager/owner and your interaction designer are at every daily status meeting (aka “standup” or “daily scrum”). These morning meetings are the beginning of the communication process, not the end. There will be a constant stream of discussion about the product. Designers should be previewing functionality to the developers and QA. Developers should be showing off completed code to each other, QA and the designers and product manager. QA and developers should be identifying potential pitfalls during prototyping, and helping the team to make better functionality, design and implementation trade-offs.
8. Don't just launch every sprint – reassemble sprint results in a staging area until you have enough to make a release as defined by the product manager/owner. It's the product manager’s job to ensure that there is sufficient functionality to warrant a release to the user. Remember that in a product environment, constant change can be more upsetting to your customers than less frequent upgrades (see Help Prevent User Abuse.)
9. At the end of each sprint, make sure you demo the current state of the product, as well as the prototype for the next sprint. Having everyone see what you finished validates the team’s hard work, gives the entire company insight into the product, and keeps the evangelism going.
10. Get Agile training for your entire team. Hire a consultant to help your product team to move to Agile, but make sure it's one that has proven experience with product software teams and understands the difference between product software and IT or custom software. If everyone understands the mechanisms around Agile, then you can focus on the execution. If people don't understand, you'll get bogged down in the semantics and dogmatic issues.
There’s one question that comes up very often with Agile teams: Why can't the initial sprints be considered a prototype?
For very simple software they can, but for most significant projects there are three reasons.
First and foremost, time to market. A sprint is far too long to wait to try out an idea. An idea which will most likely be wrong. It is much faster to try that idea out with a disposable prototype in hours or days rather than wait weeks or months for one or more sprint cycles.
Second, there are typically too many critical things for the engineering team to do to use them for the product discovery process – by taking their time for this they are not able to do what they should be doing – building production quality software that is scalable, fast, highly available, fault-tolerant, reliable and maintainable.
Third, while Agile methods do much to encourage the team to learn and respond quickly, it is still difficult and time consuming for a team to change directions significantly once they have begun down a path, and put long hours into a particular architecture or approach.
I’d like to thank Joe Arnold of Yahoo and Andrew Sandler of Salesforce.com for their contributions to this article. They are both working hard to adapt Agile methods to meet the demands of product software environments.