What Has Gone Wrong: And How To Fix It.

I was not planning to write this article (and soon to be blog post on https://nigelbaker.wordpress.com) - And whilst writing it, I have discovered it needs to be a book. (A book I will never write, btw - So do not panic!)

But we have another DOA (Death of Agile) post, and feel it is important to understand what actually is going on and why it is going on.

The short why is simple: Money. Things are getting very tight across the world in business in general and technology specifically. Over-hiring post pandemic, and a constant flip flop between Remote and RTO (Return to Office) has caused a huge over-correction in the workplace.

But how the correction is occuring, is causing specific damage to the Agile community. Some unjustly, and some rightly so.

Now, this is causing some voices to proclaim the DOA and the end of Scrum, etc.

I have written before about some of the trends that are coming through to justify/supercede this. If you recall, I spoke about what I coined as "Delivery-Fascism"

"I am noticing an increase in what can only be described as "delivery-fascist" posting. This newish movement seems to be focussing on the "great man" theory of society, whereas development process and many organisational roles are complete waste - And in fact, corrosive and dangerous - And all that is needed is sharp clear requirements led by a Great Man with Vision. Now, this does sound similar to Agile - But these posters are making clear that Agile is The Enemy - Because of it's wasteful processes, roles and principles. Why do people need all these meetings if the requirements are clear and detailed? Who needs feedback? The Great Man has a vision that are being held back by The Others. He can see what others cannot." - Me, Three Months Ago.

But what has created the environment, for this thinking to flourish? As we have seen in "Real World" politics, the populist movements did not appear from nowhere. There were genuine concerns that people held, that populists have harnessed.

In my prior post I said: "Now like all ideas, there is a truth at the heart of this - Agile in 2024 has become baroque - With excess roles and excess processes dressed up in faddish ritualisation and gimmickry - And the answer may indeed be a simplification... but a simplification of the right things and not a slip backwards into the pre-history of Product Development."

I would like to explore this statement, with a particular view to organisational structure.

I have used a graphic like this to describe the situation in many organisations for about ten years now. This is a pattern that appeared again and again.

Embracing Agility "on the ground", (in teams basically, and almost certainly Scrum), and not changing at all the behaviours, activities and culture of the management layers of an organisation.

So what do we mean, when we say "Embracing Agility"? Some use that as a synonym for "Doing Scrum" or XP or Kanban or or or...

We need to look at what Agile actually is. I came up with this definition last year:

"Agile is incremental, iterative, empirical and empowered product development.Incremental?requires strong?technical ability.Empirical?requires?close customer and stakeholder interaction.Iterative?requires us to?learn?from the first two, and?empowered?is freeing us to do?all the above."

In a typical bureaucratic structure, that most organisations have (and humans secretly and sub-consciously aspire to), change is scary and difficult. And a loss of power is scary and difficult. Of my four phase statement above, as a traditional "feudal" leader:

I do not know how to do number one,

Number two challenges my authority,

number three challenges the status quo

and number four, I don't know how to do, challenges my authority, and the status quo.

I am not surprised it is hard... and I am super not surprised that the big issue is empowerment.

So what have businesses done instead? If these four factors are so hard?

Some would hire external coaches in. And Squeeeeeeze them between the workers and the managers. Giving them limited ability to change and help change the organisation. By being under direct line authority of the people that probably need to change the most, they find their change effort stifled and limited to a small problem domain ("just fix the team, the business won't change") and a smaller solution domain ("We have to use this tool, we have bought an enterprise license")

Worse still, even the idea of a coaching team fell away and now coaches are paid for by individual managers under these managers, and the coaches lack ther ability to genuinely work together and make change happen. And if that is not enough, some coaches are just rebadged middle managers. Those coaches knew what they had to say and do to survive. It often was not aligned with what the organisation needed.

Agile Coaches in general is a huge area of dysfunction, and (as one of the first Agile Coaches on earth!) is possibly a huge anti-pattern in the world of work. I do not want this article to be a comprehensive take down of the entire concept of the Agile Coach, except for this one idea:

If something needs to be sidelined - make it one persons responsibility. Because if it is your problem, it is not my problem.

This is what teams and managers have done with Agile.

Now, this was well known in the change industry since the eighties. The phrase I heard was Prescott's Pickle Principle from Gerald Wienberg's work:

“Cucumbers get more pickled than brine gets cucumbered.”

Or Nietzsche:

The coach becomes corrupted by the experience.

But it is not solely the fault of these coaches - The very structure that has been created has defeated them.

"A bad system defeats a good person every time"

So what have we done wrong in the Agile Industry? What did we fail to communicate or understand?

I can tell you where I went wrong. For years I was concerned that we had all these people wandering around with the self proclaimed title of "Agile Coach". I was concerned with their lack of ability to fulfil what that job title entailed.

I even had a pithy quote to cover it:

Yet, what has occurred since, is Coaches have picked up lots of skills.. as a coach.

Specifically in the Life Coaching space.

This is useful but insufficent. An Agile Coach needs more than coaching skills. They need domain knowledge. They need facilitation skills, and they need to be an effective Change Agent. This area of skill is deficient in many coaches.

Now what would you call a Coach with facilitation skills, domain knowledge and change agency ability? Because there is a pattern out there that covers all these skills.

ScrumMaster.

If you think Agile Coach has been abused as an idea, then you have never met Scrummastery!

I spoke about this at the last ever Annual European Global ScrumGathering in Amsterdam.

In fact, if we look at what the four aspects of a ScrumMaster should be:

We can see that most ScrumMaster roles have been implemented incorrectly, leading to a lack of support for the organisational change because a lack of delivery from the Change Agent and Servant-Leader aspects.

The ScrumMaster was supposed to be the Volunteer Change Army that working collaboratively, keeps momentum up, and things constantly evolving and changing:

Adding to these anti-patterns, we have seen in the last ten years an attempt to cross the divide between teams and their managers with what is sometimes errounously known as Scaling.

Having worked on the ScrumAlliance's new training product CAS-S1: Certified Agile Skills - Scaling - I have seen face to face the grand confusion between BIG and LOTS.

BIG product development, is all about structuring teams and work to allow the important aspects of agility - Empowerment, Incrementalism, Iterativeness and Empiricism to exist in very large problems needs hundreds of people.

This very different to LOTS - A range of products under development in parallel with each other but not effecting each other to any great extent.

People have been creating frameworks, with noble and less then noble intent, to sell into this space.

The problem has been, is that these frames (specifically SAFe but not exclusively so) have been adopted in the same way we spoke about before. And this has lead us to a creation of a layer of roles with which to enforce the frame. And because these frames have been overloaded with excess method, process and roles (because they do not align with the core principles decribed above) we are left with roles that (as Elon Musk so super-villainy said yesterday), are not 'excellent, necessary and trustworthy'.

Historically known as Bullshit Roles.

Or at least the appearence of such...

So, who's viewpoint are we talking about?

The people holding the purse strings. The money.

Leadership.

Imagine you are at the top of the pyramid, and you are looking down. You have been told (or decided) that for the revenue we have, and the way the world is looking today (War, AI, AI War) - That we need to reduce expenditure. A penny saved is a penny earned.

And from your position, all those Bullshit jobs, with their post-it's and stand-ups are they actually delivering any revenue? They look like the first place to start.

Or worse. Back to the Delivery-Fascists. Remember, they believe what you do. Sort of.

People are looking at Complexity, Ambiguity, Uncertainty, Bureaucracy as a swamp that must be cleared - and a Few Good Men have simple answers on how to do this.

"For every complex problem there is an answer that is clear, simple, and wrong."

H L. Mencken

This is symbolised in Aryn Rand's Objectivism and the idea of the Great Man theory is Hierarchy. "I am naturally better than you and above you and thus you must follow me." "My given talent must not be hindered by lesser men"

The empowerment they seek is of themselves, away from the process and bureaucracy they see holding themselves back. Many leaders feel disempowered by the structures around them.

So the removal of this excess, they see as getting back to basics. Back to a start-up mentality.

Intellectually perhaps the right idea, but the difference between theory and practice is theoretically there is no difference, in practice, there is.

Because those Bullshit Jobs were not. They were delicate, subtle and hard to describe jobs. Mixed in with the crap.

I call them VUCA roles. Roles that are all about the four factors of modern problems: Volatility, Uncertainty, Complexity and Ambiguity.

Companies did not realise the value that was (and could have been far more) that was delivered by those roles. And business is unforgiving.

But Agile is about flattening the pyramid. And that does mean some of the bureaucracy will need to go.

So what can you do today to make it better:

1. Adopt a proper change approach, treating it as an Agile/Scrum development drawing upon good Change leadership thinking from Kotter et al.
2. Delicately remove excess process and methods. (SAFe, JIRA et al) - Probably with a Cynefin inspired Safe-to-fail experiment model.
3. Ensure your process and roles are fit for purpose. Make sure you have no Bullshit Roles by fixing the roles to no longer be (or seen to be) non-value-add.
4. Make sure the people in those roles are fit for them.
5. Make sure you measure the value you deliver. In some way, somehow. If not - Triple lock the funding for the role.
6. Judge each situation contextually and differently. We are not resources.
7. Understand the difference between different and wrong.

Because that is the big and penultimate issue here: People often get wrong the difference between different and wrong.

They have cut-and-paste large scaling approaches from Spotify et al and it's gone wrong. Or worse, gone mediocre and exposed themselves to this oppotunity to be removed. This is where context is king, nuance is essential, yet we do not want to constantly reinvent the wheel - such as we suggested for the new ScrumAlliance training:

"Approach to scaling that focuses on using the situational context to determine how scaling is applied, starting with an understanding of the patterns of problems in a given context and applying common well-known solutions that have been proven to work well in the given context."

Because a lot of DOA people's answers seem to be actually Scrum Is Dead. And this is such a mistake, that it could set our industry back two decades or more.

Because those Accountable Roles in Scrum are essential - And we are not doing well enough, rather than the opposite! They do not exist in any other method, and that is why those methods are not fit for purpose for what many of us are trying to achieve.

Chunking our work up incrementally is not being done sufficently. Empowering teams has been stimied nearly everywhere, close connectivity with the customer is missing in most organisations and doing anything with that feedback is best a hope and a fantasy.

And doom mongers moan about Story Points and Velocity. (Neither a Scrum, but that is besides the point)

They are all focussing on the wrong things.

So rule 8.

8. Do Scrum well. If not Scrum, then do whatever it is you are doing - Well. But make sure it is better than Scrum, because it's probably is worse.

Twenty years ago we talked about ScrumBut. "We are doing Scrum but... [we are not doing that bit]"

People have seen this as some act of cultish devotion, with any variation being seen as breaking the rules of the cult.

No. This is as simple as noting the difference between variation ("a change or slight difference in condition, amount, or level, typically within certain limits." or "a different or distinct form or version of something.") and deviation ("doing something that is different from what people consider to be normal or acceptable")

The problem Agile has, today - Is the lack of understanding between variation and deviation - And the appropriate patterns to handle it.

Because there are TechBro's with very clear and volumable ways to handle it.... badly.

Nigel

P.S. If you would like to comment on the above, please do so - I may even agree and edit.