Tag: agile

Indecent proposals

Another year has flown by, and once again I’m pleasantly surprised by the number of articles I managed to post in-between the trials and tribulations of life.

In December I like to review each one with a view to identifying a common theme. This time around, I’ve noticed that I – perhaps more directly than usual – presented my ideas in the form of proposals.

As to their decency, I’ll let you be the judge…

A woman with her hand to her mouth in a bashful manner.

US Liberty $1 coin

By the way, thank you everyone who reached out to me to express your appreciation of my annual compilation of L&D conferences in Australia. You’ve given me the reason I needed to continue doing it, so stay tuned for January.

In the meantime, I wish you and your family a merry Christmas and a bonza start to the new year!

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

A young brown hare in a grassy field.

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.

An ornage sticky note pinned to a wall.

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.

Gift horses

If I had asked people what they wanted, they would have said faster horses.

I’m fascinated by this quote that Henry Ford may or may not have uttered.

In The best of both worlds I promoted Design Thinking as a means of using customer insights to inform strategic decision making. However, as the above quote suggests, customers don’t know what they don’t know. Sometimes it takes an expert to show them.

In an era in which the very existence of the L&D department is attracting evermore scrutiny, the role of the “expert” in our context is becoming increasingly pertinent. I have long been of the opinion that L&D professionals should dispense with being the SME of what is being trained; and instead be the SME of how it’s being trained.

Under this paradigm, we are the experts in the science and practice of learning and development, and we consult the business accordingly.

This resonates with me because beyond the education and research I invest in myself, I’ve been around the block a few times. I have a strong idea of what will work, not only because I’ve read up on it and thought deeply about it, but also because I’ve seen it play out with my own eyes.

I also get paid to focus on my portfolio every day. I consider it not only my mandate, but an ethical obligation, to originate and innovate.

Horses in a pasture

So I’m more than comfortable with L&D professionals pushing the envelope on the basis of knowledge, curiosity, creativity and experience – so long as these activities are put through the Design Thinking cycle too.

By this I mean be confident that your idea is a sound one, but not so arrogant as to instil it with blind faith. Put your one-man (in my case) fruit of ideation to your customers to check it will work for them. While you’re at it, confirm the problem statement is indeed one that needs to be solved.

So much for Design Thinking being linear!

Then proceed with prototyping and testing, prior to launching an MVP, and iterating and evolving it.

In this way, the promise of expertise is tempered by an agile approach. It hedges the bet not only by building confidence pre-launch, but also by minimising potential losses post-launch.

Ford Mustang emblem depicting a galloping horse

If Mr Ford had resigned himself to breeding faster horses, he never would have launched the Model T.

In our admirable quest to utilise our customers as a source of innovation, let’s balance that approach by empowering the experts whom we have hired to practise their expertise.

Lest the L&D department be put out to pasture.

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.

Empathize, Define, Ideate, Prototype, Test

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.

Design Thinking is at the intersection of evidence and delivery

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.

Empty fuel gauge

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.