Follow your instincts

There is always an internal conflict between what our gut feeling tell us and what our reasoning reveals. Normally, people choose to follow their reasoning, because its logical and probably supported by others around.

I called up one of my team members and informed him that in he could have added a few more details in the status report he sent to the client. He immediately responded, “Yes, I even typed that information in the report, but then removed it.”

When he typed the required information, he actually followed his gut feeling – “I should mention this here”, but his logical mind somehow was not convinced and he deleted those two sentences. My immediate response was, “Why din’t you go with your intuition?”. “May be, I was not sure”, he replied.

Seth Godin over his weblog writes a fantastic post “The intuition vs. analysis conundrum“.

“The analysis, based on past events, certainly seems sound. But your instincts are the only way you’re going to do something unsound.

And unsound things become hits. Sound ones never do.”

As Seth writes, gut feelings need to validated. Blindly following intuitions might lead to problems. The most important thing is to listen to your internal voice, think about it, validate it and then go for it. He says -

“The challenge is not to somehow persuade those in search of soundness to change their minds. The challenge is to do enough of a gut check to decide whether you should defend your instinct. And then do it.”

Any further ideas ?

Bug Reporting is an art

The work of a software tester on software projects is much like diagnosis doctors do. There is no scope for ambiguity when a doctor diagnoses. Before a doctor reveals his diagnosis, a lot of symptom analysis and mind work goes into it. A doctor has to be very precise in reporting the problems as he diagnoses. “Patient X has something like cancer” will kill the patient just out of shock. In any field, effective reporting is much of an art.

Similarly, when diagnosing issues with software while testing, there is no scope of ambiguity. As testers, we have to remember that each bug reported involves some work for developers. They have to understand the context of issue, try to reproduce it and resolve it after it is reproduced. May a times, a project manager needs to understand what are severe issues open and manage the project accordingly.

For this, testers must clearly and succinctly report each of the finding with appropriate severity and priority assigned. Suppose you are a developer and you see a bug stating “The values in category combo box are not proper”. How would you react to it?

Following are pointers to effectively report software issues:

• Each bug should be clearly identifiable by the bug title
• Each bug should be reported after building a proper context. What are the pre-conditions for reproducing the bug?
• Write down steps to reproduce the bug.
• Be very clear and precise. Use short and meaningful sentences.
• Cite examples wherever necessary, especially if bugs are a result of a combination of values.
• Give references to specifications wherever required. E.g. Refer invoices module on page 14 of SRS.
• Keep the descriptions simple.
• Be objective. Report what you are supposed to without passing any kind of judgement in the bug descriptions.
• Thoughtfully assign severity and priority to the bug. Remember, a minor issue may have high priority and vice versa.

Reporting a bug is no rocket science but it surely requires a lot of common sense. I have seen people writing mini-essays in bug reports and also the ones who report one-liners.

Reported bugs should not add an overhead of understanding to the developers but help them instead to reproduce the bug and effectively resolve it.

Workplace Detoxification

“When in doubt, throw it out” is what Peter Clarke says on Stickyminds.com whose company has embarked on a “lean office” initiative.

Peter stresses on workplace cleanup by cleaning up junk periodically. Sure, we can be more effective if the physical desk and desktop are cleaner. Things become easy to access leading to greater efficiency.

Peter says,

Nowadays, I practice the same clean up at work. My team and I had several training sessions, where we learned about the “five Ss”: Sorting, Storing, Shining, Standardizing, and Sticking to the Rules. I was enraptured to learn that Sorting involved looking through all of our stuff and figuring out what to keep, what to store, and what to throw away. Here was the leverage I needed to finally get people to throw away the cruft that accumulates around the office like toenail fungus.

I would like to extend this theory to personal clean up as well. When we work, we subconsciously keep on stuffing our brain with a lot of unnecessary junk. Over a period of time, our conduct gets limited by our prejudices and preconceived notions. These are the same toxics to our brain as the piles of papers are for our workplace and these need to be cleaned up too. Taking a break (sabbatical), reading interesting stuff, attending events of our interest or by just being home and spending time with family are good ways to detoxify ourselves and this should be done periodically to ensure that our brain remains open to new ideas, new perspectives and new ways of doing things.

My comments on Peters article goes here.

Hi Peter, I like to call this “detoxification exercise”. While we work, a lot of toxic elements (thoughts and things) keep piling in our mind and workplace on a daily basis affecting our efficiency to a certain extent. It helps to “detox” periodically by taking sabbaticals, doing routine cleanups, sorting, re-organizing and throwing out as you rightly mention. Thanks for your article. ~ Tanmay Vora

Should Project Managers be technical?

There has been an ongoing debate around on whether a software project manager should be technical. I have worked with project managers who are technical (a part of them is still a developer) and project managers who are non-technical (people who know how to get things done, and not exactly how to do it).

However, one sure thing is that a project manager must know the processes involved in executing a specific project. A project manager in construction Industry should know the process of how buildings are constructed and similarly a software project manager should know what the software is all about, how is it built and what processes are involved.

According to Johanna Rothman,

Project managers need to understand enough about the technology so that they can make tradeoff decisions (or help product owners make tradeoff decisions) about what will actually make it into the release. The more PMs understand the product under devleopment, the better decisions they will make–or guide the project team to better decisions.

Here are the two extreme situations I would like to avoid: the un-knowledgeable PM and the PM who would rather be the architect. I’ve worked with several organizations who thought that PMs in other industries, such as event planning, would make great PMs of software projects. Nope. Not a chance. The PM needs to understand the process of the project. And in addition to the process, understanding enough about the product and the tools can help a PM assess risk and manage it during the project.

In my experience, the PM as architect is just as bad. This PM understands the process and the technology and ignores the work of the PM. If the PM is focused on development instead of managing the project, the project suffers as much (although differently) as if the PM was ignorant of the project.

As Johanna suggests, a lot also depends on the kind of team matrix as well. If a project manager does not understand nuances of technology but is proficient in management, overall processes, execution methods and scope, it helps to have people in the team who can take up complete accountability on technical aspects of implementation.

What do you think?