I’ve started working with a new client and it’s re-affirmed my belief in the importance of asking the question “Why”?
Ask it again.
Follow up with more Why?
Make sure you get to the root why.
I’m not focusing on the “5 Whys” popularized by Toyota and now part of the 6 Sigma process, although that is important. Rather, it is to focus on understanding why a process was put in place, and why these processes have been established. More than anything else, it’s about listening.
In the current scenario, I’m helping a team that is near midway through a product release cycle. They’ve adopted a series of agile processes, build and deployment processes, and common practices for branching in git, deploying changes, and so on.
Like all teams, half way through a project, they aren’t sure if every process is working out well. This introduces friction and concern: Should the processes be changed? If so, to what?
This is where ‘why’ becomes important.
The first ‘why’ to ask is “Why did you adopt this process | tool | guideline?” From this question, I learn what gains a team hoped to achieve. What problems had existed, and how this was intended to help. Once that’s known, it’s easier to discuss the benefits and any unseen costs that a new initiative has brought. On the whole, was it good?
The second “why” in this situation is “Why is this new initiative not generating the benefits you expected?” Is there more friction? Are you finding that adopting new techniques took more time and investment than you thought? Are you losing productivity because a technique is not familiar yet? Does the team fear that “we’re not doing it right?” This starts to get to the cause of this new discussion.
The third ‘why’ for the team is “Why change now?” One important goal for high-functioning teams is “continuous improvement”. And while it’s important to always look for opportunities to improve, it’s also important to pick the right time for change. That’s especially true if the proposed ‘change’ is at large scale. (Example: I’m not switching Source Code systems a month before release. Too much churn, not enough gain). Related to that, if a team did implement a major change before starting this release cycle, has it been fully explored?
OK, give me a little license here. I know I can’t ask questions of a software tool. But, the point is that sometimes teams adopt a tool, or toolset, and then fight that tool because they don’t want to understand why it works the way it does.
One example from a previous client is git. They had planned an initiative to move from SVN to git. However, they did not expect this to change their workflow, or their overall development workflow. They didn’t develop a branching strategy. They didn’t work through the distinction between commits and push/pull. Git failed badly for them. They were fighting against the toolset. This example is not meant to take a position on centralized vs. distributed source control, or on a particular vendor. Both workflows can be done well. Both workflows can fail. The point is to work with your tools, not against them.
Sometimes that means picking different tools. Sometimes that means adopting a different process because of the tools you want to use.
In addition to asking “why” a tools was designed they way it was, it’s important to ask “why” the team picked a certain toolset. Did they originally intend to adopt the mindset supported by the tool? Or were there other drivers?
Early in my career, I received one of the best pieces of advice from a mentor:
Some people really listen. Others simply wait for their turn to talk. Be the former.
That sums up what’s necessary to really bring about change and to really have a positive impact. If you listen to all the team members explain their issues, describe what is and what is not working, you will be in a much better position to make a positive impact. You’ll also be solving real problems. Problems that real team members have described.
Listen. Ask Questions. And remember that the most important question is “why?”
You’ll have a bigger impact.
All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.