A few weeks ago, there was a request in our planning system: "On the customer edit form, change the button that links to payments to green if the customer has payments."
The first thing that came to mind was why? As far as I know the customer edit page is very rarely used, and it's not a hot bed of activity to get to other systems like payments. Naturally, I saw no value in the request.
The next day, I stumbled to put this nicely by talking about the cost and perhaps we could prioritize it for much later on. Honestly, I need to get better at just asking one word: "why?"
Anyways, my customer agreed to de-prioritize it, at which point I felt a mutual understanding so I asked why it was needed, my customer helped fill in the value. When deleting a customer, he wanted to know if they had any payments so he could consider the consequences.
At the instant I heard this, a flood of ideas came to mind.
The specifics of my ideas aren't the point, the point is everyone on a team has knowledge that can be shared, I've often been impressed by ideas from other people. Also, at the very least, everyone should know what they are trying to accomplish, the objective. How, is the implementation and can only be discussed in the context of the objective.
When making or receiving a request, if you feel the urge to ask why, chances are something is missing. Even when you don't have an inclination to ask it, it may still be a good idea to force yourself.
There is the possibility that one could ask why to the point we get into a philosophical debate about words, that's not what I am after. My end is to understand the objectives of the business, the value they will add and how to measure if they are met. This way I can help ensure the value is achieved, which is what will make a business successful.
If I don't know the objectives, nor the value and metrics, then an implementation you hand to me may or may not achieve that objective. Furthermore, I don't believe people intentionally hide things, so if I'm not given this information my first inclination is to doubt if anyone else has even considered it. It's easy to get lost in implementation; it's one of the exciting parts of our work!
Anyone in software development dreads when we have to scrap an idea for another: first A, then B, then C. In my past this has often been paired with a lack of an explanation of what objective we were trying to accomplish. Worse yet, when I have asked why, I have often found no one else has asked why. Not only is this frustrating, it drives up costs. This alone is reason enough to talk about objectives first and implementation after.
