When Building Process, Ask Why

Process is not a term belonging uniquely to business. Process fills our lives.

There are things we all do on a regular basis which are wrapped in processes we may not even realize have been established. (I bet you washed the same parts of yourself in the shower this morning in the same order you washed yourself the last time you showered. It’s your process.)

The most critical piece of creating any successful process is knowing why.

agile developmentWhy can be a bit of an irritation, so we like to avoid it. But without knowing why we do something, why we own something, why we buy something, etc – we end up with waste. Wasted time, wasted space, or wasted money.

Process in business often goes unquestioned. Nobody asks why.

If those same processes were implemented at home, someone would ask why. 


At home, imagine you were asked to cook dinner.  You were told that you’d be cooking it with two other people, but none of you could be in the kitchen at the same time.  You’d each take turns alone in the kitchen, working on the same meal.

You’d ask why.

How will the other people know that you edited the recipe or began the sauce already? You will have to devise a way to pass that information on before you hand things over. When it’s again your turn to be in the kitchen, you’ll need a way to know what the others have done.

But wait – what if you forget to tell each other that you salted the meat, and it’s over-salted? I guess you just have to be sure that your communication is flawless.

Can you imagine tag-team dinner preparations at home every night? You’d ask why.

But in business, we don’t ask why.

We hand things off to other people, wait to see what they do, they come back and ask questions, we explain or document so they all know what they’re looking at, and then we get it back again to finish.

(Many times, the meat ends up double-salted. We dump it out and start the process over again. We don’t ask why, we just repeat the same process we used when we screwed it up the first time and hope for a better outcome.)


documentationIf you were asked to keep notes as you vacuumed the living room, you would ask why.

But if someone in business asks for documentation to go along with whatever is being created for them, nobody asks why.

Sometimes there is a good reason. Maybe the person who bought the vacuum wants to know if the cord is long enough to reach the entire room.  Maybe they are shopping for a new vacuum and they want to know if a more powerful vacuum is needed.

Maybe there is some sort of regulation requiring your customer to own complete documentation of the product you’re building.

(Knowing why you are documenting something can also help you understand how it should be documented.)

You don’t always have to say no. But you should be asking why.


At home, if someone told you that they were going to put a couch in the hallway, you’d ask why.

I mean, couches are cool.  Someone might want to sit in the hallway one day. But they cost a lot of money and take up space, not to mention the work it will take getting it crammed into the hallway.

So why?

But in business, cool features are often accepted without question. Rarely do people stop and ask why.

Process & Change

I regularly use a screwdriver to tighten the hinges on our kitchen cabinets. For a long time, I would go get the screwdriver from my tool bench in my garage, use it in the kitchen, then put the screwdriver back on the garage tool bench where it belonged.

One day I asked why.

It’s common sense and it’s simple, but now that screwdriver belongs in the kitchen.

Also common sense: I did not talk to my husband or children when I made this change. I am the person who uses the screwdriver, I am the person who does this task, so I made the change without wasting their time or mine by sitting down and having a family meeting about it.

In business, a similar change would have required meetings, input, discussion and possibly a bit of documentation.


Stop doing things without knowing why.

If you can’t answer why something deserves your time, money, or space, then it’s time to examine your process.




Scrum Does Not Tell You How to Build Stuff

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

Talk to Us Today