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.
At SRT, we continuously examine the overall technology landscape and make decisions on where to invest more time, what should stay the same, and what should be getting less investment. The change is actually quite fluid. We are always looking at what can help our customers achieve their goals, and what technologies seem to be getting less emphasis in the future.
But, the beginning of the year seems to be the right time to make a statement for the coming year. Here goes:
We’re seeing three areas that deserve big investments this year: Mobile, Single Page Web Applications, and the seamless integration of user experiences.
Let’s start with mobile: We’ve been building mobile applications for years, and demand continues to grow. There is obvious growth for iPhones, iPads, Android Phones, and Droid tablets. Windows Phone 8 and Windows 8 tablets are adding strong competition as well. There are a number of questions relating to how much market share each of these platforms will enjoy. But there is no question that the overall market for mobile software is growing, and growing quickly.
But mobile is only half (or one third) of the story.
Our customers demand that users access applications from their main computer as well as from their mobile device. Modern web applications, termed “Single Page Applications” behave more and more like desktop applications everyday. Facebook and Gmail are the two most popular examples. These web applications provide an almost native experience in the browser.
This gets to the final and encompassing strategy decision: Applications we’re building now must be available to users on any device, at any time. Data must be available on the web, on mobile devices, or on the desktop/laptop. The best apps can move seamlessly from device to device. That requires building applications that are part mobile, part web, part cloud, and always available from anywhere.
We’ve positioned ourselves to build those applications. We’ve got strengths on mobile platforms, web platforms, cloud platforms, and most importantly, building applications that span those different environments.
In my next few posts, I’ll go into more detail on each of these three topics: why they are important, and how to learn more about each of these topics. In the meantime, what do you think? Are these where you’re investing? Do these ideas represent the kinds of applications you want to use? Leave comments.
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.