Optimizing Development Processes for Business Value

The point of software development is to deliver custom value as quickly as possible. At least development in the context of a business.

While teams should be self-managing, they should also strive to create value. These are principles for development I've seen increase productivity.

Deliver the smallest amount of functionality that provides value to the customer

The smallest? Yes. The smaller the change the easier the whole flow from idea to production is. The easier the flow is, the more value will get pulled through the flow.

Small changes result in easier merges. They block other parts of the system for shorter amounts of time. They are easier to reason about the effects on the whole system.

But, they need to also provide value to the customer. This forces efforts to track toward a common goal and helps scale the changes.

Customer value can also be things the customer won't notice, at least until they're missing. Performance and well working code, for example.

Reduce waste

Waste is anything that doesn't help the customer or slows down development speed because it's not actually needed.

Waste should be continuously monitored, and reduced or eliminated.

Waste often sneaks in as processes that seem needed, but aren't. Scrum comes to mind as a pretty common area of waste.

Scrum is primarily a process to manage up and provides little benefit to the customer. One exception is when a team is using Scrum over a worse option, like waterfall, in a transition to something more efficient.

Another huge area of waste is having teams split into functional areas. For example having a QA team instead of a QA person on the team. Cross-functional teams are more efficient.

Automate repetitive processes

Repetitive processes are waste when not automated. They're wasteful by nature being repetitive and when done manually are more error-prone.

Tests should be automated. I'd argue they must be automated. They should run on each commit.

Linting, is a programmatic way to catch and often fix simple errors and formatting. It should be automated. There are other benefits in providing a coding standard for the team.

Task management should be as automated as possible. Connecting source control to the task management system will provide a good start.

The build process must be automated. This is another must in my opinion. Whatever needs to happen to produce a final build needs to be automated.

Integration tests should be automated. This can get very complex for larger systems with multiple services. It's worth automating as much as possible.

Deployment should be automated. A good first step is to make sure deployment happens by some script or process that isn't manual. The next step is to automate starting the deployment when code is committed.

These are major areas that should be automated. Every project will have other things that can and should be automated.

The team owns the codebase

This means anyone on the team should feel free to change any code in the codebase. Team members can often get siloed into a specific area of code. Sometimes by choice, sometimes by the organization or team.

Siloed developers aren't good for a number of reasons and should be actively discouraged.

Other developers will start to feel they can't make a simple change because that part of the code is "owned" by someone else.

When the siloed developer leaves, anything to do with that part of the code will stop or slow way down.

Team members will write better code knowing someone else on the team will be working with their code in the future.

Release early and often

High performing and innovative teams deploy often. Usually many times a day.

Work toward continuous delivery, where each bit of functionality is deployed as soon as it's committed to the codebase.

Continuous delivery:

• Removes most merge conflicts
• Gets functionality to the customer quickly
• Makes it easy to fix bugs

Limit work in process

People are not good multitaskers. They shouldn't work on more than one thing at a time. Meaning, they should work on one bit of functionality until it's released.

Often, something will be blocked, and another thing will need to be worked on. Still, limiting work in process is important to keep the rate of delivery high.

Limiting work in process has other benefits, even ignoring those, there is a huge advantage in letting people focus on one thing at a time. Check out [Lean] and [Kanban] for more ideas.

Keep the code quality high

While these principles have the side effect of keeping code quality high. It's also worth calling out this principle directly.

High quality code is easier to reason about. Easier to change. And easier to grow.

It takes constant focus to keep code quality high. Otherwise the codebase will naturally get worse over time.

Figure out how to implement these principles and watch the speed of development increase.