Why Process!

The agile manifesto says people come above processes. But every team I have worked with has always followed a process framework. The usual suspects are of course Scrum and Kanban. Why do they do this?

A process

I would like to move away from the context of agile. For me, a process is something more fundamental. Processes are not something which only teams follow. It can be applied at a personal level as well. So let me state the definition of the word (Googled it!)

This definition captures the essence of the concept of process for me. Processes exist in all shapes and sizes. I follow a daily routine or process to start my day and get to work on time. I follow the process of TDD - Red, Green, Refactor when I do any worthwhile development.

Why process for me

I am sure you are asked to follow certain processes in day to day work. Or there could be these process gurus who are asking you to follow some new shiny process. And, you are either verbally or non-verbally quoting the agile manifesto to convey your disgust about following this process. In your mind - processes are a waste of my time! . I used to belong to this same gang.

Then something changed. May be old age (read experience, gray hair etc.) changed me. Once you get to a position where raw energy is not enough to accomplish something, I think the concept of process kicks in. At least that happened to me. Also raw energy is better harnessed with a process of steps that can be followed to meet an end. Just my experience. That said, I always remember that process is never bigger than the end it is trying to get to. It is a set of steps that one can follow to get there hopefully and it is also something which needs attention and tweaking.

Why process s**ks for you

Let us turn back the attention to you and your complaints. You ask me - Why do processes s**k?. I have also felt it sometimes (even now feel it sometimes). In my opinion, processes suck for two reasons.

One:

Most of us adopt a process so that we can move faster. I follow this process and my delivery speed will double or triple. So I am going to do this. Within a week or two, you see you have slowed down to half the rate. WTF! This process sucks. and this is the problem. In my opinion, the primary purpose of adopting a process is not speed. It is to get predictability in terms of outcome and results. Let me repeat that - Process helps make things predictable. And believe me that is a more useful quality than speed. Predictability allows us to plan and decide; to ensure that we get where we want to get to in a well known time. It helps us make right choices. In a word it makes us effective.

Speed is about efficiency and that is good to have. But first you need to be effective. The main purpose of process is to drive that. It might eventually lead to speed or efficiency and that is great. But seeking speed instead of predictability is sure shot way to ensure that a process never works for you. It will s**k!

Two:

A process becomes effective only if person(s) following it give it a chance. Giving it a chance means

• being involved in the process - look at the steps - its motivations and purposes, understand them, observe them, and
• giving it time.

When I started TDD, it felt very taxing and time consuming, even time wasting. I am sure many of you felt that way. Once I started following the process, observing the details and kept doing it for sometime, something changed. Now it has become my natural way to do development. Am I faster? I am slower than if I am just 'spike'-ing, but if I am developing anything worthwhile (that implies with tests), then TDD is faster. More importantly I am not looking for just speed. I now have a predictable way to write good quality code and allow me to think through things. And lo and behold the process works!

Another good example of a process is a standup. A standup is where the team get together and share what is happening (that is a very simple definition but still a useful start). A typical standup

• starts on time
• a team member talks about what they did, what they are going to do and impediments
• next one follows suit until everybody completes.

This is just the basic outline. The process entails a lot of other nuances which are equally important. Let me pick one of them.

In one of the teams I was part of, standup happened as members reporting their previous day's work to the leader(s) in the team. And of course that sucked! The team members felt a lot of pressure. The standup process itself says a strong NO to this. We being believers, noticed this and asked each person to face the team to provide the update and not the lead. And something changed - it felt more like sharing than reporting. There were many more nuances which we watched out for, acted and made changes to the way we were doing things. And it took time. Eventually the standup became a process which everybody looked forward to come into, so that they know where their team is and how they can help or contribute.

In closing

Good processes (whether team or individual) needs feedback and time. If you give up too early and don't really get involved it is bound to fail.

And more important than that please remember a process is about predictability and consistency. Speed is a potential side effect which you may get to enjoy.

Please write in with your feedback and thoughts on processes in your own life or work. I would love to hear and learn more.