The observations made in response to my QA posts were interesting. Unsurprisingly, there is a lot of lived experience out there. What is surprising is that a lot of people commit to strong opinions about what the "right" process is for software development.
This is an area that I find myself conflicted, as I have my opinions as well. But what I have learned is that the right thing depends completely on the context. I'm sure this may bother folks who are very Type-A, consultants, or otherwise box checkers. I find that those camps tend to be inflexible, and care more about their prescription than they do the outcomes.
I know this is obvious, but there are an awful lot of variables to consider. Company size, budget, individual experiences and capabilities, culture, industry, legacies of all kinds... no two situations are the same. When I say that I learned this, I mean that I learned it the hard way by being prescriptive about process, without regard to context, and got it very, very wrong.
There are a lot of themes that are universally right, but I've never really enumerated them. Themes are less specific, and allow room for context. For example, smaller, self-organizing teams might be a theme. Fewer, tightly-scoped meetings are a theme.
But the biggest thing that I come back to, when it comes to process, is to treat it like a feature itself. That means define the problem and (mostly) agree on that definition. Write down the acceptance criteria, so you can tell whether or not the process is solving the problem or arriving at the desired outcome. And above all, let it change and evolve as you discover new things about it.
That last part is the thing that I rarely see. It's the box checking problem, with disregard for the context. We've come to accept all kinds of ceremony and convention in our line of work that doesn't actually serve the desired outcome, which is shipping great software. "Planning poker," I'm looking at you.
Everyone wants to write a book about the correct way to do stuff. It might be abstract, but correctness is contextual. Being a good manager doesn't mean following a step-by-step manual, it means getting the context, and ruthlessly adapting (or rejecting) the process to meet the situation.
No comments yet.