“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. 

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

Sprint Termination Narrative Fragments

NOTE: If you’ve arrived here directly this is a set of narrative fragments edited together to become a fable.  The purpose of which is to socialise desired behaviours within an organisation.  It is presented as an alternative to stating and enforcing simple rules along the lines of “Only the Product Owner may abnormally terminate the Sprint” and instead attempts to capture the richness and subtle involved in such decisions.  Like all good fables, it also contains several other minor lessons.

A LASTing Benefits Scrum Fable

Our Protagonists:

Bob – The ABC Corp Product Owner, recently married

Sally – The CEO of ABC Corp, & Bob’s boss

Gareth – The CEO of Company X

Jim, Gary & Peter (aka the Three Amigos) – schoolmates who now find themselves working on the same Scrum Team at ABC Corp. They all hold a large number of options in ABC Corp stock.

Betsy – the Scrum Mistress at ABC Corp, nobody’s boss

A Conscientious Product Owner

Bob the Product Owner being recently married is going on a long honeymoon. Knowing how important a Good Backlog is to the success of the ABC Corp Product, Bob grooms far ahead and spends quality time with his team ensuring that they have the information they need, and know what is expected of them whilst he’s away.

A Deal in the making

Sally (ABC Corp) and Gareth (Company X) having been working together on an exciting new joint venture for some time. They plan to build on the natural synergies between their company’s respective software suites and create an entirely new class of product which should take the market by storm.

Work needs to be done at both organisations. Their respective marketing departments have also requested that Gareth and Sally provide some kind of indication of when they think they can deliver it to the market.

Sally and Gareth get their respective software teams together to estimate how long the integration effort might take.

Both companies use Scrum for development. The estimates produced by the teams indicate that at the current rate of development, it’s most likely that the work will take between 4 & 6 “Sprints” to complete the integration. Marketing immediately calculates a calendar date from this information and starts working on Press Releases and Marketing Collateral.

Bob returns with a smile and a sunburn

The day after the deal is signed, Bob comes back to what appears to him to be a very different organisation to the one he left!

There is a note on his desk that he’s to see Sally the very instant that he gets into the office.

Swallowing back the fear that he’s going to be fired, Bob checks his grooming in the mens room before taking a deep breath and going to find Sally.

Sprint the First – Responding to Change over following a Plan

Sally briefly explains the deal she made with Gareth while he was away and directs him to start work immediately.

Bob explains patiently that he will most certainly prioritise the work in his “Product Backlog” but that “his” team cannot start on the work for a least another 10 days, as they’re currently “in Sprint”.

Sally explains to Bob, that time is of the essense, wheels are in motion and that 10 days is far too long to wait to get started.

“Bob, irrespective of what the team is currently doing, it cannot compare to how important producing the Joint Venture Software is. We need this.”

Bob stands firm.

“No!” he says, “I cannot break my promise to the team! As the PO I committed to not changing my mind about what the team is to deliver in each Sprint. If I break my commitment I’ll go to Scrum Hell! I’ve seen pictures in Betsy’s Scrum Bible, and it looks horrible!”

Sally considers firing Bob on the spot, but his mention of Betsy’s Scrum Bible reminds her of what’s in her bottom drawer. She opens it and takes out the gold plated plaque that Betsy gave her last Xmas. It is inscribed with something called “The Agile Manifesto for Sofware Development”, she scans it quickly to find the text she’d thought she remembered seeing.

She holds up the plaque and begins to read from it.

“We Value… Responding to Change over Following a Plan”

“Sounds to me Bob, like you’d rather follow your plan, than respond to the change I’ve just given you!”

“Um”, says Bob as he becomes increasingly fascinated with the top of his shoes.

“But wait, there’s more!” exclaims Sally

“We welcome change, even late in development, Agile processes harness change for the customer’s competitive advantage”

“Right Bob, I’m your bloody customer and I can see some obvious competitive advantage to hand here and I’m asking you to harness it for me!”

“But, Scrum Hell…” says Bob.

“You need to make a choice Bob, do you want to be Agile or do you want to follow the rules of Scrum to the letter? I had, until this point in time, thought that the entire point of doing Scrum was to become more Agile, not to be drowned in process and buracracy! It seems that I was mistaken!”

Bob is flummoxed. He thought he’d been such a good Product Owner, but now he felt himself torn between following the rules of Scrum and avoiding Scrum Hell or “being Agile”.

And then he thought of the solution.

Betsy. Betsy would know what to do. Afterall, this was a matter of process, why wasn’t she here?

Well Duh!

Sally called Betsy into her office, and they retold the story.

“No Prob” she said.

“Just Abnormally Terminate this sprint and then plan a new one. Bob avoids a painful eternity in Scrum Hell and you get your fancy new software built sooner rather than later. Just make you explain to the Team the reason as to why you’re doing this”

And so they did.

Sprint the Second – A series of unfortunate events

Jim, Gary & Peter have known each other since high school.

The news of the joint venture has delighted them as it means they now have a real chance to become squillionaires.

So when Bob announces the termination of the Sprint and the reasons underlying the change, they plan the new Sprint eagerly with the rest of the team.

And then they make a plan to celebrate…

And so they did.

Quite enthusiastically.

In fact they were so enthusiastic that they now can’t come into work for at least the next 6 days whilst their wives raise the bail money.

The rest of the Team optimistically soliders on for a few days, but after 3 days, all indications are pointing towards the cold hard fact that they’re on a Fool’s Errand. They can no longer deliver on their Sprint Commitment. Not a chance. Bail has been raised, but the three Amigo’s won’t be released from the county lock-up until the end of the Sprint at the earliest.

They ask Betsy what to do and she tells them that they need to tell Bob ASAP. She recommends that they agree to terminate this Sprint (as it’s no longer viable) and plan a new one, one that is achievable with the staff to hand but still progresses towards the overall project goal. Since Bob has just learned about abnormal sprint terminations, Betsy doesn’t forsee any problems and so lets the Team see Bob alone and heads off to her dentist appointment.

The Team meet with Bob. Bob goes ballistic. He tells them that he kept their commitment to them, and that they therefore need to keep their commitment to him.

The Team try to explain that the basis on which they made their commitment no longer exists. After all, if they could still deliver, why would they ever have originally needed 7 people to accomplish the goal?

Bob won’t hear a word of it. As far as he’s concerned, what the team is working on is “Super Duper Best Lucky Priority #1 Urgent Stuff” and he’s already terminated one Sprint already, surely terminating two in a row can’t be allowed. He decides it isn’t and tells the team so. Betsy said he could abnormally terminate a Sprint, not Sprints and anyway, he wants it done.

So Bob draws on his previous experience in “motivating” people and threatens the team: “If you don’t make your Sprint Commitment I’ll take the espresso machine out of the kitchen and dock all your bonuses by 20%”

The Team, horrified, nod acquiecense.

Dejected and feeling hopeless, they settle on a plan.

“Well, we could create the appearance of delivering this work, if we seriously compromised on quality and developed againt the current Alpha of Windows 9 – after all, it has a lot of what we need to do already built in”

“That’s hardly ‘Potentially Shippable’ though is it?” somebody asks.

“Who cares, he asked for something completely unreasonable, so let’s give it to him”

“Just make sure Betsy doesn’t find out about what we’re doing. She’ll go mental

And so they do.

Sprint Review

As per the plan, the Team develop a plausible facimile of the features requested. It only works on the latest Alpha Version of Windows 9 of course, but this is not at all apparent at Sprint Review.

Bob and Sally are both delighted. Bob secretly compliments himself on his management prowess.

Jim, Gary and Peter, recently released from the lock-up, sit at the back of the room, nursing their wounds and wondering how the team pulled off this miraculous achievement. But the mood in the room is so positive, that they say nothing.

Unintended Consequences

As part of the arrangement between ABC Corp and Company X, at the end of each ABC Sprint, ABC delivers the latest codebase to the Company X team. All this happens without the knowledge of the ABC Corp Scrum Team.

When the Company X team get their delivery, they are unsurprisingly less than pleased. The code is effectively useless, there are no tests, it’s full of bugs and it ONLY runs on a version of Windows that’s not expected to ship for 3 years.

They immediately tell Gareth, who turns a deep shade of beetroot red and immediately leaves to meet with Sally in person.

After her meeting with with Gareth, Sally considers taking a leaf out of Don Drapers book, but thinks better of it and settles for a deep breath and a walk around the block before going to see Bob. This time she remembers to make sure Betsy’s there too.

After some spirited discussion and finger pointing, Betsy soon uncovers the the root cause of the issue. She patiently explains to Bob and Sally that if the Team thinks the Sprint is no longer viable, and they can point to clear reasons why they think this is so, it’s probably better to listen to them than rely on wishful thinking and threats.

Sprint the Third – Life is hard and then you die

After a few false starts, and the addition of three new members to Alcoholics Anonymous, ABC Corp is ready to start work on the deal of the century.

With a full team, and an adjusted release plan, and under the watchful eye of Betsy, the Team plan to fix up the mess they made last sprint and then start on some entirely new functionality.

The Sprint Plan looks good, and they get to it.

However, halfway in, they discover that the map is not the territory. Design information that they had been given by Company X, information on which they’d based their initial estimates has turned out to be completely incorrect. To make matters worse they’ve also discovered areas of the Company X codebase riddled with technical debt. This is going to take a lot longer than first expected. So long in fact, that the seemingly perfect Sprint plan now seems impossible.

The mood is dark, most of the team would rather quit than ask Bob to terminate the Sprint again, but Betsy is adament and the three Amigos are game.

Bob discovers calm rational thinking

Bob, somewhat a changed man from his experiences to date, listens patiently. Bob and the Team discuss what the problem is, and what the impact is likely to be. They identify work that clearly cannot be done this Sprint, and descope it from the Sprint. Bob agrees to communicate this upwards to both Sally and Gareth. Sally should be pleased at least that this time it’s Company X at fault.

However, the team is concerned that this is still not enough and push to terminate the Sprint again.

Bob furrows his brow in deep concentration and asks them “So tell me why you want to do that?”

The Team stares at Bob blankly for a moment before replying

“Well it’s obvious isn’t it? We are no longer certain that we can meet our commitment, so we have no choice but to terminate the Sprint!”

“And then plan a new one…” says Bob.

“Yes, of course and plan a new one” chimes the Team.

“A Sprint Plan to do what exactly?” asks Bob.

“Turn the Product Backlog Items of Highest Priority into Software of Potentially Shippable Quality” the Team parrots back.

“Which are?” asks Bob

“Whichever ones you say are the highest priority, Product Owner, Sir! Yes Sir!” the team says in unison.

“Well I say the ones remaining in the current Sprint are the highest priority” said Bob.

The Team goes quiet until somebody mutters “But the code is a mess, we don’t know how long it’s going to take to do this…”

“But it can be done?” asks Bob?

“Well yeah, we’re pretty sure about that, just not how long”

“Do you think that there is a chance that you can pull it off in the time remaining in the current Sprint?”

“Well yeah, sure, there is a chance” says the Team “And even if we don’t get it all done, by then we’ll probably have a clear idea of how much longer it’s going to take, because we’ll have come to terms with it”

“Well, then get out of my office and go to it! We’ve agreed to descope the work that there is no chance of getting, and I’ll set expectations upwards about that. We’ll use the Sprint Time Box as a safety net. Try as hard as you can to solve the problem and we’ll see where we stand at the end of the Sprint.

“You know what to do so I’ll leave you alone for the rest of the Sprint to get on with it. Go wild, be creative, do whatever you need to do to figure this out and get this project back in control, if not moving forward”

And so they did.

Sprint the Fourth – Plain sailing

Sprint 4 proceeds without incident. Now aware of the technical issues and having fixed many of them this time around the team commits to a comfortable amount of work, and produces it all to the pre agreed definition of Done.

At the end of the Sprint it all integrates perfectly.

Jim, Gary and Peter start to peruse boat catalogues…

 

Creative Commons License
Sprint Termination Narrative Fragments by Simon Bennett is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Permissions beyond the scope of this license may be available at http://lasting-benefits.com/contact-us/.

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.