The A, E, I, O, U of agile innovation

Following on from an earlier post (https://ronhealy.wordpress.com/2020/11/14/go-far-avoid-the-fogs/), I have developed a memory tool as an easy way to remember the agile approach to iterative innovation. It is a simple-to-understand set of activities that should be suitable for all agile innovation – no matter how big or small the innovation effort might be (whether it is a new idea, a new feature or even a new product). If any of these steps are skipped, opportunities may well be lost – opportunities to evolve towards a desired result or opportunities to exploit unexpected outcomes for new ideas. Having said that, as with all-things-agile, it is not a doctrine, it is a starting point and it should be open to adaptation and evolution as you see fit.

[click below to ‘read more’]

The A, E, I, O and U in this mnemonic stand for:

---

Of course, these steps could be taken in a variety of different sequences (and some more than once) so they should not be interpreted as a simple 5-step sequence that’s guaranteed to result in Innovation. For true Innovation to be even remotely possible (let alone to actually happen) all participants – not just the ‘creatives’ – need to feel like they are empowered, encouraged and permitted to try (and, by definition, not punished in any way if they fail). And if true innovation is to happen, it probably isn’t because of some series of headings in a blog post. These are just reminders to try put the eureka moments in a repeatable structure that will give you the best chance to leverage any innovative idea that does raise its head.

For individuals, teams or organizations that are not particularly familiar with flexible, fluid innovation, the AEIOU approach is a reasonable way to begin. And then evolve (hint: that’s the important bit… “evolve”)

Analysis:

The analysis stage could be anything from analyzing an entire market, a product space, a specific product, a feature, a process or a technique. Analysis could be of a very narrow focus to see if opportunities exist in a specific niche or it could be a very wide and very open-minded view. It is rarely a once-and-done stage. It can – and should – happen as often as appropriate for a given scenario and focus may be iteratively and incrementally narrowed as more learning is derived from the analysis or from any other stage in the innovation lifecycle. In fact, every time there is new information or a new outcome that leads to new or increased facility for understanding (or rethinking previous assumptions), some level of analysis can be expected to happen again… and again.

Innovation in the complete absence of analysis is hard to conceptualize. Most innovation happens as a result of understanding some situation or problem, at least on the surface level. Sure, an innovation can be proposed without any analysis at all, but the likelihood that it will be truly innovative is pretty slim. True innovation usually comes from awareness of the area in which the innovation is positioned.

Everyone should be encouraged to participate in Analysis. This does not necessarily mean everyone should be in the same room for an extended period (although that can be good, as in the Design Sprint approach!). But there should be some agreed & consistent forum to facilitate collaborative Analysis & the communication of results, interpretation and ideas. While Analysis itself is an activity that people generally carry out independently, it is the communication between people who have all taken a look at a given subject that leads to real synergy and creativity.

Analysis is not an end in itself, though. It is not something that should just be ‘ticked off’ a list of activities and it is not something that can be done the same way by every stakeholder. Some people like to read documents, others like to look at diagrams while still others like to think or talk about a given subject. For that reason, individual participants should define how best to carry out Analysis activities. In addition, while Analysis is not something that can easily be scheduled into a given time-slot, it can (and should) be time boxed. Even the most long-term Analysis (e.g. for a PhD) has a time constraint – the only difference in Agile developments is that the time boxes are smaller! Ultimately, the way to handle time-boxing will depend on the team and the scenarios but everyone should know there is a time limit. In an Agile (e.g. Scrum) context, this can be a set number of hours set aside in a given Sprint.

Evolution:

The essence of iterative innovation is an evolutionary approach. Instead of packaging dozens of new enhancements into a given develop-and-release cycle, dropping it into the market and hoping for the best, smaller incremental enhancements are more effective for the following primary reasons.

1. It is quicker, less costly and less complex to develop smaller, evolutionary increments than large, multi-faceted increments. Of course, the definition of ‘small’ and ‘large’ are dependent on the exact scenario but the general rule stands. If smaller increments are implemented and are successful in moving towards the ultimate goal, this is great feedback. Equally, if a smaller increment is released and causes a complete re-think, this is equally valuable (perhaps more so). Either way, the feedback is realised with less (time or money) cost by developing smaller increments than larger increments.
2. Smaller, more regular enhancements reduce the time between development and feedback (whether from the Team, the Business or the Market). Since feedback is crucial to understanding whether things are still on track for the desired outcome, whether a pivot or re-prioritisation is required, or even whether some new opportunity has been subsequently uncovered, then the earlier the feedback can be assimilated, the better.
3. By making smaller incremental changes, any impact of such increments can be isolated to the enhancement itself. By packaging multiple enhancements into a release, it might be difficult to understand which enhancements contribute to the impact or feedback. This isolation of variables so they can be tested independently is well understood and commonplace in both Scientific and Testing circles but maybe not so much in Product Innovation and Corporate circles.
4. Incremental developments can help to reduce knowledge silos by ensuring that Teams are not working in isolation on bigger enhancements that take all of their time and attention, thereby limiting their ability to maintain awareness of what others are doing. Large-scale developments tend to cause Teams to focus on their own roadmap, even where that roadmap is (conceptually) integrated into a ‘bigger picture’. There are times when this is not an issue, of course (e.g. where Hardware and Software teams are working towards the same target this can be done separately in many cases). However, at other times, it can be very detrimental to success.

There are numerous other reasons why a more evolutionary approach to development, improvement or innovation are more effective than ‘big bang’, all-or-nothing increments. This does not necessarily mean that every small increment is a potential release to the Market. Instead, each small increment can be viewed as an opportunity to validate assumptions on everything from cost to viability to suitability, even if it is only for internal stakeholders.

Implementation:

Even during the implementation phase, constant iterative evaluation is important to ensure that (appropriate) incremental enhancements are behaving as expected and achieving the expected outcomes. The implementation stage is not simply about deployment or release. Implementation is a periodic activity that includes everything from implementing an initial Proof of Concept, high-fidelity prototype or similar to implementing a market release for a Product and even to deploying Products or Features into customer environments.

At each stage, where any new enhancement or increment is implemented, it should be iteratively reviewed and evaluated with the intended outcome in mind but also with a view to exploiting additional previously-unexpected outcomes from each implementation.

That is not to say each release should be as small as technically possible, only that the starting point should be for smaller incremental releases unless there is good reason not to – and even then, small increments can be released without publication / promotion, which can also add value in terms of testing and validating functionality outside the critical glare of consumers and users.

Outcome:

No matter how much a new increment is designed and tested and no matter how well it works ‘in the lab’, the real test is ‘in the wild’. The old adage “The proof of the pudding is in the eating” stands especially true in this regard. No matter what the theory, the ‘ingredients’ or the specification and no matter how well the end result matches the original expectation, the success or otherwise of any innovation or enhancement can only be realised after it has been made available to others – whether that be Business and User representatives, a focus group or the intended public audience.

This activity is not a once-and-done. It is a repetitive and iterative activity. A new feature or enhancement – or even a new product – can meet or exceed expectations at one stage of its life cycle and then perform completely differently at another. Sometimes, the early stage is great and it tapers off. In other cases, the early stage might be disappointing but it might become a ‘slow burner’. The modern Product professional should not simply fire & forget, moving onto the next shiny new feature. Even the oldest legacy Products can have a radical impact (e.g. radio waves facilitating the democratisation of IoT).

Product professionals should repeatedly monitor their products and each subsequent release for any change to the expected outcomes. Adding a new feature or innovation is just one point in time to focus explicitly on the outcomes of that new functionality but also to re-visit previous outcomes to see if they are still valid results (i.e. outcomes) are as expected & desired.

Understanding:

At regular intervals, Stakeholders should assimilate all information made available (e.g. by product usage, market & user research, internal & external feedback etc) since the previous information-sharing exercise, and feed it back into their continuously evolving understanding of the complete ecosystem and environment of interest. This should be both an intuitive, constant evolution of understanding as well as a formalized activity within the lifecycle.

By pooling and centralizing various different perspectives, the lessons learned at each step along the way can feed into a new round of innovative thinking, starting again from the (re)analysis stage. Each new attempt to socialise and compare understanding should start with previous assumptions and understanding, and should compare and contrast.

Summary:

Of course, this is a very simplified overview of incremental or evolutionary innovation. The reality is much more complicated, more fluid and more evolutionary than many of us – especially in Strategic and Planning circles – would like. Ultimately, however, we can’t impose our plans and ideas on reality. Reality is always imposed on us. Logically, therefore, it makes sense to constantly and iteratively re-evaluate the specific reality we are faced with at every phase of the iterative innovation lifecycle.

The AEIOU approach might help to remind us of that and might allow Product innovators to put some sort of repeatable shape on their activities.