Recently I was talking to one of our customers about how they feel about our services. This reminded me again of Dave and my conversation on the Definitely, Maybe Agile podcast on this very topic. Which is indeed the topic of this latest entry in our business agility series: why business agility needs customer interaction.
As we have in previous weeks, we will highlight three areas of consideration on this important topic, building on last week’s topic of business agility success depends on feedback loops.
Now we’ve known this for decades. It has been common knowledge that it is an essential skill to frequently ask your customers to guide your direction yet, perhaps in recent years it has become truly essential. We see companies that if they take their eye off the ball can find themselves becoming obsolete extremely quickly. The pace of change is only accelerating.
Over the last few weeks, we’ve talked about five specific benefits that Business Agility can bring to your organization. Among them are:
While Business Agility brings many benefits, implementing it effectively is a challenge. When adopting Business Agility, businesses are bound to encounter both internal and external challenges.
These challenges must be addressed if you wish to get the most benefits from implementing business agility into your organization. Below we discuss five of these challenges. We have also discussed these on our Definitely, Maybe Agile podcast. Let us take a look at these obstacles, and how to work through them.
The modern marketplace is constantly evolving. Customers expect a fast return on investment of both their time and money. The complexity of many technology solutions now resides behind easily consumable web interfaces and SaaS services, making it easy to rapidly switch to alternative products. It is easier than ever to “try before you buy”, and if you don’t feel like you are getting the value, try something else. To counter this, consider how introducing Business Agility practices can protect and improve your bottom line.
Introducing organizational change is a tricky business, especially when it involves new technology. Even seemingly innocuous changes to technology can have a far-reaching impact on your organization, disrupting the ways you work. Your initial vision of a smooth implementation, rapid adoption, and a high return on investment is easy to say, not so easy to achieve. For example, it is widely discussed that 70% of transformations fail.
Governance is something of a dirty word. It often generates a visceral reaction in people, conjuring up images of red tape, bureaucracy and time-consuming audits. These are seen as roadblocks to progress, innovation and adoption of new ways of working. This is especially true when we are looking to accelerate the rate of change or delivery speed, such as commonly occurs when adopting DevOps or Agile practices.
Below, I will discuss why we have governance, how it gets applied and some immediate approaches you can look at to help change your ways of working.
Let’s start with the purpose of governance. Governance practices intend to manage risk. I sometimes hear that “this doesn’t apply to me. I’m in a small start-up,” but all organizations, whatever their size, need to manage risk. In one form or another, we are all subjected to governance. In larger organizations, we have added complexity to deal with in creating and managing risk. It is also true that heavily regulated industries ...
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:
Realize you need more information or organizational buy-in
Engage consultants to show you how
Consultants leave
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?
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...