Have we (finally/thankfully) reached peak Agile/Lean?

14 min readMar 3, 2018

Disclaimer — I’m sure this article will hit a raw nerve with some people, and if that’s you, then maybe you shouldn’t be reading this article.

But the intent of this is not simply to raise some people’s blood pressure, but to bring some measure of reality back to the product processes we use in companies.

I do give recommendations at the end, so if you don’t want to read the whole piece, skip towards the end and see how everything turns out.

But your comments and feedback are more than welcome and I look forward to a healthy debate on this topic.

— –

As a Product Manager, I first worked with an Agile development team in 2004. To be honest, I didn’t know they had “gone Agile”. I hadn’t even heard of Agile practices or the Agile Manifesto back then.

We were working on a major new component — a centralized security and administration system — for a large product. We needed to perform a lot of user research to understand the issues. The development team was eager to succeed on this effort as it was a high profile project in the company.

I remember the Development Manager telling me they were going to use a new development approach that was different from what other teams in the company used.

I said “Great, whatever works best for you guys.” (Or something like that. It was a long time ago).

We had regular meetings, hallway and cafeteria conversations, discussions on requirements, UI mockups and reviews, internal demos etc. I included the team in customer calls, worked collaboratively to the extent necessary, and we delivered the required functionality for the release. It was well received by customers, and updated versions of that system are still in use to this day.

And that was it. Even though we were located on the same floor of the building, there was no material difference in how I interacted with this development team (who were “Agile”) and other teams who were not “Agile”.

I had no idea if they were using Scrum or XP or Kanban or something else. It didn’t matter in the least. Their development process was their concern. They were a self-organizing team right?

As for me, the Product Manager, I worked with them (and they with me) as much as needed, no more, no less. They didn’t need me sitting next to them, asking me questions and feeding them information everyday.

And they knew that sometimes getting answers took time so there was thought put into our interactions. We worked collaboratively. There were no ceremonies or other rigid formalities to contend with. It was a great working relationship and I remember it well to this day because of the success we had.

And of course, as a Product Manager, I had other responsibilities to tend to. My job wasn’t simply focused on working with various development teams. I ran an extensive beta for that release; worked regularly with sales and marketing on opportunities and programs; kept Services and Support abreast of changes and made major packaging and licensing changes with that release.

I was speaking with analysts and helping evangelize the company and products in user group meetings, AND of course, I was researching and collecting requirements for subsequent releases and the roadmap.

It was a tough job, but it was a great cross-functional role that led to real success in the market. Over the years I worked in other companies that had formal Agile/Scrum processes and in those, I certainly knew those teams were Agile.

Jump ahead a decade or more….

Now in 2018, things are quite different, at least with the Agilists.

Agile is now truly “a thing”. It has been so for a number of years. According to the 2017 VersionOne State of Agile report[1], about half the development teams use Agile methodologies within software companies and enterprises.

And most of the respondents state they have seen some benefits from adopting Agile. The top benefits are shown below. The percentage shown is the percent of respondents stating they’ve experienced the listed benefit.

There is goodness in Agile methods, but managing change, project visibility and increased productivity are things that we’d have worked towards regardless of whether “Agile” existed or not. e.g. working in smaller teams, focusing on the customer are not intrinsically Agile. They existed well before the Manifesto was created.

Is Agile a virus?

What’s interesting about the world of Agile is that it’s gone from a movement to address software development issues — the Agile Manifesto[2] is actually entitled “Manifesto for Agile Software Development” — and turned into “a thing”, a blob, a fungus, a virus, that aims to engulf everything it can touch.

There’s Agile Marketing, with it’s own (me-too) manifesto[3], Agile Sales[4], Agile Customer Support[5], and even….wait for it…..are you sitting down?…. Agile Accounting[6]. Yes, I’m serious; Agile Accounting is actually “a thing”. It’s right there on the Agile Alliance site.

Before you think I’m a hater, or that I just don’t “get it”, let me say that I’m amongst a growing population of contrarians on this topic. But here is what I do “get”:

I “get” that while Agile started out with the software development community, there are definitely principles that can be applied to project management in other domains.
I “get” that tightly coupled team members moving forward together has great potential for increased productivity in the right contexts.
I “get” that with software development, there have been definite gains and improvements over the last 15 years using Agile principles.
I “get” that I may simply be a curmudgeon, who grew up in the “old world” when things were done differently and my initial experience with an “Agile” team was not strictly, purely, truly, really, actually, properly implemented Agile.

Real vs. promoted benefits

But here’s the rub.

First, a lot of things have changed in software development since the Manifesto was published in 2001. One cannot simply isolate the gains made with Agile practices from other improvements and benefits contributed by technology, development tools and languages, Internet infrastructure, open source software and libraries, collaboration tools, hardware and network availability and new development techniques over the same period.

There is no A/B test to give the unbiased measure of the positive impact of Agile independent of everything else that has changed. There are benefits yes, but no one can accurately state the exact size and value of those benefits.

Second, there’s big chasm between what some of the Agilists are stating and promoting as the benefits of Agile practices and the reality of what people are seeing on the ground AND what is really important to businesses.

I won’t get into specifics of things like Scrum and how the whole definition of Scrum Product Owner is fundamentally flawed — i.e. The Product Owner DOES NOT literally own the product and is NOT a mini-CEO, regardless of what is said on Scrum.org[7]. Even Product Managers are not truly “mini-CEOs”. That’s such a hackneyed term to be honest.

The Product Owner DOES NOT literally own the product and is NOT a mini-CEO

And while I’m here picking a fight :-), let me throw some shade on the current use of “Lean”. Lean was originally used in the context of the Toyota Production System[8] and Lean Manufacturing[9], and has very clear and meaningful principles and definition. But it was co-opted and then popularized in software by the Lean Startup movement.

Similar to Agile, Lean focuses on iterative learning and iterative enhancements. But its focus is primarily the very EARLIEST parts of the product development process, before you have “Product/Market Fit”.

ALL learning is iterative. Remember the “walk before you run” rubric?

And let’s be clear about something. ALL learning is iterative. Remember the “walk before you run” rubric? Everything we learn is through an iterative process, whether it is learning arithmetic and algebra, or writing and grammar, or software design and development. This idea that iterative learning for building software is new and revolutionary is just patently false! The specific methods may be new, but the principle is old and well understood.

Agile diet, Lean exercise or something like that

There’s a huge aspect of truthiness[10] in what Agile/Lean proponents espouse. They describe an old world of utter dysfunction and failure (the sad days of rigid, monolithic waterfall processes) and the new world of extreme benefits and success (by being Agile and Lean with tightly coupled teams that are constantly learning). And they do this while ignoring the benefits of the old and the detriments of the new.

As an aside, the world of waterfall gave us the incredible Apollo space program that went from a declaration of intent by President Kennedy[11] in 1961 through to a successful Moon landing in 8 short years. This included the development of rockets and boosters, including over a dozen test and manned flights, the lunar orbiter, the lunar lander, space suits, the technology and software to get the astronauts back to Earth safely. So, let’s be real when we compare new vs. old methodologies and what was possible vs. what is possible.

Side Note: It’s pretty clear that the “waterfall” processes that were used in the 60s bear very little resemblance to the strawman examples used to describe waterfall processes and thinking by most Agile proponents.

These days, far too many people are attaching themselves, their businesses, their software tools, their canvases, their frameworks, their methodologies etc. to Agile/Lean when there is little truly “Agile” nor “Lean” about them.

e.g. what is actual “Lean” about the Lean Canvas except that it “leaned” really heavily on the Business Model Canvas and is simply a derivative of that.

And don’t even ask me what I think about the terms Agile Product Management and Lean Product Management. The terms are utterly meaningless.

In fact, Agile/Lean are the tech industry analogues of paleo/cardio in the diet/exercise industry. They’re cool and easy to attach your product or service to. You could even apply Agile/Lean in that domain. Behold:

A90X — Agile CrossFit Total Body Workout by Tony Horton
The Lean Diet — Apply the scientific Measure/Eat/Reduce methodology to lower your weight and get amazing results faster.

See what I mean? Those sound pretty reasonable right? The words have little real meaning. They’re simply convenient adjectives thrown about for marketing and convenience.

The certification trap

It’s frustrating though how many people unwittingly are using unworkable or overpromised frameworks and methodologies or pay for 2 or 3-day courses that “certify” them in certain roles.

Q: What you get after 2 days of “certification” training?

A: You have a day 3 problem because the training has not enabled you to make the changes needed in your organization.

Am I being harsh? I don’t think so.

To be “certified” in something means you’re qualified through education, testing, implementation and practical training. For example, to get a BASIC certification in scuba diving, you need to take classroom courses, pass some written tests, understand how to operate the scuba equipment, practice diving in swimming pools and then successfully complete several open water dives. i.e. you learn what to do, practice it, and then execute it several times in real world situations before being certified.

Can anyone claim that a 2 or 3-day product management or product owner class can provide anything similar? Absolutely not. Where is the practical implementation of what you’ve learned, particularly in real-world environments? How can anyone be “certified” if they’ve just listened to lectures and written some basic tests?

Yet, we have the equivalent of puppy mills putting out “certified” graduates and inflicting them on companies. It’s a disservice to the companies and an even greater one to the people themselves, who believe they have enhanced qualifications to take on business critical roles.

Speed and Value. Don’t conflate the two.

According to many Agilists, to do Agile (e.g. Scrum in particular) right, you HAVE to do things VERY differently than before, regardless of what that “before” was. And if you read the Agile literature of late, apparently most people are doing Agile wrong. The few that are doing it right are getting PHENOMENAL results, but of course, you’re not getting that because you’re doing it wrong.

Agilists cite statistics such as the following (from the Scrum@Scale[12] guide)

Amazon has 1000 Scrum teams that deliver a new feature to production every second without an integration team.

“… a new feature to production every second…”. Sounds impressive doesn’t it? But what exactly is “a feature”? And how do we know those “features” are valuable in any way?

But that statistic above is actually an understatement! David Rico, who is referenced by the Scrum@Scale guide, gives different, but higher numbers in a YouTube video[13].

30,000+ Amazon developers deliver 136,000+ releases per day

That’s 1.5 “releases” every second! That’s about 5 “releases” per developer per day. And if a developer works an 8 hour day, that’s a “release” every 100 minutes, every single day! But what exactly is “a release”? Is it a “feature”? Is it multiple “features”? It it a “bug fix”? A single line code change? Who knows? Who really cares?

Yes, those are big numbers. But what do they tell me? They tell me that Amazon is VERY BIG, has LOTS (and I mean LOTS) of systems, applications, infrastructure etc, has LOTS of developers working on all those systems, application and infrastructure, and if you ADD UP ALL of what those thousands of developers do and treat it like one single application, then the numbers sound impressive. That’s it.

Given that Amazon runs:

the most sophisticated ecommerce systems in the world
and the most sophisticated cloud infrastructure system in the world
and the largest ebook delivery system in the world
and the most sophisticated warehouse fulfillment system in the world
and probably many other world class applications

how could they not be “releasing” very frequently.

But, the reality is that only Amazon is Amazon and they have invested BILLIONS of dollars and TWO DECADES to get to where they are.

These numbers are meaningless for pretty much everyone else, except possibly companies like Google or Microsoft and their ilk.

But the extreme statistics belie another hidden truth. Agile/Lean methods are supposed to be focused on delivering “value to the business”.

And yet, there is rarely, if ever, any demonstration of literal value in the cited examples. It’s always operational and development metrics such as builds, releases, bugs etc.

And that’s cool if only because that’s what these practices are actually about — development efficiency. They claim to be about more, much more, but if that’s the case, where exactly are the mounds of measured evidence? Anecdotal stories of the top .01% of companies are not sufficient.

Rapid code iteration vs. deep insights

So, let’s call that a win for developers, but let’s make a VERY clear separation between that “value” and business value. Deep insights and significant business value are NOT found through rapid iteration and deployment of code, or even rapid learning by building, deploying and measuring actions from code.

You can’t A/B test your way to deep insights.

Deep insights come from spending time AWAY from the keyboard, the screen, the web browser etc. and out in the world, with warm blooded individuals who perform real work and have real challenges and problems to overcome.

Deep insights come from understanding a problem domain so well that you can connect dots to find solutions that others don’t even see.

Deep insights take time to identify, understand and assimilate.

Business value comes from taking those insights and aligning them with potential business models or business practices that can drive value for customers and revenue for your company.

The push by some to “rapid learning”, “continuous integration”, “continuous delivery” and “continuous innovation” is a false promise. It’s unnecessary for many, unacheivable for most, and unsustainable for all.

Recommendations for moving forward

Let’s take a deep breath here and slow down for a minute.

I’ve outlined a series of issues in philosophy, implementation and results in the world of Agile and Lean. And let me reiterate that I’m not saying there is no value or that these approaches don’t have a place in companies.

In fact, they do have a place in the tool chest.

Agile/Lean processes just shouldn’t take up the entire tool chest and the rest of the garage and suck all the oxygen out of the room.

They should be one of several tools and approaches that are available and used appropriately.

Agile/Lean practices have become mantra, almost religion to some. They are certainly the livelihood to many and I understand why people have become preachy about them and defensive when critical analysis is thrown their way.

But in business, if anything is true, it’s that there is no single best way of achieving success, and that fundamental practices remain fundamental practices for a reason. They have worked, they do work and they will continue to work for the foreseeable future.

So, let’s take a step back and review some fundamentals.

Deep insights are incredibly valuable, but take work, effort, skill and time to identify.
Those insights are used to drive business and product direction and ultimately the focus of product success.
We do need to be in a state of constant learning, but that learning is not simply about iterating on product features and releases.
The business needs to learn different things at different rates than what the implementation (i.e. software) team needs to learn. The two are related but the cadence and activities are different so the learning processes and timeframes should be different.
The “deployed code” is simply one aspect of the overall “product”, and we should be very careful about over-focus on code iterations and deployment at the expense of other equally important business priorities.
Just because you can deploy a “feature” or “release” every second (or minute or hour etc.) doesn’t mean you should or must. Business goals drive what we do in product, and not the other way around.
The rate as which customers can or need to consume “value” is more important than the rate at which you can produce “value”.
Let’s find the right balance between being business drivers and technology drivers. The two are inextricably linked in our world, but with the Agile/Lean camps, the scale has become tilted FAR too much towards technology. Can anyone say Juicero[14]?
There’s nothing more valuable than a well-trained team who are confident in their ability to do their jobs.
It takes time for people to get proficient at their jobs. We live in a complex, quickly changing world. Give people real training, real management, real mentorship and real time to succeed. 2–3 day “certification” courses are not the answer. In fact, I’d say, they are part of the problem.
Work to minimize the amount of “imposter syndrome” in your company. It exists and is hurting your company, whether you realize it or not.

I hope we have reached peak Agile/Lean, simply so that we can get rid of the hype and dogma and focus back (finally) on the important things like people, business goals, delivering value to our customers and businesses and making the world a better place, and not just a more technocentric one.

Saeed

A little feedback please

Since you’ve read this far, why not give me a little anonymous feedback on the article. 3 short questions, it’ll only take a minute, and it’ll put a smile on my face. What could be better than that?

==>Click here<==

About the Author

Saeed Khan is a founder of Transformation Labs. He is a consultant and helps companies improve their products and product organizations to accelerate product success. He speaks regularly at industry events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on Transformation Labs website.