Agile methodologies date back to the 1990s and really began to pick up steam in 2001 with the introduction of the Agile Manifesto used primarily for software development. Since then agile has grown in popularity and organizations in a variety of industries have seen the value it can bring across the enterprise to all functions and teams, not just within IT. This is the first blog in a three-part series in which we will explore scaling agile in further depth.
Agile is a collection of tools and delivery frameworks that organizations can utilize to increase the speed and reliability of results from projects. For instance, agile can be used to manage a recruiting pipeline, run a marketing project, deliver software, or any other initiative that requires teams executing and delivering work. Historically agile focused on small teams working on individual projects.
By scaling agile, multiple project teams can come together or involve different parts of the organization. There are many frameworks specifically designed to address scaling, along with the pros and cons based on the desired outcome. Some of the frameworks include: Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS), and Scrum of Scrums.
Why would you need scaling?
What drives an organization to a scaling model anyway? Having multiple teams isn’t necessarily a reason for scaling. If teams are not dependent upon each other, or interact in any meaningful way, then scaling isn’t needed. Scaling agile requires change. If an organization isn’t interested in changing HR practices, compensation plans, organizational structures, and ways of working, then it may not be a good candidate for bringing agile to the rest of the organization.
So, why scale? Let’s consider two main scenarios: teams working together and organizational agility.
1. Teams working together
Ask yourself or your teams the following:
- Are we working from the same backlog of work items?
- Do you depend on the work I’m doing to do your work?
- Is there potential that we could be working on the same things?
If the answer is yes to those questions, then a scaling model could be valuable. Likely you’re feeling the pain of coordination, communication, and planning which are strong indicators that a scaling model can be helpful.
2. Organizational Agility
Ask yourself or your teams the following:
- Is your organization interested in agile outside of the technology group?
- Does your executive leadership team support the idea of evolving the organizational culture?
- Is there an appetite for the long-term process of changing the way the organization thinks about work?
If the answer is yes to those questions, then you may be in a good place to begin the journey to organizational agility. Likely your organization is looking for solutions that will help it manage and execute work more quickly and flexibly across the board, as well as evolve your culture to one of empowerment and engagement.
Do you actually need Agile Portfolio Management instead?
If it is difficult to identify what to work on or prioritize, then scaling might not be required. Some of the scaling frameworks include Agile Portfolio Management, but some do not. If this is the only component needed, then it will be important to choose a framework that includes it or just look to that as the solution.
Agile Portfolio Management is the process to identify, prioritize, and manage the work. Within this process, the focus is on the value delivered instead of the cost of the work. It’s about maximizing the opportunity cost in order to increase the return on investment. However, both Scaled Agile and Agile Portfolio Management increase involvement, flexibility, and transparency for a company’s initiatives. These are important attributes to support the innovation which is often a key goal of enterprise initiatives.
In our next blog in this series, we will discuss popular scaling frameworks. Or skip right to the last blog in this series where we review how to successfully roll out agile.
