To Agile or Not to Agile? – That is the Question

Author: Mark Matheson, Liqueo Ways of Working Agile Coach

“Everyone’s going Agile!”
“We’re on an Agile transformation journey…”
“We deliver our projects using Agile.”

Just how common have these – and similar – phrases become?

The last 10 – 15 years have seen an ever-increasing awareness of Agile. It’s recognised as a way for businesses to get products and services to market quicker with the promise of reduced waste and, in turn, increased profitability.
And that awareness has resulted in the adoption of Agile across a panoply of industries well beyond the world of software where it found an early home. These range from hotels to healthcare, car manufacturing to construction – and from Asset and Wealth Management to advertising and marketing.

But in homage to the famous lines from Shakespeare’s Hamlet quoted in the article headline, there are a couple of “elusively obvious” but vital questions worthy of consideration when approaching Agile:

Are we doing Agile?
Or
Are we being Agile?

The subtle linguistic difference between these two questions may appear to be splitting hairs. But to paraphrase David Snowden (co-author of the Cynefin Framework a model used to aid better decision making):

“You cannot change the future without a change in the language we use to define the past.” ¹

Be warned: this article will not give you a simple, direct answer to the Hamlet-inspired question in the headline. This is because I will be applying a principle that I learned in my early years of coaching football / soccer “Discover, don’t impose, by using established principles.” 

So, although there will be a couple of key takeaways in this article, its primary intention is to evoke discussion and elicit questions, to be answered within the context of the reader’s team and organisation.

A Slightly Different Take on Agile History

According to the above image, and contrary to popular belief, we’ve been “doing Agile” for a very long time! Let me explain.
Agile is fundamentally rooted in “empiricism” which means the focus of anything being done in an Agile manner must have experimentation and experience at its core. The 17 individuals who put together the 12 principles of the Agile Manifesto back in 2001 (the endpoint in the above diagram), clearly had experimentation and experience in mind when they advocated:

• Teams to reflect on how to become more effective at regular intervals
• That continuous attention to technical excellence enhanced agility
• To build projects around motivated individuals, giving them the support they need and trusting them to get the job done; with both business people and developers working together daily

Yet the same empiricism that Agile demands dates back to the 17th century and to the “Scientific Method” created by Francis Bacon. The process of inductive reasoning relies solidly on experiment-and-observe. Schwaber’s work that was presented at OOPSLA-95 regarding “SCRUM” ² demonstrated precisely this, and was a key development toward the Agile Manifesto (among other works from the manifesto signatories).

Sutherland and Schwaber pay homage to the seminal paper of Hirotaka Takeuchi and Ikujiro Nonaka, published in the Harvard Business Review, January 1986. In the paper, the concepts of “scrum” and “rugby” were likened to the ways product development teams were successfully delivering strategic goals. ³

And going even further into the past of how corporates got products ‘done’, both Deming and Shewhart, the modern forefathers of “Quality”, laid the foundations for Takeuchi and Nonaka’s work when they created the Shewhart Cycle (1939) and Deming Wheel (1950). It meticulously outlined the “Specification-Production-Inspection” ⁴ and “Plan-Do-Check (or Study)-Act” feedback processes.

But what does all of this demonstrate anyway?

That we’ve been doing Agile (or empirical, experimental and iteratively-based) product creation/business delivery for far longer than we realise – for nearly a century. Yet according to the 2021 State of Agile Report just 50% of all respondents measure the success of their Agile adoption by the business value it clearly delivers. ⁵ To coin a phrase by Schumpeter, companies must deliver value or suffer creative destruction.

“Not to Be [Agile]”

Clearly something is amiss, so let’s offer the following starting point:

When don’t we want to do Agile? When is Agile not appropriate?

In Hamlet’s soliloquy, when he said “… or not to Be”, he was pondering the significance of life and death. Arguably, a project, team or organisation could find themselves down a path of death by a thousand cuts because it believed that it needed to do Agile, even if it was clearly not appropriate after the necessary consideration.

Mike Cohn was one of the very early adopters of Agile (via Scrum) and a co-creator of the “PM Declaration of Interdependence” (yes … such a thing exists!). He wrote that it’s relatively straightforward to identify projects that are not suitable for Agile. ⁶ According to Cohn, there are three primary areas to question. If all answer “No” with a good degree of confidence, ⁷ then the conclusion most appropriate response is “Not to Agile”. These areas are:

• Novelty – is this a new, or substantially unique, feature, project or product to the individual, team or organisation?
• Complexity – is this feature, project or product complex?
• Urgency – is the need urgent?

So if something is in a sufficiently known space, is non-complex and isn’t urgent, then why consider “doing Agile” to deliver it? And especially if we are relatively new to Agile?

Note: It’s important to note that something might be classified as “complex” when it’s closer to being “complicated”. There is a difference and that is where the aforementioned Cynefin Framework can help hugely – both in the initial classification process and during the lifespan of the problem space being considered.

Figure 2 – Cynefin Framework

Another potential challenge is when a team or an organisation are just not ready to do Agile (using Scrum for example) because they can’t commit to a full-time, dedicated, “committed to the cause” and fully empowered Product Owner. They just shouldn’t do it until they have such a person.

I like to think of this person, as the “Sir Alex Ferguson role”. Manchester United Football Club were successful for almost 25 years because Ferguson had a clear vision of his “product’s” success and understood his customer base – the fans – intimately. He was also fully supported by his management team and empowered to execute his vision.

Do you have your “Sir Alex Ferguson, Product Owner” on your project or product development team? You might be successful without satisfying this minimum requirement of doing Agile using Scrum. However, Man United’s fortunes since their Product Owner’s retirement and non-replacement, should be warning enough for anyone.

“To Be [Agile]”

Should we just keep doing more Agile of whatever shape, size or hue, in the hope that delivering business value will get faster, more profitable and even more fun?

Let’s consider Figure 1 again and the dashed, red, vertical line.

The dashed red line represents the turning point paper by Takeuchi and Nonaka in 1986. This did far more than just show us case examples of how to do product development differently. It laid down far more than just the foundations of the Agile methods that followed in subsequent years.

Takeuchi and Nonaka gave us clear insight into how these teams and organisations were thinking differently, behaving differently and, therefore, being different too. It is often said that Agile is an ideology whilst Scrum, SAFe, LeSS, DSDM etc are methodologies. While that may well be the case today, the origins clearly show that Scrum, at least, was not a methodology to Takeuchi and Nonaka. They may not have called it “Scrum” in their 1986 paper, but they referenced the principles of rugby a dozen times throughout the paper (e.g. moving as a team unit, passing the ball back-and-forth to a teammate, the team unit getting the ball over the line together with shared responsibility).

In an interview with Jeff Sutherland some 25 years after they published their paper, Nonaka shared what Scrum always meant to both himself and Takeuchi:

“Scrum … means cross-functional teams engaging in the dynamic conflict of ideas that generate ‘ba’, the energy flow that surfaces knowledge that forms new products.” ⁸

Not a single method or how-to in sight. Not even a Product Owner at this stage. What they were discovering was an “energy flow”, the intangible stuff that produced tangible results.

Scrum as a way of being was already well underway, before both Scrum (the methodology) and Agile (the principles) were brought to public consciousness. The Agile Manifesto, therefore, is not just based on some wishful set of ideals generated by seventeen blue-sky thinkers from the world of software, affectionately known as the “Organisational Anarchists”.

The Agile Manifesto – and the intangible principles and values it encourages teams to embody for long-run, sustainable success – has its roots firmly set in scientific principles, empirically-based outcomes ⁹ and, above all, successful delivery of business value.

So, what is required to “be Agile”, if being Agile can lead to improved tangible results?

In keeping with the principle of encouraging discovery through discussion, we’ll answer that with a series of questions. This is an area that could well be seen as “woo-woo” or ethereal, yet it has clearly demonstrated real-world and tangible results. We’ll also add some surrounding narrative, drawn from that foundational paper by Takeuchi and Nonaka, as much of it is still pertinent today.

Can you/your team/your organisation genuinely handle “built-in instability”?

• Are all levels of management comfortable with just setting a “broad goal with a wide measure of freedom”? One that is still extremely challenging for the team/organisation, whilst allowing a plan to potentially emerge through experimentation?
• Are teams ready for this too?
• This approach has been described as a spirit “of putting team members on the 2nd floor of a building, removing the ladder [and elevator!] and then telling them ‘jump or else’”! ¹⁰
• Scrum has “courage” as one of its five core values. Is your organisation able to demonstrate this level of courage, especially in a regulated environment?

Are you able to handle being truly self-organising?

• To enable teams to be self-organising, one executive said: “we open up our purse but keep our mouth closed.” ¹¹ Does your organisation have that level of trust with teams and individuals?
• For teams to be given this level of autonomy, have they already built this level of trust or is there still some distance to go?
• Are teams ready to take on-board the responsibility of owning when they don’t deliver a sprint goal – without looking to blame team members? Likewise, are all team members ready to be totally accountable when they genuinely know they have let the team down but are willing to make amends?
• Are teams willing to continually pursue “a never-ending quest for ‘the limit’”, often referred to as being a high-performing, self-organising team?

Can your organisation stomach the intensity and pace of Agile?

• Takeuchi and Nonaka said that this Agile way of working was naturally intensive. It makes sense as the goal is to surface knowledge as quickly as possible so they can course-correct where necessary.
• It may seem anecdotal, but Scrum does call them “Sprints” for a reason!
• The early stages of an Agile project are particularly intensive. This is when team members step on each other’s toes and bump into each other, metaphorically speaking, as they learn to operate cross-functionally in the specific context of the new project. We know this to be true today. And Takeuchi and Nonaka found this as a dominant characteristic of this way of working 36 years ago.
• The upside to this intensity is it “enhances shared responsibility and cooperation, stimulates involvement and commitment, it sharpens a problem-solving focus and it encourages initiative-taking”
• The downside is stark – teams disintegrate and failure occurs.
• Hence, it’s worth asking again: Can your organisation and staff stomach the intensity and pace that (typically) comes with Agile, whilst still seeking a consistent and sustainable pace?

Are managers willing to become “Servant-Leaders”, in that order i.e. relinquish the old model of “Command-and-Control” and Authoritarianism and, instead, serve the team?

This one is self-evident, yes?

In line with the above point, are managers willing to effect “Subtle Control” only?

• Takeuchi and Nonaka described this as “Control through Peer Pressure”, “Self-Control” and, wait for it … “Control by Love”! (“Love” in a business environment?)
• So even if your business is unable to embody Agile principles and values to this degree, can your organisation embody the essence of it?
• To use a tangible example: How does your team/organisation handle mistakes being made? Do they embody a spirit of anticipating and then tolerating mistakes because we often learn more from mistakes than successes?

Hopefully this article has generated some insights and questions about the true nature of Agile. We have only scratched the surface of some of the sensing and probing (in the spirit of Cynefin) required to determine if we are stuck in the important, yet limited, “doing Agile” phase.

Being Agile is clearly more difficult due to its less visible and less tangible nature.

But at Liqueo, we believe “being Agile” is the “elusively obvious” next step that unlocks greater speed to market, increased profitability and, hopefully, more fun in your Agile journey.

Here at Liqueo, we provide organisations with the skills to implement programmes successfully through our flexible workforce model, tailoring solutions for our clients’ strategic goals. We deliver an exceptional, bespoke service to every client via a dynamic and agile framework. If you are interested in how we can help you implement successful programmes or want more information about the Daily Stand Up, contact us.

References

1.  “How leaders change culture through small actions”, AcademiWales, Summer School address by David Snowden, 2016

2.  https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-09/Scrum%20OOPSLA%201995.pdf

3. The New New Product Development Game (hbr.org)

4.  Statistical Method from the Viewpoint of Quality Control, W. A. Shewhart, 1939

5.  https://digital.ai/resource-center/analyst-reports/state-of-agile-report, p10

6.  https://www.mountaingoatsoftware.com/blog/deciding-what-kind-of-projects-are-most-suited-for-agile

7. Even this phrase “a good degree of confidence” must be approached with caution due to the human tendency to do “First Fit” pattern matching and not “Best Fit” pattern matching. Again, check out the “Cynefin Framework” for more information on this

8. Takeuchi and Nonaka: The Roots of Scrum – Scrum Inc, 2011

9.  In line with David Snowden’s view, Case-Based Practice has its limitations vis-a-vis Theory Informed Practice

10.  The New New Product Development Game (hbr.org), p5

11.  The New New Product Development Game (hbr.org), p6