Many experts have previously written about the challenges seen in the market when scaling agile using official frameworks. Doing a simple job search online, I find a steady increase in the number of postings for agile jobs as Scrum Master and Product Owner but also for some of the more debatable titles as Release Train Engineer, SAFe Program Consultant and Product Manager. This trend underlines the importance of understanding the mechanics behind the frameworks but also the consequences of introducing them in an organization. The result can be festive and colorful like fireworks, but without safety goggles and proper handling it is easy to get into trouble.

Luxshan Ratnaravi who is an agile coach with Bankdata in Denmark, has made a list of questions that could be answered to determine if agile scaling is the right solution – and if you should use an official framework:

1. What challenges can we not solve without scaling?
2. What is our goal with scaling agile?
3. How can an existing scaling framework help reach our goal? Or should we rather cherry-pick elements form the different frameworks?
4. What are the leading indicators of whether our chose scaled agile setup is (still) solving our challenges?
5. Are our existing agile teams sufficiently mature for us to scale?
6. Have we tried to remove the dependencies between our teams?
7. Will we organize our team of teams around a value stream that is relevant to all teams?
8. Can we align all involved teams on a relevant and common vision, roadmap and program/product backlog?
9. Are the involved teams better together (define ‘better’ as you wish) as a team of teams than separately as individual teams?
10. Should the involved teams work as feature teams with a collective program/product backlog?
11. Will we prioritize the high-level PBIs across all involved teams, their products and competencies in order to enable team swarming?
12. Do our stakeholders agree that the benefits of scaling are greater than the overhead of it?

These questions are extremely relevant and should be part of any decision on agile scaling. In addition, it is my opinion that agile scaling is temporary mitigation of shared impediments. And what does that mean? It implies that introducing e.g. SAFe should be a temporary solution to the shared impediments found by answering the 12 questions above. In the course of time, the organization should reduce the need for shared goals, visions and road maps with a target condition of having independent self-managing agile teams.

It is important the stress that no matter which framework – or no framework – you chose for scaling you must have deep understanding of the mechanics behind. A success requires experience with the frameworks, knowledge of the organization and an ability to implement and facilitate the change. This is typically solved in a strong coalition between external specialists and internal employees and internal managers. No change can be implemented solely by external specialists with the hope of creating sustainable change in the organization. It requires a change of organization, employees, ways of working and delivery model.

The most common framework for agile scaling is SAFe. This framework provides a silver bullet for transforming an organization from plan driven development into iterative and incremental development. The silver bullet is called “SAFe Implementation Roadmap”. As you know, there are no silver bullets, and nothing is as easy as a text book prescribes:

• The implementation roadmap can be seen as the only route from A to B and this rarely the case. This roadmap is written based on certain observations in other organizations and your organization might differ and need another approach
• Without knowing the mechanics behind you may end up introducing roles, events and artefacts without achieving any improvement. Experience shows that simply changing the job titles will not make people act different. They need help
• Without knowing the organization and products you may introduce teams, team of teams and portfolios that doesn’t add value. Most organizations have already introduced teams in various shapes: some are adapted to the system landscape others by competencies. If you do not re-organize around products and value streams the change will have no value
• A framework is perceived as the one source of truth and adaptions within the team of teams is considered a dysfunction. The events and artefacts have a purpose to consider, however the format and details will vary from organization to organization
• The most dangerous part of a framework is when you apply the mechanical elements without doing any real changes in your organization: the layers of a framework can swiftly be translated into traditional stage-gate plan driven organization which is not the intend and will certainly not add value to you

 What are the highlights of applying an implementation roadmap and a framework?

• The roadmap underlines the importance of training and recruiting skilled employees and managers in all functions. It is important to have understanding, ownership and motivation in all involved in the change. This applies to employees working in a team along with managers, customers and other stakeholders
• The roadmap shows that there are many artefacts, people and considerations to be handled in order to gain full value of the change. They must all have good guidance and training to understand the change
• The roadmap emphasizes the importance in having change agents to aid the understanding of the framework and translate it in a way that is producing more value than the starting point. A change does not happen overnight. It has proven valuable to have a team of skilled employees and managers responsible for translating from idea to concrete actions
• The framework specifies roles that are recognizable in job posting a cross organizations. This gives employees an idea of what the job entails when hiring and training. This is a positive benefit in opposition to self-invented roles such as Chief Product Owner Team Lead or similar
• The framework can be used as a starting point for collaboration between teams with a goal of becoming between than before

Bottom line: It’s crucial to wear safety goggles when applying an agile scaling framework – otherwise you may end up with permanent damage and a gut feeling of improvement that is not real.

Feel free to contact me at rasmus@ugilic.dk or write your thoughts in the comments. I am happy to answer any concern you may have. 

This article was originally published in Danish on LinkedIn. Click here to read it.