Development teams typically hate process and rightfully so. In the moment process is objectively bad and a lot of process is put in place for the wrong reasons.

What is Good Process

Good process is put in place for one of two reasons: it speeds up development overall, or it eliminates team issues. Think of it like driving a car. With no infrastructure it's a ton of fun driving around an off-road equipped jeep or dirt bike. But if we want to go far, fast, or with many many people, we need process. Roads help us go fast and guardrails help eliminate and entire class of issues.

Another analogy that might resonate well with engineers is immutable data structures. They are objectively less powerful and more restrictive than mutable data. In the moment they are more verbose and difficult to use. They take more memory and computing power to handle. However, they eliminate an entire class of issues. It's taken years for engineering communities to step back and see this larger picture but we got there.

Examples of Good Process

One example of speeding up and scaling work is agile methodologies. Fundamentally understanding where the team and company are headed and how we're planning to get there is like paving a path to drive down. The ability to easily create work, get it prioritized, and work on the top priority thing brings a team together and streamlines efforts.

Processes like project proposal, RFCs, architecture reviews, and testing norms are your guard rails. These prevent an entire class of "team bugs" like bus factor, hero culture, and code debt over time.

Examples of Bad Process

Put simply, any process that doesn't fall into the "good" bucket above, is bad. Bad process realizes the localized pain without providing sufficient macro benefits.

To identify bad process it often helps to reflect on why the process exists:

• "We've always done it this way"
• "That team is doing it, so should we"
• "I read a book and so we're doing this now"

I say above that agile is an example of good practice, this may not be true for all teams.

Going back to our driving analogy, if you're in an off-roading vehicle and your destination is a mile off the road, then roads and guardrails are actively hindering you from reaching your goal.

One more analogy, if you're transporting a manufactured house, you shouldn't be going down the fast lane on the autobahn.

Fit the process to what your team needs now, not in the future or in the past.

Eliminating Bad Process

The key to keeping good process and eliminating bad process is embracing continuous change and experimentation with curiosity in mind. Retrospectives are essential for proposing trying something new or dropping something old, reflecting on that change, and adopting or rejecting it.

Teams often don't take this seriously. This takes time and thought about the current moment. Forget what the team was doing a year ago that worked so well, what got you here will not get you there.

What if you eliminate sprint planning? What if you switch from sprints to kanban? What if you go from two week sprints to one? What about three? If the team immediately reacts with negativity, push them to think more creatively about all the implications of change that these ideas would bring.

Shorten Sprint Example

Say you run a three week sprint cycle. You notice the team always has a heap of work carried over from sprint to sprint. Some tickets are marked as obsolete as we adjust mid-sprint. Some tickets carry on for two or three sprints in an unknown state.

Proposal: let's try one week sprints!

Initial reaction: gasp! That would never work. There's no way I'm sitting through three times the sprint ceremonies. What about tickets that themselves take more than a week?

Creative and curious exploration: well how would that work? We'd need to cut our sprint ceremonies down to the minimum so we're not spending too much time in meetings. We'll find a few ways to make them more efficient and get to the point. We'll need to keep the backlog very prioritized or we'll never get to some things we want to do. We'll need to break tickets down much further before starting so we can ensure no work will take more than a sprint.

Result: shorter, more focused meetings, more clarity around top priority, less workstreams in-flight at once (team focus), capped ticket estimates at 2 points means clear chunks of work. After taking a few weeks adjusting and tweaking this new flow the team has zero carry over. They feel good about taking work and knocking it out and have a better idea of where they're going.

In Summary

Take a step back and look at the big picture. All process is objectively worse locally, but at a macro level can eliminate entire classes of team bugs. Think critically about why you are doing your current process. Removing old process is just as important as adding new. Propose change and iterate keeping in mind that you often won't see big wins immediately.