Minimal Viable Process

The problem: you are no longer a two-person show, and you are struggling to stay on the same page while trying to achieve your vision.

The solution: process — but who wants that? It will slow you down, cut your velocity, force you to read some docs and follow a set of “from some book” rules. — You JUST want to code and create.

The ideal state is to have people spend 90+% of their time creating — while also putting just enough order to the chaos so that vision, ideas and plans are easy to communicate, and even easier to consume. At Manifold, we have a set of “minimal requirements” to help us get this done.

Minimal Requirements

We strive to satisfy two key requirements:

  1. Minimal cognitive gear shifting.
  2. Make it easy to know what we are doing now, next week, and (maybe) the next few months.

Minimal cognitive gear shifting

Process can not defined by tools or the latest tips and tricks. Trend chasing and overloading with tools reduces efficiency and kills focus by overloading the cognitive switching we have to do throughout the day.

Identify where your team needs to spend most of their time (say in code development making commits and pull requests against master) and find a way to keep them there as much as possible.

Now, next, and our goal

Much of the time, we need process because we are feeling the pain of not knowing what everyone is doing, and everyone not knowing what is next and/or why it is being asked of them.

As a team grows, getting this level of vision in a consumable, remote-friendly, asynchronous form is crucial. In my experience, GitHub issues have been the single most useful and easiest way to do this. By adding a small set of labels to your GitHub issue list, you can easily keep both an issues state as well as its scope. We simply use the concept of a backlog, todo, in-progress, review and done. These map well to some git states and GitHub actions, and have the added bonus in that they tend to be a part of a developer’s existing process.

Putting it all together

Currently, our flow looks like this:

  • One GitHub repo
  • Engineering documentation as the “code”, written in Markdown
  • Issues for ALL work, no matter what repo it is in
  •, supplemented with Github labels for:
  1. Ready, In Progress, Review (PRs), Done (Closed)
  2. Major components (may or may not map to actual repos in a 1:1 manner)
  3. Flag labels to mark Bug and Priority, everything else is in a state

By using milestones to both grab the concept of epics and agreed upon delivery dates, we can utilize the most critical parts of agile, while staying within the tooling GitHub provides us.

What does this give us?

To sum up, using GitHub issues + Slack + over-communication get us:

  • A living and asynchronous factory of discussion and record of decisions that anyone in the team, anywhere in the world, can use to stay up to date and contribute.
  • A developer friendly way to track what everyone is working on via changing GitHub labels, referencing issue numbers in commits and pull requests. This lets us minimize tooling and cognitive gear shifting so we can focus on work.
  • A minimal process that may not be perfect, but is adaptable enough that the team can see how conclusions were made, share what they are working on, and give all key stakeholders enough visibility so we can manage expectations and plan releases of product and features.

With all of that said, what do you do? I’d love to hear from other teams out there who have tried/trying to develop a super light process while also staying on track as they grow out the team and the product.

Original photo by Photo by Daniel von Appen on Unsplash

Recent posts

Related posts