Have People Lost the Plot?
I recently read a description of agile and Scrum as having the goal, “... your organization can increase speed and predictability, all while optimizing existing teams.” Boy, that was depressing. Have people lost the plot and forgotten why the word “agile” was chosen?
Why the word “Agile”?
Do you agree with this statement?: The purpose of agile is to improve efficiency, predictability, productivity, and meeting the project plan.
If so, no offense, but you don’t understand why the word agile
was chosen, the purpose of agile
, and the reason Scrum and related approaches were called agile
frameworks. And that’s OK. We’re here to help ;)
Let’s start with a potted history that will reveal why the word “agile” was chosen: In the 1990s a family of “light” frameworks were gaining traction, including Scrum, XP, DSDM, Crystal, and Adaptive Software Development. In late 2000 Bob Martin (“Uncle Bob”) wanted to organize a meeting of like-minded people about these systems, leading to the Feb 2001 Snowbird meeting, which included Ken Schwaber and Jeff Sutherland (the co-creators of Scrum).
Now we come to the key point: Early on at the Snowbird meeting the group wanted to choose a name to describe the major purpose of these frameworks. Two leading contenders were discussed and voted on: adaptive
(suggested by Jim Highsmith) and agile
(suggested by Mike Beedle). Please take careful note of this choice of words: they were both meant to convey flexibility
. To quote Martin Fowler, who was also there:
We considered a bunch of names, and agreed eventually on “agile” as we felt that captured the adaptiveness and response to change which we felt was so important to our approach.
Agile is for Agility
The hot book when the word “agile” was chosen in 2001 was XP Explained
by Kent Beck. Note his subtitle: Embrace Change
. One of Kent’s key themes in motivating XP was to discover great solutions by learning and adapting, and to make that approach effective we need to lower the cost of change.
In short, agile is for agility. Scrum—an agile framework—is first and foremost for agility. Not efficiency, predictability, productivity, and meeting the project plan. This was further emphasized in the Agile values and principles that the group created:
Customer collaboration over contract negotiation.
Responding to change over following a plan.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
In the first LeSS (Large-Scale Scrum) book, Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum
, one the thinking-tool chapters is called “Be Agile”; it includes the following:
“Agile” is not a practice. It is a quality of the organization and its people to be adaptive, responsive, continually learning and evolving -- to be agile. … Agile does not mean delivering faster. Agile does not mean fewer defects or higher quality. Agile does not mean higher productivity. Agile means agile -- the ability to move with quick easy grace, to be nimble and adaptable. To embrace change and become masters of change -- to compete through adaptability by being able to change faster and cheaper than your competition can.
Perhaps faster delivery and higher quality will be achieved with an agile method such as Scrum, but it is vital for business and engineering leaders to appreciate that the raison d’être of agile methods is ... agility.
Value and Agility
What about “early delivery of the most value”? Isn’t that the purpose of agile approaches and Scrum? Well, yes, but it’s vital to understand that the key message of “agile” is that the path to that delivery of value will increasingly be—in today’s fast-paced, high-change, highly competitive environment—from the organizational capability to adapt (change direction) cheaply and easily, based on learning from feedback, rather than upfront planning and “following the plan.”
I like to say that the goal of agile approaches, including Scrum, is to discover successful solutions by being able to … turn on a dime for a dime
The heart of agile and Scrum is not about “good execution of the project plan.” It is not about “speed, efficiency, predictability” and so on. People promoting that message have lost the plot of the agile story.
Less Agile or LeSS Agile: Descaling with LeSS
My focus, and that of my friend and the co-creator of LeSS, Bas Vodde, is to help larger product groups be agile and then discover and deliver successful solutions being able to turn on a dime for a dime at scale
. Large traditional development group often impede agility or flexibility due to their organizational design; they are structurally less agile. So in the first (2008) LeSS book, we wrote:
It is vital to appreciate that organizational agility cannot be achieved by a development team in isolation -- it is a system challenge for organizational redesign. Especially when you are interested in LeSS within an R&D department of thousands, where each product group may have 200 or 700 people distributed in two or five sites around the world. If an engineering team has the technical capacity to adapt or change quickly, but requirements management, legal practices, product management, HR policies, site strategies, and deployment processes all emphasize rigidity, conformance to original plans, conformance to the status quo, and slow practices, then how can there be real agility?
The point of “making change cheap” is especially relevant at scale, because large-scale groups often have fossilized organizational designs and processes that “make change expensive.” So much of what is happening in successfully scaling Scrum is removing those organizational elements that inhibit agility, that inhibit changing direction easily and cheaply. What are some examples of elements that inhibit “change easily and cheaply”? Single-function groups, project milestones, the traditional program/project management system, single-function workers, high levels of WIP, handoff between groups, and more.
So LeSS is not really about enabling an existing big group to “do Scrum at scale.” Rather, LeSS is about descaling the organization
, and creating a design that systemically enables agility at scale, with simple elements, to be LeSS Agile.
To learn more about LeSS and descaling the organization for real agility, check out LeSS.works