Often when we first engage with organizations, we find they enter the conversation with a clear idea of what their problems are. Sometimes they get it right and other times - more often in my experience - they are focusing on their own belief of where the problem lies.

For example, if the problem is the deployment process, why does the automated script take 5 minutes to run. Having successfully worked with development teams to automate deployments of their major platforms, being told deployment is the issue seems like the wrong place to focus. If it still takes weeks to get code into production, the problem lies elsewhere. Perhaps our test verification takes five weeks?

Ok. Well, if deployment of code isn’t the issue and testing is, let’s focus there I hear the cry! Well, let’s see…

Following on from my blog post covering the first two ideals from the Unicorn Project here, I’d like to continue discussing the next two of the five ideals from the book.

The next two ideals from the Unicorn project focus on two important factors of the improving flow in your organization:

• Continuous improvement of work

• Psychological safety

Part of the continuous improvement of work talks to the importance of challenging the status quo, something that can be difficult without psychological safety. Both are necessary to deliver better outcomes from working together.

Let’s delve into these two ideals.

Your organization is changing and undergoing transformation. You’ve rolled out Agile (Scrum and Kanban), you’ve scaled it (SAFe, LeSS, etc.) and even applied DevOps practices (you’re using Kubernetes right? Isn’t that DevOps?) Yet still, millions later, the purported value has yet to materialize.

So how come, after all this work, we still have not realized the value?

Despite all the evidence to the contrary, perhaps we are still stuck in old ways of thinking. Real transformation requires new ways of thinking about the problems and in the case of the examples above, have we really changed? (Kubernetes is an orchestration framework for containers and does not equate to having adopted DevOps).

With millions spent already, what are we missing?

You have an idea, a spark, concept of how your organization could do things better. Now all you need is to work out how. A typical pattern from here is:

1. Realize you need more information or organizational buy-in

2. Engage consultants to show you how

3. Consultants leave

4. You implement and realize all your goals!

Except step 4 so often doesn’t happen. You have the report, you’ve confirmed what you thought and have a solid plan, but at execution, everything goes wrong.

So what can you do to help your idea succeed once the consultants are gone?

As we introduce technology into our organizations and transform the way they deliver value, bureaucracy is often cited as a common barrier. So why have it at all?

As organizations grow, the “side of desk” style of management eventually starts to fail. Communication becomes more complex as you add more people and more teams. For the company to continue delivering high-quality value, they put standards into place. Governance exists to support the continued delivery of business as usual and the satisfaction of regulatory requirements. However, too much management feels bureaucratic. What would be great would be to have just enough to support your governance needs without hindering innovation.

So how do you create your Minimum Viable Bureaucracy (MVB)?

Today I want to talk about a common digital transformation topic I get asked about, application modernization. More specifically, how everyone is doing it but so few successfully. Typically the conversation starts with one of the following:

• “I need to move off my legacy system, how can I use containers to do this?”

• “How do we move to a cloud-native microservice architecture?”

• “We’ve been told to move everything to the cloud, how do we do that with thousands of applications?”

Often, my initial answer is another question: “Out of curiosity, how did you get to this as your solution?”

Strangely, at that point, it often falls off the rails.

I’ll answer these questions in more specifically at the end, today though I want to talk about complexity and the need to experiment.

One of the biggest problems here is that these are all solutions looking for a problem. While we hope they may be appropriate solutions, hope is not a strategy. On their own, there is not enough information to provide guidance an...