May 09, 2017
May 09, 2017
Recently, Patryk created another episode for our videocast on project management and other soft skills that will help you deliver better projects fast. This one’s about processes that we use in our daily work. Feel free to watch it on YouTube or read a transcript below. Enjoy!
Agile Manifesto says people over processes. It doesn’t mean that processes are inherently bad or not useful. For example, there is a process which lays the groundwork for this recording, and I’m really grateful for it. I’m sure you have some processes which you value as well. Then why do processes have some bad connotation for developers?
In my experience a bad process will include at least one of the following things:
In other words, your team is not behind it. They don’t understand the process; ergo they don’t trust it.
We do something because it improves our results, or prevents something bad from happening. The reason why the process exists in the first place is the essential information in this case. Without it, a process doesn’t appear to be important.
This is a bottleneck kind of situation. It usually happens when there is some kind of a gatekeeper in the process that doesn’t scale up.
For example, I cannot merge my branch without a code review from the team lead. Or I can’t assign you a ticket, because I lack permissions in JIRA.
You can probably tell dozen of stories like this. Gatekeepers are really common among bad processes. Hitting a wall can be very frustrating as it makes you powerless, it stops you from doing your job.
It is another source of disappointment. We could be aware how a poor process could be improved, but we don’t know how to implement the change. Also, the change might be very costly to make.
It can be hard to improve a process if you don’t have access to the owner of the process. Perhaps it is owned by a different business unit, or even the owner is another country.
How could changing a process be pricey? Well, many times it happens because processes were automated too quickly — before they were able to mature. Automation can make them rigid and a nightmare to change.
What starts with frustration can lead to resignation. A person with good intention will give up, nothing is improved, and everything goes the slow painfyl way, exactly as in the past.
As you can see, most of the described issues have communication problems at its root. It is easy to produce a bad process. However, it doesn’t mean that you should drop every process in your company and become “agile”.
Processes are important. Especially in small companies where everybody has to wear many hats and change their roles multiple times a day. You might be a DB admin in the morning, then a developer, then a product manager, then a tester, and in the afternoon you are doing consumer support.
In such a case, you’d want to have processes for all those roles just to free your cognitive brain powers. For example, you could offload parts of the work to a simple checklist that is easy to follow.
Without a process, recording of this video would probably take twice the time and it could end up in footage, which I wouldn’t be able to use. My process saves me from throwing away material and doing repetitive work.
I personally like those, which are based on some serious fuck-ups from the past. They are obviously important, right? Nobody likes to repeat failures from the past. Therefore it’s more likely that more people will stand behind them and use them in their work.
But here comes the trick! Document the reason why the process was created in the first place. The why should go right above how in the process description. It should be literally on the same page.
In the 1960s, there was a racing war between two car manufacturers Ford and Ferrari. Enzo Ferrari collected every car part which broke and led to losing a race. He put them to display in the main meeting room in Ferrari factory. This way every responsible person would have a look at those failures and never repeat the same mistake again.
Let me stress that again. If it’s not written down, it’s not a process — it’s a mess at best.
A process can be a pain to follow, and if nobody knows the reason, the value of the process, the pain of following it can make you drop the process. And this can have of course costly results in the future.
You need to tell everybody it’s okay to question anything that was said in the past. Evolution is always healthier than stagnation. Remove old stuff, improve what can be enhanced. You should encourage everybody to challenge a process.
The reason is that to change something you will need to learn all about it first. So, even if it doesn’t get better, at least everybody will get a deeper understanding of it.
Think about how the process will work when a key person or service is not available. Perhaps a co-worker just got sick, or an important service has its outage. If in this case your process jams, it’s not good. It’s a good exercise to think of extreme cases to detect a weak spot. Your process has to be flexible enough to adapt.
They are invaluable help to detect faulty processes. You might get used to things, but a freshling will react allergically to them. Encourage them to report their findings.
A new person on the team is like a canary in a coal mine —they provide priceless feedback on a situation that the team doesn’t notice anymore.
Well, if you read all the way till the end then the obvious next step would be to subscribe to our blog and video channel to make sure you get notified about the next episodes. Also, it’d be great if you could share this content with anyone that is interested in improving their processes.
Also, if you’re into technical tricks to help you deliver better applications faster, we have a second treat for you! We’ve just started Brain Picks, where we share tricks, technologies and ideas that will take your development process to the next level. Check it out!
Till the next time, take care!
Clicking "I want to know more" you consent to processing your data by Brains & Beards sp. z o.o. for marketing purposes, including sending emails.