The duality of Agile

The term “Agile” means different things to different people.

To some it’s the powerhouse of efficiency and productivity; whereas to others it’s a vague label at best, or an empty buzzword at worst.

And I can see why the conflict arises: because two forms of agile exist – one with a small “a”, the other with a big “A”.

Small “a” agile

Small “a” agile is a 400-year old word in the English language that means to move quickly and easily. In the corporate context, it lends itself to being open to change and adapting to it, while maintaining a healthy sense of urgency and prioritising delivery over analysis paralysis.

It’s a mindset that underscores the concept of the MVP – Eric Ries’s construct of good enough – to get the product or service that your customers need into their hands as soon as possible, so they can start extracting value from it now.

Then you continuously improve your offering over time. Retain what works, and modify or cancel what doesn’t. That way you fail fast and small, while iterating your way towards perfection.

Big “A” Agile

In comparison, big “A” Agile is a methodology to manage that way of working.

It provides tools, structures and processes – think sprints, kanbans and retrospectives – to pin down the volatility, uncertainty, complexity and ambiguity of our work, thereby maintaining clarity over what needs to be done, and baking in accountability to ensure it gets done.

Hence it may be helpful to think of small “a” agile as an adjective and big “A” Agile as a noun; bearing in mind that big “A” Agile might also be used as an adjective to describe a person, place or thing that adopts the methodology.

Regardless, some of our peers rail against Agile as a redundant neologism. As with other trends such as Design Thinking, they argue it’s merely old world practices repackaged in a new box. It’s what we’ve always done and continue to do as consummate professionals.

But I politely challenge those folks as to whether it’s something they really do, or rather it’s something they know they should do.

If a new box helps us convert best practice into action, I’m a fan.

The best of both worlds

There’s no point landing the perfect plane at the wrong airport.

That’s an analogy someone shared with me several years ago to explain Design Thinking, and it has resonated with me ever since for two reasons. Firstly, it exposes the solution-first approach that pervades the corporate sector; and secondly, it challenges our obsession with perfection.

When I look across the business landscape, I’m continually surprised by the decisions that some companies make on behalf of their customers, without those decisions being informed by said customers. It’s more prevalent then you might think. We humans are beset by bias, prejudice, arrogance and self-importance. We make assumptions and just know what is best for others. So we launch blind. No wonder so many initiatives fail.

Likewise I am continually surprised by the great lengths to which some companies go to ensure their product is flawless. All that time spent prior to launch represents time out of the market. And all those eggs put into the one basket means if it fails, it fails hard.

Design Thinking promises to overcome these problems by recasting the customer as the source of innovation rather than merely the recipient. Moreover, it’s agile – in the sense that it combines speed to market with continuous improvement.

Perhaps the most widely recognised variant of Design Thinking is the 5-stage framework espoused by Stanford University’s d.school. I won’t bother delving into its details when countless others have already done so. Suffice to say it involves empathising with your customers to find out what they really need; using those insights to define the problem you’ll solve for them; generating ideas for a potential solution; prototyping and testing (and modifying) the solution; prior to launching a minimum viable product (MVP).

Design Thinking is an iterative process, with an emphasis on cycles of learning: informing your decisions with intelligence; trying them out; failing fast; failing cheap; adapting; approaching ever closer to designing the right thing, and designing it right, to maximise its probability of success.

And it doesn’t end at launch. The MVP is a starting point, not an end point. In the heat of the market, the cycle of learning continues, and so the product evolves.

Of course Design Thinking has no shortage of detractors. One commentator likens it to syphilis (!) while others are even more offensive, calling it linear.

Much of the disdain appears to stem from the evangelism practised by fanbois who worship the idol of Design Thinking, the healer of all ills (including, no doubt, syphilis).

I also find the language of the protagonists sometimes misleading; for example, IDEO – the proponent of Human Centered Design, Design Thinking’s alter ego – claims “you’ll know that your solution will be a success because you’ve kept the very people you’re looking to serve at the heart of the process”. I know what they’re getting at, and I agree with the sentiment, but anyone with a freshman’s appreciation of statistics understands you can’t possibly know an outcome based on a sample. The best you can do is infer; or in layman’s terms, increase your confidence.

Nonetheless, I’m prepared to see past the breathless zeal and call myself an advocate of Design Thinking. Why? Because I consider it the best of both worlds: it’s evidence based, and it delivers.

Do your homework to check you’ll add real value, but get on with it and start adding that value now.

Over time, the value will grow.

The caveat of content curation

At last week’s Learning @ Work conference in Sydney, Clark Quinn declared:

Curation trumps creation

And this resonated with me. Why spend time, effort and money reinventing the wheel?

However I’d like to explicate his implied caveat:

…if good content is available.

There is a belief prevailing among L&D folks that all the information we need is at our fingertips. We can learn anything online. Everything is googleable.

But this is a myth.

Anyone who’s spent 5 minutes in an organisational setting appreciates how difficult it can be to source relevant, actionable content. If it’s not hiding in a walled garden, it’s of terrible quality or doesn’t even exist.

We’ve all scoured user manuals and discussion forums and video libraries, seeking assistance for that one specific thing we need to do, only to give up dispirited and empty handed.

Under these circumstances – when the right content can not be found – there is nothing to curate, so we have no choice but to create it.

Having said that, I recognise a halfway point.

Clark observes that finding good answers is more problematic than just finding an answer. In an agile environment, it is also important to realise that an answer will be useful if it is good enough.

By way of illustration, I am currently piloting what I call a “MOOC-like” training program at my workplace. Uncertain of whether this kind of L&D will fly with my colleagues – and mindful of failing fast and cheap – I have purposefully avoided investing big in scenario production. Instead, I have found a couple of videos on YouTube that are good enough to support my minimum viable product.

If the MVP proves to be a success, I’ll scale it up and invest in producing scenarios that press all the right buttons.

In other words, I’m taking Clark’s advice to create when I have to, but only then.