Take an Empirical Approach to Products, Operations, and Innovation
Heavily influenced by Scrum, enterprise agility encourages an empirical approach to products, operations, and innovation — experiment, learn, and adapt. This approach is in response to the traditional method of speculating what will work best and investing considerable time planning a solution only to discover (upon delivery or implementation) that the solution doesn’t work or the product doesn’t deliver what the customer wants or needs. With an empirical approach, a team has an idea, tries it out, and gathers feedback before investing a lot of time and effort. The empirical approach is consistent with the Agile Manifesto’s fourth value: “Responding to change over following a plan.”
All the top enterprise agile frameworks support the empirical process and break it into two stages:
- Pulling in ideas, features, and tasks
- Delivering small batches to gather and analyze frequent feedback
Pulling in ideas, features, and tasks
The idea of pulling work into the teams is further broken down into three types of work: ideas (innovation), features (product), and tasks (operations). The type of work dictates how it’s pulled into the system:
- Ideas: Data-driven organizations may be interested primarily in mining new ideas by collecting and analyzing large volumes of data.
- Features: For teams focused on product development, most of the work being pulled into the system is in the form of features, epics, or user stories. Teams select the highest priority features and work toward integrating them into an enterprise-level product.
- Tasks: If you’re primarily focused on operations, such as a helpdesk or DevOps, work orders are in the form of tasks. Many helpdesks, for example, use a tool similar to a Kanban board to track workflow. They may have color-coded tickets, such as red, orange, and yellow to prioritize items. DevOps may use a similar approach to manage infrastructure, creating a prioritized list of tasks that must be completed to perform a major operation, such as installing a new server or creating a testing environment.
All the enterprise agile frameworks have ways to pull features into the teams:
- SAFe® starts with strategic themes at the enterprise level that are broken down into solutions by solution train engineers and then broken down further into release trains by release train engineers, which are then passed along to various agile teams.
- LeSS has one product owner who maintains an evolving product backlog from which the agile team members pull their work.
- DAD has a three-phase delivery lifecycle, during which the team members plan their work (inception), do the work (construction), and release their work to the rest of the organization (transition).
- The Spotify Engineering Culture follows a “think it, build it, ship it, tweak it” approach that leaves it up to the teams to pull work and complete it.
- Kanban relies on a Kanban board, which serves as a to-do list for teams. Many enterprise agile frameworks use Kanban boards to create a prioritized list of work items that teams use to manage workflow and communicate work status to the rest of the organization.
Delivering in small batches
The success of empirical process control hinges on delivering work in small batches, collecting and analyzing feedback frequently, and making adjustments. With small batches, team members learn from their successes and failures and can apply that learning to improve the product and the process for creating it.
Think of the small batch delivery and feedback loops as the engine of the empirical process. This engine enables teams to frequently experiment with the product and the process and zero in on the best solutions, resulting in both a better product and a better process. It also encourages a culture of continuous improvement, which is a key factor to improving overall enterprise agility.