I remember an incident occurred few years ago when one of the developers in my team had put incorrect domain name (the name of a business unit) in the code. Although the working of the code was technically fit and it was just a matter of hard-coded text, but it was not acceptable for obvious reasons. During the review session, when the developer was communicated that the provided name wasn’t logical then he galloped amusingly “Well, I don’t know anything about the business relevance. Had you asked me to write ‘Shakespeare’ or ‘Obama’ in that place, I would have done that…All I was focusing on was the working of the code technically.”
This is not just one incidence. This is a prevalent situation with more than 50% of the associates in the workplace. We are given a task (or a story/work-item/assignment). The description of the given task, most of the time, is written in a crisp outline mentioning what-to-be-done. We delve into it instantly. We produce results too; but sometimes without knowing the “business relevance”.
Amid the rush of task completion and deadlines, we occasionally slacken to invest ourselves to know the associated details of the task – the objective, the business need, and the impact. We even escape from the very first question – “why are we doing this task in the first place?”. We lose sight of the holistic view of our task fitting into the picture of the whole project/product.
How could then we learn these essential details, which are erroneously considered the dead-weights such as good-to-know and I-can-ignore-it? How to enforce such culture in the organisations? And why it will be a good turn for everyone in the workplace, we’ll explore this further in this article.
As soon as you are assigned your new adventure, all you need to do is to ask “why am I doing this?” You will be surprised to see how this single question will lead you coming face-to-face with all the reasons behind the existence of a task or a project.
Take a scenario where are you are assigned to a project which is supposed to replace a legacy system. Your curiosity of “why we are doing this?” would translate to various other questions, such as:
There are many other weights in a project – contractual agreement, finance, resource management, software management, and variety of other headaches – that a delivery team does need not to worry about. You have project managers to get oppressed with these episodes. However, apart from that, the set of questions unearthed during the “why” question-interrogation must not be disregarded by any member of the delivery team before they jump into the implementation phase.
The answer is – each person involved in the project. If it is not already imparted by the project manager, then the associate must be proactive to pose these questions to the leads. The project must have this information documented heretofore. Additionally, the guidelines to associates that they must ask these questions to the project team must be a part of the induction program itself.
Induce a quality check. It could be in a form of recurring meeting where associates could be encouraged to explain whether they are familiar with those questions. Or this quality check could be included as a closing criteria of a task. For example, in scrum methodology, there used to be a document called ‘Definition of Done’ (DoD) having a list of criteria which is used to evaluate a work-item before it is closed.
When you are assigned a task, you are placed at the core of the system, the innermost level, and your output propagates from the smallest level to the biggest level in a spiral like form.
Considering that, the chances are affirmative that the details of your project would be required by anyone at any level in the organisation. The very first question anybody would ask is that “What is this project about?” or “What are you doing?”. Hence, it is imperative that you prepare not only to educate yourself but also to help others for the benefit of the organisation.
When associates get clear idea of what they are doing and why they are doing, it renders them having a strong-mindset and confident-thinking. It prompts them to look beyond their boundary of spiral and analyse the task from different possible angles. By asking questions, they in fact give permission to themselves to learn, to communicate, to see the bigger picture, and all these add up to build an empowered-self.
When empowered individuals work together in a team where each one has a sound idea of the comprehensive view of the project, then there evolves a self-sufficient team. In such team, each team member is strong enough to carry multiple hats – that of a developer, a tester, an analyst, a reviewer, or anything else that the delivery team needs to complete the work. In the moments of crisis, those self-sufficient and independent teams are the one that come to rescue.
There could be many other strategies that you must be following to keep your team educated regarding the objective and the integrated view of the project. Share your strategy, advice, or experience from your industry type.
This article also appeared on Alpenglows magazine http://www.alpenglows.com/why-am-i-doing-this/#.WQXtZROGPDc