New beginnings throw working practices into sharp relief. What worked somewhere doesn't necessarily work somewhere else. Even quite small decisions in tool selection and working practice can have a big impact when they become part of the working methodology. What do I mean? Let's say a team of 10 developers have been working on a new product for a year, they've made some progress but management wants to speed things up so in short time, 10 becomes 30 developers. Do they suddenly see a speed up in the throughput of work? No. Should they expect this? No. Why?
If you've not read the Mythical Man Month then perhaps this is a good time to add it to your collection. I read it at University as part of my software engineering minor and it's a book that has resonated in the last thirty years of building software... until I read the Unicorn Project. Why? Because everything described in these books actually happens in day-to-day software engineering practice - and has done for over forty years now.
Despite regular reminders, software engineering is still a mystery to many. The naive view persists that we can treat software engineering as a manufacturing process - more people equals more output.
Software is not an output from a software engineering process. All there are are outcomes. And often because the outcomes are abstract it's hard to know when to make a change.
Here's another example. A group of the best developers and architects are pulled into a project that will define the infrastructure for a project. They build the machines, or kubernetes infra, they create the pipelines, they create the standards. This is a platform for the rest of the development organisation to use - but this team of individuals sees themselves as too senior to support the developers in using the platform they have created. They will create, but not support. And why should they? They were persuaded to create this new thing by management who had no concept of what they would build.
Whose fault is it that developers cannot reliably deploy to the new infrastructure? Is it the developers shortfall of knowledge? Is it the architects fault for making it too complicated? Or not supporting it? Is it the management's fault for staying too hands off with this process?
So how do you help someone understand something different in a different way?
Similarly when we build deployment pipelines - do we think that having Pull Requests and working in a Gitflow manner is helping our customers?
It's the start of conference season, and I'm shocked by the price/value return for many of them but one I can recommend without having been there is the Fast Flow Conference in London at the end of May. This brings together the Team Topologies experts from around the world. Applying systems thinking and Lean methodologies to our software delivery processes is crucial, now more than ever. Small decisions have big consequences. I hope to see you there.
Enjoy your Easter break!
-- Richard
Doing Gitflow means you’re leaving Business Value on the Table
Published on April 4, 2023
 |
Gitflow means using different branches to develop software. It was invented to help software projects cope with multiple developers making simultaneous changes to a single codebase. It was a good thing when it was invented – better than merge conflicts – but it was only ever a workaround to a workaround. Namely how do you… Read More »Doing Gitflow means you’re leaving Business Value on the Table
