As leaders an important thing to consider is how your team is optimized for progress vs process. How this is balanced should be based on your assessment of the needs of the stakeholders. Let’s start with defining the difference.

First lets talk about “progress”. I’d define this as anything necessary to “ship” the deliverable. Advancing the fulfillment of a deliverable includes:

  • Writing code
  • Defining acceptance criteria
  • Creating tech specs
  • Designing database tables
  • Deploying code
  • Writing unit tests (building in quality is still building – it’s part of the deliverable)

Then there is “process” which almost always inhibits progress – anything isn’t directly part of completing a deliverable:

  • Sizing stories
  • Sprint planning
  • Demos
  • Support/Release documentation
  • Breaking down work
  • Code reviews
  • Retrospectives
  • Standups
  • Regression & functional testing

So these are all good things right? Agreed. However, it’s important to understand that these things do come at a cost. They can potentially contribute to better velocity over time as long as they have been implemented in a way that improves “how” the progress is made. That isn’t a guaranteed thing.

One the other hand unimpeded progress is also a problem. Think of a speed boat without a rudder – in the end you run into a bunch of rocks.

The trick is to impede progress in an intentional way. Process is really easy to create – but really hard to get rid of because it feels comfortable. As leaders our job should be to constantly asking – how is this process providing value? For example – that support documentation you create, does anyone look at it? How about that the standups – are they actually proving to be effective?

A good question to ask is how do I determine what level of process is necessary within my team? I’d propose utilize process to solve specific problems. You also should consider re-evaluating on a regular basis to determine if the problems still exist & is that process actually solving it. I am a huge fan of developing process via retrospectives. I’m also a big fan of MVP (minimum viable process) and letting a process develop over time.

Here are some signs your team needs more process:

– Context switching and undelivered work inventory.

– External teams are unable to align efforts.

– Difficulty supporting applications due to domain knowledge “silos”.

Here are some signs your team needs less process:

– Ideas are regularly discussed but never get executed.

– Decisions consistently produce roadblocks due to waiting for the “right people” to sign off.

– Meetings occur without actionable output and there is no follow up.

In the end understand that process is costly and progress is risky.

A good team can sense when more progress can be made, and can also sense when unacceptable risk exists. When a good balance is found it makes for amazing results.