Hi everyone,
Now that we covered agile ways of working at a team level, how might you expand to deliver larger and more complex products. Previously, you most likely ran large programs through "waterfall" - planned projects with detailed and complex project plans, program managers, project managers, developers, testers, etc. But we haven't really mentioned any of these roles or artifacts in our introduction to agile and we will continue to not mention these terms as we move forward. I am about to introduce you to a few options for addressing larger, complex initiatives where scaling may be of interest.
Credit: jile.io
This picture does a really nice job of depicting the popular options for scaling: SAFe - Scaled Agile Framework, DAD - Disciplined Agile Delivery, LeSS - Large Scale Scrum, Nexus, Scrum of Scrums (SoS) and one not listed here is Scrum at Scale. To me, SoS is more of a practice or technique rather than a methodology or way of working, but it does provide an approach to scaling multiple teams as well.
Source: www.productfocus.com
The picture above depicts the market share from surveys in 2020 for how companies are approaching their scaled agile transformation. While Scaled Agile (SAFe) clearly holds the largest segment, interestingly, the next largest is "Don't know / other". I have encountered several companies that are creating their own approach to agile implementation or scaling. Typically, these companies are following a scrum based approach with modifications to meet their particular needs or alternatively, they sometimes think they can deliver better by implementing their own approach. Sometimes, companies create their own to avoid expenses related to license fees or bringing in specialized resources for training. To be honest, I think this is a bit shortsighted, but that's just my opinion.
Let's provide some insight into a few of these. I will cover SAFe, Scrum of Scrums (SoS), Disciplined Agile Delivery (DAD), and Large Scale Scrum (LeSS) since these are the most well known of the scaled agile approaches.
Starting with the Scaled Agile Framework otherwise known as SAFe. There are two websites where information can be found: 1) www.scaledagileframework.com - this site starts with the "big picture" of the framework and is an interactive site where you may click on an item and it will bring you to detailed information on that particular topic 2) www.scaledagile.com - this site will provide information regarding scaled agile, and course details and description of the various certifications. You may also visit course descriptions and schedule on www.agileadvancement.com
SAFe currently has the largest market share and a significant number of Fortune companies are utilizing SAFe practices in their scaled agility. I look at SAFe as a framework that is meant to be utilized as a framework. This means to adjust and adapt pieces of the framework and practices to meet the needs of the company. As a coach and consultant, this is a large part of my approach. Meet the client where they are at in their transformation, assess, listen, learn, and then coach on how to improve practices and value delivery by adjusting the framework.
Many will argue that SAFe is "disguised waterfall" or has an enormous amount of overhead. From my perspective, this depends on how it is implemented. The idea is to be lean with reduced overhead while maintaining strategy, execution, guardrails, and transparency. In a future blog we will discuss why agile and scaled agile implementations fail.
Scrum of Scrums (SoS) is a way to scale scrum for multiple scrum teams. An SoS is often a meeting of scrum masters from multiple teams on a regular cadence to align, discuss issues and dependencies and how to work together to deliver value as quickly as possible. The SoS often has a backlog of its own on how to improve as well as the work to be completed from an SoS perspective. Information and articles on the SoS may be found at www.agilealliance.org
Also, the SoS acts as a communication vehicle across a "program" or many teams working to delivery a complex solution. This team is responsible for helping deliver a fully integrated product at the end of every sprint and help ensure customer value is delivered as committed by the teams. The SoS is usually a scrum team with a chief product owner role and a something similar to a chief scrum master. The team acts and follows the same process as the other teams and as defined in the scrum guide. Additional information may be found at Scrum of scrums | Atlassian
Like all approaches, done properly, SoS is lean with minimal overhead while still providing a collaborative communication vehicle while allowing for quick delivery.
BREAKTIME:
https://www.reddit.com/r/ProgrammerHumor/comments/88ywbp/agile_development_in_a_nutshell/
Full transparency: I have not worked with Disciplined Agile Delivery (DAD), but felt it was important to be aware of this approach as it is often discussed as an option when deciding how to scale. The Project Management Institute (PMI) defines it as a people first, learning-oriented, hybrid agile approach to IT solution delivery.
When looking at the Disciplined Agile (DA) toolkit, it's a little overwhelming, although I have to admit a cleaner diagram and less intimidating than the first time looking at the Scaled Agile Framework. But I wonder, how can DA address all of these items and still be lean and effective.
Similar to SAFe, DA provides choices. It is not meant to be prescriptive, but identify what makes sense for your situation. It is a goal driven approach and one needs to know what are the goals and what are the trade-offs when using DA. Overall, DAD appears to be well documented with plenty of guidance and support as needed and may be integrated with approaches and does not need to be standalone. This may be a good option to explore further when deciding how to scale.
For more information on DAD: Why Disciplined Agile Delivery (DAD)? (pmi.org)
Finally, Large Scale Scrum (LeSS) appears to becoming more popular lately. Similar to SAFe and DAD, LeSS has a website with an interactive framework at Overview - Large Scale Scrum (LeSS)
LeSS is starts with Scrum and builds upon the single agile scrum team when scaling. The objective is to start with one scrum team and as you "build" or scale to multiple scrum teams, identifying how to do that while remaining within the constraints of Scrum.
I like the idea of LeSS because most everyone is familiar with standard Scrum. Utilized properly, LeSS is lean and uses concepts and rules where everyone has familiarity. As with all frameworks, LeSS is as good as the implementation. It is meant to be lean, but could turn out to have plenty of overhead if not handled appropriately. I recently helped with a transition to what I consider a LeSS approach although it was more of an informal change as we did not call it LeSS, have LeSS experts to help, but many of the events, practices, and rules are LeSS related. More info may be found LeSS Framework - Large Scale Scrum (LeSS) A friend of mine is a highly respected LeSS trainer. If interested please contact me and I will put you in touch with him.
You are now familiar with the primary approaches to scaling agile. Until next time, Sprint Ahead