Digital and Innovation
DevOps – More than a relabelling
30 Aug 2021 - Estimated reading time: 3 mins
In my previous blog post I sketched out the types of challenges our team faced when incorporating DevOps ideas into our software development. A charitable interpretation of that post might be that I was whetting your collective appetites for the details to come. A less charitable interpretation might be that I didn’t get down to brass tacks! If you tend to the latter view, I’ll try to remedy that here with a post about the behaviours, expectations, and process challenges that we encountered.
I’m going to structure this post around the different roles within the team, as I think there’s considerable variation in how each role is affected by the switch to DevOps. In particular, I want to focus on the effects of the switch from a batch paradigm to a flow paradigm. To recap the previous post, the flow paradigm aims to deploy new features to production as soon as they are complete, with the batched paradigm aiming to periodically deploy collections of features.
Let’s start with the project manager. (There are lots of different titles for this role, including the faintly atavistic “tribal lead", if the Spotify model is your thing). Whatever the title, I mean the person tasked with managing the team’s workload and coordinating delivery of new features.The shift to flow can be a disorientating experience for anyone accustomed to expending considerable effort planning which features will be included in a given version of your application. A version is really just another name for a batch of features and batches are what we’re trying to avoid.
When flowing features out to production, versions become somewhat arbitrary in that they are simply what happen to be complete at the end of a sprint (I’ve not forgotten semantic versioning, but that’s for a future post). It can be very hard letting go of the comfort that comes from having a plan, extending months into the future, of features tied to versions tied to dates. This can lead to a phenomenon that I’ll call relabelling (I’m almost certain this isn’t a term that I coined but I’ve not found a source to cite). Relabelling is when, instead of a fundamental change to the way we work, we subconsciously cleave to our deeply ingrained ways by just changing the names of things. For instance, we might try to move away from versions to something more flow-oriented but find that we’ve just relabelled versions as phases or epics or milestones.
Relabelling is when, instead of a fundamental change to the way we work, we subconsciously cleave to our deeply ingrained ways by just changing the names of things.
David Boyle - Technical Architect
If you find yourself discussing at length whether feature X should go in phase Y or phase Z then you may have subconsciously relabelled, rather than changed, your processes.
Let’s move on to architects. Architects, like project managers, gain some semblance of security by performing up-front analysis. That is, they attempt to divine the evolution of an application and, given that evolution, specify a gross structure that will support the application’s functional and non-functional requirements. The change in behaviour required here is to dial down the amount of up-front analysis and instead focus on defining “just enough architecture”, as Kent Beck puts it, to get the project started. Like everyone else on the team, the architect needs to then react as user stories are drawn into sprints and modify the architecture to satisfy the requirements as they actually are, and not as they were perceived to be at the outset of the project.
Finally, let’s talk about Quality Analysts. If a bug fix that takes an hour to implement precipitates a day’s worth of manual testing then our flow is going to be…well… viscous! The QAs at Hymans are some of the most knowledgeable I’ve ever worked with. They are often qualified, or part-qualified, actuaries and have a far, far stronger grasp of what the actuarial models are doing than I do. They also tend to be adept at creating models in R or VBA. This means they can quickly get up to speed with writing automated tests – which is fortuitous, as nothing improves flow more than a comprehensive suite of automated tests.
What about devs, you may be asking? That will be the focus of the next instalment.
0 comments on this post