Increase Your Team's Productivity by Establishing Processes - Part II

This is the second article in the short “Increase Your Team’s Productivity by Establishing Clear Processes” series:

1. Why Team Processes Are Useful
2. How To Define Team Processes (this article)
3. What To Cover With Processes

Where To Start

So, you are ready to formalize your workflow with a process. The question you might have now is where to start?

There are two ways of defining a process for an existing team:

1. Reshape your existing process.
2. Start from scratch.

Reshape Your Existing Process

This is the common approach that works most of the time, since in any existing team there are already some processes the team follows (even if they are not formalized in any way).

For this, you need to define your existing workflow first and then you can remove unnecessary steps, add steps that might add value and adjust existing steps that can be improved.

Start From Scratch

In some cases you will realize that you are doing too many adjustments to an existing process, or maybe you have a new team. In those cases, it is better to start from a blank slate.

Keep It Simple

One thing to always keep in mind when defining a process is to keep it simple.

In software engineering there is an expression that says “best code is no code”. Writing code is easy. Building products that are maintainable, scalable and serve a specific purpose is very hard. Each additional line of code that is added to the project adds complexity, is a potential source of bugs and security vulnerabilities. If you have no code, nothing can be hacked and nothing should be maintained.

The same applies to processes. The best process that transforms inputs into desired outputs is no process. It is the fastest, most reliable and consumes no resources.

The idea behind this way of thinking is very useful and has helped invent many useful things as part of TRIZ (the theory of inventive problem solving)¹. One interesting concept from TRIZ is the Ideal Final Result (IFR)—the ultimate idealistic solution of a problem when the desired result is achieved by itself. While that is practically impossible in itself, you can theoretically come very close to it.

Define only the necessary steps in a process. If you can skip a step and get the same result in the end, then remove that step. Likewise, if you can simplify and reduce several steps to one, then do it.

Involve Everyone On The Team

Involve all your teammates. While the most experienced people on the team have been doing their job for some time already and could contribute with useful insights, they are the most biased toward a specific way of doing things, which is not necessarily the optimal way. Consider talking to new members as well, since they can bring a fresh perspective on the workflow.

When discussing with the team, it is important to set up expectations and keep an open mind. Sometimes people will protect what they are doing simply because they are familiar with it. Other times they will resist changes because they don’t know anything else, even if the work they are doing has zero added value. But most often people will collaborate. Have a conversation. Listen to what every team member is saying and what their arguments are.

Keep in mind that the workflow might depend on some external inputs or rely upon factors that are external to your team for which you have zero control over. You should account for such cases and incorporate them within your process.

Draw the process

People are visual beings. Although we have 5 senses, the visual channel has the highest throughput of information. Danish physicist Tor Nørretranders created the “Bandwidth of Senses” infographic in which he quantifies the capacity of each sensory channel:

Therefore, having a visual representation of the process will aid in defining it. You will be able to see the logical sequence and spot the gaps you can fill and improvements you can make.

Start by drawing the input and the expected output and then proceed by filling in the intermediate steps necessary to transform inputs into outputs. You can move from start to end or backwards, from the end result to the beginning of the process, depending on how you feel will work better.

Let’s take a specific example of a software engineering team. Since in different companies such teams might have different inputs/outputs, let’s assume the team receives user stories in form of a backlog, which they should transform into features that are deployed into the production version of their product.

A good place to start is to define the generic phases of the process:

Once you defined the main phases of the process, you can break them down and increase the granularity of each step in the process. For instance, the next iteration of the above process might look like this:

The process can branch out into several flows as well, as in this third iteration:

You can go into the details as much as you want. Just don’t transform that process into a recipe for micromanagement of the team.

Look For Existing Methodologies

Maybe you’ve heard about Agile methodology, Scrum and Kanban. Maybe you are using these as part of your workflow, or you have other popular methodologies in your industry that you are using. While they might prove useful—it is important to keep in mind that such methodologies are just an attempt to generalize some phases of the workflow. In software engineering, Agile might define the values and principles that should guide the workflow, but it doesn’t say how exactly your team should build that product. It defines a bird’s eye view on the development process, but doesn’t provide any operational steps. That’s why you need to define how your team should work and what process to follow. The existing methodologies are going to be just a constituent part of your broader, unique workflow.

What’s Next?

This article has touched on some ideas on how to define a process that guides the main workflow of a team. But this is only one instance where a process might be useful. The other examples are going to the presented in the third and last part of this series.

If you liked this article, consider subscribing below and following me on twitter (@iuliangulea).

---

1. TRIZ (Russian: теория решения изобретательских задач, teoriya resheniya izobretatelskikh zadatch, literally: “theory of the resolution of invention-related tasks”) is “a problem-solving, analysis and forecasting tool derived from the study of patterns of invention in the global patent literature”. ↩︎

---