Thoughts about scaled agile frameworks and why they are useless
“What if we scaled agile to the entire company…”
This is a phrase heard more often than not in companies getting more mature at being Agile. But what does this sentence mean exactly? What does the idea of ” scaling up” imply? Are there solutions that can be applied quickly?
Did you say Scaled Agile Framework?
The term “Scaled Agile” is often accompanied by branded frameworks such as “SAFe”, “DaD”, “LeSS”, “Nexus”, … These are the names of frameworks or standards of practice dedicated to the implementation of Agile principles across multiple delivery teams; these “frameworks” gather a coherent set of practices/rituals/roles/artefacts intended to allow an organization to run according to Agile principles.
What triggers an Agile transformation “at scale”?
Depending on the maturity level of these companies, the Agile principles range from the small, isolated team that works in “full agile”, to organizations composed of multidisciplinary teams that deliver quality software, frequently, all aligned on strategic objectives.
Attracted by the popularity of some frameworks, the bosses of the less mature companies hasten to declare “Agile” in their teams, to send an army of “Agile coaches” and then ensure the deployment by the book of some applied guidelines within the teams. In 6 months, all team must “do” Agile!
In most of the cases, the announcement produces an electric shock in the teams: Agile has good press. The management takes it and uses the term in all its flavours: “ok, we will change the specifications, we are agile”, “We cut the tests to go faster, because we’re Agile “, “ Sorry, I’m late at the meeting, but it’s okay, we’re agile “…
But the enchantment does not last; the introduction of new operational rites is taking place at a rapid pace, often without any profound questioning of the existing structure of the company. We rename functions to include “agile” in them, we change the job descriptions at the margin, we add a ScrumMaster here, a Product (sometimes “Process” or even “Project”!) Owner there, the hierarchical links do not change, all employees are agile-washed through a 3-day training (finally shortened to 2 days and sweetened so as not to offend anyone…).
And then, the company declared doing Agile but isn’t Agile.
SWARMing, what is it?
The situation described above is often accompanied by the disembodied use of agile principles. These “frameworks” invite/force employees to organize their day differently, without questioning the fundamentals of collaboration.
These standard methods, packaged and branded, combine tools of collaboration and organization of teamwork. Used in a block, without understanding the fundamentals, the frameworks do not allow the deep transformation of the working modes of the companies.
In one of his articles, Dan North is the first to use the acronym SWARMing for “Scaling Without A Religious Methodology”.
My argument is not that packaged scaling methods are unhelpful per se, that they are neither necessary nor sufficient for successful transformation.
Dan North
Dan North sums up a thought that we share at OCTO; Scaled Agile Frameworks are only toolkits, and in no way magical doctrines or recipes to follow to the letter in order to claim to be an “agile enterprise”. These frameworks serve a company’s desire to adopt Agile practices, that is far from the initial approach promoted by Agile itself.
You can’t judge a book by its cover. It is essential to dig into the underlying principles/ideology of a framework to understand it completely.
Abandon Agile?
Ron Jeffries even provocatively advocated that “developers should abandon Agile”. It is in fact about abandoning the processes described by these “Agile” frameworks which prove to be real shackles that hinder the learning and the improvement of a team.
Back to basics: empower the team to improve
The best way to establish a team approach which is closer to the Agile principles is to give the team (or the organization) the power (time, availability, legitimacy) to improve its functioning regularly on the basis of the 4 values of the Agile Manifesto. This is not to “install” this or that framework or Agile method, nor to execute it to the letter. Above all, it means knowing regularly how to listen to and understand the impediment encountered by the team and, collectively, testing solutions that enable the team to lift these obstacles.
That being said, not everything is to be thrown in scaled agile frameworks.
How to get inspired without getting caged
If you have a hammer, everything looks like a nail.
This quote from Abraham Maslow reminds us that our vision of problems is distorted by the solutions we are used to using.
Agile frameworks are toolkits; you have to know how to dig in to find the right tool adapted to the problem you are facing.
Take the best of each scaled agile framework, depending on your context and your purpose
Let’s take some height.
Instead of immediately looking at operational activities, let’s list the main themes for which Agile principles bring a different vision:
Sharing the Vision and Strategy
The diffusion of the elements of meaning/vision around a software product allows a degree of autonomy to the teams and the ability to propose initiatives from the team members.
Prioritizing the topics of action
The company is committed to choose where to focus its efforts. Prioritization is an essential concept of Agile and it is found at all levels of strategy management.
Composing autonomous multidisciplinary teams
One way to gain reactivity is to bring design, decision and execution in the same place, within the same team.
Converging teams’ efforts on a daily basis
The autonomy given to the teams must be compensated by an additional inter-team synchronization activity to maintain a high level of efficiency and consistency during a software application development.
Resolving dependencies
In a context of agile work, the responsibility for the scheduling of work, formerly “centralized” at the level of the PMO, now belongs collectively to the team. What mechanisms can be put in place to achieve functionalities that require sequencing of interventions?
Improving continuously
An underlying principle of Agile is the continuous improvement of the team’s process and tools. What does continuous improvement mean at the company level?
Reducing cycle time
How to deliver more (and the most valuable) features to users, and get feedback?
Adapt the budget to steer the strategy
Agile teams manage their work in progress to avoid overflow/suffocation and to maintain a sustainable pace. We then admit that the total capacity of the organisation is limited to the amount of work reasonably achievable by the teams at any time. And not by the budget that the top management decided to invest for the year.
The fiscal logic is thus reversed: although the budget drives the total delivery capacity of the company in the long term (strategy level), the day-to-day budget allocation is delegated to the teams. The organisation trusts them to make the best choices depending on unexpected events, opportunities and impediments.
How does this apply to a multi-team project and throughout the company?
Conclusions
Beyond applying agile practices at every level of your company, your focus should be on solving a real pain for the business, and on your organization’s ability to observe and adapt functioning to strive for optimal operation.
Finally, it all begins with a retrospective, doesn’t it?
