A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.

Ensuring that the entire team is involved in major feature discussions and decisions – Part 1

This post traces my experience at 2 different organizations, with a difference between them being in the way that their organization culture was. The first organization had a culture which did not have too much of a focus on openness and ensuring that all the team members were involved equally in discussions and decision making. The second organization had already been through a phase whereby they ran through many of the issues faced by the first organization and they decided to make significant changes in their culture.
The case of the first organization was typical of many product companies, where there is a premium on the work being done by the development team, as compared to the quality team. Since the development team was typically involved in various discussions earlier than the quality team, there was a certain feeling within the development team about only involving other team members when they felt that there was a need. This was a not a good situation, since there turned out to be many cases where other team members such as the quality team member did not get involved till much later, and this caused problems at a later stage. Some of the issues were:
– Missing out on important decision. During product development cycles, unless the teams have a large number of resources, documenting each and every decision can be a problem. There was a specific case where there was a decision early on in the cycle, relating to some of the assumptions used during the development process. At that point of time, it was not felt significant, and hence was not captured in any documentation. When the testing was ongoing, it turned out that unless somebody knew about that assumption, they would make a different assumption; and that is what happened, with the QE guy making a different assumption and proceeding with their testing. The final result passed some of the test cases, but there were a minority of the test cases that were not passing, and the developer assigned to solve the issue was unable to find the reason. He knew about the assumption, but did not know that the tester did not know. By the time these issues were resolved, they caused the loss of around 3 man days of effort between the developer and the tester, days that could not be afforded to be lost. And it turned out that the tester had not been involved in the initial discussion, which would have solved a number of items.
– Contributing towards the discussion: When important stakeholders in the specific feature are not involved in the initial state, there is a certain morale problem that starts to emerge. I could see this in the earlier organization where the developers felt deeply involved with the feature, but the testers did not have the same attachment to the feature. You need all the people on the team to feel deeply connected to the feature, since that is the only way that you will be able to ensure that the details of the feature have been worked out, and both sets of people are contributing mightily to ensure the higher quality of the feature.

More in part 2 ..

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>