Agile@Scale for Dummies: what’s the matter?
Nowadays, Agile is BIG
Today, I’d like to explain in layman’s words all the fuss that is going around Agile at Scale or Agile@Scale.
Truth is, there is more to it than buzzwords. It simply is not easy.
What does “at scale” mean?
Let’s say that a company is trying to address big problems in a contained amount of time. That means that the problems can’t be solved by a single team. As a result, the company sets up several teams to work on the same big problem, at the same time.
This is called scaling because the company is trying to scale its own size to fit the size of the problem, typically through the number of teams.
Why scaling?
Scaling a company is a choice. It is not mandatory. Companies could also choose to keep their problems small and thus to keep their size down. Basecamp is a company well-known for doing so, and their owners Jason Fried and DHH have written several books about it.
Yet most companies choose to try to solve bigger problems because bigger problems usually means bigger revenues. Because companies are chasing after bigger revenues, they then have to solve bigger problems. And thus, those companies have to scale up in order to solve the bigger problems and to get the bigger revenues.
Is Agile at scale hard?
Short answer :
Agile is hard, scaling is hard, Agile at scale is super hard
Agile is hard… in this kind of company
To be precise: Agile is not always hard, it actually depends on the environment… But I think we can safely assume that the kind of companies that choose to scale are probably the kind of companies where Agile is hard.
Why am I saying that? Remember the previous section: companies that try to scale are chasing after revenue. They are not chasing after an awesome user experience nor are they chasing after a great environment for their workers. Focusing on the user experience and on the worker environment are typical of an Agile-friendly company. On the other hand, chasing after revenue without taking these elements into account can be very destructive.
So, yes, Agile is probably hard in this kind of companies.
Scaling is hard… or at least very costly
Scaling is not easy because by definition it introduces coordination between several teams.
At the very least, scaling is very costly:
- The bigger the teams, the more time and effort are wasted in communication into the teams
- The more teams, the more time and effort are wasted in communication between the teams
In other words, the more people, the less each people is productive.
And of course, all these people must be paid. While people are less productive, they still expect to be paid the same.
Why is Agile at scale super hard?
Let’s dive into more concrete stuff that explains why mixing Agile (some hard stuff) and scale (more hard stuff) gets super hard.
Scaling exacerbates all the problems
When an organization scales, all the problems that the organization already have become even more problematic.
Problems get amplified and what was a bearable workaround becomes an intolerable situation.
Some examples:
- Let’s say that non-regression testing is not automated. When the team is small, keeping running these tests by hand is a waste of time but yet it can be tolerated and you can actually go very far with just manual testing. As the company grows and puts several big teams on the topic, it becomes simply impossible to keep running the tests by hand. What was an inconvenience becomes a critical issue that can bring the whole company to a halt.
- Let’s say that the product backlog is not very well maintained. When the team is small, their members get to find the information and to prioritize things at the last possible moment. It is common to lose some time getting out of the flow to get information that should have been already made available, but it kinda works. As the company grows and puts several big teams on the topic, the not-enough-maintained product backlog becomes a major pain point: teams can’t synchronize with each other if they don’t have a proper product backlog.
- And so on…
Big money usually make people risk-averse
Remember the situation:
- The company wants to make a lot of money
- Hence the company creates a lot of teams to be able to create a lot of value quickly and thus make a lot of money
- From a money perspective, this could be seen as an investment, or even a bet: you put money on the table with the hope that it will grow bigger
- In the end that’s a lot of money that is invested, so the investors (the famous stakeholders) are concerned with the risk they are taking
Hence the many Agile at scale frameworks: SAFe, LeSS, DAD, Nexus, Scrum@Scale…
Why all these Agile at scale frameworks? There is no doubt that there is a lot money to be made by helping big corporations getting Agile across the whole company.
And of course, a framework is giving the illusion of a reduced risk. Like, we have a plan to follow. Or, there are testimonies of the framework working elsewhere.
The big problem with such frameworks used in such contexts is that, even through frameworks are definitely helpful, they are more like toolboxes than full-integrated, ready to deploy solutions.
Too often, these frameworks are sought (and sometimes sold) as ready to go. The result is a big dissonance between expectations and reality.
Finding the good organization model is not obvious
Focusing on the framework is like focusing on the sculpting tool, rather than on the piece of art. The good sculpting tool depends on which part of the sculpture is currently worked on…
The good organization model for a given company is specific to this company.
To be more precise, the only model that truly works in a sustainable manner is to be a learning company, reshaping itself over and over again.
As you can guess, getting there is no easy feat.
What are the various Agile at scale “models”?
To end this article, I’d like to do a non-comprehensive tour of Agile at scale models, frameworks and ways of doing.
Please note that I am doing my best not to judge the relevance of these practices. My goal is to give you some background about what is doing the industry, not to assess if they are a good option or not.
Likewise, please do not assume that just because a lot of companies are doing it means that it’s a good practice.
Discovery and delivery as two different pipelines
What’s discovery and delivery?
- Discovery is about finding a market/product fit, about UX research, about learning about the customers and the market… The outcomes are learning.
- Delivery is about building and delivering a solution. The outcomes are money, usually through a working product in the hands of users.
The two activities are tightly linked:
- You must discover insights before you can deliver a solution based on those insights
- The results of a solution delivered in production could and should be used to feed the discovery process
A common way to scale is to clearly split these two activities and to handle each of them by different teams:
- Discovery is done through a specialized team typically made up of Product Manager and UX/Designer, whose job is to find out how to make a great product and then to design it for the delivery teams
- Delivery is done through a number of software factory teams, whose job is to deliver what the discovery team has designed for them
Of couse there can be variations depending on the company. For instance the discovery team might embark software architects to think in advance of the technical challenges. Or design could be considered to be more of a delivery activity. It depends on the company.
It can be debated whether such a split is a good idea as it typically produces a “dumb worker” mindset into the delivery teams. Yet it’s a very common and effective way to organize.
Sociocracy, holacracy, freedom-form company
Scaling is about having more and more people working together. That implies more and more management work, right? Well, what about getting away without management?
That’s the idea of several models like sociocracy, holacracy and freedom-form company.
While this is an alien concept for many companies and people, it has been proven it can work very well.
But not everything is better, as some people don’t fit in this way of doing. Unsurprisingly, removing managers does not mean there is no process anymore, it is actually the opposite so that for the company can take decisions without any decision maker.
Biological models
As I already pointed out in a previous post, mother nature has many lessons to teach us. Most of them are relevant to scale a company: favor redundancy, self-sustaining, local decision making…
Spotify
The “Spotify model” is often compared to other Agile at scale frameworks like SAFe and LeSS but it is actually very different: it is not a framework deemed to be used by other people outside of Spotify.
It was originally shared as an example of scaled Agile, focusing on what was doing Spotify at that moment — by not way a method or framework to be re-used by other companies.
Still, a lot of people and companies got very interested in this article, and ended up trying to reproduce the “Spotify model” or to cross-breed it with Agile at scale frameworks like SAFe.
What should be noted about Spotify is that they reached the point of being a learning company: they built up their own framework for their own company, people, product and context, and they keep challenging it again and again over time.
SAFe
SAFe is an Agile at scale framework that grabbed a lot of attention in the Agile at scale framework.
SAFe became popular because it provides a lot of tools and guidelines, which obviously appealed to the more risk-averse companies. Sadly, these companies took the guidelines and applied them as blind rules. In the end, SAFe’s success is a little like a curse: it also led a lot of people in the community to simply bash SAFe, calling it “anti-Agile”.
The problem with SAFe is well-known and is very similar to what happened with Scrum… The problem is not in the framework itself, but in the people who applied the framework in some insane, perverted way.
LeSS
LeSS is a very interesting Agile at scale framework because it focuses on scaling the building of a big product through several teams working together. The framework provides ways to share the product backlog, the product owner and the Scrum meetings (sprint planning, sprint review, sprint retrospective) so that several teams really move forward together on the same product.
Scrum@Scale
Scrum@Scale is an Agile at scale framework provided by Jeff Sutherland, co-creator of Scrum. Obviously the focus is on Scrum teams, re-using as much as possible existing artefacts and elements of Scrum.
One interesting element of Scrum@Scale is the minimum viable bureaucracy concept: scaling implies more coordination and usually bureaucracy follows — this should be actively fought and kept to a minimum.
DevOps
DevOps is quite a big buzzword since a few years now.
The core idea is to reduce time-to-market as much as possible. This implies automating and smoothing the delivery pipeline up to the point of Continuous Delivery, that is that each minimal change could be put in production. This delivery pipeline is about building and scripting, but also testing.
DevOps is not strictly tied to Agile at scale but it is very hard to succeed at Agile at scale without it. DevOps is a core element of an Agile at scale strategy.
Micro-services
Micro-services is a scaling pattern where is team gets the exclusive ownership of a specific, small portion of the product, but from a technical and functional points of views. This ownership goes up to the production environment (see DevOps).
The key to micro-services implementation is to reduce dependencies as much as possible. As a result, the problem is scaled down and can be easily managed, instead of needing to scale up the organization and to really get several teams working together on the same thing at the same time.
Feature Teams
Feature Teams are usually part of the Agile at scale model that companies put in place.
It is the idea that teams are cross-functional and able to address a topic from start to finish, from design to production. In short, it is no more about focusing on the technical side of things only, but instead to focus first on the business and user value.
This practice is directly aligned with DevOps as the goal is, again, to reduce time-to-market as much as possible, this time focusing more on the business and building parts, DevOps supporting more the delivering part.
In order to be sustainable, Feature Teams need strong communities of practices. Since the teams’ focus in on the product itself, communities of practices are really important to keep the technical side living.
Communities of practices
All these teams need to share good practices. They also need to align on how to do things, like coding conventions. This is especially true when following the model of cross-functional Feature Teams, where the developers of a given skill set are spread out among all the teams instead of being all together in the same team.
This sharing and synchronization is usually done through one form or another of communities of practices.
The idea is that, for instance, all JavaScript developers get together on a regular basis and discuss how they should write code, share tips, and maybe do a collective coding or review session together.
Maybe even the communities of practices have dedicated time — maybe 20% of their time, one day per week — to address specific topics like tooling, or exploring new technologies.
Having properly working communities of practices is essential into a Feature Teams model. Without communities of practices, you’ll risk having all teams write their code differently. On the longer term, maintenance would be a real problem.
Beyond Budgeting
What about budgets? This is also a common blocker to being truly Agile: you need to plan in advance what will happen in order to have the budget.
Beyond Budgeting is a comprehensive management model which also offers alternative ways to handle budgeting.
Liked this article? Show it!
Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.
And follow me on my blog to be notified when I publish new articles!
Thank you so much!
