Getting Organised - Organisation organisation at MHR
At some point, as a leader, you will need to "organise your organisation". Everyone will tell you the "right way". But there is no right way. Some ways will work for you and some ways won't. I won't write about the right way. Instead, I will tell you what we are doing at MHR and how we are doing it.
Organising an Organisation
This will likely be the first of many articles taking you through our decisions and how they play out. You will see what we did right, did wrong, and learned as we went. You can draw your parallels and get ideas for navigating these waters your way for your situation.
The problem we face
MHR is in a position that many established businesses find themselves in. We are several generations of the core product idea in, with almost 40 years of building software behind us. In those ~40 years, we have made many decisions based on the best practices of the time and the information available to us. The ever-evolving world of technology and the recent speed at which it has changed have led to those decisions creating complex ingrained patterns and ways of working that aren't conducive to the modern practices of the world in which we operate now.
We have a reasonably sized organisation of ~120 engineers split over ~15 teams. Despite the majority of these having been with the company for less than 5 years, the teams follow processes defined over 10 years ago, if not more. We are using DSDM and time-boxed delivery windows - waterfall, despite DSDM claiming to be Agile - and have recently moved from a quarter-by-quarter release cycle to a bi-weekly one. That is where we stand now—a slow release cadence and many historical processes.
Where do we want to be?
There will be no major surprises here; I don't think. We want to reach a point where we deliver value continuously. Engineers and Teams should deliver things daily in small increments of value. We want to be responsive to the needs* of our customers and be able to adjust our direction in reaction to changes in the market or in the broader regulations that are a part of our industry. We want to be agile.
* Notice that I say "needs" here and not wants. This includes an adaption to how our product org assesses and prioritises ideas. Hence, we deliver the work with the highest positive impact on our customers, even if it is not what they shout the loudest about. Proactive, not reactive.
How will we get there?
Now that's the kicker, isn't it? Figuring out how to get from A to B. We haven't yet gained full clarity on some parts of this plan. As with anything, we know there are known unknowns and likely unknown unknowns to face along the way.
It starts with boundaries. We are sandwiching this problem at first. We have gone to the upper bound and got the broader buy-in on why we want to go through this transformation, and we have set the goal to follow scrum in all product teams as our first step away from DSDM by the end of 2023. Then we have gone to the boots on the ground. We have hired a Head of Agile Transformation and Agile Coaches to help the teams transition into a new way of working. They are, in turn, partnering with each product delivery team 1 by 1 (or 2 by 2, 3 by 3 etc., as we hire more coaches) to help them transition into more Agile ways of thinking and working.
We're now focusing our attention on the filling of this sandwich. Beginning with determining what we will consider success and then how to measure the indicators of this success. I don't think anyone here will be shocked that we are starting by utilising the DORA metrics. These will begin to form/play into KPIs we will use to help drive our transformation and demonstrate our progress. No, we are not about to set ourselves up to fall foul of Goodhart's law. We're not setting goals on the number of daily deploys or specific numbers. Our goals will be focused on reducing the time to production for work and increasing the number of deployments per time period (2 weeks at first, then weeks, then days) measured in a % of our starting baselines.
That's not a very big sandwich!
No, it's not. But that is deliberate. The biggest mistake and cause of failure in these types of projects is doing too much too quickly. We could turn around and tell all the teams that tomorrow they need to use scrum and that we have set goals to reduce how long it takes to get work into production. But if we did that, the teams would struggle to operate as they try to work out scrum without support. The quality will drop as they feel the pressure to deliver faster while trying to change their ways of working. And ultimately, the effort spent on getting business buy-in is wasted as the project is pulled because the state of things is worse, not better than before.
So in the spirit of Agile. We are starting by delivering the smallest slices of value we can in our transformation journey. We are gathering data, assessing our options, what delivers the next most valuable change, and then going around again. After all, it would be heretical to deliver an Agile transformation in a waterfall approach, wouldn't it?
What's next?
I can't tell you exactly what will be next up for us in our transformation. Or when the next learning will come. However, I can talk a bit about one topic - Team Structures. So expect another post in the next week or two talking about Team Topologies and how your system design impacts your teams and your teams impact your system design.