Evolving the Agile Organization - Scaling Scrum & EBM

Evolving the Agile Organization includes concepts and tools for measuring and enabling business agility through Evidence-Based Management (EBM). It also examines the importance of Organizational Design and Culture, which includes human factors, processes, and structures in the organization that can promote or inhibit agility with Scrum. Key focus areas are Emergent Software Development, Managing Technical Risk, Optimizing Flow.

Evolving the Agile Organization – Scaling Scrum

Scaling Scrum Large-Scale Scrum is Scrum scaled up to multiple teams. It isn’t a bigger process that includes Scrum but is Scrum at its core. In agile development, you focus on creating value early and often. If there are multiple teams then they can only deliver value when they deliver an integrated feature across all teams. So the focus from optimizing the individual component teams’ performance needs to be moved to focus on optimizing the performance of the whole department/all teams.

The Key is focusing on optimizing for flow instead of optimizing for resource utilization. To achieve this the logical step is to move component teams to feature teams or if it is a big change then management can adopt scaling scrum.

Scaling Scrum to the department means that all teams work from one product backlog. One Product Backlog means one Product Owner.

Sprint Planning at scale

All features that are candidates to be in the Department Sprint are properly refined before Sprint Planning. A Definition Of Ready was introduced.
The Product Owner works with line management, project management, project architects, and Scrum teams’ representatives to order the Product backlog before Sprint planning so that the most valuable work is at the top.
The Product Owner prepares a Sprint Goal.

Sprint Planning Part I

1. Prioritize the features based on Cost-of-Delay and cost of development.

Sprint Planning Part II

Identify the capacity of the Scrum teams.
Pick the most valuable feature and adjust the remaining capacity from the teams.
Repeat until the team’s capacity does not allow any new feature to be completely developed.
The Scrum teams identify dependencies between them and how to resolve them.
With the work distributed across the different teams and the dependencies identified each team individually plan their Sprint and creates a Sprint backlog.

Daily Scrum at scale

The teams manage their own dependencies at the daily department Scrum.

Backlog Refinement at scale

At least two times per Sprint, project architects, integrators, domain architects, domain experts, and Scrum team representatives come together to refine the top of the product backlog’s features into stories for the individual Scrum teams.

Sprint Retrospective at Scale

Every Scrum team has its own Sprint retrospective where they look at team improvements and team building. Management actively solves impediments outside of the teams’ reach.

Sprint Review at scale

At the end of every department Sprint, there is one big Sprint Review. The department Product Owner Peter presents to the external stakeholders the achievements of the last sprint.

Evolving the Agile Organization – Portfolio Planning

Agile portfolio planning (Portfolio Management) is an activity for determining which products or projects to work on, in which order, and for how long. The portfolio of work-in-progress tells the team what is happening and when the team can change it similar to a product backlog. It requires cross-organizational commitment. Portfolio Planning is used to make Decisions, Tradeoffs, and Assignments. It moves between the strategic view to the tactical view, creates a rolling wave plan & provides transparency into the organization’s work.

Participants in Agile Portfolio Planning

Internal Stakeholders have the perspective to properly prioritize new products and make decisions regarding in-process products.
Product Owners of individual products, act as champions for their products and advocates for resources.
Senior architects and technical leads ensure that any important technical constraints are factored into decisions.

Portfolio Planning: Inputs & Outputs

Input:

New-product data: cost, duration, value, risk.

In-process products: intermediate customer feedback, updated cost, schedule, and scope estimates, technical debt levels, and market-related data.

Output:

Portfolio Backlog: It is similar to a product backlog; however, while a product backlog contains items relevant to only one product, a portfolio backlog describes multiple products, programs, or projects for which development has been approved but not yet begun.

Set of Active Products: It includes new products that have been approved and are slated for immediate development, as well as products that are currently in process and have been approved to continue.

Participants in portfolio planning manage the portfolio backlog and set of active products through four categories of activities:

Scheduling
Inflows
Outflows
In-Process Products

Agile Portfolio Management employs an Agile mindset to provide real business value:

Business Value focused
Shorter releases
Ability to reprioritize when needed
Highly transparent
Rich data
Quiet when it is going well, noisy when it is not
The mindset of continuous improvement
Sustainably more productive
Happier people

Benefits of Portfolio Planning

It makes it clear where the time is being allocated—and where the time is not allocated.
It makes it possible for the organization to optimize at the organization level, not at the person level.

Evolving the Agile Organization – Evidence-Based Management

Evidence-Based Management (EBM) is an empirical approach that provides organizations with the ability to measure the value they deliver to customers and the means by which they deliver that value, and to use those measures to guide improvements in both.

EBM consists of four Key Value Areas (KVAs)

Current Value
Time-to-Market
Ability to Innovate
Unrealized Value

Ebooks on EVM: Click Here