In a previous post, I suggested IT functions should create their own shadow IT capability to accelerate innovation by delivering prototypes quickly. It’s great to see how many companies have embraced this approach, often by setting up an ‘innovation lab’ alongside the technology function.
However, a number of these labs are struggling to get things working well. Recently, I’ve been doing some work with a digital consultancy to take a number of specific lab case studies, look for underlying causes of the issues, and find a way forward. We’ve found two groupings of issues: Process issues and People issues. Both of these are quite big topics in their own right, so I’m going to look at the Process issues in this post and the People issues in a following post.
One concern I hear consistently from executives is “we don’t have the right skills for digital”. The solution seems to be to embark on a large external hiring push to bring in many more ‘digital’ people. I won’t focus on the people aspects here, but what we create with this influx is a set of new expectations and approaches, and likely also, a disconnect with how our organisation currently operates. Don’t get me wrong, disconnects aren’t always a bad thing, sometimes they are good catalysts for change. But the benefits only flow if you are prepared to change the way the rest of the organisation operates.
At a small scale, a lab can often work without disturbing the host organisation. But that isn’t scalable, and as the lab takes on more projects, increasing friction is generated where it connects to the rest of the organisation. This is where we see the Lab Process issues consistently turning up.
The fundamental reason is that agile delivery needs to consume services in their widest sense, in near real time. And if your digital protagonists have arrived recently, they’ll be perplexed as to why this doesn’t work. Let’s take a specific example. On-demand (cloud) infrastructure is so commonly available that no ‘agile native’ would think they have to plan their infrastructure 2-3 months ahead of time. But in traditional technology delivery, there’s a much more planned and deliberate approach to infrastructure delivery to make the best use of scarce technical resources. If you keep these two apart, it’s fine. But in the end, they have to come together, and that’s when the friction happens. If we’ve done nothing to modernise these common services teams ahead of time, there’s no way they can meet the demands that agile delivery places on them.
And it’s not only infrastructure delivery where this happens, it’s a long list of activities inside a company that need to be reworked to meet the needs of agile delivery:
- Funding and business case approval
- Data sharing
- Risk management
- Service introduction
So what’s the solution?
The biggest challenges you’ll face in creating and scaling a lab will appear in the places where the lab needs to interface to your current activities. Start small, and use the time and space this creates to modernise each of these common services areas so that they can provide an on-demand service. It’s this approach, done well, that successful organisations are using to reap the company-wide benefits of agile redesign.