Agile Excellence
Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams
Agile Excellence is an Agile overview written for product managers (as opposed to a software development audience). In addition to covering Agile tools and processes, Cohen focuses on the business case for Agile, how the role of product manager fits in an Agile team, the importance of product strategy and roadmaps, and attributes of strong product development teams. Cohen also wrote 42 Rules of Product Management with Brian Lawley of the 280group.
The Cost Curve
Agile Excellence begins with the observation that, with traditional software methodologies, the cost of change increases as the team moves through the product development lifecycle. Agile methodologies typically have a shorter feedback cycle which helps decrease the risk of finding critical issues late in the development process. Agile embraces change (rather than trying to eliminate it) and focuses on decreasing the cost of change. With traditional waterfall methods, the cost of change is increased by the amount of process surrounding change approval (documentation, meetings, approvals, reviews). This is the fundamental business case for using an Agile approach in software development.
[youtube=https://www.youtube.com/watch?v=7ZLtiZnP6wU]
Writing good user stories
User stories are a basic building block of Agile development methodologies–they are the basis of estimation, velocity and sprint planning. Although the format of user stories is widely documented, criteria for what makes a good story are not quite as abundant. Cohen offers Bill Wake’s INVEST framework for judging when a story is done. User stories appear to be an approachable tool, but in practice writing good stories is challenging, particularly as the number of stories grows and questions begin to arise about all aspects of the product.
- Independent – Stories should not have dependencies on one another
- Negotiable – Consider stories a starting point for a conversation with the Engineering team
- Valuable – Why is the story worth implementing?
- Estimable – The level of detail and overall size of the story should support estimation by the developers
- Small – Each story should be no larger than the sprint length and at least a half-day of work
- Testable – Acceptance criteria must be testable
[vimeo https://vimeo.com/43601248]
Non-functional requirements
Cohen includes a section on non-functional requirements, a topic that is frequently glossed over or completely missing in other books, leaving product managers with user stories like “as the system, I want to process 1 million requests a second so that I can meet performance metrics.” Having a good framework for non-functional requirements is important because the benefits of many products are derived from non-functional attributes.
Cohen suggests writing Mike Cohn‘s constraints on cards and specifying each attribute as appropriate:
- Performance
- Accuracy
- Portability
- Reusability
- Maintainability
- Interoperability
- Capacity
Non-functional requirements are frequently left out of development projects due to the focus on functional requirements and user experience. This is a mistake because so many products fail due to performance, scalability, and maintainability issues. Often, these characteristics are left as assumptions or are not included in acceptance tests and QA phases. Writing non-functional requirements requires stepping outside the product itself and thinking about its context of use and overall business environment.
Product strategy components
You need to know where you’re going before planning a release or iteration
Cohen stresses the importance of starting with business strategy which informs product strategy, which then frames the construction of the product roadmap. The roadmap can then be broken up into releases which are pulled from a prioritized product backlog. Sprints are finally mapped to releases.
The product strategy should include: 1) the market problem and identification of target audiences, buyers, and users; 2) a description of the product itself including the minimum marketable feature set and competitive analysis; 3) business model and financial model; 4) marketing four p’s; and 5) timeline and budget. Providing this overview to the entire team will set the context for the product and support decision making as a result of goal and objective clarity.
Writing for product managers, Cohen re-affirms the value of product management in an Agile team by situating sprints and releases within the roadmap that is designed to support the product strategy.
Team challenges
Cohen discusses several challenges to effective teamwork based on The Five Dysfunctions of a Team by Patrick Lencioni. The five dysfunctions are absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. Each of these can cause an Agile team to fail, and, in many cases sway the organization’s perception of Agile itself. Cohen emphasizes many environmental factors like team dynamics that are often left out of Agile discussions which focus on tools and methods.
[youtube=https://www.youtube.com/watch?v=6dRKa700RaQ]
