By now, probably everything has already been said and written about agile software development and scrum. But it’s different with its bigger — albeit younger — colleague, SAFe, or the Scaled Agile Framework. This methodology is already quite popular, but because it is intended for the largest of the largest (both projects and organizations), its practitioners are fewer in numbers than experts operating daily on the basis of “ordinary” agile methods.
SAFe was born 10 years after the Agile Manifesto. It was based on the assumption that the ongoing digitization will make everyone — including large global companies — start to develop software sooner or later.
Agile is a standard now for companies whose core activity is software development, digital transformation, or data management. But still, in many large global corporations we continue to encounter a certain conservatism with regard to agile, and our activity has a significant educational aspect.
It is the same with SAFe.
I am writing this text to help company managers realize that their organizations must get ready to work in accordance with scaled agile. More — they must have people in their structures who will take on specific roles that SAFe requires.
Agile programming methodologies have been designed for teams of several people. Scrum roles, events (ceremonies) are planned for, and carried out, in relation to a single team focused on a specific project. But what about projects involving entire ecosystems of enterprises, numerous solutions and applications, data lakes fed from multiple sources and used at many levels of the organization? With dozens, even hundreds of people needed to work on the project, many corporate projects go far beyond the possibilities of the original agile.
SAFe is actually a superstructure of new roles and ceremonies built on top of the classic agile (more about these roles and ceremonies later). It combines Scrum, Kanban, Lean Product, Lean UX and DevOps. While it should be noted that SAFe is not the only methodology available on the market to support large-scale software development, it is the most widely adopted one. According to data from Scaled Agile, Inc., which in 2011 released its methodology version 1.0, 70% of Fortune 100 companies and a growing number of the Global 2000 have certified SAFe professionals and consultants on-site, and over 700,000 practitioners have been trained to date.
Big projects, big success stories
SAFe has many success stories to its credit. I truly recommend that you visit the Scaled Agile Inc. website where you can familiarize yourself with them. For example: thanks to SAFe, the Dutch Tax and Customs Administration delivers major releases 3 times more often and has reduced its technological debt by 80%.
It is also worth paying attention to the case of the pharma industry (sorry, professional bias, I specialize in projects for this industry), in which Astrazeneca summarizes the effects of SAFe implementation, claiming that thanks to this methodology it observed substantial financial benefits delivered in the first year, significantly faster time-to-value delivery, reduced team sizes and improved the quality of outputs over previous solutions.
Another giant, this time from the financial sector, Nordea claims that thanks to SAFe their software development process increased efficiency with team members aligned and working together, while at the same time their creativity increased, as teams are empowered to make decisions.
Superstructure: new roles and ceremonies
SAFe adds a structure to agile, which is built of additional roles and ceremonies. Its task is to coordinate the work of many agile teams, in development streams and between them, while maintaining the agility of their functioning and all standard ceremonies. Yes, there are new roles, but the old ones do not disappear: there is a Product Owner and his backlog, there is a Scrum Master and the usual scrum events (or ceremonies, if you prefer).
SAFe adds new levels: program, solution and portfolio. Each of these levels has new roles. This additional layer of roles allows you to create the team that makes up the Release Train: a continuous process of agile software development (Continuous Delivery Pipeline).
For more information on roles and events, consult specialized sources. Overall, on the team level, as I mentioned, nothing changes.
When we enter the program level, SAFe Architects, Product Managers, Release Train Engineers and, last but not least: Business Owners appear. The situation is similar at the level of large solutions and the portfolio.
Roles up for grabs
Note the two roles: Release Train Engineer (RTE) and Business Owner (BO). The first one is like a Master of Scrum Masters — an RTE coordinates scrum events at the Release Train level, coordinates individual teams, keeps an eye on the release calendar and its synchronization.
They embrace the whole.
Working on a suite of digital solutions to support manufacturing operations of one of the COVID-19 vaccine manufacturers, we provided entire agile teams, architects, devops and scrum masters. Our client wanted to hold the vision in his hand and have a real impact on when, where and how the Release Train will arrive and reserved this position for themselves. SAFe perfectly fits here with its roles and the split of responsibilities — the key client roles in this scenario were Product Owner and Business Owner.
Business Owners are a group of stakeholders who are responsible for governance, compliance, and return on investment (ROI) for a solution developed by the Release Train. Their importance grows with the importance of the role played by governance and compliance in the client’s operations.
In regulated industries — such as the aforementioned pharma producing a vaccine for which we work based on the SAFe framework, Business Owners play a key role in helping the Release Train deliver value and are always representatives of the client.
Obviously, the Product and Solution Manager are also on the customer’s side. As a link between the market and the product, their role is to lead not only to the delivery of the product or solution, but also to the deployment at internal customers or on the market.
SAFe itself was founded because everyone makes software — regardless of their business profile. Digital transformation continues and involves large organizations with a global scale of operations. A large-scale approach is needed in such companies. While SAFe methodologies obviously should be known to IT service providers, also competent people should be found in the client organizations themselves.
Every now and then we start new projects based on the SAFE. It presents managers with many challenges, especially in the initial stages of the project. We plan to share our experiences and publish another article about the SAFE methodology — this time focused on what should be taken when launching a project on a large scale.