Scaling Agile appears to be a theme. At times, I am wondering how many organizations there actually are that would adopt large scale Agile to start with. Currently, I have the impression there are as many scaling frameworks out there as participants that joined a casting show. But I am exaggerating at bit here. With all these frameworks out there, how do you pick the right one for you? Or should it be a mixture of all of the frameworks available? While diving deeper into scaling frameworks, I found some considerations at picking the right one fruitful. Here they are.

Retrospectives

Usually when I start evaluating a framework, I am starting with the most important thing in any agile adoption: the retrospective. The retrospective is a core practice. Indeed all other practices and principles can be derived from a working retrospective.

That said, when I evaluate a framework, I jump to the retrospective part first. What’s described there? How many different variations of retrospectives are recommended? Is there a pointer to literature on the topic? What particular phases are mentioned? What do the authors recommend for a large-scale distributed retrospective?

In my experience a simple retrospective format that focusses on what went well, and what didn’t work so well, does not work in the long run. Over time participants will leave the retrospective with the feeling that nothing is changing, and everything is becoming more and more terrible to work with. I am guilty of facilitating a couple of such retrospectives on my own. If the reader could be left with the impression that there does not need to be someone driving forward the actions identified in the retrospective, the retrospective format is likely to miss the point. If the reader is left with the impression that the ScrumMaster or Agile Coach takes all the action items with her, then the retrospective will not be leading to a self-organizing team, rather one that the ScrumMaster or Agile Coach is organizing. This is a sure way to a symbiotic relationship between the team and the ScrumMaster or Agile Coach. And it’s a sure way to self-organization failure.

Retrospectives are the place for the team to inspect and adapt their working process. They own the process, so they are the ones in charge for changing it. That means that team members should take action items with them into the next planning meeting and iteration.

On a larger scale the inter-team process also needs to have an inspect and adapt process. Is something mentioned in your framework about that? Who is participating in this larger retrospective meeting? Who will be in charge to move forward with the current process? These questions should give you some clues on the level of empowerment behind the particular framework that you evaluate.

The basis

The next thing I look for lies in the basis for the framework, and which Agile methodologies are described. The agile umbrella describes a couple of methodologies. Some of them are still in use 13 years after the original authoring of the agile manifesto. Others almost have disappeared.

For sure, no scaling framework needs to address all the methodologies that were around since 2001. A good scaling framework would recognize those methodologies that are widespread together with those methodologies that are helpful. To date, and in my experience, that would include the project management framework of Scrum, the technical practices from eXtreme Programming, and – maybe – the portfolio and support approaches from Kanban.

But there is more. Underlying successful implementations of Agile lie principles. If these principles are not understood, then single- and multi-team adoption of Agile is certainly going to fail. Alistair Cockburn has written about a couple of these principles in his Agile Software Development – The Cooperative Game. Other principles include systems thinking, queueing theory, beyond budgeting, and Lean thinking.

There are probably more which I am not aware of. When evaluating a framework, right after the retrospectives, go to the underlying basics. If these are not mentioned, you are likely to do a poor job of applying the framework, and its intended principles. Even if it comes with “best practices”, you are likely to miss the intention behind those practices, and might drop some which are crucial to success.

Scaling of key roles

After the retrospectives and the basis for scaling makes sense to me, I start to take a closer look into how key roles are scaled. How many ProductOwner do we need? How many coaches, ScrumMasters? How are legacy structures like architects and testers dealt with?

These questions are crucial when it comes to size. Some might claim that you shouldn’t scale any product development. Some might say that you need more managers. How do you know which one is true?

When it comes to agile software development, I have seen large organizations with manager ratios between one manager for 50 people and up to three managers per developer. If you need three managers to coordinate the work of one developer, then I would claim there is something wrong. Figure a road worker where three people tell him what to do. I don’t see how this is going to work effectively – and surely not efficiently.

Self-organization is a key concept in agile. That said, ProductOwners, coaches, and architecture and testing should work in self-organized groups. They should coordinate to evolve a common vision for the speciality. And they should work with their teams to improve that vision.

What’s the source?

Finally, I seek the source of the scaling framework. How often has this actually been implemented? How successful was the scaling approach in the long run? What about the market that organization falls into?

I suspect that “this one worked once here” methodology is something that you want to try with your large organization. If I were in charge of a large organization, maybe responsible for 500 employees, I would also look for success stories of the framework in question. How long is the reported period of time? When investing money to transition 500 people to a new methodology, I want to be sure enough, that it worked on a timeframe of at least seven years. I don’t want to tell half of my staff that I made a terrible mistake with that transition in five years just because I did a sloppy job of research today.

Also, take a closer look at the original companies where the framework comes from. How successful are they in their market? Did they go out of business? Did they miss important market windows lately? All of these questions could indicate that these companies are not as agile as they claim to be.

A Simple Framework Evaluation Framework

Retrospectives, underlying principles and values, scaling of key roles, and the origins – that’s all I need to dive into to come up with an opinion about a scaling framework. Thus far, it has not failed me.

A final piece of caution: though Jerry Weinberg points out in Becoming a Technical Leader that one path to innovation lies in copulation – that is combination of two successful ideas – cherry-picking some practices from one framework and another does not result in copulation. That would be more like taking an arm from one body of knowledge, and a leg from another one. If you miss to take the head and the heart, you will probably end up with Frankenstein’s monster.