Revisiting the trade-off between simplicity and not reinventing the wheel. Finding out if scaled framework are Agile.
Simplicity has always been considered the essence of Agile Software Development.
As in the simple design for software development, and in the 80/20 Pareto principle for the scope and the most valuable features of a product. As in the tenth principle of the Manifesto: “Simplicity–the art of maximizing the amount of work not done–is essential.” And as in the lightweight adjective used for the Agile frameworks.
Recently the Simplicity in Agile has been challenged by the idea that Agile frameworks, especially the “scaled” ones, should include additional practices, techniques, and processes for not having to reinvent the wheel every time a team/department/organisation starts using an Agile framework.
The other side of the argument is that the Agile frameworks (Extreme Programming, Scrum, Kanban, …) are partially incomplete, intentionally, and fit loosely to leave room for adaptation and manoeuvre to those doing the work on the ground, so they can experiment, learn, adapt and evolve their practices, and ways of working, to fit their specific circumstances. One of the values of the Agile manifesto, after all, is “individuals and interactions over processes and tools.”
So should Simplicity take precedence?
Or should not-reinventing-the-wheel come first?
Is there a good trade-off between the Agile Simplicity and not having to reinvent the wheel every time?
My take is based on one principle and one prerequisite of Agility.
John Gall’s principle from 1975 has often inspired Agile:
A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
You have to start over with a working simple system.
The idea is that you don’t build from scratch a whole airplane just to try it if it flies only at the end, as someone put it (Giovanni Asproni). When tackling a complex problem, it is more effective starting small and iteratively and incrementally experimenting, learning, adapting and evolving. This idea of iterative incremental refinements permeates Agile.
Even more this principle applies to how teams/departments/organisations adopt an Agile framework and agile ways of working.
For them, the principle means it is not possible to define, comprehensively and upfront, an effective way of working even using a hypothetical omni-comprehensive all-encompassing Agile framework and the wisdom of the smartest “Agile luminary” to configure/tailor it.
This is because, for example, that in every team/department/organisation the fundamental relationships and the interrelations are different and have a huge and unique impact on which ways of working will be effective there. Therefore such effective ways of working can only be discovered by those doing the work on the ground, starting small with a framework that is partially incomplete, and incrementally adding only what seems to be needed and not more, and only when is needed and not before. And observing what works in practice, and what doesn’t. This will also lead to novel practices or processes that are not included in any existing framework.
An interesting and less obvious consequence is that there cannot be a recipes book that can tell upfront how to scale a company. Not an expert can design upfront a way to scale a specific company. Instead the path to the journey of scaling an organisation unfold and reveal itself as you go.
The final part of my take on Agile simplicity is based on Maneuver Agility (also known as C2 Manoeuvre Agility and C2 Maneuverability), a pre-requisite of Agility described by David S. Alberts as follows:
Maneuver Agility Is the ability to recognise the approach appropriate for the circumstances,
and to transition to this approach in a timely manner.
It is a function of the set of approaches available.
It is an ability of those on the ground doing the work. An Agile framework that is as simple as partially incomplete, underspecified, challenges those doing the work to improve iteratively and incrementally experimenting, learning, adapting and evolving their ways of working, since the very start. So they develop this ability to maneuver and they can continue to use it to adapt to the changing circumstances.
An interesting and less obvious consequence is that a scaling initiative cannot be driven and directed from an “Ivory Tower”, instead those doing the work on the ground should be directly involved in shaping and driving the scaling initiative.
In conclusion, John Gall’s principle (start small and grow your ways of working) and the pre-requisite of Agility called Maneuver Agility (adapt your ways of working to your current circumstances) suggest that simplicity in Agile is still essential. An omni-comprehensive, all-encompassing, framework would violate John Gall’s principle and neglect the Agility pre-requisite where a simple and generative, seed-like, Agile framework would honour both.
Simple Agile frameworks exist in the context of a lively lean-agile community constantly innovating, refining and growing a vast and open knowledge base of techniques, practices, and processes and open sets of patterns that complement every Agile framework. See the Present continuous in the ‘Uncovering’ at the very beginning of the Agile Manifesto. See also this funny video from Breaking Bad: https://youtu.be/X4LOuaMb-yI
Those doing the work on the ground should have direct access to the lean-agile community and such knowledge base, without limitations, intermediation, or filters, where they can find options and inspirations they can use to adapt, and evolve their ways of working, with the awareness that their specific problem may not find an answer there and instead they may need to invent novel practices (read here how to get involved in the lean-agile community).
This is what we did in the beginning, about 20 years ago, and more recently this concept has been reminded to me by Al Shalloway.
These below are a few historical examples of the open knowledge base of solutions and patterns from the lean-agile community:
– Portland Pattern Repository: http://wiki.c2.com/?PortlandPatternRepository
– Scrum Pattern Community: http://www.scrumplop.org/
– Top 100 Agile Books: https://www.goodreads.com/list/show/41715.Top_100_Agile_Books
– AgileAlliance on Agile: https://www.agilealliance.org/agile101/
And here a google doc with similar lists: https://tinyurl.com/wholeorg-agile
Chet Hendrickson points out that since Agile is simple, a scaled version of Agile should also be that simple, or even simpler. Otherwise, it will no longer be Agile (excerpt from The Nature of Software Development, by Ron Jeffries, 2015).
SAFe and DaD seem to be in a very different place.
Other less normative and less paternalistic scaled frameworks seem to violate the idea of simplicity too, even if to a lesser extent.
What are the consequences? What is your take on this matter?
Do we really need scaled frameworks then?
The example of these companies tells us that we may not.