The Greek philosopher Heraclitus was onto something when he said many years ago that

A saying as true today as it was for Heraclitus in Ancient Greece.

Today, businesses are impacted by change. Competitors introduce new capabilities or services, customers' loyalty shifts from brands towards value propositions, and new and exciting players disrupt the market altogether.

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.

Purpose

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 ...

Continuous improvement is at the heart of any agile approach. But where do we start? And how can we know that our improvement initiatives are moving the needle? This blog post expands on the ideas from what throughput can tell you about your team and provides some additional thoughts to help you truly embrace the following principle from the agile manifesto:

Well-designed metrics provide your team with insight into where to focus and look for improvement opportunities. They also provide you with a baseline, a measuring stick to assess any improvements.

In a previous post, I focused on what we can learn from a metric as simple as throughput. Here we take it a step further.

Recently I was on a call chatting with a group of senior leaders and the topic of work-life balance came up. More explicitly, how “now he seemed to have so much less time at the weekends”. Asking a few questions of the gentleman who brought this up identified that he had been newly promoted to a VP role.

Which got me thinking about the challenges as you move between roles in larger organizations. Expectations change as you move from an IC to manager to director to VP or above.

So I thought I’d jot down a few thoughts on the matter.

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?