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 ...
Let’s talk about the elephant in the room. Most transformations do not deliver upon their intended results. Many of these transformations use sound agile methodologies, yet they fail to deliver on the expected results. DevOps came along and refocused the effort, but still, we run into difficulty with transformations stalling or even failing.
Current thinking puts the development (aka. delivery) team front and center in the transformation to rapidly enable the delivery of value to customers. For a team, they need to be able to have all the right skills and capabilities at the disposal so they can own their delivery processes. In complex environments with multiple architectural principles at play, this can be difficult to achieve. To cope with this, we create another team, the platform team, to enable the delivery team.
The question is, do I need a platform team?
Whether we are working from home or our offices, the challenge of ensuring the secure delivery of business value to our customers is a difficult one.
On the one hand, we need to enable our teams to deliver value quickly as this increases our ability to learn from our customers. On the other hand, we want to stop the unwanted exposure of customer data by ensuring secure delivery. These two goals may seem at odds. After all, a high-rate of change increases the chance something goes wrong. This results in a natural tendency to want to slow down the delivery process. However, there are ways to ensure you get both speed and safety.
Let us look at some of the common failure patterns and how to approach creating a strategy to remediate.
We talk about this a lot but do not always do a good job of explaining why it is so important. I would argue not understanding this difference and developing this mindset can cause your whole transformation to stall.
So what do we mean when we say project vs product and why is it so critical?
Read below for my thoughts on the topic.
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
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.