I have recently started a new job. The company is still very small, and has been operating in a very start-up mode. When they brought me on board, they wanted to start implementing new processes. Since I am very passionate about this, I was very excited.
I have a very agile mindset, and believe that the team should be very involved in defining the processes that they use, and have the ability to modify those processes when they are not working as well as they would like, or even working against them.
One of our developers works remotely, so in order to facilitate discussion of what processes we wanted to put in place, the company flew him to the office and we had a 2 1/2 day developer summit. We didn’t do any (or much) development during this time, but simply used the time to talk about how we wanted to work.
During our discussions, we, thankfully, agreed quite often on what we felt was the right process for us. But, our discussions were more than just a checklist of “we should do a, b and c”. We often talked about what we wanted to do, why we wanted to do it, and what that process or practice would allow us to accomplish.
At the end of the summit, one of the more junior developers mentioned that she really enjoyed the summit, and was happy to hear us explain why we wanted to have the processes we talked about.
Why the why?
Years ago, I realized how important explaining why was to our line of work, and I got myself into the habit of always explaining “why” when discussing something the team had not previously discussed. I also, try to restate the why periodically just so everyone remembers why we do what we do. It is very easy to get into the habit of doing something, and forget why you started it in the first place.
So, why is “the why” important? Why can’t we just state that our process is x and execute on it?
I can think of 3 reasons why knowing the why is important (I am sure there are more).
1) Knowing why a process was put in place makes it easier to remember what the process is and explain it.
When a new employee starts, it easier to explain a process when you understand why the process is in place. Also, for me, knowing why can often make it easier for me to remember the actual process, especially when it is something that is not used very often.
2) Knowing why a process was put in place makes it easier to know when to not follow the process.
I live by the rule that we control the process, and the process does not control us. A process is there to make our lives easier and allow us to do our jobs more effectively. Sometimes the process will get in the way and make it harder for us to do our jobs. In those cases, we should be able to weigh the benefits and costs of not following the process for this one instance. If we do not know why the process is in place, we will have a much more difficult time weighing the effect of skipping the process.
3) Knowing why a process was put in place makes it easier to know when that process no longer makes sense.
As I said earlier, we are in charge of the process. Sometimes processes are put in place that make sense when they are initiated, but over time, the benefit of the process goes away, but we continue to practice it. Knowing why a process is in place, and what benefit it brings allows us to revisit these processes, and decide if it is time to retire it. This is why it is important to restate the why every so often.
Not just for processes
Understand the why is not just useful for processes, but also for coding standards, code techniques, design patterns, etc. Understanding what these things are is important, but it is just as important to understand why we would want to do some of these things. This helps keep us from applying techniques inappropriately, and helps trigger our memories to apply the technique when it makes sense.
I encourage all of us to look at what things we do and understand why we do them. If we are doing things that no longer give us any benefit, then really think about whether we should continue doing them.
I also encourage everyone to make it a habit to state the why when talking about a new process, and restate the why occasionally, especially when new people are around, but even when it is the same people as always.