(Fail?) Fast and learn at any pace

My team and I are on the cusp of a significant new product release. Well…we are approaching a cusp and considering how to navigate it. (Looking at the definition of the word, I think we have to decide on our metaphor first). There is some considerable focus on how to handle the first release of this new way of offering our learning content. I confess to a little anxiety at times. No matter how well prepared a product development team is, user response is always unpredictable at some level or other.

Something will happen quite soon after the switch is flicked which will surprise us and from which we will need to learn quite rapidly. This is the way of software releases. There is a devil, of some size and ferocity, snuck away in one part of the detail or another. Usually it will be quite well hidden.

I struggle with articulating this as failure, however. Failure is a judgement laden word. It suggests (to my ear at least) omission and neglect. It suggests a lack of success. This, I fear, is enormously unhelpful. We are in a world of rapidly evolving tools and behaviour patterns where a confident offer of a definition of success is usually a mistake in itself. Anyone who confidently predicts what success will look like is likely to be stretching their credibility. We can describe and aim for improvement. We can plan for better outcomes and greater clarity. Success, though, will remain mercurial.

The “fail fast” mantra, or it’s success as a catchphrase, is largely attributed to the style and approach of Mark Zuckerberg and the early days of Facebook. Start ups, racing each other to economic value, would hire engineers to rapidly release and improve their tools and products. To iterate – the new panacea for the incomplete. Facebook’s buzz phrase was, in fact, “move fast and break things”. I suspect this was, at least in part, a swipe at established companies and their planning cycles and waterfall approaches. Zuckerberg had seen a new method at work and working much more quickly. He also saw that a succession of smaller bets in quicker succession (from which adjustments can relatively easily be made) is less economically risky than fewer, large ones which cost time and money to recover from. He was also smart enough not to espouse failing as an objective. Learning is the real outcome he describes.

Move fast with stable infra

As Facebook’s scale has taken the world by storm, the mantra itself has morphed. It now has a more grown up ring to it: “move fast with stable infrastructure”. This is much less pithy but unstable infrastructure will never be fast in the end.

None of this is about failure. It is about the quest for success, however, and about the definition of it as progress is made. Which gives rise to one of the words of our times: iteration. As with any over applied phrase, it has become twisted and bloated. The simple principle of adjusting and developing as a team learns is still a very useful guiding thought. It works best when a team is always applied to the management and development of a product. A good product team will study user reaction and usage, make good judgements of priority and apply development to small changes made quickly. All the time. This is not failing at all. It is learning from experience. This, in tun, is more like succeeding.

These new organising structures and teams have created a fascinating example of learning cultures and principles. Very much ‘learn as you work’ (rather than ‘stop and train’) and share your learning along the way. There are a variety of tools and services which are relied upon in this agile world. None of them are learning tools but all help teams and individuals to learn and develop. They support open sharing of status, information and problems (such as Trello). They support direct communication amongst a team/community/group (such as Slack). They record, through documentation, the principles and guides by which decisions are made (such as Jira) and the method of making whatever is being made (such as Confluence). All these artefacts are available to all participating in the work.

Not a tracking code, enterprise system or LMS in sight. These are all tools for productive working. For doing a job. They are strong learning tools because they are part of the work not separated from it in a special learning land.

Iterating can, though, be an excuse for never approaching a quality outcome seriously enough before the first release. (Hence my current anxiety). This is not really about learning though, it is more about managing expectations. The ability to improve as you go should not be an excuse for not doing things as well you can from the outset. There are other routes to a useful rehearsal space and practice arena. (A topic for another time).

4 responses to “(Fail?) Fast and learn at any pace”

  1. Another good piece, Myles. There needs to be much more work done to educate project sponsors, users and other stakeholders about the quality that should be expected at go live. Rather than talking about our methodologies – inputs, or how we do it – we need to reframe the discussion to give them clarity – and crucially, input – on what the “minimum viable product” is, and more specifically what it means to them.

    In a traditional training environment I have lost count of the times I have heard (and delivered) the sales message “We are the best company because we approach things in a particular way”. The client doesn’t care how you do it, he/she wants to know what results from spending money with you as opposed to your competitor. Will it make my staff better at a task or skill? How can you prove it?

    One of the issues that I have with Agile methodologies is that they often focus on the development team, rather than the customer. The backlog and the sprint become reasons why something can’t be done, things which may be essential to the customer. We need to educate our audiences and talk about things from their point of view to really get the idea of continuous improvement across, because frankly at the moment, they don’t get it. They see you toiling away and they expect something that is perfect.

    So, back to your point about failure – there will always be problems at go live. We know that, we expect it. That’s not failure, as you say. But it is failure when proportions – even small ones – of your user base can’t do the basics – logging in, basic navigation, and anything else that comprises the minimum viable product as defined by the customer.

    At the risk of being irritating, I’m going to repeat that.

    “As defined by the customer”.

    • Thanks James. There is a balance definitely. A long debate about the viable definition in MVP is often the result. As you say, the answer must be defined by the user/customer/audience.

  2. Thought provoking article, Myles.
    You might find this talk by Jeff Gothelf (author of Lean UX) of interest.

Leave a Reply

%d bloggers like this: