A very American phrase, I know, but it hits right at the heart of many of the problems I’ve seen in software development teams, both Agile and waterfall. Put into more understandable terms, it means understanding the reason behind what you have been asked to do, be that at an organisational level: Why are we doing Agile? Or at a feature level: Why are we adding a foobar? Right the way down to the tasks: Why does that have to be a service?
This topic came up at work when a colleague suffered some confusion over a new feature or – more accurately – the ever-changing ways of implementing the same feature. After spending a week getting the feature to work and being able to show that it works, there followed talk over how the code could be changed to make the feature work. I’m sure you’ve all been there. So after the meeting, we walked away and talked about why he was getting confused over something that shouldn’t be outside of his technical grasp. During the conversation, I mentioned that it could be to do with his lack of understanding of the mission and not a lack of anything on his part. Talking this through brought out the idea of two different commitments that a person can make to the product: on a professional level, where you do as asked, and on a more personal level, where you do what is needed, thinking about not only the product but also the user’s needs. Without an understanding of why something must be done, I cannot see how you can be expected to care about the implementation, which is necessary for a quality product.
In other words, understanding the mission directly impacts how involved you become in the process you become and how much of your brain you are willing to engage in any given task. Without that understanding, you could be the world’s greatest programmer but will have no passion for the product and will then let through code that is just enough. Or, as in my colleague’s case, you are unable to care enough to follow the changing requirements from start to finish and lose the thread somewhere along the way, making it difficult to stay on the same page as those around you.
From a team member’s perspective, it is possible to support or build this understanding using The Five Whys: this is an incredibly useful, though equally annoying, technique to learn the underlying reasons for a request, not taking things at face value. The method is straightforward: just phrase the question as “Why….?” and listen, think and respond with a follow-up “why” question for each answer. Once you’ve asked four questions and received reasonable answers, you should have a good grounding in the reasons behind what you are doing.
Judicious use of The Five Whys is an excellent way of gaining insight, but caution needs to be used to prevent two things:
- Sounding like a broken record and
- alienating the less-tolerant of management. They are often not used to explaining their actions.
For articles, too;s and more, check out our resources library
Need help with Scrum? Get in touch with us using the link below.