Thursday, November 12, 2015

Scaling Agile: Scrum at Scale

Scrum at Scale
This is the fifth of six articles on approaches that try to help to scale Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The following articles are about Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS) and Scaled Agile Framework (SAFe). This article will present the Scrum at Scale framework.

The creator of Scrum at Scale is Jeff Sutherland, the co-creator of Scrum. Jeff's reasoning is that part of the key to Scrum's success is that it allows for context-driven solutions and processes – which is why no two Scrum implementations are identical. So why does the conversation about scaling Scrum focus on finding a prescriptive, one-size fit all solution? The conversation should instead be about how to scale the underlying principles of the Scrum framework that have enabled it to be so adaptable.

The Scrum at Scale framework is his first move in that direction. It is a minimal extension of the core Scrum framework that keeps the modular structure at the core of the Scrum framework and allows you to scale a Scrum implementation tailored to the unique needs of your company.

There are four major reasons why Jeff thinks modularity is important:

1. Modularity allows versatility. Scrum has been successful in a wide variety of product and project contexts. It’s been used for everything from traditional software development to designing a new granola bar or designing complex integrated defense systems. No single prescriptive approach could work in all of those different contexts. You need something that is modular to adapt to the specific strategic context of your company.

2. Scrum is modular. At its roots, Scrum is inherently modular. For example the Retrospective ceremony within Scrum doesn’t tell you exactly how you have to implement the retro, it just says that at the end of it, you need to have a plan for improving the team process, puts some bounds around how long that meeting should take, and gives guidance on who should attend that meeting. It leaves the actual practices for how to do that to the team that is actually conducting the retrospective. And as a result, we’ve seen a proliferation of different practices that are successful in lots of different contexts.

3. Deploying incrementally is easier. If you have a modular context and you define all of the interconnections between modules ahead of time (namely what the goal of the module is, what the input to the module is, and what the output of the module is) then it doesn’t matter what happens inside that black box as long as it meets those constraints it still satisfies the goal of the module. That means you don’t need to have an entire solution delivered in one “big bang” at the very beginning of your scaling. It frees you to iteratively use Scrum to incrementally develop the modules that are most important to you and after several iterations have a fully-fledged scaled Scrum.

4. Modularity supports a pattern library. A library of what people have tried in the past, and in what context, is a great way to accelerate the speed with which you can try new scaling experiments. As an agile community, we can quickly build, distill, and capture knowledge so that we can improve the state of the art by borrowing patterns and practices that have been used by other companies in a similar context to ours, and then contribute incremental learnings back to that library. It’s a powerful concept that allows us to crowdsource the development of scaling Scrum.

Context is important

- How important is the speed of delivery?
- How important is innovation?
- How important is team empowerment?
- Where are teams located?
- How complex and/or tightly integrated is the product?
- What is the driving timeframe for becoming agile?
- How severe are the repercussions of a product defect?

Answers to these questions define context, and context is very important when trying to scale scrum. But too often it is neglected in discussions of scaling approach. DAD states the same. There is no one size fits all, and context determines the most suitable approach.

The different modules

The whole framework is described in the picture below.
Scrum at Scale
I will give a short description of the goals each module below:

1. Team Level Scrum Process: Maximize the flow of completed and quality tested work; try to increase velocity a little each sprint; operate in a way that is sustainable and enriching for the team in the long run

2. Strategic Vision: Clearly align the entire organization along a shared path forward; compellingly articulate why the organization exists; describe what the organization will and won’t do to leverage key assets in support of its mission; update and fine-tune vision continuously based on feedback to outmaneuver the competition

3. Backlog Prioritization: Identify a clear ordering for products, features, and services to be delivered by the organization; reflect value creation, risk mitigation and internal dependencies in ordering of the backlog

4. Backlog Decomposition and Refinement: Break complex projects and products into manageable independent functional elements that can be completed by one team in one sprint; capture and distil emerging requirements and customer feedback; ensure all backlog items are truly “Ready” when they reach sprint backlog; parse backlog to individual teams

5. Release Planning: Forecast delivery of key features and capabilities; communicate snapshot of delivery expectations to stakeholders; inform updated prioritization, as needed, based on stakeholder input

6. Release Management: Deliver a consistent flow of valuable finished product to customers; integrate the work of different teams into one seamless product; ensure high quality of the customer experience; capture and communicate feedback on product, process, and schedule

7. Feedback: Understand how customers actually use and interact with the product; define improvements to existing functionality; distil actionable changes in direction from the noise of all responses; capture ideas for new features and functionality not previously identified; update progress towards product/project completion to refine release planning and stakeholder alignment

8. Continuous Improvement and Impediment Removal: Identify impediments that slow teams down and reframe them as opportunities to get faster; maintain a safe and structured environment for prioritizing and removing impediments, and then verifying the resulting improvement;; ensure visibility at the right level(s) in the organization to effect change

9. Cross-Team Coordination: Coordinate similar processes across multiple related teams; manage cross-team dependencies to ensure they don’t become impediments; maintain alignment of team norms and guidelines for consistent output

10. Metrics and Transparency: Provide all decision makers including team members with appropriate context to make good decisions; shorten feedback cycles as much as possible to avoid over-correction; accomplish all of this with a minimal additional effort by teams, stakeholders or leadership.

For each module, you can decide how to implement this best and then start the adapt and improve cycles that form the core of any Scrum implementation.

How does Scrum at Scale relate to the other scaling approaches like DAD, SAFe, Nexus, LeSS?

This question is part of every one of my Scaling Scrum articles but not answered by me. I will try to find quotes from the author(s) of the framework regarding this question. In the final article, where I will compare all the frameworks, I will give my own opinion. Unfortunately, I could not find any quotes except for a few outdated spoken ones of Alex Brown.

Are there well-documented use cases of companies using Scrum at Scale?

Since Scrum at Scale is not really a method but more a help and guidance on choosing your own approach for scaling there is no real clear use case. Scrum Inc is consulting companies whilst using the Scrum at Scale approach, so there are people and companies using this approach, but these cases are not documented and available to the public. When you have one or know where I can find one, please contact me.

Other articles in this series:

Read more…

Monday, November 02, 2015

Scaling Agile: SAFe

The Scaled Agile Framework
This is the fourth of six articles on approaches that try to help to scale Agile. For the introduction to this series please read the first article Scaling Agile: Nexus Framework. The second article is about Disciplined Agile Delivery (DAD) and the third about Large Scale Scrum (LeSS). This article will present the Scaled Agile Framework, or SAFe.

The creator of SAFe, Dean Leffingwell, tries to provide a receipe for adopting Agile at enterprise scale. So not just scaling Scrum, it is all about the Enterprise. SAFe provides guidance on architecture, integration, funding, governance and roles at scale. SAFe, as many enterprises, loves three letter acronyms like DBT, ART, RTE, PSI, NFR, RMT and I&A. I will try do give a short and understandable overview of SAFe, but I have to admit that this is not so easy to do. The whole framework is described in a single poster.
The Scaled Agile Framework
The Scaled Agile Framework (click to enlarge)

What is so special about SAFe?

There are three levels in SAFe:

1 Team
2 Program
3 Portfolio

Team Level

SAFe uses Scrum with XP engineering practices at team level. Define/Build/Test (DBT) teams deliver working, fully tested software every two weeks. This is called one iteration. There are five to nine members in each team.

Program Level

SAFe defines an Agile Release Train (ART). As iteration is to team, train is to program. The ART (or train) is the primary vehicle for value delivery at the program level. It delivers a value stream for the organization. Between 5 and 10 teams work together on a train. They synchronize their release boundaries and their iteration boundaries. Every 10 weeks (5 iterations) a train delivers a Potentially Shippable Increment (PSI). A demo and inspect and adapt sessions are held. Planning begins for the next PSI. PSIs provide a steady cadence for the development cycle. They are separate from the concept of market releases, which can happen more or less frequently and on a different schedule.

New program level roles are defined
- System Team
- Product Manager
- System Architect
- Release Train Engineer (RTE)
- UX and Shared Resources (e.g., security, DBA)
- Release Management Team

In IT/PMI environments the Program Manager or Senior Project Manager might fill one of two roles. If they have deep domain expertise, they are likely to fill the Product Manager role. If they have strong people management skills and understand the logistics of release they often become the Release Train Engineer.

SAFe makes a distinction between content (what the system does) and design (how the system does it). There is separate “authority” for content and design. The Product Manager (Program Manager) has content authority at the program level. She defines and prioritizes the program backlog. SAFe defines an artifact hierarchy of Epics – Features – User Stories. The program backlog is a prioritized list of features. Features can originate at the Program level, or they can derive from Epics defined at the Portfolio level. Features decompose to User Stories which flow to Team-level backlogs. Features are prioritized based on Don Reinersten’s Weighted Shortest Job First (WSJF) economic decision framework.

The System Architect has design authority at the program level. He collaborates day to day with the teams, ensuring that non-functional requirements (NFRs) are met. He works with the enterprise architect at the portfolio level to ensure that there is sufficient architectural runway to support upcoming user and business needs.

The UX Designer(s) provides UI design, UX guidelines and design elements for the teams. In a similar manner, shared specialists provide services such as security, performance and database administration across the teams.

The Release Train Engineer (RTE) is the Uber-ScrumMaster. The Release Management Team is a cross-functional team - with representation from marketing, dev, quality, ops and deployment – that approves frequent releases of quality solutions to customers.

Portfolio Level

PPM has a central role in Strategy, Investment Funding, Program Management and Governance. Investment Themes drive budget allocations. Themes are done as part of the budgeting process with a lifespan of 6-12 months. Portfolio philosophy is a centralized strategy with local execution.

Epics define large development initiatives that encapsulate the new development necessary to realize the benefits of investment themes. There are business epics (customer-facing) and architectural epics (technology solutions). Business and architectural epics are managed in parallel Kanban systems. Objective metrics support IT governance and continuous improvement.

Enterprise architecture is part of SAFe. The concept of Intentional Architecture provides a set of planned initiatives to enhance solution design, performance, security and usability.

Are there well-documented use cases of companies using SAFe?

On the SAFe website there are almost 20 case studies available. See SAFe Case Studies for the complete list. They include companies like John Deere and Intel.

Other articles in this series:

Read more…