Workflow

I use "workflow" as a generic term for "how you organise your teams to get things done". In product development teams, I use the term to describe the systematic organisation of the journey an idea goes through to become a feature we ship to production. Of course the journey involves other activities: fixing bugs, data analysis and reporting, infrastructural improvements, and so on. There are no two companies using the exact same workflow. There is always something slightly different about the way a team handles their tasks.

Workflow is the most visible and obvious process we use at work everyday. All methodologies aim to offer simple and effective ways to organise, distribute, and visualise work. That's why it's so central to many conversations, to the point of coming up on job ads and during interviews. In this context, I focus on the workflow we use to develop features when the input is ready. Product discovery, design of user experience and interfaces is a broad fascinating topic, but it's out of the scope of this book.

Over the course of the last few decades, there has been a lot of development on the subject. People came up with different methodologies and approaches. These approaches are all slightly problematic in the same way: they assume teams can adapt to a specific process. The assumption, frankly absurd, is that every team can be productive with the same process. What happens in practice is that every team creates their own version of whatever methodology they think they're using.

These slight differences create an internal vocabulary and a set of specific processes that are often not documented anywhere. The implicit knowledge complicates onboarding and makes the day-to-day operation of the team somewhat confusing.

Teams are different, so there is no good reason to adopt a methodology just because it worked for someone else. Of course it's helpful to know how other teams organise their workflow, it can inspire you to try new ideas.

Each methodology is a complication of the simplest workflow possible: you have a few things to do, you pick one and do it, when you are done you start over. A product development workflow may have a few stages like "quality assurance" or policies like "choose what to do for the next two weeks" on top of this simple concept. As it often happens, the industry solves the same problem with many different solutions. All of them have one thing in common: they are all over-engineered. I advocate for simplifying as much as possible first, and then focusing on what you want to add to this process based on what works for the team.

I advocate for a "just-in-time to-do, doing, done" workflow. An uninteresting long name.

Since it loosely resembles Kanban, I often refer to it as "my version of Kanban". Kanban marks a lot of checkboxes I care about. It's not a methodology and it doesn't tell you how to organise your workflow. It provides guidance on how to improve your processes and keeps the focus on visualisation of the work in progress. Kanban doesn't try to standardise the way a product development team works, so it fits nicely with the idea of simplifying the process as much as possible: work your own way and improve it constantly.

The most important aspect of "just-in-time to-do, doing, done" workflow is the just-in-time part. It has important implications, so let me clarify those first.

Some workflows batch tasks together and we often call batches sprints. Managers love these batches of work to-do; they can aggregate work and play the deadline game using sprints as immutable blocks of work. The keyword here is "immutable": nothing ever goes according to the plan. Immutable blocks of work don't exist in practice. Moreover, sprints delegate down to the teams the main responsibility of engineering managers when it comes to workflow: making outcomes predictable. Team members have too many details to take care of, there is way too much going on in their daily operations. You can't expect them to come up with accurate estimates. Batching doesn't help the people doing the job and doesn't make the outcomes predictable -- unless the input is steady and uniform.

This is where the just-in-time part comes in. A just-in-time process means people take the "next thing to do", put it in "doing", and then release it to "done". Right now, I'm oversimplifying so we can keep the focus on the just-in-time aspect.

Batching workflows assume that there is a specific moment in time when someone brings in more work. Just-in-time workflows assume that there is always more work people can pull from. It's a different assumption, a more flexible one if you ask me.

In practice, you can still batch to-do work before team members run out of work. A just-in-time process is more flexible because it can adapt to whatever phase your project is in. There are no two weeks that look the same in a product development team, so optimising for a process that quickly adapts to your needs pays back immediately.

One critique that often comes up when I discuss this workflow is that you can only implement it if everyone in the product development value chain (from stakeholders to developers, passing by product managers, designers, and so on) agrees and commits to it.

I actually agree with that! It's my favourite aspect of this approach: it's obvious you need everyone involved to agree on the way to work. The point is: this is always true, no matter what workflow you implement in your teams. I prefer how explicit and intense this approach is compared to hiding behind story points and sprints. How often have you heard things like "Sorry, can't fix this bug this sprint". A just-in-time workflow doesn't provide that kind of excuse.

In a real world project, the three stages "to-do, doing, done" are rarely enough. Keep simplicity in mind:

• If you are starting out, start with these three stages only. Work won't always fit into one of them. Let the design of new stages emerge from your actual day-to-day work.
• If you already have a process with stages, look out for stages that are either always empty or always full. You can refactor your workflow by either removing some stages or breaking them down.

What matters the most in this just-in-time process is how accurate the visualisation of each stage is. While this seems obviously a good thing, you rarely find an accurate visualisation of who is doing what (not to mention why) in a product development team. Describing with precision what's being worked on is crucial for engineering managers. You can't improve what you can't see.

Ask yourself if what you see in your workflow visualisation is what's really happening in your team. No visualisation can ever be perfect. That's OK, but any degree of visualisation accuracy is the starting point of the "continuous improvement" Kanban is famous for. Leading doesn't mean taking all the decisions on your own, and improving the workflow itself is no exception. Making sure everyone feels comfortable to propose a change in the workflow is the key to "kaizen". To find out if you are "kaizen enough", ask yourself: how often do we tweak our workflow?

If you haven't changed anything for a long time, chances are something is wrong now, because the only good explanation would be that there is nothing left to improve. I have yet to experience that.