Key principles of experimentation and why we need it for a genuine digital transformation

Innovation, agility, creativity and speed - these values seem to have overtaken all strategic agendas and this one question seems to be on everyone's mind: 'but how do I get there'?

The Agile 'movement' has more or less won this war.

Vast majority of organisations have implemented an Agile approach by following some common practices. However, much of what they have implemented is faux Agile. While they 'seem' to be making the right sounds about tech-led strategies and software delivery practices, they are failing to address the wider issues around organisational culture and processes.

Especially in larger organisations we still see months being spent on budgeting, analysis, and requirements gathering before any real work starts. The scope is then broken down into phased projects with infrequent releases and asking for customer feedback is not even considered as part of the scope.

When the product is finally ready for production, there is often an unanticipated surprise. The worst one is that your customer requirements have moved on. Ouch! Further investments are required to play catch up with your customer demands and we have failed to produce a sustainable process for digitalisation.

In contrast, we see more lean and Agile organisations tackle this completely differently. They emphasise on experimentation. They test ideas, designs, products and even business models by giving their users early access. Based on feedback, they either bin the idea or iterate and expand the product further.

The benefits of evolving your products early and often and taking an experimental approach to product development are clear. What is not always clear, however, is how to embed experimentation in the new way of working (and thinking).

The key principles of experimentation (tools for Agile)

1. Work In Small Batches
2. Increase Dimensions Of Awareness Throughout Organisations
3. Emphasise on Empowerment of Teams
4. Customer Feedback

Work In Small Batches

Create small enough 'batches' or experiments that can be completed in a week or two. If your experiment doesn't turn out to be a success, bin the work. In some successful cases, work might still be required to be binned and rebuilt in a scalable way later on. Experiments are like prototypes, you might not actually use it in production but you have tested your hypothesis which has given you the confidence that whatever you are after, works.

What happens to digital transformation when we don't build in small batches

The bigger the batch, the slower our learning process. No team or organisation is an expert once they start doing the work. It is about their capability to learn fast and efficiently.

We often find it hard to apply this principle in large scale implementations, rollouts or upgrades of large enterprise systems. The architecture seems to be closely interconnected, it is difficult to do testing without requiring an integrated environment and deploy or releases of applications cannot happen independently.

If this is the case, then the infrastructure will possibly need working on to achieve engineering excellence first.

Just remember, the bigger the batch, the longer it will take before we know that what we are building is right. In other words, we can be spending a lot of our resource before finding out that we are on the wrong track. Don't fall for this culprit.

Increase Dimensions Of Awareness Throughout Organisations

Too often, people that make decisions are not the same people that build the solution. Your role is to shorten this gap as much as possible.

And let's not confuse strategy with operational decisions such as scope, timelines and budget. Only one of them can be fixed at strategy level.

For teams to make the right decisions about the other two variables, they have to have an understanding of the problem statement at an organisational level. Otherwise their decisions will be siloed and therefore not optimised in the value chain.

For this process to be efficient, we have to be sufficient in three dimensions of organisational awareness:

1.?????Individually focussed awareness. This is focussed on how emotionally intelligent each individual member of the organisation is.

2.????Group focussed awareness.?The second-dimension focusses of how aware an individual in the group is and its ability to regulate members within the norms that have been established.

3.?????Cross team boundary. The 3rd dimension involves how aware your group is of external boundaries, which means any feelings or concerns of important individuals or other interdependent groups within the organisation.

At all three levels, an organisation has a duty to encourage, coach and educate its employees for the benefit of the customer and long-term vision of the business.

Empowerment of teams

Empowering your teams is a natural progression from organisational awareness. Once you have created a high degree of organisational awareness across all three dimensions, you should be safe to delegate and trust your employees to make the right decisions. Give your teams the authority to create and change any requirements without the need for approval.

A rigid structure and approval processes is an indication that there is little trust in the decision making of your teams. This could be a consequence of the organisation's inability to coach and educate on its vision and values, hence creating a shortfall on organisational awareness.

Customer Feedback

Let's take feedback out of its context of technology for a minute and just think about it in terms of learning. It’s no secret that feedback is an important component of effective learning.?

Frontiers in Psychology , feedback is “information provided by an agent regarding aspects of one's performance or understanding”. It’s a reaction to a learners’ action that aims to engage, inform and increase knowledge by reducing “discrepancies between current understandings and performance and a goal”.

If you don't include feedback in your extermination cycle, it's not an experiment. Period.

In an ideal context, we would like feedback to be 'instant'. That's how we learn best. The further you are removed from 'instant', the more you compromise on learning, improving and closing the gap between what’s required and your goal.

Bringing back technology into the equation, the longer you are building something without asking for feedback, the more you compromise on your product.

Incorporating feedback into your development process isn't an easy task. Even though we 'see' how this makes sense, it is not always straight forward to understand how it can be embedded to increase speed, creativity and agility without the need to compromise on it.

The answer lies in your continuous integration and delivery model and the hierarchical structure of your organisation. Once you get it right, incorporating feedback and creating market leading products and services becomes an inevitable part of the process.