Do You Design Your Software Process for Flexibility or Repeatability?
Back in the ’90s, everyone was into repeatable processes for software.
What that often meant was we were supposed to do all projects in exactly the same way, regardless of the type of project. We were supposed to document what we did and deliver the same documentation each project. It didn’t matter how much innovation we needed, how many experiments we needed, or if we needed to iterate on the architecture for one project and not another. We were supposed to treat each project the same way.
Repeatability was supposed to provide us with a guaranteed outcome every time—if we could just define the right process. (Does this sound like requirements to you?)
I see the same problem with agile now.
Well-meaning people think agile means Scrum. It doesn’t. You can use an iteration-based approach and not use Scrum.
Well-meaning people also think kanban is a tool only for manufacturing. They don’t realize that kanban can help a team see how the work flows—or doesn’t—through the team.
Process repeatability is great for manufacturing. Manufacturing design looks a lot like software: You iterate through possible solutions. Once you understand how to build something, the manufacturing itself is about replicating the making process. You want repeatability for that.
But software is not like manufacturing.
Software is about learning about the problem as you solve parts of it. This is why users often have change requests once they see a version of the solution. When you hear, “You gave me what I asked for but not what I need,” you and the customer are closer to understanding what the problem is and how to solve it.
We can create guidelines for our processes and projects. If you work in a regulated industry, you might even have rules. But how do you use those guidelines or rules? You have flexibility.
I like the flexibility of saying, “Let’s make sure we always have more than one pair of eyes on the code” and being able to use code reviews, pairing, or swarming as my options. Some projects require formal code reviews. Some don’t. The idea of “multiple eyes on the code” helps me know what approach to use in this context.
Repeatable process is a way to stop thinking about how we work—what we do and how we might improve.
If you think you need a repeatable process, go meta. Think about what you want from a repeatable process, and create guidelines that help you think about how to achieve those outcomes.
Your process works in your context. As soon as that context changes, you might not be able to use your current process. If you think about the outcomes you want instead, you’ll have a better chance of creating a process that works for you.
I find more comfort in people thinking about their work and process than I find in repeatability. How about you?
