Formalizing Loose Processes

Non-spoken rules

There are certain "non-spoken" rules that happen naturally as a project grows in size.

These rules are not documented anywhere, nobody talks about them regularly, but they do exist. Some certain day you'll break one of these unspoken rules and a more senior teammate will come to you and say "Hey, you can't do that" or "We do that differently".

There's usually a de facto way of doing things in a project that everybody gets to know eventually (the unspoken rules); it's usually trivial work or simple processes that are often adopted out of repetition. "out of habit". Some times these processes can be done in a few different ways but the "escence" of the task remains.

The problem with loose processes

While a team is small enough, and everybody is in the same page, this is more than ok; "Communication over Documentation"; many startups get away with chaos because their developers are good communicating and good technichally. But as the project grows in size, the communication grows in complexity more than the processes themselves. At the end, there's only so much time a developer has to interact with other team members a day, and also be productive.

One more problem with these loose processes is that people's interpretation of the process can be different. One problem I've seen is that the very expectations of the role may not be clear for everybody the same way; I've seen brilliant developers struggle with performing at their best bacause these loose processes are on the way. They might think they are givin their best and focusing on the wrong bits of work.

Writing down the process

There are three main questions you want to answer in order write down the current process:

  1. Is it a problem? Do you really need to be thinking on this? Is this a pain point identified by yourself or another person in the team?
  2. What is the goal of the process? What is the end result?
  3. Who are the actors? What roles are involved in the process? and What do they do?
  4. What are the expectations from everyone? What is the expected involvement from each role?

1. Is it a problem?

Identifying the pain point

Retrospectives are the best place to identify pain points. This is also when you realize if you have some loose processes that would be better written down, or even better: improved.

You can tell when a process is the problem when a person is a bottleneck for everyone else. Or when more than one person is confused about how to perform a task.

Is it worth it?

Not all the processes need to be written to the letter. Some simple processes are better left loose. We are not trying to turn the development team into a bureaucracy. Before going out your way documenting, make sure it will solve a problem for more than person on the team. Sometimes a simple knowledge sharing session is enough.

For the development workflow, there are many comments of unhappiness happening. and spicy comments like: "things are not clear", "I don"t know what they want" or "why does it take so long to change a button?". So, it is a problem.

2. What is the goal of the process?

Some processes are very straightforward. for example: functional tests. Or Pull Requests. No need to write down what a PR is.

Nevertheless, there are processes that are abstract, composited of many other processes. Like the Development Workflow.

The Development workflow is a good example of a loose process in many companies. It is kind of an umbrella term for all the many tiny processes and activities that a developer performs. The following diagram is the result of answering the questions above:

As seen in the diagram, The development workflow includes many activities that are not related directly with the code itself. While in the diagram is clear that coding is just a small activity, this wouldn't seem to be the logical conclusion that many people would get when they think of the activities of a developer at first. Even developers themselves.

The goal of the process is to deliver software. To take it from inseption to production. That's important. And by making the process explicit, we can make sure that we understand the capacity of the team as well as the team can understand what are the expectations from them. Before having the diagram, we have the first two questions answered.

  1. It is a problem, because neither the developers nor the stakeholders know where the development time goes
  2. The goal of the process is to deliver software transparently

3. Who are the actors?

The actors are the people that has influence in the process. Anyone that can change the outcome of the execution of the process.

In the case of the development workflow, the actors are: The developers and "others" (QA, Product, Design, etc). Because we want the developers perspective, we are focusing in the developers activities

4. What are the expectations from everyone?

The expectations from all the actors determine what are the fundamental pieces of work. you can start putting together the steps of the process by answering the questions:

  • How do we fulfill the expectations of the actors? and
  • Are these expectations realistic? Sensible? Clear?

The diagram above shows an example of the activities that need to be done by developers to deliver a product. These are the expectations from the product team, or the customers directly.

Depending on the organization of the company and the teams these diagrams could look completely different. This is an example for a growing startup that has little resources and small teams are not only multidisciplinary from person to person, but also a single team member absorbs responsibilities that are traditionally for architects or for other roles like Product owners or testers.

Conclusion

Writing down the processes makes sense when the processes are getting on the way or some terminology could be open to interpretation. In the developer workflow example, it's very easy to assume that developers will need to focus only on delivering code, but once we get all the pieces together, we can see that the process is larger and the code is just a small part of it.

The first step is accepting you have a problem

The first and hardest step is identifying there's a problem. Many times this flies over our heads simply because we are very used to how things work. But maybe, now that everyone knows the workflow, we can start thinking about improving it.