Process Consensus

Managing a product is hard work. Managing a product with a large codebase is harder. Managing a product with a large codebase and dozens of developers across a half dozen teams is madness unless you have a common process. However, too much process gets in the way of what many think of as the real work of programming. How do you strike a balance? What process is helpful, and what becomes just a burden?

To start answering this question, we must ask a few more targeted questions.

1. Why do we want a common process?
2. What does the process provide?
3. How can we let the process deviate over time or between teams to fit different needs?

By asking and answering these questions, we can start to find a place for common work strategies without slowing down the act of coding too much. Before we go on, though I should say that reducing the speed of coding isn't always a net negative. In fact, as with any scientific endeavor, deliberate action is usually preferable to slapdash chaos. While it is certainly possible to plan to much, it is even easier to plan too little and get trapped with the poor decisions, whether those choices were intentional or not.

Why do we want a common process?

Busy Kitchen by Nathan LeClair

Let's think about a restaurant. With multiple cooks in the kitchen, the possibility of someone getting burned increases drastically if proper caution is not taken. Also, a server waiting to find out if their table's dishes are ready needs a way to ask without getting in the way. Finally, the host needs to know if more customers can be seated or if special requests can be accommodated, again without being too disruptive.

A common process helps keep the cooks safe from each other. It hopefully provides insight to the servers on how close the food is to being ready. Finally, the host shouldn't have to walk into the kitchen to know how long the wait may be or what the kitchen is capable of producing.

In terms of software, then, our goals are threefold:

1. Enable concurrent development
2. Provide insight to delivery dates
3. Guide future development commitments

What does the process provide?

Planning Meeting by Kay Jones

With those goals in mind, what can a process provide to meet our needs? What questions should an organization ask as it develops the rules of the road? Let's tackle them one at a time.

Enable concurrent development

To have multiple cooks in the kitchen, we need a way to communicate the orders to each one separately while also holding them to a common standard. Our process therefore needs a way to describe the desired outcome. In addition, since no one is perfect, there should be a defined means of checking the updates against shared rules and expectations.

To those in the field, this should be relatively clear. The orders are requirements, acceptance criteria, usecases, or some other way of defining what the system should provide when the work is done. The validation of that work is code reviews, architectural analysis, quality validation, and similar.

Provide insight to delivery dates

To estimate delivery, our process needs a certain amount of knowledge baked into it - if you'll pardon the pun on my continuing analogy. How quickly do we cook stuff, and how complicated is the stuff being cooked?

It's impossible to put exact numbers on either of these, of course. No two problems are identical, and no individual, let alone team, ever works at a truly immutable speed. Even so, with the proper knowledge coming out of our process, we can approximate both our rate of development and provide reasonable estimates for remaining work.

Guide future development commitments

Finally, as we plan for future work, we need estimates of work that hasn't even started yet. Perhaps there are problem spaces we've never entered before, or we desire new ways to use existing functionality and data.

At this level, there is less detailed information than when simply providing delivery dates for what is already under way. The process needs a way to analyze the unknown and arrive at a reasonable understanding of the work's size and scope. What other areas may be impacted? Are there areas for possible future extensibility to plan for? Is the solution generic enough to support all customer needs while also fulfilling the immediate requests?

How can we let the process deviate?

Detour sign by RoadTrafficSigns.com

As we build a working process, it is important to acknowledge that not every situation can be known in advance. Nor does one set of guidelines cover all projects and all styles of work. If flexibility is an understood part of the equation, the process as a whole is bound to be more useful in the long run and more responsive to changing needs.

For this to happen, there must be both a continual review of the guidelines and reasonable leeway written into them.

The continual review is used to determine which rules are working, which need adjustment, and which should be discarded entirely. New challenges may force us to shift course, and we need to be responsive to that as it occurs. If the process is too rigid it will break under pressure. At that point we either to start again from questioning why we need a process at all or simply accept that it will be ignored when inconvenient.

Leeway means that each rule should strive to be a guard rail rather than a railroad track. The former prevents us from veering off course into a ditch or, worse, over a cliff. The latter prevents any deviation from the defined course. If there is no room for movement in the process, there is no room for creativity. Creativity can bring unexpected value and open as yet unknown possibilities for future work.

Rinse, Review, Repeat

Forest by shushi168.com

Never let success make you complacent. When you have flexible development process that maintains product quality, delivers features effectively, and informs future direction you're only part of the way there. Even with ongoing review of the rules a team may fall into a rut and not see the forest for the trees.

It's important to occasionally look at the process as a whole to determine if it's still the right fit. Chances are that if you haven't done a core review in a year or two there's some piece that people run through by rote without thinking about why it's done anymore. These periodic resets may not result in large changes to what you do, but are far from a waste of time.