In my years working on and leading software engineering teams, I have used plenty of developer workflows or a development process as some call it. A good developer workflow can serve many valuable purposes for an engineering team. And they are at times mistakenly overlooked and underinvested in. 

In this post, I’ll discuss the importance of a developer workflow, pitfalls to avoid, and what’s worked for me throughout my career. There is not a one-size-fits-all approach, if you want a bespoke solution, please reach out and we will find what is best for your team. 

Why focus on a Developer Workflow

So why are developer workflows important? 

There are several valuable aspects of a good developer workflow.  The “right” developer workflow makes things simpler and automation keeps things more accurate. Additionally, it should serve as a single source of truth. Anyone on the team (technical or not) can determine what anyone else is working on, via a self-serve model of just looking at the board, versus needing to ask someone. 

Furthermore, one could self-serve information about what work has recently been completed, launched, or signed off by stakeholders. Assuming due dates are being utilized (subject for another post) they can also see when the work is expected to be done. 

This minimizes wasted communication overhead. Rather than having engineers or product managers constantly pinging team members to check in on what they are working on and when it will be done, everyone can head to a single destination, which they all trust, to get the information they need. 

Freeing up this wasted communication time enables developers to solve more important problems and make better use of their time. It also reduces the amount of time spent on context switching. 

Another added benefit is that it minimizes bureaucracy, maintenance time, and unnecessary work. People are no longer responsible for chasing down everyone else on the team to figure out what they are all working on. It also can reduce time spent in meetings where people are simply giving updates, information that could be self-served asynchronously.

With the “right” system, there can be a main hub for people to work from. This provides added clarity, direction, and simplicity resulting in a more efficient team!

Pitfalls to avoid

There are several pitfalls that I’ve seen teams get caught in. 

Having a workflow that doesn’t clearly delineate who needs to take the next action is a common pitfall. This can happen because the workflow is too simple or too complicated. 

When the workflow is too simple, a deadlock can occur when team members are waiting on each other to complete their respective tasks, because they think it is someone else’s turn to act. 

When the workflow is too complicated, team members don’t know what’s going on and tend to rely on personal views that aren’t aligned with other team members, or worse get overwhelmed and stop using the tool altogether. Also, an overcomplicated workflow makes it harder for team members to remember what things mean, what, and whose turn it is to act. This almost always creates a cycle where tasks aren’t correctly updated, which leads to a lack of trust in the board. 

Another pitfall to avoid is having the board not be accurate. If the board is not updated correctly and consistently, people don’t trust it. When the team doesn’t trust it, there is little value in the board. 

The Broken Window Theory states that disorder flourishes when small problems aren’t addressed. It creates a cycle where some disorder leads to more disorder.

This applies directly to a developer workflow, when team members don’t trust that the board is accurate, they are less likely to update their tasks. 

What’s worked for me

I’ll give a brief outline of the various workflow statuses and then go into them more in-depth. 

These are the statuses in order: 

  • To Do
  • In Progress
  • In Review
  • Staging
  • Production
  • Done

To Do

Tasks that haven’t been started yet. They enter this status as a result of planning or reprioritization. In a future post, I can go more in-depth into planning, sprints, grooming, and backlogs. 

In Progress

Tasks where the assignee has started the work. With integration, the task will be moved automatically into In Progress when an engineer makes a properly named branch in your VCS (Version Control System), e.g. GitHub. 

In Review

A task moves to In Review when the development work is done and code review has begun. Again with integration, the task is moved here when a Pull Request (PR) is opened via automation. 

Pro Tip: When the code review is complete, automation can add a label or tag that indicates the task is merged. This label/tag allows people to quickly differentiate a task that is waiting on a review vs. one that is waiting on a deployment. 

Staging

When the code has been reviewed and merged, it is recommended to be deployed to a non-production environment (often called staging). With integrations enabled, the task is automatically moved to staging once the CI/CD (Continuous Integration / Continuous Delivery) pipeline deploys to said environment. 

Production

A task moves to production after the code has been signed off in staging. At this point, the code is ready for a production deployment. Through integration, tasks will be automatically moved to this status when the CI/CD (Continuous Integration / Continuous Delivery) pipeline deploys to production. 

Done

Finally, a task moves into the Done status when the Product Owner signs off in production and manually moves the task from Production to Done.

Why it works

This developer workflow has only 6 statuses. Compared to other approaches, it’s on the lighter side, while still providing valuable granularity. With this simple workflow, team members can understand the process quickly and reach alignment.

Automation helps to minimize the manual work that goes into maintaining the statuses of the tasks. Tasks typically aren’t interacted with manually, with most transitions automated. The manual actions are putting tasks into the To Do status after planning and later the Product Owner moves the task to Done after signing off on it in production. 

This lack of manual interaction gives the team confidence that the statuses are correct and true. When the team trusts that the tasks are accurately accounted for, they don’t have to waste time tracking things down and trying to find out what is actually going on. Earlier, we discussed The Broken Windows Theory. Here, the other side of that theory is being leveraged, when the team maintains an accurate board, individual members feel responsible for keeping the board accurate.

What has and has not worked for you?

Topics not covered

In this post, I focused only on a developer workflow. 

There are plenty of related topics that I could go into in another post: 

  • Work estimation
  • Due dates and tracking them for accountability
  • Planning, sprints, grooming, and backlogs. 
  • QA team integration with the team and board
  • How people (within or outside of the team) can bring things to the team’s attention (bugs, features, etc.)
  • When to release (to staging, production, …)

If any of these topics appeal to you, let’s go more in-depth in another post or let’s jump on a call.
Let me know in the comments if there is anything you would like to hear more about.
I can help you in several ways: