Part 7. Face-to-face conversation is the best form of communication (co-location)
In a previous blog, I indicated why this principle is highly deficient when applied to anyone outside the immediate development team. Additionally, there is a strict reluctance from both development and architecture to include enterprise architects in the development process (quite correctly, as it is a level of detail they should be unconcerned with outside the segmentation of the capability and the governance of its production).
Once the interfaces, acceptance criteria, principles and constraints (of which requirements, functional or otherwise, are part) and documented and understood, the team can choose to work whatever way they wish. If there is no clarity in the understanding of what deliverables the team should produce, the exercise will result in wasted development effort or high risk deployments which may fail catastrophically to deliver the value of that capability.
Also, it is the QA and PM’s responsibility to make sure that all communication into and out of the team is strictly controlled and is in accordance with the TOGAF communication strategy documentation. Use of importance-interest stakeholder quadrants (e.g. Eisenhower matrices) and stakeholder analyses/management techniques is the domain of the enterprise and business architects. Once agreed, it is not the responsibility of the development team to deviate from that strategy.
In larger organisations, developers are not the best members of the team to communicate information to non- technical audiences who are unconcerned with the detail of the realisation exercise, especially if they are unaware or unconcerned with the bigger picture (which is an area a lot of practical agile developers normally shun). As a result, they may make development decision on the fly or make the client aware of system level decisions which are incongruent with the enterprise strategy at a higher level, meaning the customer will go away thinking one thing, when the EA has stated something altogether different. These ‘double binds’ lead to confusion, which potentially can feed back into the team when the ultimate stakeholder makes what they think is a ‘corrective’ change to requirements, which may encompass the work of other teams which fall outside the remit of the source developers.
This results in a violation of architectural principles or governance procedures, duplicated and incompatible development deliverables (as the symmetry of conformance principles may be unable to be applied to both sides of interface contracts), overlaps in responsibility which fall outside what is known about in development capability (at the enterprise architecture level) and many other problems.
A slight modification can see RACI matrices help delineate responsibilities for capability deliverable by team. Once delineated, it should be strictly enforced and governance procedures/logs used to determine the decisions that were made and why they were made.
This article first appeared in GoadingTheITGeek in April 2012. It was the most visited article with 4,490 readers.