Workflow fragmentation

08 Apr 2016

Workflow fragmentation is a huge problem for modern engineers in my opinion. People like to think that being in an office and communicating solves this problem but this cannot be farther from the truth.

The problem is, we are using too many tools to communicate and to schedule work tasks.

Those tools don’t “talk” to each other and this creates a problem for companies and teams.

We like to think of ourselves as “agile” using these tools, but in the process, we lose context and we lose discussion by many smart people contributing to the decisions on features/bugs.

Let me dive in a bit…

The workflow

Let’s take a very common workflow for an engineer. You are starting a new task.

Your steps.

1. You pick up the task from your task management software.
2. You open a new branch on your source control.

Diving in

1

You need to open a browser, choose a task that suits you (or assigned to you).

2

You need to create the branch on your local machine, git checkout -b feature/some-feature-name.

Disconnect started…

There’s already a disconnect between your branch and the tasks system. Unless you “started” the task on the web (or mobile), no one really knows what you are working on and that you started working on this task.

OK… Continuing…

You go about your day and then you

1. Commit some code with a descriptive (or not) commit message
2. Push the code
3. Deliver your task in the management software after you verified

While this is a simplified version of likely any engineer daily routine, this comes with a lot more difficulties than described here, so lets dive into them a bit.

Again here, there’s a huge disconnect, especially when you think about the product manager needs to “see” something.

The product manager has no way of knowing what the status of the task is unless the engineer actively tells him (through the system). Even tough, as engineers, everything we do is a “notification”. “I deployed this to staging”, “I am running tests on this”.

Between git, Github, PivotalTracker and the CI. there’s not a single like of communication, a feed of what’s going on with this task

Real life example

In order to further clarify what I am talking about, I want to take you through a single bug I worked on. This bug involved all of the problems.

Part of my work at Gogobot is working on search. Search is a huge part of Gogobot so it involves pretty much every aspect of the product whether it’s on the web or on the mobile application.

Recently a bug was discovered in a new (shhh) product we are working on.

This bug was communicated to me via Slack private message.

Now, this is a pretty serious search quality bug, users finding the best fit for them is part of our DNA, this is something I should be working on right away.

I start working on the problem and report back.

The fix took about 10 minutes and I opened a pull request

Now, you’ll notice that this has absolutely no data about the bug. This simply is titled “fix”. When your memory is fresh that might be fine, but you have no idea what was the initial cause of this “fix”.

Like magic, I got a new question on Slack about 20 minutes after the fix was already deployed

This is the bug report on Pivotal Tracker and it described what was described to me in chat.

Understanding the problem

If you were able to follow along, you likely already understand the problem. This is not exclusive to us, any company will experience this over time.

You have many communication channels, some verbal, some written and some are in code and commit messages.

For example, if you run git blame and you see a line that your colleague wrote a few months back, you don’t really have the “why” and the discussions that led to this fix.

Beyond the simple syntax and obvious bug fixes, this becomes a problem.

Attempting to fix

This post has been in draft mode on my computer for a long while, I have to say I don’t have a complete solution, but I think a solution is possible.

The solution involves multiple stages

1. Story in your bug tracker / sprint planner
2. Slack channels opens and link to it from the story. Any discussion on this story happens in the Slack channel (and recorded)
3. Opening a task should be pickup-task $task_id and it links your git commits into the story
4. Opening a PR, running tests or anything else on that branch, pings to slack (again, recorded)
5. Once approved, the PR is stated “ready to merge”, task is delivered, channel is closed and recorded for later reference.
6. commit is squashed and link to the story (with the discussion) is added to it.

This would have solved the problem described here. (or at least it’s a good start)

The story would have a timeline of the discussion between the product, the engineer that picked up the story and later for reference if you are looking at the code.

What’s the situation for you?

Would love to hear what’s the situation for you and how would you suggest to solve it.