Scaling Agile for Dummies


What they don’t teach you at the Scaling Agile courses

By Leise Passer Jensen, founder of AgilIT.

As you may recall:

Agile started way back but had to go ‘under the radar’

Agile scaling frameworks have finally officially popped up*. Just a few years back.

According to that time’s pioneers, agile started in the 1950s as the normal way of doing things. When certain methodologies became popular, agile continued ‘under the radar’ until a decade after the Agile Manifesto for Software Development was published in 2001.

We noticed the scaling frameworks at a time when the agile teams for quite many years had begged top- and middle management:

“Please listen to us?

Accept our agile way of working as legitimate, fun, motivating and effective.”

*) The origin of LeSS and Scrum@Scale had been used for years, but we may not have known them under those names.

Enterprise Scrum was the first Software Scaling framework (2002). Presented November 2010 at OreDev conference in Malmo Sweden.

We were convinced agile was the way forward for software- and systems development. We had seen the light. But felt quite alone with that view.

How do I know?

-I was part of it.

How could managers claim “Of course we work agile in our company”?

I truly don’t know what happened.

IT projects and waterfall had been dictated for years.

As if it had to stay that way forever. Now something else was dictated: Do agile!

Then suddenly:

Many companies claimed more or less overnight “We are agile”. Or at least that they were doing a pilot in some areas.


More and more IT teams were claimed to work agile.

Agile anti-patterns

The visibility of dysfunctions

Teams were doing daily standups and reporting progress to a Scrum Master (if they had one) sitting down two times a week (some teams met more frequently and some stood up). They had a common task list (called their Backlog) and tasks were assigned by the Scrum Master. Sometimes they could show others what they had achieved during the last 2 months.

Once a week a Product Owner might visit them. Some teams could show him/her their delivery plan.


More and more teams were announced as working agile.

A few might actually do it.

True: Some teams got it right!

The Scrum society was successful with their marketing and Scrum training.

Extreme Programming had gotten popular, pair programming was the new black. User stories and use cases took over from the detailed Requirements Specifications.

Crystal Clear popped up (my favorite at that time for small teams). The announced Crystal Orange book (how to scale) never came.

More and more teams got it “right” – whatever that meant.

Other so-called software processes like Adaptive, RUP, etc. were published. The message was understood: Both an iterative and incremental approach is necessary. That message was also taken in by some formally authorized decision makers.

Executives started to acknowledge agile because they could see some financial benefits from development teams using it.

And the IT guys became better at communicating the benefits of changing from the traditional waterfall projects that hardly delivered what was needed, into working in sprints demonstrating working solutions at a regular basis.

Or not.

Some teams were forced to work agile against their will.

"This was never the intention" co-writer of the Agile Manifesto Martin Fowler said on his blog post "The agile Imposition" around 2006 (link).

The problem of imposition is elaborated in the essay "The Agile Industrial Complex" by Daniel Mezick here.

Avoid Scrumfall


Managers who continued to initiate IT projects and programs dictated that traditional project managers should now run ‘agile projects’ - whatever that meant.

Few really knew at that time.

“Keep proving that you are in full control of everything!”

Project managers had (and many still have) to present their Gantt charts every second week to Steering Committees, and keep reporting to accountable decision makers the traditional way on data, it turned out, they no longer had.

How do I know?

I was part of it.

I was even fired once as agile project manager because I refused to lie as dictated by my line manager.

He asked me to present timelines and estimates to the Steering Committee that would show what he had promised them. I did not. Of course not.

I showed them the correct data that was provided by a united team: That it would take 6 months more to deliver the first MVP – not the expected full monty.

You already know the consequence
(I was fired)

But we were working agile – or so our manager claimed.

The development team and Product Owner were doing really great and were becoming agile by heart. The management team was obviously not yet.

I realized I had failed to tell my manager when I accepted the job offer as their first agile project manager, that of course I expected the management team to adapt to an agile mind set as well.

The good news:

They later learned it and the company, a small startup offering a SaaS solution, became extremely profitable and successful, by the way. And still are.

I had also learned my lesson

Hey!   What does all this have to do with Scaling Agile for Dummies?

Wait and see....

Agile Projects?

I still – in 2019 - meet project managers who don’t know that projects can co-exist with getting deliverables from agile teams. Without lying about reporting data.

Without mixing thoroughly steered projects with the way the scaled setup is organized.

Agile Leadership?

I hear about supposedly self-organizing agile teams being dictated by formally authorized leaders not only what to do and when to deliver, but often also how to do.

Some teams are decoupled from critical decisions and are no longer accountable for their deliverables.

That was never the intention behind the Agile Manifesto and the 12 agile principles.

Are people lazy or self-motivated?

Douglas McGregor’s Theory X and Theory Y is still being totally misunderstood.

Many still believe that employees (X’ers) are lazy and need to be controlled by managers (the Y’s) who are perceived as the self-motivated ‘thinkers’ needed to be in charge and take decisions.

The truth is: Theory X people don't exist!

- Only in people’s imagination. They still teach it wrongly at the business schools!

The consequence: Command and Control is prevalent

Although it is of no use in a complex and unpredictable work place.





People get demotivated and 85% of the total global work force are unengaged in their work (Gallup, 2017).

Here comes the crazy part:

Watch this...


  • Even small companies with only 3 agile teams are so-called 'scaling', although the bureaucracy that follows from scaling is not needed.

Agile Release Trains are formed around the existing departments/areas instead of based on Value Streams.

  • Automated regression testing has been considered as nice-to-have and too expensive, but orgs. anyhow claim to be deeply involved in implementing DevOps.

"That was never the intention..."

... said co-creator of the Agile Manifesto Martin Fowler, concerning imposing agile on teams. He continues: "An important consequence of these [agile] values and principles is that a team should choose its own process - one that suits the people and context in which they work."

  • "Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking."

Part of the overall problem with scaling agile the way we do is:

  • When you scale, you also scale your critical problems. Many companies ignore this and unfortunately fail to achieve their goals with going agile.

  • I repeat: 85% of the global workforce is disengaged at work (Gallup 2017)

And the best is:

There exist Engagement Models to accommodate for that


Do the right things first

Decision makers don’t thoroughly reconsider if their org. setup is still appropriate

Below are the first 7 of my 14 suggested actions you should initiate to change the crucial situation as outlined in the Agile Industrial Complex ( by Daniel Mezick.


You see:

  • We have failed to work with and communicate properly to executives and middle management.
The root problem is:

The first 7 pre-requisites before you start scaling anything are:

  1. Fix critical organizational problems/dysfunctions first. Then scale - if you must.
  2. Adjust the organization to deal with complexity.
  3. Replace old-fashioned command and control systems
  4. Run agile projects - if you must
  5. IF you scale, use a framework that fits your purpose. Don't use it for stuff we know won't work
  6. Stop imposing agile. Start Self-management by using a few simple principles
  7. Ensure *lasting* change/transformations using Engagement Models

Those points are not covered in the certificate based agile scaling courses. But read on...





1. Organizations forgot the criticality in becoming a Learning Organization

2. We have failed to support executives and decision-makers big time!

3. Agile is now being imposed on teams!


Here is an interesting article by Willem-Jan Agelin in Serious Scrum: How Managers slowly got removed from Scrum. Enjoy!

Learn about AgiliT