擴展敏捷框架的比較

Nowadays, with the development of new products and services getting larger and more complex, organizations continuously investigate and explore frameworks that will ensure initial business value, secure time and cost, and lower its delivery risk. Coupled with the fast changes in technology and market innovations, the popularity and clear superiority of the agile frameworks are becoming evident regarding its benefits and the value it can produce.

There are many methods or frameworks well-proven agile methods such as Scrum, XP, and Kanban. These agile methodologies focus on being adaptive to change and creating software iteratively. It has been widely practiced by teams of small sizes. Meanwhile, several scaling agile frameworks look to solve the problems associated with agility at scale. These framework set down the guidelines, techniques, and processes, roles and artifacts which ensure that working with hundreds of practitioners, remains coordinated and easy to manage.

The leading frameworks are Nexus, Large-Scale Scrum (LeSS), Scaled Agile Framework (SAFe) and Disciplined Agile (DA), how these frameworks differ or which one works best. In this article, we will cover the four popular scaling agile frameworks.

The Maturity Requirements for Scaling Agile Teams

Before the scaling agile methods are introduced, we better review what is the level of maturity of the agile team that should have to minimize the risks for the adoption of a scaled agile approach on an enterprise scale. According to The creator of LeSS Craig Larman, the prerequisite for adopting a scaling agile method for multiple agile teams is that:

All these teams should all be structured as cross-functional and self-organizing Scrum teams.
The teams vertically slice requirements into the smallest possible increments that can be deployed independently.
Teams are also expected to focus on technical excellence such as doing continuous integration and automated regression testing.
At the end of every sprint, the teams should have a potentially deployable product.

Only if each of the agile teams has the above characteristics of agility, the organization can be more comfortably adopt scaling agile method, so that we can dealing with the potential problems such as cross-team dependencies, or scheduling of release coordination for deliverables.

What is Nexus Framework?

Ken Schwaber and Scrum.org developed Nexus, and it is just simply a framework that implements scrum at scale across multiple teams to deliver a single integrated product. Teams work in a common development environment and are focused on producing a combined increment every sprint with minimal dependencies.

It can be applied to 3-9 scrum teams. Each team consists of 3 to 9 developers. Therefore, it is not recommended to be scaled to more than 9 teams and thus, not more than eighty practitioners. Nexus is a framework that you build upon Scrum but doesn’t change that foundation of Scrum. The Nexus framework adds a new role, the Nexus Integration Team, and events: a Nexus Daily Scrum, a Nexus Sprint Planning, Nexus Sprint Backlog, and Nexus Sprint Retrospective and Refinement in the Nexus framework.

Note That:

Product Owners? No, there are no Product Owners in each team. One project has only one Product Backlog and one Product Owner, to minimize complexity, and ensure that prioritization is done properly.
Each team still needs a Scrum Master, and since this role is not necessarily full-time, one person can be the Scrum Master for more than one team. However, not more than one Scrum Master would be assigned to one team.
Multiple teams should ensure that they can create a product increment with the combined skills of everyone on the team. If the team has cross-functional skills, it will be easier for the team to collaborate and create a potentially releasable product increment each Sprint.

What is LeSS (Large-Scale Scrum)?

LeSS is a framework for scaling agile development to multiple teams. LeSS comes from Craig Larman and Bas Vodde and is based on their work in the financial and telecommunication industries. The framework scales up with minimal additional process compared to single-team Scrum. i.e. use as little process as possible to get multiple Scrum teams to work well. Thus, LeSS is a good starting point when you already have Scrum in place and are just beginning to scale up with more teams, one at a time.

For Example:

LeSS recommends that multiple teams have the same Product Owner and a shared Product Backlog.
Their sprints are synchronized to the Product-level Sprint leading to one integrated Potentially Shippable Product Increment.
Sprint Planning, Sprint Review, and Sprint Retrospective run at the same time for all teams.

Large-Scale Scrum (LeSS) Structure

There is one Product Owner with one product backlog, and several teams, each with its sprint backlog. Except for the multiple teams, all these concepts are already established in Scrum, so no news here. The multiple Development Teams working on different Product Backlog Items from the same Product Backlog. Scrum Masters serve the Scrum Teams as within Scrum.

Role of Product Owner in LeSS

The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale, the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

Why One Product Owner in LeSS?

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.
In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. She acts as a connector, bringing teams and customers/users together so the teams become more customer-focused.
In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity. Simply put, you “get more with LeSS”.

Role of Scrum Master in LeSS

Scrum Masters are responsible for a well-working LeSS adoption.
Their focus is on the Teams, Product Owner, organization, and development practices.
A Scrum Master does not focus on just one team but the overall organizational system.
A Scrum Master is a dedicated full-time role.
One Scrum Master can serve 1-3 teams.
In LeSS there is no ‘manager’ role, but managers may exist and they can have a useful role.
Their focus is on the value-delivering capability of the product development system rather than the specific scope of a product.

Sprint in LeSS

There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product. LeSS is pure Scrum (time-boxed iterations, sprint planning, daily stand-up, sprint review, and retrospective), with a modification. As per Scrum, Sprint Planning is split into two parts and retrospective meeting to be conducted in two levels

Sprint Planning in LeSS

The first part is a joint meeting attended by representatives from all of the teams to agree “What” Product Backlog Items (PBIs) will be built in the coming Sprint. The second part of Sprint Planning is then used by each team to produce the Sprint Backlog and agree “How” the PBI’s will be built.

Review and Retrospective Meeting in LeSS

The end of the sprint also needs to be synchronized. This is accomplished by having one common Sprint Review for all the teams. The Retrospective is divided into two parts, similar to the sprint planning. First, each team holds its team Retrospective, then representatives from each team hold a joint Retrospective together that enables them to identify and address issues that cannot be solved at the individual team level.

What is SAFe (Scaled Agile Framework)?

The Scaled Agile Framework (abbreviated as SAFe), Created by Dean Leffingwell, is an interactive software framework that enables you to apply Lean-Agile and Scrum practices at large enterprises. SAFe is described as an interactive knowledge base for implementing agile practices at an enterprise scale and it provides a lot of guidance and covers a broad scope including financing and enterprise architecture. SAFe is constantly being improved, and its latest version is 4.5: Full Configuration consists of four levels:

Team: the fundamentals of Scrum are used at the Team layer. Cross-functional teams that work in sprints facilitated by a Scrum Master.

Program: the gathering of multiple Agile Teams (ART’s) to deliver a collection of several Product Increments (PI’s) in about five sprints.

Large Solution: we only speak of Large Solutions when a product needs to be developed by more than 150 people. This means that additional people are added to the teams to ensure quality.

Portfolio: mainly relates to leaders within the organization. This mainly concerns employees who work with portfolio management and are responsible for the strategic plans and budgets. They are designated to determine the budgets per ART.

The cohesive integration of the Portfolio Management group within the Scaled Agile Framework brings the ability to understand, and manage, cost to market. SAFe enables Lean budgeting practices for organizations to fund products. The typical financing model of funding fragmented projects will be a thing of the past.

In short, the Scaled Agile Framework differentiates between Team, Large Solution, Program, and Portfolio levels. At the Team level, SAFe® is not that different from simple Scrum extended with a few XP practices. The Program level aligns the teams to form an Agile Release Train, while the Portfolio level aligns the ART with the strategic goals of higher management.

Disciplined Agile

DA is subdivided into Disciplined Agile Delivery (DAD), Disciplined DevOps, Disciplined Agile IT (DAIT), and Disciplined Agile Enterprise.

As you can see in Figure above, DAD is one aspect, and arguably the core of DA is DAD, where IT solution delivery is defined end-to-end: from initial modeling and planning, setting up the team and securing financing to continuous architecture, continuous testing, continuous development, and monitoring during the entire lifecycle.

Building on this, Disciplined DevOps and Agile IT (DAIT) focus on the coordination of a company’s IT as a whole – shaping the development cycle, operations, support, data management, and other areas to become as effective and uncomplicated as possible.

The Disciplined Agile Enterprise results from all the prior segments – a company that can anticipate market changes and adjusts its strategy accordingly. In other words, an agile company.

DA Hybrid Toolkit

In general, Disciplined Agile (DA) is a hybrid toolkit that builds upon the solid foundation of other methods and software process frameworks. DAD adopts practices and strategies from existing sources and provides advice for when and how to apply them together. In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

The hybrid nature of this framework pulls the best elements from several proven methodologies that allow teams to follow the agile method while also tailoring it to their unique needs. However, it is not an ideal framework for organizations new to agile, because it does not provide strict enough guidance on how to follow that philosophy. An organization newly transitioning to the agile approach, Disciplined Agile might make that learning curve too steep and costly.

Which Scaling Agile Framework Should be Adopted?

Every organization is different and there isn’t a “one size fits all” approach. When deciding what large-scale agile development model works best in a particular setting, analyze the needs and constraints of your specific case. So, no matter which scaled agile approach you want to go for, there needs to be an understanding of what you need:

A simple and small-scaled agile teams option found in LeSS or Nexus
A mid-sized company solution with light weighed management of LeSS
An enterprise-scale on Agile transformation may try SAFe or Less – Huge.

They seem to be similar but there are discrepancies among them that take the form of team size, training, and certification, methods and practices adopted, technical practices required and organizational type. We should choose the right one not just for now, but for the future as well.