In the previous post, I started discussing one of the problems that emerge with regard to email communication in a group (email communication in a group part 1), especially when it relates to the email communication groups that are formed for interacting within a feature team. The advantage of such an email group ensures that communication related to discussions, decisions and rationale are shared by everybody and such an understanding can help people later on, when actual work related to development or testing is happening.
However, when there is fast paced development happening, the amount of email that can be generated by a feature team of 6-8 people can be fairly high. The feature team is focused on development, but the workflow designers and product managers would be working on multiple items, or multiple features, and it gets difficult for them to read so much email and recognize that there may be discussions happening which can influence their work. Consider where there is a discussion going around a certain feature, and one of the QE team members comes up with a reason for why a certain workflow was designed in a such a way. Now, it is upto the designer and the Product Manager to pick up the feedback and incorporate this in their plans.
We had teams that were working like this, but we started running into problems related to this when we found that a particular workflow did not incorporate the finding of one of the QE team members and hence the workflow had to be changed, which involved a certain amount of cost, a cost that pushed us into finding some solutions.
It was difficult to curtail this habit of email. Team members could be in the office, could be working from home or from a remote location, could have found this idea while anywhere outside and sent out an email using a tablet or their phone, and these were valuable in a number of cases, enough that there was no cause to stop these emails. So, one solution that we worked out, but which involved more work (it is difficult to find solutions to tricky problems without some kind of extra work) was to have regular discussions with the designer and the product manager where major decisions and discussions would be noted. In addition, there was a page added to the feature team Wiki which noted down major queries, discussions and decisions and these were quickly brought up in these meetings. This involved extra work from a development team lead and from the QE team lead, work which was not initially accounted for, but this work led to far less slippages in terms of downstream changes in the specifications or workflows.
Another item which was added was that we added a specialized email list that was only meant for more important communication, and the designer and product manager were encouraged to join this list and get themselves removed the earlier more widely used list, and whenever there was any matter that any member of the development team or the QE team felt was important, these were sent onto the smaller and more focused list, and hence it was ensured that they were informed of all that was important for them. This measure finally led to us getting a system that worked well for email communication. This of course was not applicable for teams that had smaller sizes, since the amount of email communication was well under control, but we started using this system for feature teams that had larger sizes and were more active in terms of feature development.
|How to Manage Your Email Before It Manages You||45 Key Strategies for Better Managing Your E-mail Overload||Managing Your E-Mail: Thinking Outside the Inbox|