Categories

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 2

In the previous post in this series (email communication and teams), I started the discussion related to how, in a previous organization, there was not enough involvement of critical team members, such as the QE team, when decisions were being made or they were in progress. In this post, I will talk more about this issue, adding more points to what was discussed in the previous post:
– Missing out on some critical workflows: Typically, the developer has a good idea of the design of the software and the architecture behind the features; the experience designer knows about the workflows (although in my experience, the experience designer does not know the minute details of all the workflows, knows these workflows at a top level); it is the QE team member who has a lot of details about how the feature works, and out of these team members, the QE typically knows the most about how a feature works.
So, when the QE member is not involved in the initial discussions, and then in the decision making process, there is a good chance that things can get missed out. Consider this example. There was a major design change, discussed between the experience designer and the development team, and the new design was worked out and set as part of the new requirements for the features. It was later, when a lot of the development and testing had taken place that it was realized that there was a small section of the features that was not immediately noticed in the normal feature walkthroughs, but was there in the detailed test cases, which did not work with the new design.
It was a small part of the overall feature, but it turned out the application crashed in this specific workflow, and the fix for ensuring that this problem was not a small one. It required around 3-4 days of development effort, around 2 days of detailed review since the change was at the core level of the application, and then another 6-7 days of testing. This was not effort that the team could easily afford, but there was no option, the change had to be done.
– Disputes between the development and the QE team: When some of the decision making happens in discussions between the development and the product management teams, and the QE team is not involved, it tends to create gaps in understanding between the developers and their corresponding QE. When the QE execute their cases, the way a particular feature works may have a different meaning between the dev and QE. The dev may have a certain interpretation based on their new discussion, while the QE would understand it based on their earlier understanding. In most cases, this understanding would be the same, but there could be cases where this understanding is different, and these differences can cause problems to the team.

More on this in the next post (post 3)

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>