Some guiding principles that have emerged for me over the years of inheriting somewhat broken Product Development organisations – and the approach that has worked well for me.
1. Start where you are
If you’re relatively new, or taking on a new area, first do no harm. Chesterton’s Fence applies. Without a good understanding of the local context and complexities, you risk dismantling or destroying something that is actually important. This may sound obvious, but you’d be surprised the number of times a new person arrives and immediately leaps into solution mode before they’ve got a good understanding of the problem space. This is dangerous.
2. Horses for courses
Don’t be tempted to leap straight to a standardised model treating everything the same and applying your cookie cutter. It may seem more simple, but not every area will need the same skillset or shape of the team in order to deliver value early and often. The feedback loops that exist may well be very different. For instance, the shape of a team that is dealing with the integration with some 3rd-party COTS system that they don’t control the code-base for will be very different to a team doing green-fields digital front-end portal development and very different again to a team that is mostly doing configuration of some 3rd-party platform. Reality is often more complex, and that complexity is often only obvious when you get really close to it. Even within a relatively small organisation, you’ll probably find significant variations that matter.
3. Measures that matter
This is partially an extension of the first point, to start where you are – but I’ve found it really important to not just have a picture in your head, but to also have some concrete measures as a baseline before you set off. I’d recommend the DORA metrics as a useful starting point. No only are those fairly easy to quickly measure, there’s a solid evidence base behind those measures being meaningful to the performance of your Product Development org. They’re a great set of things to focus on shifting the dial as well and it’s really good to be able to look back and see how far you’ve come. You could add to the DORA metrics with other measures that matter, but don’t go crazy. Keep it simple. Any more than a handful of measures and you lose focus.
4. Experiment and iterate
Rather than picking some off-the-shelf solution, ask the teams themselves to consider how they might improve those measures that matter. Give them room to experiment and learn, iterate and improve. Centralised change rarely works and creates a lot of risks. Even when it appears to work, it tends to be lipstick on the pig. From my experience, SAFe is one of the worst offenders in this space. It gives the appearance of “agility” without really addressing or confronting a lot of the bureaucracy that you actually need to cut through for meaningful change. Of course, for this to work you need to confront that inexorable desire for the centre to control the change. Instead, the centre should focus on making it safe for teams to try things and learn, own their own way of working.
5. Be patient!
“Slow is smooth and smooth is fast.” Yes, it’ll take time, but it’s worth it. Just keep repeating the strategic direction of travel, but don’t ask for a timeline – I’ve found it actually goes faster if you don’t ask.