The 3 Things
- /
- The Product Playbook
- /
- The 3 Things
We have everyone and everything (skill sets, tools, etc.) needed to deliver working, tested, documented, and deployable products.
Teams are the people who build, test, and deliver the products we ship to customers. Agile frameworks assume that we have a team with everyone and everything needed to deliver working, tested, documented, and deployable products.
The implications of this assumption are that organizations will have to evaluate whether they are providing their teams with the tools and skill sets required to fulfill the business needs.
This evaluation may lead to organizations finding that they need to hire people with different skill sets, provide training to their teams, and/ or invest in tools and infrastructure to deliver tested products.
Backlog items are appropriately sized. Backlogs are ordered and prioritized to capture work needed to develop product/end deliverables
The second component of what makes Agile frameworks effective is backlogs that are:
Simply having a backlog is only the first step, however.
Once a backlog exists, it’s critical to ensure that the backlog truly reflects a deep understanding of priority, customer need, value, risk, and technical feasibility.
Good backlogs provide teams with the confidence that they can pull work from the top of the backlog and expect it to be appropriately prioritized, sized, and detailed enough to create a common understanding and provide clear direction.
Deliverables meet defined acceptance criteria, have been reviewed and approved by product owner/ stakeholders, been tested, and are shippable (with no bugs or known/ accepted bugs)
The final component of what makes Agile frameworks effective is the frequent delivery of working, tested product.
The concept of delivering a “potentially shippable” product at the end of a given timebox (ideally, at the end of each sprint) requires a shift in how we develop, test, and validate work.
In order to be able to ship product at the end of each iteration, we need the following:
Deliverables meet acceptance criteria. (Requires strong and continuous collaboration with product owner and stakeholders).
Deliverables have been reviewed and approved by the product owner/ stakeholders. (Requires having demo-able product increments that stakeholders can experience).
Deliverables have been tested and are shippable. (Requires having clearly defined practices and tools for testing, considering work “done”, and releasing into a production-like environment).
The way we form teams and foster collaboration across the organization
Structure is the expression of teams at scale. We want cross-functional, collaborative participation at all levels of the organization—and for all functions. This forms the backbone for how the Agile enterprise operates. The business architecture, the technology architecture, and the organizational chart inform the structure. We’re constantly looking for opportunities to encapsulate, decouple, and minimize orchestration costs.
The way we make economic tradeoffs in the face of constraints
Governance is the expression of the backlog at scale. It’s about how we govern and manage the flow of work, decompose requirements, and make prioritization decisions and economic tradeoffs in the face of uncertainty. It’s how the organization determines the batch size, breaks down work, coordinates across teams, manages constraints and dependencies, and deals with feedback when plans inevitably change. At the end of the day, governance is the process through which a team receives its backlog.
Figure out what gets in the way of progress, and organizational agility
Metrics and tools are the expressions of Working Tested Product at scale. It’s the way that we measure how the entire organization is delivering value, not just at the team level, but across teams and across the entire organization.