Category Archives: Uncategorized

Metaphors are about communication, not truth

If a friend says to you:

“I just left my terrible job. I don’t know why I stayed so long. I guess I was just like a slowly boiled frog”

Do you get her meaning?[1]

Do you know that the metaphor is not true?[2]

Does it matter?[3]


  1. That the changes were so slow and gradual that she barely noticed them and thus stayed well past the point she should have done.  ↩

  2. The metaphor is that “If you put a frog in a pan of already boiling water, it will jump out. But if you place it in a cold pan and then slowly heat it, it will sit there calmly until it boils to death”

    Except it’s a complete myth that a frog won’t notice and allow itself to be boiled alive. The fact that this myth is so widespread however I take as a good thing, because that means there are very few people wanting to test it out. Although sadly this was not always true:

    Several experiments involving recording the reaction of frogs to slowly heated water took place in the 19th century. In 1869, while doing experiments searching for the location of the soul, German physiologist Friedrich Goltz demonstrated that a frog that has had its brain removed will remain in slowly heated water, but an intact frog attempted to escape the water when it reached 25 °C.

    The moral of which I’m guessing is you can slowly boil a frog anything as long as you remove its brain.

    Additionally the entire metaphor is silly if you think about it – because a frog dumped in boiling water would not jump out – it would die.  ↩

  3. IMHO? No. Because we’ve mangaged to convey a concept clearly and concisely – typically avoiding all the nonsense contained in fn2 above.

    Bottom line here is that if people are using a metaphor to describe something to you – focus on the communication aspect rather than picking apart the factual accuracy of the thing.  ↩

Best for me, best for now (Practice)

In my last post, I covered the concept of “Best for Me” Practice.

In this post I want to extend that a little further into “Best for Me, Best for Now” (Practice).

The Tyranny of “Best”

“Best Practice” is often held up as a gold standard – something to aspire to, rather than to do.[1]

This leads broadly to two dysfunctions:

  1. Aiming too high
  2. Aiming too low

Aiming too high is akin to somebody who desires to increase their fitness through running and reads that “best practice” for fitness running is to run 5km, in under 45 minutes three or more times a week. They walk out onto the street, never having run a step in their life and hop to it.

Aiming too low is akin to somebody who reads the same advice and decides that “well, given that I’m 80kg overweight and struggle to walk down to the shops, I could never do that.”

Neither case is likely to ever reap the benefit. (And if it’s not obvious, aiming too high can rapidly lead to aiming too low, with a short bout of depression and self loathing in the middle)

Focussing on Outcomes, not Activities

Ultimately the real problem with Best Practice, is that it places the focus on the means and not the ends. There is a massive leap of faith that by doing this, we’ll get that. And if you’re not getting this fast enough (or at all) then just do that harder.

Rather than trying to run 15km a week, both our hypothetical couch potatoes would be better off taking on board a “Best for Me, Best for Now” approach.

The outcome they want is a longer healthier life; and the best first step is probably along the lines of:

  1. Walking a little more than they currently do
  2. Making some dietary changes
  3. Adding other physical activities that they enjoy and will sustain and won’t cause injury [2]
  4. Tracking some metrics – looking for correlations[3]

“Best” Practices, like MVP’s[4] should be considered as hypothesis

If you did those four things – then you would rapidly[5] become a different person with a different capability (and potentially even different goals).

And thus Best for you, Best for now would change.

And that’s a good thing.


  1. And if it is seen as something to do, then often the question turns to why aren’t you doing it now?!  ↩

  2. When you focus on the outcome, you free yourself up to explore other alternate paths to reaching it. Running is a way to get exercise, it’s not the only way. Considering that when it comes to weight loss, exercise is more about improving mood than it is about burning calories, it’s doubly pointless to do something that you don’t enjoy.  ↩

  3. Perhaps measuring this with a FitBit and some bathroom scales. Noticing that on the weeks they walk more, they lose or at the very least maintain their weight and feel better to boot.  ↩

  4. Minimal Viable Product  ↩

  5. OK, this would depend also on your age, starting weight and whether or not you had any pre-existing glandular or metabolic conditions, but hopefully you get my point.  ↩

Best (for me) Practice

What do we mean when we speak of Best Practice?

Best Practice is a rather polarising term. Very few people are neutral about it. It’s either the watchword of an organisation or an instant irritant. But what does it actually mean?

Genuine Best Practice

As previously discussed, in Authentically Simple Systems – the term “Best Practice” is entirely valid. Given the current body of knowledge, there is One Best Way to perform this task.

To do otherwise would be, by definition, either inefficient or unecessarily prone to error.

But this term is used widely outside of the Simple Domain; and not ironically.

Best (for me) Practice

A lot of the time “Best Practice” is really just a shorthand for “Best for Me” Practice.

But this shorthand can actually hide two completely different intents…

Best (for me) Practice, given that I don’t want to take responsibility for my own actions

This is, at least for me, is the darker and more frustrating meaning I’ve encountered.

It often equates to “just tell me what to do”, with the subtle undertone of:

“If this doesn’t work, then it’s not my fault, because you told me it would work. I didn’t fail, the practice did. And so did you for recommending it.”[1]

Best (for me) Practice, given my context and your knowledge

If you’re not a Complexity Geek, then you’re probably not as hung up on the term “Best Practice” as much as some people are.[2] To you it infers something actually far more wooly, subtle and frankly more complex[3]:

“Given everything you’ve seen about our situation so far, combined with everything you know and your general experience, what are the best recommendations you have for us?”

Which to me, seems fair enough. Even if I still rankle occasionally at the term.

So how can we tell the difference? (And also avoid a pointless argument about nomenclature?)

Practice or Principle?

One aspect of the concept of “Best Practice” that is I think universal (regardless of the meaning you adhere to the term), is that a Best Practice is something that’s been tried before by somebody else[4]

The logic is sound (if not overly courageous):

Somebody else has already taken this risk, figured this out and now I’m going to reap all the rewards, while taking none of the risk.

This all seems fair and theoretically puts a new spin on our two “Best for Me” cases above, effectively merging them. Both are simply risk adverse and wanting help.

But now we’re back to square one – because it’s only for systems that live in the Simple Space that cause and effect is infinitely repeatable.[5]

And if that’s true, then Best Practice may not be as simple as it seems after all[6]

Fundamental Attribution Error and confusing correlation with causality

Just because somebody has tried something before and they were successful (even repeatedly so), doesn’t mean that it was those practices in particular that caused (or even contributed) to their success.[7]

As science progresses, every day we’re discovering new evidence that much of what we considered causal is now correlated at best, and in some cases completely unrelated.[8]

Best Principles? (or how to tell the difference)

And this is how you can tell the difference between a “Best for me in my context” and a “Best for not taking any responsibility” intent.

Those folks who are genuinely interested in better outcomes for their problems in their context will take on board the concept of Best Principles – Principles and heuristics that successful organisations use in order to develop their own (evolving set of) Best Practices.

And those who are interested only in shirking responsibility? They’ll listen politely and then quietly insist that you tell them what to do.[9]


  1. You could argue that this is precisely why branded methods are so popular. They’re less about buying a solution than they are about acquiring a scapegoat.  ↩

  2. Also, well done for reading this far.  ↩

  3. Ironic no?  ↩

  4. And hopefully shown to work. because otherwise we’ll have to class “Tilting at Windmills” as Best Practice too.  ↩

  5. To make this clearer at the very least you’d have to be doing exactly what the other organisation was doing – in which case I would question where your competitive advantage was coming from. But even then, you’re almost certainly doing it with a different set of people.  ↩

  6. Pun partially intended.  ↩

  7. I’ve met the odd entrepreneur that attributes Apple’s success directly to the less cuddly parts of Steve Job’s personality; apparently nobody else at Apple does jack squat.  ↩

  8. By which I mean there is no scientific evidence to support any kind of relationship whatsoever; however likely or plausible it might seem to the layperson that there is a link. This seems especially true of dietary advice.  ↩

  9. Whether or not this is because of an innate character flaw or simply that this is what they’ve been incentivised to do is a topic for another day.  ↩

Using Narrative as an alternative to rules of Best Practice

In my last post, I spoke about the limitations of Best Practice.

I can imagine that some of you may be thinking:

“Well Mr Bennett, it’s all well and good to poke holes in rules of Best Practice, but what do you suggest we do instead!?  We can’t just have a free for all!  How will people know what to do?”

A free for all is not at all what I’m suggesting.  In fact far from it.  The deep and lasting irony about using Best Practice outside of its appropriate domain of use is that you get less actual control as people game the system to get around it.

Let’s use a concrete example to illustrate the point I’m talking about.

You might for example be using a process control framework (let’s call it Scrum) – and you can have a simple rule:

Rule A) “Only the Product Owner may abnormally terminate a Sprint”

OR

Rule B) “Only the Team may abnormally terminate a Sprint”

OR

Rule C) “Either the Team or the Product Owner may abnormally terminate a Sprint”

There have been passionate discussions (mostly online) as to which one of these rules is “right”, and evidence of one kind or another exists to support all of them.  Clearly, as written, they cannot all be right.

Which one is Best Practice?

Rules are used to guide behaviour and also provide an objective justification for punitive action towards rule breakers.

In our society we are all aware of the punitive actions associated with our criminal justice laws.

But terminating a sprint is a process rule, not a criminal justice law.  If a criminal justice law is broken, it is used in a court of law in order to provide guidance as to whether the rule was in fact broken and what the appropriate punishment should be.  When was the last time this happened on your project?

Process laws are therefore less about punishment and more about guidance.  But how suitable are rules for this purpose?

Rules like these unfortunately offer very little guidance for complex situations.   And the more general they are, the less guidance they seem to offer.  You could easily argue that Rule C could be replaced by “Anybody except the ScrumMaster may terminate a Sprint” – it may sound silly, but really, what is the effective difference between that statement and the rule as described?

The problem with rules is that to be clearly enforceable, they need to be pretty specific – which is OK when your rule genuinely is “Best Practice” because everything else apart from following the letter is going to be an undesirable outcome.  But if anything less than perfect is your aim, then simple statements such as “Only the Product Owner may terminate Sprints” begin to lose their utility and we instead direct people towards a “not terrible, but not great either outcome” – in many cases like these, the focus tends to be not on excellence but instead on preventing horrible failure.  The problem with this approach should be obvious, you drag down the great outcomes to protect yourself from the bad.  Maybe it’s me, but I don’t see a competitive advantage in that approach.

Narrative is a good option – in these series of narrative fragments I have provided an alternative to simple rules – and one in a very human form, one in which our race has been learning and passing on knowledge for centuries.

Instead of a single point, instead there is a rich tapestry of guidance and learning.  One in which the team and organisation can add to themselves over time as they share their successes and failures.

Rules & Narrative Fragments

Best Practice is not a panacea

Best Practice is a term that’s bandied around a lot these days.

It ascribes to wishful thinking, and speaks to our fundamental human fear of the true nature of reality.

The very idea that there is “one right solution” helps provide the illusion that the world is a well ordered place.  Or at the very least could be, if we just tried hard enough.

However, as students of complexity are well aware, the only legitimate domain to apply “Best Practice” is in the Simple Domain.  This is a domain where Cause and Effect are obvious to all, and also endlessly repeatable. (And as such prime candidates for codification)

607px Cynefin framework Feb 2011

But most of life, especially knowledge work, does not fall into this appealingly controllable space, as much as we might like it to.

To increase our feeling of control, we often like to codify our notions of Best Practice into rules.  After all, if something is truly “best” then all other options are inferior and should therefore be avoided.

We then distribute these rules out to the population of humans whose behaviour we wish to control and sleep soundly knowing that our job is done and the world will be a better place from now on.

Because of course, everybody will follow the rules, and thus both their behaviour and the outcomes that they produce will therefore be “optimal”.

But what if we don’t trust people to follow our rules?

Why then, for the people’s own good (remember we we’re talking about the one best way here) we select some people that we do trust and have them enforce both our rules and their precious Best Practice payloads.

In the average corporation we might call these Best Practices by other names such as “policies”, “rules” or “procedures” and we call our trusted caste “managers” which we can then arrange in a hierarchy so that spatial position corresponds to the level of trust we place in each of them.  Everything is now ship shape and Bristol Fashion!

However, as I’m sure we’ve all experienced first hand.  The human mind likes to game the system.  We do so for all manner of reason: for fun, for malice, for personal gain and oftentimes just to get our job done.

The map does not always match the territory.  Maybe the rule is outdated, inapplicable to our current circumstance or simply badly or meanly written. Regardless, if it conflicts with our superordinate purpose then it gets in the way of the creation of value and betterment.

Regardless of the motivation, the instant a rule is created, people will be looking for ways to get around it, but without risking censure.

The unspoken mandate then becomes to follow the letter, but not the spirit of the rule, and therefore the same applies to the application of the “best” practice it was designed to engender.

This can lead to an arms race between the rule makers and the rule breakers. And so, rather than simply having one rule to follow, we have many.  Each describing the “Best Practice” version of the events that our incoveniently highly variable universe has chosen to throw at us.  Each created in retrospect for a situation which may never arise again.

Which brings us all the way back to the concept of attribution error that I spoke about here.

The rule makers’ attribution error is almost certainly that they believe that every problem is Simple and that Best Practice is therefore universally applicable to every situation.

If that’s your belief, then when you discover that the rules are not in fact engendering your desired outcomes, your reaction to fixing the situation is almost certainly to add more rules, or find ways to enforce the ones you have.  It will keep you busy, that’s for sure, it might even keep you entertained.

But it’s not going to give you better results.

If it’s the wrong tool for the job, it’s irrelevant how skilled you are at using it.

You cannot fix a broken watch with a chainsaw.

But once you see the world for what it is.  That it can be complicated, complex and chaotic, then you can achieve success through applying methods appropriate for managing those domains and give your rulebook a much needed rest.

Attribution Errors and the Importance of Context

I recently read a fascinating study that was done in the 1950’s by a physchoanlyst named Allen Wheelis

What Wheelis observed during the 50’s was that classic Freudian Analysis techniques were no longer working as often as they used to.

Simply put: The number of people who were “cured” by these techniques was significantly lower than had previously been the case and it was getting worse.

Leaving aside, for the moment, the large portions of Freud’s work that have now been discredited, lets examine the core theory behind why something that had previously been empirically shown to work no longer did.

A Different Time

Freud’s work was anchored in the Victorian Era, an era and a culture strongly dominated by very strong wills, opinions and morals.  It was very much a culture of “character” and “self discipline”.

Freudian therapies reflected this situation as they focussed very heavily on ways in which one might  break through the mental barriers that these strongly opinionated and disciplined individuals had errected and thus reveal to themselves the cause of their neurosis.

Once the said cause was revealed, the Victorian ethos of self discipline would swing into action and work diligently towards correcting “the unsightly defects of their minds”.  And apparently (I wasn’t there) this worked, at least enough of the time to be regarded as a “reasonable approach to the problem” – “empirically proven in the field” if you will.

Oh noes!

By the 1950’s however, Freudian Analysis was beginning to fail, and fail and fail again.

Why?

We now know that the reason is most likely the fact that the personality of the average individual had changed quite markedly by the 1950’s.  People were (at least compared to the Victorians) far more relaxed, open and introspective.

As such they achieved insight into the source of their problems far more quickly than their Victorian predecessors ever did.

But once they had discovered the fundamental cause of their woes, unlike the Victorians, they did not have the self discipline and strength of character to follow through on their discoveries to improve their mental situation.  And Freudian techniques, which were effectively designed for a different personality type, were basically ineffective in strengthening self discipline and “building character”

Bummer.

Well there’s your problem…

So how did the majority of the professional community react to this?

In two really interesting ways.

First of all, they congratulated themselves for being so damn clever and talented!

Why?  Because the first phase of Freudian Psychoanalysis was positively rocketing along, that’s why.

They attributed this not to some fundamental shift in the character of their patients, but rather to a combination of the advancement that they and their contemporaries had made to the current body of knowledge and also, of course to their inherent natural talent and skill.

The second reaction, was keyed to and influenced by the first.

“Well, we know that we’re awesome, so the problem must be with Freud’s theories, they must be wrong”

Now, as it turns out they were right, at least partially; but they were led to the right conclusion for the wrong reasons.  And every time that happens, your success is actually based more on luck than on good management.

So what does this mean for Agile? Lean? Complexity? CALM?

Context is important.  And knowing why something works is also important.  It’s not always enough to see that something seems to work in practice now, and thus assume it will always work in the future.  The world changes, people change and will (I hope) continue to change.

And if this is true, then so do our approaches need to change and evolve with us.

Just because something worked once or twice, maybe 5, 10 or 20 years ago; for somebody else in a similar set of circumstances to you does not mean that if doing the exact same thing doesn’t work for you in 2012 that the reason for your failure is that “you must be doing it wrong”

If you’re working solely at the practice level, then that could easily be an attribution error, and a potentially costly one at that.

What your apparent failure might mean is that your context is sufficiently different to the previous success story, that approach selected is never going to work, no matter how well you do it.

Which again is why I’m going to state again that theory informed practice is so vital.  If we understand the principles (or at least have usable models which we are willing to throw away once we have better ones) behind why certain practices succeed or fail, then we can operate at the principle level both to knowledgeably apply appropriate practices to our work as well as synthesise and create new ones in order to confidently and effectively solve our problems in our contexts.  And maybe even advance the state of the art.

Complexity: Justify, Explain or Apply?

Any idea, theory or science can be used to:

  1. Justify what you’re doing now, or would like to start doing
  2. Explain previous events, why some things fail and others succeeded
  3. Applied to create or synthesise new approaches to problems you have today

All are valid, and do not exist in isolation; rather they exist as overlapping zones in a continuum , and you can move between them at will.

Complexity Science’s oldest and most loyal cheerleaders are probably the Scrum Community; Complexity Science gets a mention in Ken’s landmark book “Agile Software Development with Scrum” – and the Stacey Matrix appears in the majority of Scrum courses today.  Scrum is touted as “a Framework for Product Development in the Complex Space” and the Stacy Matrix serves well to explain what the Complex Space is and why you need a new approach to dealing with it.

So this is useful, but ultimately it is simply using Complexity Science as a means to justify changing the approach used to manage Software Product Development (or anything else that Scrum is being applied to these days)

Nobody sane makes a change without some kind of Justification,  so this has been and still is a valid and useful technique.

Problems can occur however thanks to our friend Confirmation Bias.  If you like Scrum then you’ll want to use it all the time, and because of this you’ll be biased  towards seeing every problem as “Complex” so that you can use your favourite tool on it.  You have effectively created a tiny mental prison for yourself.

“So what!?”, you might ask…

in which case I would reply: Scrum has been around for 15 years or so, and we’ve been attaching the “Agile” label to things for the last 10, and the results have been rather varied.  Panacea it most certainly isn’t.

But why?

This sort of question has led myself (and others) to delve deeper into the techniques we’ve been using, the underlying theories (if any) they were based on, and to seek out the latest research in a quest to truly understand what is going on, and what expectations we should have.

This search led me through a personal journey beyond Stacey and into the wonderful (but hard to digest) world of the late Max Boisot and his I-Space model and then ultimately onto the current cool kid on the Complexity Block Dave Snowden’s Cynefin.  I then delved into works of Baumeister, Kahneman, Tversky et al to better understand the limits of our cognition, how we make decisions and effective mechanisms to overcome procrastination.

I used this research to understand what the Scrum practices were trying to achieve, and what effects they actually had. I then extended this knowledge to create a model to explain why Scrum (as interpreted solely by its practices) will thrive in certain situations and self immolate in others.   I presented these findings in a workshop I held at Agile 2011 called “Scrum as a Thinking Toolkit”

This is just one example of moving from Justification (where we know the right answer and seek information only to confirm our existing beliefs and desired actions) – towards explanation – the creation of models & theories which help us understand why things have historically gone the way they did and thus hopefully provides useful insights into dealing with the future.

Once you have begun to understand, you can then begin to Apply.  Once you know the “Why” you can begin to create your own “How” – and even better, you can  take advantage of the considerable advances that have been made in the area of human cognition and social complexity to enhance your work.  As such, among other things, I began to apply “SenseMaking” to the management of Backlogs and Ritual Dissent to Release Planning.

And you know what I found?

Hey this stuff works…

This is the philosophy that is at the root of CALM (Complexity Agile Lean Mashups) – that of “theory informed practice” – synthesise new practices based on well researched principles and then validate these practices in the field.  Loop back and continue.

It’s this level of understanding that will help you understand why in some projects removing the time boxes made things improve, whilst in others it led to anarchy and disaster.

So I can imagine what some of you are currently thinking:

“Hey! Complexity Science was originally applied to create Scrum in the first place!  It’s built in! I don’t need this!”

And that’s exactly my point.  Regardless of where we mark the Scrum epoch (somewhere between 1987 and 1994 I believe is the currently accepted range) – Science has moved on.  Many of the models used to originally describe (and thus by association define) Scrum are now dated at best and debunked at worst.  We know so much more now.  The heartening thing is that using our current best available knowledge the “old girl” actually stands up very well for her stated mission.

But there is still more to have – much of software today exists outside of the Complex realm, there are other containers than time boxes, there is knowledge out there that scales far beyond the methods we’re using today; and perhaps most importantly there are strategies and techniques which can help us address the wider organisational issues beyond just those we encounter in our teams and on our projects.

CALM is about making a move from using science to justify what we already want to do, towards a mindful application of theory; a cycle of evolution and synthesise where practice and theory co-evolve to help us realise our true potential.

The first CALM event, CALM Alpha will be held in the UK on the 16th and 17th of Feb 2012.

Nobody Can Do Agile

Let’s be clear on one point.

You can’t do Agile.

You can only be Agile.

What causes some confusion I think is that in order to be Agile, you often need to do some of the things you’re currently doing now differently.

But if you really want to succeed at being or becoming Agile, you really need to first conquer how you’re thinking.

Agile Is Culture, Not Process

Before you learn anything else about Agile, you should take this concept on board.

Because it frames absolutely everything else that you learn and do after that point.

Many Agile coaches and trainers think that the majority of their students infer this fact based on the common practice among good Agile courses of starting with the Values and Principles of the Agile Manifesto.

But in my experience, this isn’t true enough of the time.

So I feel it’s time to start saying it explicitly:

Agile is Culture, Not Process. This is what the Agile Manifesto is trying to tell you. This is not a process you can simply adopt. It’s potentially a new way of life.

When faced with something genuinely novel in a familiar setting, the majority of busy people have difficulty relating the abstract to the concrete. This is doubly so if they are making the assumption that what they’re seeing is not in fact genuinely novel, but just yet another process with weird new words for things they’ve been doing for years.

“So this year we’re calling our requirements User Stories and Milestones are now called Sprints and there are a lot more of them”

The second problem with implying culture solely from teaching the Manifesto is that most people have been subjected to around 10-15 years of Corporate and Management Consulting rhetoric which has resulted in the words Value, Principle and Vision having in many cases lost all meaning.

So in a lot of these cases, once they hear the word “Values”, some folks tune out of the Agile Manifesto stuff…

…then only tune in when the instructor starts talking about specific practices that they can concretely relate to their job.

Why does this matter?

Starting with the concept that Agile is not a process, but a culture allows for the possibility of being Agile but doingthings that are “the same” or “similar” to the way in which things are done now.

Mental Models

The mental model of “Agile is a process”  drives people towards asking questions like:

“How does Agile handle this specific thing [that is a pre-existing concept present in my culture] differently to the way my existing process does?”

…and if the answer does not appear sufficiently obviously different to them, then they reject Agile as a whole because it’s “no different” and thus clearly snake oil.

The concept of Agile as a process leads people to believe that if Agile is to create “better” results, then the mechanicsmust all be different. And if they are not convinced that the mechanics are in fact different, they then reject the premise that the results could be different.

Finally, thinking of Agile as a process leads to the ‘pick and choose’ mentality of

“We’ll try daily stand-ups and see if that doubles productivity”

or the pick and reject mentality of:

“We can’t do Agile because automated testing is impossible”

Situational Coaching

So I was talking about this just the other day at a social gathering and an acquaintance (who is currently involved in an Agile adoption) said to me:

That’s what we’re doing. We’re trying to change people’s behaviour. People expect to have a process, to be told exactly what to do in any situation.  But instead, we’re saying ‘you can decide for yourself what to do and these are the principles that you should use to determine the best course of action’ But it’s not really working. They’re just waiting for instructions. Help!

So that probably came out differently than how it was meant – but obviously teaching people the Agile principles and then saying “you decide” is not going to work in the majority of cases, which is why in my team at EMC, we use what we call the “Situational Coaching Model” (which is based on the Situational Leadership Model)

In a nutshell, the Situational Coaching Model sees your Agile Coach taking your team, project, programme or even organisation on a journey through Directing, Guiding, Supporting and finally to Delegating.

If you’ve not read the referenced article, one of the key points is that in the first two phases, the Coach decides how the team approaches the situation. The rationale behind this seemingly un-Agile approach is that in the early stages of adoption it’s only the coach who’s living and breathing the manifesto, and whose job is not on the line when they cross the corporate culture police.

The beauty of the model is however if the team already lives the Manifesto, then it’s easy to move through the stages quickly. (I have horribly oversimplified my explanation of this approach)

I think as a community we’re sometimes not correctly setting expectations as to just how long it can take teams to move out of the first two stages.  It’s just not something you can set to a timetable.

Being vs Doing

One of the aspects of “being” as opposed to “doing” is that ultimately every individual decides for themselves. Your boss can make you “do” something. They can’t however make you “be” something. (Except maybe miserable if they do a lot of the first thing)

It’s the attitude that each individual brings to the daily stand-up that matters exponentially more than the precision with which they follow the process of answering those three questions and taking up exactly 15 minutes a day on it.

If you don’t internalise the culture / process distinction – you’ll never leave the first two phases.

This is the leading root cause behind Agile rollouts that begin to “come unstuck” once all the Coaches and Trainers leave. The culture never changed.

If Agile isn’t a process, then why is there so much emphasis on how to do things differently?

There are several answers to this question – some reasonable, some harsh.

Reasonably speaking, once you start to believe and value different things – you look for ways in which to support your new beliefs and values. The central tenant of quality, quality, quality in the Agile Manifesto Principles drove people to find better ways to develop and test software. The emphasis on working software as a measure of progress led to developing software in vertical slices, which in turn led to Continuous Integration in XP and resulting in the burn down charts used in Scrum.

These techniques are mostly all awesome – and generally useful too even if you’re not Agile, which causes confusion if you believe Agile is a process.

But understand, regardless of their subsequent general utility these techniques were born of the Agile culture; the desire for individual mastery, the desire to enjoy work for a sense of camaraderie, pride & craftsmanship.

The harsh answer is however that the emphasis on processes and techniques is potentially a failing of those trying to teach you Agile – either knowingly or unknowingly.

The knowing kind are the worst – these are the people who do know that Agile is culture, but assume you don’t want a culture change and so tell you it’s a process because they want to take your money.

The unknowing kind may very well be experts in other fields, but are genuinely ignorant of the true nature of Agile themselves. Perhaps they’re enthusiastic beginners, or perhaps they were led astray by one of the “knowing kind”.

In either case, are these the people you want guiding your Agile adoption?

Or to be more accurate, your Agile transition, because if you’ve read this far, I hope I’ve convinced you that you can’t really adopt Agile, you can only transition your culture towards it.

Lo-Fi for the Flow Guy

Recently I was doing some pair Kanban Coaching with Karl Scotland, and as is not uncommon during these types of engagements, we got out of the classroom and “took a tour of the Gemba”.

Whilst the tremendous value that an accurate Kanban board can add to the effectiveness of such a coaching exercise should probably be the topic of another blog post, on this particular occasion another aspect jumped out at me; and that was the raw power of the lo-fi solution.

There were multiple teams, and each team had their own Kanban board. All were functional, none were fancy. They had been made out of what was to hand, whiteboards, envelopes, post-it notes etc.

As we moved from board to board we made comments and asked questions, and in several cases, working with the teams we immediately made tweaks and improvements to issues they were facing. And by immediately – I mean we did it then and there.  Limits were changed with the rub of thumb and the swish of a marker, the use and meaning of “blocked” stickers was changed in an instant, batches were made, unmade and sized, columns were added and removed. The changes were tangible and immediate. Changes that worked were kept, those that didn’t were so low cost to make it just didn’t matter.  The sheer absence of friction created its own momentum and spoke directly to the hacker and tweaker that lurks inside everybody passionate about creating great software solutions.

Whilst seeking process flow, each of us fell naturally and happily into a state of personal flow.

At the end of the tour each board and team was the better for it.  The level of understanding had risen markedly – as the team now felt the board. The board also described the work better by showing the actual current state & shape of flow as the team understood it (and that was without generating even a single CFD)

All this was done without permission, the need for a licence, admin access or even a thought to how this might “effect historical data”

There are some pretty decent Agile & Lean tools out there these days, but for sheer speed and humanity of operation, the lo-fi approach has some serious advantages which I think tend to get overlooked far too often.

If you and your team have lost that flowing feeling, it might be time to go old school for a while.