Are you a software creator or a software maintainer? If this sounds like a trick question, you might be on what I'm calling a build/operate team. I'm actually not sure whether there is a standard term for this. It is at least similar to a "product team" as opposed to a "project team".
So we are talking about a team which owns a particular sort of value and is staffed to provide it, including as much of product, design, engineering, testing, support, etc, as feasible.
One way to say this is "if you build it, you support it". In that case, a handoff from a build team to a maintenance team is an anti pattern.
But when I showed an early draft of this essay to someone struggling with these patterns, they objected. But we don't want everything to be owned by the last person/group that touched it! We don't want to make it impossible for someone to chip in without committing themself unto generations to come!
That's what made me think of flipping "if you build it, you support it" on its head. What if we formulate it as "if you support it, you get to enhance/replace it"? Especially if your organization always seems to neglect maintenance activities, putting them at the front of your mindset may be helpful, but this flip also helps address some of our paradoxes from before.
Is something owned by the last person who touched it? Not really, we're aiming for a world in which someone who jumps in temporarily is working with an owner who is engaged enough to understand what is being done, has the final say on how it is done, and knows how it ties into their ongoing responsibilities.
Can we reorg without damaging the principle that people build things and also support them? Yes, although to follow the rules a reorg has to assign the ongoing tasks which come up on a regular basis, as well as the glamorous new things which we are getting all excited about.
"Products Over Projects", by Sriram Narayan, https://martinfowler.com/articles/products-over-projects.html .
No comments:
Post a Comment