Tag Archives: Lean

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. 

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.

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.