12 Questions to Answer Before (and after) Scaling Agile
By: Luxshan Ratnaravi
Tags: Scaled Agile, Scaled Agile Framework, Agile, Scrum, Questions

Illustration: Mikkel Noe-Nygaard

The purpose of this article: to increase the probability of your upcoming (or ongoing) scaled agile effort becoming a success, by providing you as Transformation Lead, Agile Coach, Agile Leader or similar with a list of relevant topics to discuss with decision-makers before starting your journey, so your organization bases its decision to scale on a solid foundation. The next iteration will include a canvas with room for answers and actions as well as a facilitation guide.

In order to get the most out of answering the questions, make sure to involve the right people, such as the transformation sponsor, an (enterprise) agile coach, a couple of Scrum Masters as well as a business, technical and management representative, respectively.

Here’s the process:

An initial question

Scaling is not a goal in it self, but a means to an end. It comes with an overhead cost of managing the scaled setup, so it is potentially more effective not to scale. Therefore, answering this initial question can prove crucial:

1) What challenges can you not solve without scaling?

The purpose with this initial question is to frame your ‘why’ of scaling and should be your justification for investing in the overhead of it.

Three open-ended questions

Then, we want to reflect on our whole reason to scale, our means of doing it and how we will measure whether we are on track after scaling.

2) What is our goal with scaling agile?

3) How can an existing scaling frameworks help reach our goal? Or should we rather cherry-pick elements from the different frameworks?

4) What are the leading indicators of whether our chosen scaled agile setup is (still) solving our challenges?

Example: Answers to question 4) could be ‘A reduction in the number of teams that are dependent on each other to deliver PBIs’ or ‘An increase in how much of the program/product backlog that each team has the competencies to deliver’.

Eight closed-ended questions

Afterwards, you want to pre-identify any missing alignments, differing expectations and surprises that might appear once you start scaling. To do that, answer the following seven questions:

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 key stakeholders agree that the benefits of scaling are greater than the overhead of it?

Answering these 12 questions will give you a very good idea of the why, what, how, who and when of scaling, so take your time in the group to cover each of them thoroughly. Remember that it’s not necessarily the goal to convert a ‘no’ into a ‘yes’ — it all depends on your organizational context.

Download a condensed PDF with only the 12 questions here.

Should we not scale if we answered ‘no’ to a question?

At least, not before understanding the consequences of your ‘no’s. Answering ‘no’ to one or more of the questions does not necessarily mean that you should not scale; rather, it’s a pointer towards the risks for you to manage or a trade-off for you to assess before embarking on your scaled agile journey. Start by asking why it’s a ‘no’ — and whether it even should be a ‘yes’ — and then, how to make it a ‘yes’.

Example: You answer ‘no’ to “Have we tried to remove the dependenciesbetween our teams?”, so you take an informed discussion with your teams, agile coaches and leadership on whether you should remove the dependencies, and how you can do it. It quickly becomes clear that it will require reorganizing the teams, so you initiate this work while keeping your scaled setup.

What if we are already on a scaled agile journey?

Still ask the questions. Potentially, it can help you assess if you should optimize your current setup, move to a different scaling framework, remove a team or two from your setup, or even descale your organization.

Example: You answer ‘no’ to “Can we align all involved teams on a relevant andcommon vision, roadmap and program/product backlog?” because of one specific team that does not find the vision or roadmap relevant to their work, as only this team always only implements a specific type of PBIs that are not relevant to the other teams. This could be a call to action to either remove them from the team of teams or share their competencies with the other teams.

What do you think?

Remember that there are nuances of grey; it’s not about either scaling, not scaling or descaling. It’s about taking a pragmatic approach to solving your challenges and meeting your goals. Maybe, cherry-picking elements from different scaling frameworks is the right approach for your organization?

What is your opinion? Do you have a better approach to all this? Maybe, you’re much more in favor of descaling? Let’s hear some experiences and advices in the comments below.

Download a condensed PDF with only the 12 questions here.

Thanks for providing feedback on the content of this article to Leise Passer Jensen and Martin Nymann Vinther.

This is my first article in a series about scaling and descaling agile. So, even though I don’t provide all answers or elaborate on all details here, there’s a big chance that I will do it in another article.