Agile Thinking
Agile development processes have had a pretty big impact on product management. An agile product manager has to be adept at bringing clear customer requirements into an iterative development context. This can be a terrific opportunity for product management and engineering to innovate during the development process. But I've found that this kind of agile approach can be applied to a more traditional development process, too.
In an agile world, a product manager (often serving as product owner, as well) is responsible for delivering customer requirements in the form of use cases as the team goes through a series of rapid development cycles. The product design may change after (or even during) each of the sprints, so the PM is responsible for restating the customer requirements in the new context, as well as creating new use case examples. All the while, the PM must keep the product vision and goals at the forefront.
In a traditional "waterfall" development process, the PM would create a prioritized list of features, which the team would build over a period of months or even years. The PM's role is then primarily to clarify the customer requirements, as needed, and work with the team to ensure the goals are met. Changes to the specification are generally discouraged. This works well when the design is excellent and the market/competition isn't changing rapidly, but it can be a problem when design or usability issues are discovered, or when a competitor introduces a new release in the middle of a development cycle.
Waterfall development grew up when software was often monolithic and inflexible, and user interfaces were built laboriously. Of course, the internet, HTML, XML, Flash and tools like Ajax and Rails did not exist. The world has changed.
Prototypes can be developed rapidly, and discarded if necessary. Working products can be built in days or weeks. Product design can be tweaked iteratively as a development progresses, based on usability testing. QA testing can be ongoing during development. Customers can use a product long before it's "finished."
This sort of iterative development is discouraged or forbidden during a traditional process where a spec is "signed off" and the product must be built to match the spec. An iterative approach, on the other hand, provides constant opportunities for innovation. A product design can evolve over time and (as in any true evolutionary process) a failure is a valuable lesson that can be quickly corrected.
"Going agile" is one way to achieve this iterative process. But fully agile development, with an elaborate process of scrums, sprints and daily standups, is beyond the capabilities of some development teams. Sometimes the culture doesn't support it, in other cases a distributed, virtual team can not be truly "agile" from multiple locations around the world.
That's OK. By applying agile thinking to a more traditional development process, it's still possible to build products and achieve the kind of rapid innovation that agile development promotes - even on a project that requires a longer release cycle, such as a packaged software product or new web service. The trick to a "semi-agile" approach is to work closely with Engineering to plan development so that there are milestones at which the product is testable, and schedule checkpoints for evaluation and modification.
Here are some key things to focus on:
- Most importantly, the whole team, including management, must buy into the idea that there can (and should) be iteration during development. It's less predictable, can take more time, and it may reduce the number of features that can be built for a release, but the benefit should be a product that is more usable and more robust. It can also be less expensive in the end, because it's almost always cheaper to recognize and fix problems sooner rather than later.
- Specifications must be viewed as flexible documents that can change, rather than as a rigid "contract." In general, the "what" should be fairly stable, but the "how" (especially the user interaction design) may evolve. This requires a high degree of cooperation between Product Management and Engineering.
- For complex projects, functional specifications should identify and prioritize releases that are complete, usable feature sets (rather than just individual functions) that can be built as discrete, testable components. Individual feature teams may be able to develop their own working modules. This will require close coordination with Engineering.
- Describe specific use cases for the product. Prioritize them and create a backlog. Link them to features and feature sets. And update them as the product design evolves.
- Use prototypes. In some cases, the best "spec" will be a working prototype of a feature or component. Working prototypes should be developed quickly by product designers and engineers, and tested on real users (or, at least, on people who are not developing the product). Design iteration should follow.
- At an evaluation checkpoint, the product manager should plan to work very closely with the team to revaluate priorities, decide whether any redesign is required, and revise the customer use-cases if necessary. Sometimes a release may be deemed ready-to-use, but improvements will be identified and put into a backlog for future work.
- The user experience designer should participate throughout the project, especially when a prototype is evaluated.
- Project Management should plan phases and milestones that include "checkpoint, evaluate and redesign" points. If these are not in the plan at the start, they're unlikely to be added - they'll be seen as unacceptable delays, no matter how beneficial. Because iterations can become open-ended, project management is especially important for keeping development on track.
Rapid prototyping, rapid development, and "lightweight" usability testing provide more than opportunities for fine-tuning a product. An iterative development cycle encourages innovation by the entire team, which is less bound by traditional specifications. Success requires the wisdom and discipline to know when to iterate the design and when to move on. It also requires a strong vision and clear roadmap from Product Management.
"Semi-agile" development isn't for everyone. Some organizations are committed to a "spec as contract" approach, with rigid milestones. Other teams are well suited to "full agile" processes, and can realize all the benefits of the "sprint/scrum" approach. But for those in between, "agile thinking" can result in better, more usable products.
In an agile world, a product manager (often serving as product owner, as well) is responsible for delivering customer requirements in the form of use cases as the team goes through a series of rapid development cycles. The product design may change after (or even during) each of the sprints, so the PM is responsible for restating the customer requirements in the new context, as well as creating new use case examples. All the while, the PM must keep the product vision and goals at the forefront.
In a traditional "waterfall" development process, the PM would create a prioritized list of features, which the team would build over a period of months or even years. The PM's role is then primarily to clarify the customer requirements, as needed, and work with the team to ensure the goals are met. Changes to the specification are generally discouraged. This works well when the design is excellent and the market/competition isn't changing rapidly, but it can be a problem when design or usability issues are discovered, or when a competitor introduces a new release in the middle of a development cycle.
Waterfall development grew up when software was often monolithic and inflexible, and user interfaces were built laboriously. Of course, the internet, HTML, XML, Flash and tools like Ajax and Rails did not exist. The world has changed.
Prototypes can be developed rapidly, and discarded if necessary. Working products can be built in days or weeks. Product design can be tweaked iteratively as a development progresses, based on usability testing. QA testing can be ongoing during development. Customers can use a product long before it's "finished."
This sort of iterative development is discouraged or forbidden during a traditional process where a spec is "signed off" and the product must be built to match the spec. An iterative approach, on the other hand, provides constant opportunities for innovation. A product design can evolve over time and (as in any true evolutionary process) a failure is a valuable lesson that can be quickly corrected.
"Going agile" is one way to achieve this iterative process. But fully agile development, with an elaborate process of scrums, sprints and daily standups, is beyond the capabilities of some development teams. Sometimes the culture doesn't support it, in other cases a distributed, virtual team can not be truly "agile" from multiple locations around the world.
That's OK. By applying agile thinking to a more traditional development process, it's still possible to build products and achieve the kind of rapid innovation that agile development promotes - even on a project that requires a longer release cycle, such as a packaged software product or new web service. The trick to a "semi-agile" approach is to work closely with Engineering to plan development so that there are milestones at which the product is testable, and schedule checkpoints for evaluation and modification.
Here are some key things to focus on:
- Most importantly, the whole team, including management, must buy into the idea that there can (and should) be iteration during development. It's less predictable, can take more time, and it may reduce the number of features that can be built for a release, but the benefit should be a product that is more usable and more robust. It can also be less expensive in the end, because it's almost always cheaper to recognize and fix problems sooner rather than later.
- Specifications must be viewed as flexible documents that can change, rather than as a rigid "contract." In general, the "what" should be fairly stable, but the "how" (especially the user interaction design) may evolve. This requires a high degree of cooperation between Product Management and Engineering.
- For complex projects, functional specifications should identify and prioritize releases that are complete, usable feature sets (rather than just individual functions) that can be built as discrete, testable components. Individual feature teams may be able to develop their own working modules. This will require close coordination with Engineering.
- Describe specific use cases for the product. Prioritize them and create a backlog. Link them to features and feature sets. And update them as the product design evolves.
- Use prototypes. In some cases, the best "spec" will be a working prototype of a feature or component. Working prototypes should be developed quickly by product designers and engineers, and tested on real users (or, at least, on people who are not developing the product). Design iteration should follow.
- At an evaluation checkpoint, the product manager should plan to work very closely with the team to revaluate priorities, decide whether any redesign is required, and revise the customer use-cases if necessary. Sometimes a release may be deemed ready-to-use, but improvements will be identified and put into a backlog for future work.
- The user experience designer should participate throughout the project, especially when a prototype is evaluated.
- Project Management should plan phases and milestones that include "checkpoint, evaluate and redesign" points. If these are not in the plan at the start, they're unlikely to be added - they'll be seen as unacceptable delays, no matter how beneficial. Because iterations can become open-ended, project management is especially important for keeping development on track.
Rapid prototyping, rapid development, and "lightweight" usability testing provide more than opportunities for fine-tuning a product. An iterative development cycle encourages innovation by the entire team, which is less bound by traditional specifications. Success requires the wisdom and discipline to know when to iterate the design and when to move on. It also requires a strong vision and clear roadmap from Product Management.
"Semi-agile" development isn't for everyone. Some organizations are committed to a "spec as contract" approach, with rigid milestones. Other teams are well suited to "full agile" processes, and can realize all the benefits of the "sprint/scrum" approach. But for those in between, "agile thinking" can result in better, more usable products.