Process Doesn't Matter

(at least if what you're interested in is "making changes to improve a team's ability to produce software")

Process Doesn't Matter

I have a lot of conversations about the fine details of software process, because the software that I work on, is a lot like Pivotal Tracker in some ways and very different in others, and we're very deliberate about those differences. For instance: Points. We don't have them. We do all our velocity calculations and predictions with raw story counting. If we're going to add them, I want to be able to articulate very clearly why. So I talking with people a lot about why we haven't added them yet, and about what the point of pointing us.

Should we point? Why do we point? What does a point mean? Should we use Fibonacci or a powers of two or a linear scale or t-shirt sizes? Should we top out at 3 or 5 or 8 or 30 or 100? (If you top out at anything above 8 you are wrong.) Is pointing about the points or is it "about the conversation?" Are points really risk & complexity, or are they actually just time?

And on and on and on and on.

This kind of conversation is fun but I increasingly think that most of it kind of doesn't... matter? Do you point? Do you pair? Do you write tests? How do you point, pair, and write tests? There are good teams that answer all of those questions "no" and bad teams that answer all of those questions "yes."

There are correlations and tendencies. Some process decisions work better than others, and healthy productive teams are more likely to make some decisions than others. For example: The whole team pointing together and discussing it is almost always better than the team's manager unilaterally assigning points to tasks that they're not going to do.

But as levers for improving a team and the work the team is doing, I think process changes themselves are pretty weak. They're mostly downstream of more important factors, like:

  • Who is on the team?
  • What are their incentives?

If you hire people mostly for "interest in shipping" and "tendency to listen to their teammates" and then reward them mostly on what their team accomplishes, you're going to get software and it's probably going to be pretty good software. If you hire people for things like "abstract technical ability" and "ability to sound smart to people who graduated from certain schools and worked at certain companies" and then reward them for their individual contributions to the team as visible to the promotion process, you're going to get the software industry that we've got.