Monthly Archives: May 2010

Open Vs Close cubicle and its impact on QA in Agile environment

Open vs Closed cubicles and its impact on QA in Agile

Open Space & Closed Cubicles and its impact on QA in Agile

This post discusses about the pros and cons of a team working in closed/semi-open

or an open environment. is this a QA problem ?, will come to know shortly.

Since I graduated, I worked in different companies and each had their own working style and environment. In one of them each office space is a cubicle, which is not fully closed.Just raise yourself up by 4 inch from your seat, you can see the whole floor and at least people’s head. Stand up and you can confirm if the person at the end of the floor is at his cube or not. Lets call this type of cubes as semi-open.

In another company in silicon valley, the office space is cubicle as well, but the cubicles are almost like rooms with a narrow opening and you can’t see your neighbours even if you stand up and jump. To make matters worse, each cubicle has a movable metal shelf and some people arrange their shelf in such a way that its difficult to see them even if you stand in front of their cube entrance!. Lets call this type as fully closed. Another one, fully open environment as in my current company, lets call this fully open.

In fully closed type, the problem is, face to face communicate is hard if not impossible. As Agile is becoming the defacto model being followed for software development, where not just the communication but minute by minute communication within team members plays an important role in making this a super fast successful development model. Advantage is privacy to employees, but I think it was just like that from the beginning of the start-up era and continue to be like that until someone realised that its killing productivity. In a model where you don’t have a Product Requirement Document and functional spec, the frequency of communication between team members is/will and should be very high. In this way, closed cubicles and agile combination is like a train labeled as “super fast”, with a steam engine trying to pull loads of modern coaches. Last time I heard, the company I worked for, is planning to dismantle its close cubicles and replace them with open environment, one building at a time.

Quite opposite is the open environment, where same project related team members sit next to each other. Everything can be communicated by literally ‘giving a shout’. Well, the disadvantage is, people can be disturbed all the time and spreading of contagious diseases like cold and fever are very high as well.

Whatever the environment is, whenever there is a limitation in communication, whenever there is a wait before a communication can take place, the biggest impact is beard upon by the QA team. Before discussing the how part, I would like to give a pre-amble so that the reader can empathize with us. Lets take an average team, with 2 QA engineers, 6 dev engineers , 1 scrum master and 1 product owner. If you draw a one-to-many mapping within the team members, and imagine traffic flowing across these lines in both direction, the amount of traffic flowing from QA engineers to the rest of the team will be the highest. Why is this ?

During the period of an iteration, a scrum master’s communication with the team will be about helping them out from any blocks, most of the time its passive and equally it happens via email as well. A product owner’s role is to define the acceptance criteria and clear any clarification on that if necessary, again that’s passive. A CM engineer does where is requested from the team. A passive communication is when, instead of the main subject, the opposite member initiate the talk.  A developer works on one story at a time, and at most, he or she might have to talk to the product owner for clarification of the acceptance criteria. Most of these communication happens as part of the daily stand-up.

But a QA engineer will be working on more than one story at a time, say for example 3 which happens in agile. He needs to talk to 3 developers every time he finds a defect or want to clarify the way a feature behaves. If there is a defect every half an hour, then there is an active communication involved every half an hour with the corresponding developer and the product owner, in most cases. Besides that, there might be build and environmental issues that involves back and forth communication with CM engineer. Every time something needs to be tested in stage, a communication with CM engineer is a must. For every story, any addition/deletion to acceptance criteria involves communication with the product owner. Sometimes, it is necessary to communicate with marketing department as well.

Imagine if we have to wait and there is a delay involved in every aspect of the above mentioned communication, then we might as well move back to water-fall model. The argument here is, which kind of  setup  equip the team with the best environment for faster communication. One can argue that chat clients and phone are alternative to faster communication. It might be true to some extent, but they have their own limitations. The person you want to talk might not be online or not there to accept your call and not all type of discussions can happen via chat or telephone. But the open type environment encourage face to face communication which could happen at any time. You are always seeing the team and in touch with the team.

I think, for Agile, the environment should be open type to fully utilise the agility this model provides.