Because one of the limitations of standard agile methodologies is that they are designed to operate primarily at a team level, scaled agile has seen a recent boom in popularity. This is because it uses several core values and principles to align cross-functional teams throughout a large organization, and is therefore more appealing to larger companies. However, it does this without losing the key benefits of agile methodologies such as speed and focus on customer feedback. Keep reading to learn more...
As the name implies, the primary difference between our traditional agile methodologies and this scaled agile framework is the size of the organization that each was designed for. Agile was largely designed with relatively small teams working on a specific project, while scaled agile is designed with enterprise-level organizations in mind.
When it comes to the foundation of scaled agile, it’s built on four core values. Everything within the framework comes back to alignment, built-in quality, transparency, and program execution:
Built on these core values are the nine principles that scaled agile follows. These apply to processes, but also extend to intangible factors such as knowledge and motivation:
Using these core values and principles will help your organization adopt and implement scaled agile practices and framework, setting you up for success.
But why should you consider a scaled agile framework for your company? As mentioned earlier, agile methodologies such as eXtreme Programming and Scrum were originally designed for small integrated teams of approximately 5-10 people working together on a single solution or product. As the benefits of agile methodologies (early feedback, continuous integration, seamless communication, and cross-discipline teams) have become apparent to larger organizations, there is a need to scale agile from its original roots to support larger initiatives and programs.
If you consider a typical cross-functional agile team, you will have developers, UX/UI designers, and testers (automated and manual). You may also have other specialized roles (e.g. database administrator (DBA), security engineer, performance engineer, etc.) depending on the nature of the project.
In the middle you will have the product owner who works with the customer to understand the requirements (user stories, etc.) and the scrum master who is focused on the team and its operations. This arrangement works well for a single team, working on a single independent system or project.
The first step up in terms of scaling agile is the ability to have multiple teams working on either different modules of a larger, integrated system (called a product), or multiple different projects that have a common set of business objectives (called a program).
In the case of a program, you will have multiple Scrum teams that work on different projects, with a Program Management Office (PMO) in charge of coordinating the different teams that comprise the program. If you have a single, large, integrated project/system, then it would be a Project Management Office instead. Please note that although the same abbreviation, PMO, is noted for both Project Management Office and Program Management Office, their role and responsibilities are not the same.
Next, you may need to coordinate the development and release of multiple separate products (or programs). These often have interdependencies, shared resources, elevated risk dependencies, and associated governance for decision-making, or simply a common organizational reporting structure. For example, you might have one executive in charge of the rollout of a new online banking portal, mobile banking application, and related marketing updates to the website.
This grouping of products and programs is typically called “a portfolio”. Project Portfolio Management (PPM) is the centralized management of the processes, methods, and technologies used by portfolio, program, product, and project managers. They use this to analyze and collectively manage current or proposed projects based on numerous key characteristics.
PPM provides portfolio, program, and project managers in large, program/project-driven organizations with the capabilities needed to perform integrated change control while managing the time, resources, skills, and budgets necessary to accomplish all interrelated tasks. It provides a framework for risk mitigation and issue resolution, as well as centralized visibility to assist with planning and scheduling.
The next level of scaling agile, is to the entire enterprise, with the agile teams working in product groups and/or programs, organized into portfolios. This enables the company to deliver on its strategy and business objectives, while supported by the infrastructure, culture, and core values of the organization.
In this context, the agile teams will be providing high-level metrics and key performance indicators (KPIs) to the executive team of the organization. Not only that, but they will provide equally important metrics to supporting shared services such as IT, HR, marketing, staffing, and customer support, so that the entire enterprise can deliver on its promises.
For example, knowing that a specific feature is on track for release by a certain date will impact the marketing of that feature, the training of customer support agents, upgrades to IT infrastructure, as well the ability to meet company financial targets.
Finally, the ultimate scaling of agile development is when multiple organizations are interconnected to form a “software supply chain.” This could include software features, requirements, and feedback being shared backward and forwards between companies that make products, their suppliers, customers, and subcontractors.
In this context, the supply of value from idea creation to product delivery is no longer restricted to the organization itself. One company is a supplier of products that are used as a component in the product of its customer, sowing the seeds for “value co-creation.”.
There are a number of different ways that companies implement a scaled agile approach to their development. While the most common and most well-known is SAFe, there are other useful variations that are worth discussing as well.
The most common implementation of scaled agile is the SAFe methodology. The Scaled Agile Framework (or SAFe) is a software development framework that takes the concepts of agile development and provides a “larger picture” methodology that allows you to use agile approaches across an entire enterprise.
(Image is Copyright Scaled Agile Inc).
SAFe comes in four main configurations, for use in different contexts:
For more information on these individual SAFe configurations, see our guide here.
Large-scale Scrum (LeSS), as the name suggests, is a product development framework that extends Scrum with scaling rules and guidelines without losing the original purposes of Scrum.
(Image is copyright The LeSS Company B.V.)
There are two levels to this framework:
The intention of LeSS is to “descale” organization complexity, dissolving unnecessary complex organizational solutions, and solving them in simpler ways. Fewer roles, less management, less organizational structures.
Some key features of LeSS that distinguish it from some of the other scaling approaches:
Typically, LeSS teams are organized into groups that have one owner per product, with multiple feature teams under the single product owner. Each of them will have its own scrum master.
SpiraPlan includes easy-to-use product, release, and sprint boards that let you see all of the features and defects planned for each feature team in the product backlog.
The scrum of scrums is another technique to operate Scrum at scale, for multiple teams working on the same product. It allows them to discuss progress on their interdependencies, focusing on how to coordinate delivering software, especially on areas of overlap and integration.
Depending on the cadence (timing) of the scrum of scrums, the relevant daily scrum for each scrum team ends by designating one member as an ambassador to participate in the scrum of scrums with ambassadors from other teams. Depending on the context, the ambassadors may be technical contributors or each team's scrum master.
The SoS framework typically is employed at multiple levels, and within a platform like SpiraPlan, you have two main approaches you can follow:
SpiraPlan makes this approach especially fluid with its support for multiple levels of releases and sprints, each of which can roll up its progress and metrics to higher levels:
Nexus extends Scrum to guide multiple Scrum Teams on how they work together to deliver working software in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies.
(Nexus™ framework diagram is copyright Scrum.org)
Nexus is a simple framework that can be applied to 3-9 scrum teams who are working in a common development environment, and are focused on producing a combined increment every sprint with minimal dependencies.
The core of the Nexus framework is the Nexus Integration Team which consists of a Product Owner, Scrum Master, and one or more members from each Scrum team. SpiraPlan provides the perfect tool for managing the individual Scrum teams and the Nexus integration team with its support for product backlogs, multiple releases per product, and program-level backlogs.
Now that we’ve looked at the reasons for scaling agile, as well as the different levels in which it can be scaled, what tool should you use to implement it for your organization?
The top reasons that our customers choose SpiraPlan over other solutions are:
In addition, we provide superb technical support that ensures that enquiries and questions are dealt with in a timely and professional manner.
To learn more about SpiraPlan and how it can improve your agile software development processes please:
And if you have any questions, please email or call us at +1 (202) 558-6885