Agile is not a methodology, it’s an Albatross…

One of the hardest things to understand when starting out on the Agile journey, is that although most often sold as a methodology, this is looking at it at the wrong way. Scrum is a methodology, as is Kanban or DSDM or XP. But none of these are Agile itself.

The problem is that often the first experience of anything termed Agile are the methods and tools of a particular methodology. It’s how I was first introduced to it. The methods and tools however are of no benefit in and of themselves. Yes, they can help uncover issues in your current process, Yes they may have some use in helping frame agile in your mind. But this is really of limited value, as a new set of tools is not the answer to a dysfunctional organisation or industry. Frankly that’s fiddling whilst Rome burns. A methodology is not meaningful unless accompanied by a change in mindset, without that you’re just going through the motions.

The problem with Agile today is the word Agile has baggage. So much so that it is pretty much meaningless. If I asked a room full of people, who thought they knew what Agile was, what the term Agile meant, a large portion would describe a methodology (which it isn’t) and the others would probably all give me conflicting answers.

If Agile is not a methodology and it’s not really got a definition – what use is it as term?

The language and the terms we use, help define and bind us as a group. Shared terms, shared understanding, shared beliefs.

So the real meaning of Agile (if we can reclaim the term from the methodologists) is that it is the expression of a collective mindset. A shared set of values if you will. Are those values the ones defined in the Agile manifesto? I don’t think so. I think the mindset and values are evolving and we’re yet to see anything close to a definitive set of values. That’s why we need a collective term to represent and be the vessel for the inchoate and evolving values.

The language we use and the definitions that they collectively hold are important. Shared language is what defines the groups that we belong to. That the word Agile is now so laden with baggage that it has lost its meaning is perhaps a symptom of a deeper underlying issue. An expression of a community that no longer has a shared vision or language.

A community that is becoming so myopic and fixated on the methodology and tools that it is losing its collective vision. In its place a morass of commercial vendors competing to reduce Agile to a packaged and marketable commodity.

Like the term Free software morphing to open source isn’t it time to define a new shared language and reclaim the essence of Agile without the methodology?

Trying to make sense of Rightshifting

I’ve been learning about Rightshifting of late and am finding the mental models used difficult to imagine. This led me to think about how I could redefine them so they made more sense to me.

However first up let me briefly surmise what Rightshifting is.

If you haven’t got time to look at these links now, skip forward, but they do a much better job than I will of explaining!

Rightshifting is a word coined by Bob Marshall, here’s his post explaining it.

In addition there is also the Marshall model, here is the explanation:

Basically Rightshifting is based on the premise that an effective knowledge work organisation is a function of the mindeset of the organisation.

There are 4 basic mindsets in terms of organisational effectiveness:

  1. Adhoc
  2. Mechanistic/Analytic (these terms seem to be used interchangeably in the Rightshifting community)
  3. Synergistic
  4. Chaordic (if you’re interested in where the word chaordic came from, see this book: )

It is then suggested that the closer to Chaordic you get the more effective the organisation is. However most organisations are stuck at the analytic stage. Hence the need to right shift organisations.

Here’s Bob Marshal’s diagram of the Marshall model, taken from the above blog post:

Marshall model
Marshall model

Note the red transition points, denoting how hard it is to break through into a new organisational mindset.

What I really struggled (am struggling!) to understand was what the different organisational mindsets really meant.

So  I wrote down some words that might be used to describe the different stages:

  • Adhoc: Cowboy, messy, chaos, creation
  • Mechanistic: Process, tools, rules, methods, control
  • Synergistic: Learning, flow, empowered, value
  • Chaordic: Opportunistic, come together, mushroom, sharing

As you can see by the words, the adhoc organisation sounds like an early start up. The mechanistic sounds like most businesses! Synergistic sounds like an Agile or Lean organisation and Chaordic sounds more like an open source community.

I then thought further and came up with these definitions, to help me map it to my understanding:

  • Adhoc: Finding value
  • Mechanistic: Building value
  • Synergistic: Flowing value
  • Chaordic: Enabling value

Take a look at Rightshifting, if you haven’t already, and let me know what you think about my definitions of the various organisational mindsets and if you think they are a useful  or helpful way of describing them.

More Rightshifting posts:

Avoiding monsters by opening the box of requirements

How many times have you had a requirement from a client and implemented it diligently, only to find it’s not actually what they wanted at all?

Perhaps the conversation went something like this:

Client: It’s an emergency I need to add images to the “about us” page.

You: Sure no problem I just need to enable that in the CMS. It’ll take 2mins.

Some time later

Client: (Irate) It’s not working! I add images and they all appear in the wrong places.

You: Hmm, ok I think I can see what’s happening. Let me add some extra styles which should clean that up for you.

A little bit later still

Client: (really irate now) You’ve made it worse I tried to add a table to make it look ok but now the whole page is wrong.

You: Ahhh, I see what you’re trying to do – add a list of staff with a biography. I think we’ll need to build you a tool to add members of staff to that page.

Client: (Exasperated) Well of course! That’s what I asked for!

Now in this scenario, it’s easy to blame the client and say they didn’t know what they wanted or how to communicate effectively. But, to be frank, this is plainly wrong. The issue here is not bothering to open the box of requirement, then being bitten by the contents once you did.

Every requirement, no matter how small, is really a box. It can contain absolutely anything and it’s beholden on us to work with the client to open the box, look inside and make sure it contains what the label says. To do this we ask questions about what the requirement is trying to achieve and what value will be provided by the requirement.

Here’s a diagram showing a journey through the unboxing of a requirement in order to build a shared understanding.

A journey to shared understanding with the client

This diagram shows that although we start with an expressed requirement, the requirement we have in our mind and the one held in the client’s mind may be different. Therefore until we share our understanding with the client and they share their understanding with us we cannot arrive at the actual solution. As the actual solution will always remain unknowable until we have uncovered our and the client’s pre-conceptions of the requirement/solution. In short unboxing the requirement!

Often we forget to unbox a requirement when we are trying to be nice, when the client is putting us under pressure or when a requirement comes late in the project. However these are the times we need to be most careful to actually check what’s in the box before ploughing ahead.

Formal documentation is also the enemy of unboxing a requirement, as the written word acts as a box in itself. A written requirement is often written when we have only had the requirement expressed (top left of the diagram above). We are then more likely to trust the written word and therefore fail to gain a deeper understanding of the requirement – missing the fact that although the requirement is written it has not yet gone through the unboxing process.

It is this journey to a shared understanding that helps us ensure that what we build is truly valuable and that we are protected from the nasties lurking in the bottom of the box, ready to bite us when we’re least expecting.

Bored at work? Build a robot

Often at work there are repetitive tasks that need to be completed and if we’re not careful it’s easy to get stuck in the following thought pattern; “I hate this task, I have to keep doing this boring action every time. My job is boring.”

But this type of thinking is disempowering. We need to shift our thinking to how we can remove this repetitive task.

Do not engage with the internal voice that is complaining but to listen to the complaint and do something about it.

Wouldn’t it be more interesting to build a robot instead?