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?
Suggested Solution:
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.
2 Responses
Yes. My experience is little different. Being in process quality for more than two decades we always speak of adherence to established management systems and miss the difficulties with the technical team. The same is the case with the techies too. We both were speaking different terminologies.A state of annoyance was always existing. They would want that we have to “wish them get lost” while we would be at a loss to understand as to why they run away from us. Luckily we were able to get a senior technical expert who had a flair for process management and the gap was bridged. Although our getting connected well is a slow process, we were able to make a progress. 🙂
Thank you Ramachandran! Developing a relationship whether at work or in any context is a slow dance in my experience. You take it one step at a time and slowly see how you move and what you create together.