LeanUX, OODA & DEMO Loop
In a recent article I detailed how we could enhance our perspective on #DevOps to be all encompassing in our journey to create positive human behaviours with our products. #ProDevOps is an aim to merge product discovers, delivery and operations into one unified mindset. Given to a team with sufficient support, mastery and autonomy this purpose would drive great outcomes. What I didn’t cover is some of the how. So here it is, a cunning combination of Lean and Agile with a healthy dollop of do the right thing.
Lets start with LeanUX. In the book written by Jeff Gothelf & Josh Seiden you will find the following loop.
If you know me you’ll know I love a good loop. This one is particularly pleasant. The theory goes that via research and learning you can understand the actual problems people face using your product (or would like your product to solve for them). You can then define the outcomes they are looking for, any assumptions you have made and build these into a hypothesis. Spend some time designing that hypothesis into an experiment or MVP. Release it and then perform research and learning on the impact it has had. Rinse and repeat. Having been lucky enough to collaborate on one of Jeff’s training sessions I can see that this is an excellent way to learn about what product your customers and potential customers need.
To find out more have a read of the book which can be found here (https://www.amazon.co.uk/Lean-UX-Applying-Principles-Experience/dp/1449311652)
It did however remind me of one of my favourite loops, the OODA loop.
Devised by John “Forty Second” Boyd from his analysis of fighter statistics in the Korean war (which he served in). His analysis revealed that although the F-86 Sabre was slower and had a lower ceiling of operation than the Mig-15 the ratio of plane losses was vastly different. Figures suggest that during the conflict 78 Sabres where lost, whereas 659 Migs were lost.
So what was the reason? Take a look and see if you can see?
Turns out that the Sabre was more agile due to it’s hydraulic control planes; it had better visibility due to the raised position of the pilot and the bubble canopy. Both of these features allowed the pilots to adapt faster to the threats and opportunities that presented themselves. So lets just pick out some key concepts:
Agility + Vision + Inspection and Adaption + Action = Winning advantage
John Boyd rolled this up into the OODA loop. Clear observation of reality allows you to understand your position in things. Orientate yourself around the problem while taking into account your current capabilities should leave you with a number of options. Decide which option has the most probability of a successful outcome. Act. Rinse and repeat. The faster you can get around this loop the more likely you are to succeed. The F-86 Sabre pilots had the means to get around this loop far more efficiently than then Mig pilots.
John “Forty Second” Boyd’s analysis came with some provenance, he was no paper pushing clerk. The “Forty Second” nickname was earn from his time teaching at fighter pilot school (Later TopGun). He had a running bet that from a position in the sights of the trainees plane he could get to a kill spot with-in 40 seconds. It was a bet he never lost.
“Whoever can handle the quickest rate of change is the one who survives”
John R Boyd Born 1927 died 1997, Agile manifesto agreed 2001.
To find out more have a read of “Boyd: The fighter pilot who changes the art of war” here (https://www.amazon.co.uk/Boyd-Fighter-Pilot-Who-Changed/dp/0316796883/ref=sr_1_2?s=books&ie=UTF8&qid=1548105697&sr=1-2&keywords=Boyd)
Which leads me nicely to my own little take on the good old loop. The DEMO loop. As define earlier it borrows from all camps.
Observe any insight you have into the behaviours of your customers.
Define the problem. A problem being something that addresses the observed human need or desire.
Explore your options. Dive into the assumptions you have made. Make your constraints explicit. Avoid talk or solutions at all costs, as per previous articles unless you can see into the future you can’t know if your idea will blossom into a solution. Define the quickest method or experiment that will give you the insight you need to prioritise your ideas.
Make the experiment or if you have the correct level of insight make the first slice of your product. Remember you can use many different tools to make things, pen & paper, cardboard and stickers, wood and nails or software. Choose the method that will get the results the quickest and has the least maintenance cost. Once you learn all there is to know select the tool that will give your customers an amazing experience.
Observe how people use the things you make. Observe how people use your products, the problems that they experience and the desires they have.
Why DEMO. Well it’s easy to remember and we want to continually demonstrate progress but mostly we want our experiments to be as small as they can be while still giving a flavour of the full product. Think demo tapes, if you are old enough to remember cassettes (they’re coming back for some reason).
This loop should work at the micro experimental level as well as the macro product feature level. I’ve purposely avoided calling this an MVP (minimum viable product) because the term has come to mean a variety of different things. For me it’s a product that is put out simple to learn about behaviour. It’s probably faked in some ways, is unlikely to be stylistically correct and can be held together with bits of sticky tape. It is followed by an MMP (minimum marketable product) which is your first delivery to the public of a minimum set of features, styled and functional. These are often conflated so I now avoid using the term however if you plug these back into the sentence it would look like this: The loop should work at the micro MVP (experimental) level as well as the macro MMP (product feature) level.
The challenge that I’ve witnessed with this is that specialists bought into a team to perform everything from product insight and design through development into deployment feel like they’re de-skilling. After all designing product, developing code or understanding AWS deployment strategies isn’t like riding a bike. Unless of course every 2 days a new bike comes out that works in a completely different way to all the others. However there is no reason that sharing your knowledge with the team and building the teams skills should mean you de-skill. The only time that would happen is if you assume that time for skills enhancements is drive out by deadlines. The proposed loop should be focused on the highest value problem your team currently faces and although we want to traverse the loop as quickly as possible we don’t put a drop dead dates on it. Therefore deadlines should be a thing of the past. Plenty of time to keep those skills scalpel sharp. The other advantage is that the team is directly responsible for identifying the high value problems, ideate around them and delivering the kick-ass solution that resolves them. A very compelling narrative to give at any future career based meeting.
There are also three simple rules which will help guide the team:
- Personally do whatever is required by the team to be it’s best.
- As a team do whatever is best for the product you own.
- Ensure your product does whatever is best for the customer or potential customer.
These loops help bed in an experimental growth-mindset. They are designed to help teams navigate around a problem not dictate the tools that they use in each section. Teams should make the call as to what is the best way to perform each point of the compass. Obviously sharing what works and what doesn’t. To this end I would recommend at least holding a daily planning session and a retrospective. If you have multiple teams a session for cross team learning is also crucial.
Lastly remember there is no best practice, only what works for your context.
Many thanks to Jeff Gothelf, the Product Owner community and my agile colleagues at giffgaff, who have helped clarify this vision.
I hope some of the above helps. If you decide to go down this road and can share your story please let me know. Please also let me know your thoughts in the comments section below and allow me to clarify anything that I’ve probably not clearly defined.
