Agile think tanks recommend that the modern-day organization should be a cluster of empowered teams, an entity that is like an organism able to adapt itself and thrive. Alas, when agile consultants walk into a new customer engagement, chances are what they see appears nowhere near such a cluster; instead, hierarchies and silos everywhere.
Nathan Jessop, enthusiastic agile consultant, in his new assignment finds one such structural anti-pattern right away – the QA and Testing function reporting directly to the CEO. Nathan thinks that this should surely come in the way of collaboration between development and testing teams. In his first conversation with the CEO, Sharmila, Nathan alludes to this, testing the waters, so to speak. Sharmila smiles and says a few things as below:
“QA is a direct path of information & re-assurance to the leadership on the state of product & process quality; it has served the organization well all these years”
“The testing professionals are highly respected for their breadth of product knowledge as well as their on-the-ground value addition”
“Testing in our environment is very specialized in terms of people, test equipment and tools and there are stringent requirements for them to address”
“If people believe in collaboration for better outcomes, structures and roles should not come in the way; however, if people do not believe in it, mere structural changes will not make them believe”
As Nathan Jessop, how would go about processing Sharmila’s statements above and decide on next steps? Would you, for example, accept the drift of Sharmila’s statements and accept the org structure as a given for your coaching?
Very often, agile consultants and coaches in a new customer engagement are keen to “make their mark” visible to the sponsors. As a result, there is a tendency to look for low-hanging fruit. Nathan seems to be in a similar mindset. Without adequate time spent in understanding the customer organization, he is a tad impatient and has jumped on the reporting line of the QA and Testing function, a low-hanging fruit in his view. However, his view seems to be based on some extrapolation of his past experiences. Such extrapolations and generalizations are rather dangerous things for consultants and coaches.
If Nathan has enough observations about the actual collaboration between development teams and QA (or the lack thereof), then it is another matter. He should then be prepared to substantiate his recommendations to Sharmila, the CEO. In general, in my view, major structural changes in the organization are not the places to start for a new agile consultant. If at all, such major exercises should have preceded the very start of the agile transformation as pre-requisites.
So, if I were Nathan, I would just bite my tongue, observe and listen more to leaders & teams; have the inadequate collaboration (if at all) brought up to surface by the teams themselves.