Category Archives: Lean

Organisational Archetypes and Agility

A “classic” organisation basically has three archetypes:

  1. Doers
  2. Decision Makers
  3. Information Providers

These archetypes are pretty much self explanatory, and the operational model that they create should be familiar to most readers.

Doers perform the actual work; the work they do is directed by the Decision Makers. This is typically the “core” of the business. Often somewhat outside of this dynamic is a third archetype, the Information Provider. Their actions are also directed by “The Decisions Makers” and their work product is then directly consumed by the Decision Makers, with a view towards making better decisions.

Basically, in true traditional style, everything flows in and out of the decision making function, and decision making is kept deliberately separate from execution.

What happens when you Introduce Agile into this mix?

If you introduce an “Agile Bod” into this organisational dynamic, the system attempts to constrain it to one of the existing organisational archetypes.1 Where you end up depends on which archetype you most closely resemble.

ScrumMaster Shaped People

ScrumMaster shaped people are most often placed into the doer category, either in the form of “Process Police” or “Team Leader” or even “Project Manager”2

Agile Coaches / Consultants

For the Agile Coach role however, the only obvious choice is to make them Information Providers3

Thus the line between “training” and “coaching” becomes more an issue of delivery method than ontology.

What’s the problem then?

This mismatch fundamentally causes three problems:

  1. Bad ScrumMasters
  2. Unintended Power Battles
  3. Wasted Potential

Bad ScrumMasters

Even if you don’t know much about “Agile” you have probably at least heard the phrase “The ScrumMaster is a Servant Leader” or similar.

The problem is that the existing organisational archetypes don’t really allow for Servant Leaders4 – they allow for leaders as Decision Makers and Doers as Servants. Pick one.

Unintended Power Battles

So where does this leave the Agile Coach?

Agile Coaches are typically brought into organisations that are just starting out with Agile, or have tried and screwed it up somewhat.

One of the leading causes for Agile Screw Ups is of course the “not realising that this is a paradigm shift not a tweak” part.

And this is where it so often goes wrong; consultants are asked Waterfall Paradigm Questions that have Agile Paradigm answers.5

And worse, from the consultant’s perspective, the client is either not asking the right questions or focussing on the important things (at least wrt adopting Agility).

Since the consultant feels tasked (and at least partially responsible) for the client’s successful adoption of Agility, they react to this perceived lack of “correct focus” by offering increasingly impassioned unsolicited advice – which in the classic archetype model begins to look like they’re making decisions; and decisions only come from the people in charge; and consultants, if they are anything, are most definitely not in charge.

And thus you end up with an unintended power battle, the perception of a threat, where none was originally intended. Leaving behind it defensive, affronted management and a bewildered consultant who thought they were just trying to help. After all, they were just trying to save you from yourself…

Wasted Potential

So let’s assume lastly that for whatever reason no power battles ensue. We are still wasting potential here. Because the fact remains that (if Agility is the objective) the client probably is asking at least suboptimal questions and potentially directing their focus towards immaterial areas.

So instead of building a world class Agile capability, instead what you get is lots of people who are really good at Planning Poker™.

There is basically no dynamic apart from hiring on the coach as a manager (and thus letting them make decisions) whereby the organisation can benefit from anywhere close to their full expertise.

Rounding the corners

So the upshot of all this is that in order to really adopt agile, your organisation needs to be able to support and recognise at least two additional archetypes:

  1. Enablers
  2. Advisors

Enabling ScrumMastery

The enabler archetype is an oversight role which focuses on supporting rather than directing.

Without it, Servant Leadership, and thus ScrumMastery becomes nothing more than empty rhetoric6 or passive aggression.7
With it however, you open the doors for an entirely new category of management; which includes genuine ScrumMastery.

Advising on Agility

So the final “Enabling Archetype” is The Advisor. And allowing Advisors to exist and thrive in your organisation8 is Step One in terms of accelerating Agility (or the adoption of any other paradigm shift for that matter).

To borrow a term that the 1980’s rendered somewhat cringeworthy; it allows for true synergy between client and consultant.

It allows for a consultant / client dynamic where the consultant is allowed to take information in, then synthesise it with their deep domain knowledge and then spit out useful advice. Genuine contextually relevant advice. Not Best Practice. Not what the last client did. But rather what you should probably do.
It allows consultants to offer strategic, structural and operational suggestions clearly and concisely, without fear of reprisal, not hidden under one thousand layers of politics and double speak (lest the advice be mistaken for decisions and thus be perceived as a shameless grab for power)
In this way your organisation can safely and quickly navigate a paradigm shift; using Advisors as living bridges instead of seeing consultants as nothing more than expensive walking dictionaries.

  1. And if it can’t it will just spit you out. 
  2. I don’t place Project Managers fully into the category of “Decision Makers” here as they are typically tasked with overseeing that a decision is executed correctly not with making the original decision itself. 
  3. We all know that Agile Coach as “doer” is ridiculous ;) 
  4. Or more accurately Servant as Leader, as was the original phrasing that re-introduced the concept in the late 20th Century. This is clearly an even worse deviation from the norm. Many people read that statement as “And the Meek Shall inherit the Earth. Right Now” with the immediate follow-up thought of “Screw That”. 
  5. Or as Alistair Cockburn puts it, “You’ve just asked me a Shu level question that requires a Ri level answer.” 
  6. There is probably a 4th Universal Organisational Archetype – “Ballast” or “Window Dressing” – into which ScrumMaster and Agile Coaches can also be put. “We don’t really know what function these people have, we suspect none, but you’re expected to have them anyway”. This is however a slightly separate problem, because here, Agile is assumed to have no effect beyond the desirable qualities of adopting the brand. 
  7. I will forever be reminded of an Open Space session where a “ScrumMaster” proclaimed that they once tried letting their team self organise, but when they checked up on them “They were doing it wrong”. 
  8. And recognising that Agile Coaches should probably fall into this category. 

“Regular” Products Iterate too…

Occasionally there is push back about the need to iterate on software projects. In fact just today I read a comment in a blog post that clearly stated “The only process that works is Waterfall – clearly define exactly what it is that the business wants, then figure out how you’re going to provide that and then build it” – well that’s a great idea – except around 9 times out of 10 we fail at the first step.

That’s not an isolated thought, it’s an honest one. Many people believe deep down inside that somehow iteration is failing1, or at the very least cheating and some people even call it waste.2

My Refrigerator

Those of you who sat with me at lunch on the last day of Agile Vietnam will know that I own a really nice refrigerator.3

Seriously, it’s amazing. It’s not just the best ‘fridge I’ve ever owned4, it’s one of the best products I’ve ever owned. Forget Apple, this thing just works.

And then I stopped to to compare it to the last fridge I had, and then the one before that – why were they not as unashamedly awesome? Why didn’t they just build fridges like this in 2008? 2003? 1977?

Basically because we didn’t know how…

Oh sure, we could keep stuff cool to frozen5 – and the door would open, and you could in theory see into it in the dark. But I’ve never loved a ‘fridge until now. I’ve never enjoyed using one before.

It’s probably important to point out at this point that I’m not talking about a massively expensive appliance here. The benefits are less to do with how much I’ve spent, and more to do with just how much refrigerator technology and design have come on since I last bought one.

The refrigerator has iterated.

Slowly I’ll grant you; but this is not a new product, it’s an iterative build on the product that came before it.
And that’s why it’s awesome.6

“Real” products – like ‘fridges, cars, dryers iterate. The products I have today are generally recognisable and serve largely the same core purpose, but they are not the same products by any margin as the ones my parents bought.

Refrigerator MVP

But it was not always thus. Visit any stately home in Europe and I’ll bet 9 out of 10 of them have a cellar, cool room or ice room.

Once upon a time (not that long ago – I bet it’s in the memory of your grandparents, if not your parents) – ice in a box was basically the state of the art.

Ice in a box was the MVP7 for home food cooling.

Granted, no single organisation ever owned the entire process from home ice delivery through to the French Doored, humidity controlled LED lit ‘fridge of my dreams, but the market as a whole certainly did (even if it took it the better part of 50-60 years)

Don’t fight the iteration, instead admire the speed

Once you accept that all products exist only to solve problems – to create outcomes desirable enough to pay for, you can clearly see that iteration is not a failure or a cheat – it’s basically the way in which the world works.

The difference with software is the speed at which we can accomplish this.

It’s not a failure to develop your software in an iterative fashion. It’s a privilege. An exciting time to be alive.

When we accept this process as natural we can take our ideas from blocks of ice to stainless steel wonders in a fraction of the time it took our forefathers.

  1. Who precisely is failing here however seems to rely entirely on your perspective. 
  2. Somewhat missing the point I know; but waste is both a tricky concept and an emotive word. 
  3. No kidding, I think we talked about my fridge for about an hour. I think it made us all feel cooler. I cannot for the life of me however remember how the subject came up in the first place. 
  4. One of the upsides of changing which country you live in every 5-10 years or so, is that you’re basically forced to upgrade your white goods. 
  5. Although I’d have to say that the majority of the freezer compartments I had in London operated around the concept of mostly frozen
  6. Imagine if people thought about their cars like they think about their smart phones – I hate this new Audi! It has the same form factor and user interface as the last one! Boooooring! I’m so going to switch to {insert brand here} car which moves the doors and steering system around every time they release a new one! 
  7. Minimal Viable Product 

Have you Mastered the Basics?

So I’ve noticed a trend in recent years. Whereby a lot of people are hungry for “advanced” Agile and Lean techniques (whether it be at a conference, in the classroom or in a coaching engagement)

So far so good, both Agile and Lean have been around for decades – and so it should not be a surprise that people are passed the basics and ready for some more advanced stuff.

But a conundrum often arises in these situations whereby the organisations and people most eager to learn the more advanced techniques are the very same ones that are yet come to grips with (let alone having mastered) the basics of Agile or Lean.1 (This is obviously a generalisation and not true in every case, but it’s sufficiently widespread for me to consider it a trend)

As I tweeted back in January:

And talking to other established consultants, trainers and practitioners it seems that I’m not alone in this observation.

So what’s going on?

There seem to be two fundamentally different views on what “the basics” are actually comprised of.2

And these two views may be an attribute that is unique to (or at the very least exacerbated by) the very nature of Lean, Agile & Systems Thinking.

(So again making a gross generalisation here)

Many people tend to class the basics as things that you do.3

Whereas “we in community” tend to class the basics as concepts you understand.

And thus many feel that they have mastered the basics when they can go through the motions – they write things on post-it’s or enter them into a tool – perhaps they set WIP limits, and they almost certainly know which three magic questions lead to hyperproductivity

But because they’ve not mastered the basics by the community’s definition – they often fail to yield any benefits from these changes (sometimes they do however, but that’s a topic for another time) – and thus they feel the hunger for something more advanced. Something more to do.

So this explains the phenomena – at least to my satisfaction – but it does not necessarily provide an answer 😉

Except perhaps that we should more carefully consider how we use our language and how we label things; because Basic Practices != Fundamental Concepts.4

  1. This does however put me in mind of an episode of House (“House vs God”) – where Wilson convinces a child who believes that he is a saint and thus does not need surgery to have surgery through the argument that an actual saint would have the humility to believe that they were in fact just sick and not in fact special. 
  2. This being an entirely different question to “what the basics actually are” – I’m arguing ontology here. 
  3. As soon as you do that, it’s also easy to apply models like Dreyfus 
  4. Ease of measurement and evaluation plays a big part here too. It’s much quicker and easier to determine whether or not somebody is having a 15 minute Daily Scrum than it is to determine whether or not everybody has internalised the value of (say) slack.