Software architects often constitute a sort of communication hub, because they sit right in the center of software development projects. I don't want to claim they represent the most important role. What I mean is that software architects have to deal with all the other stakeholders, be it customers, requirements engineers, testers, developers, and other persons involved. As a lot of communication happens with software architects, they need to take responsibility for the strategic and tactical design. This empowerment also bears some risks. For example, architects may be "leveraged" as proxies in some (political) battles. Stakeholders may try to gain influence to architects in order to achieve their own goals, no matter whether these goals are expressed in an open manner or part of a hidden agenda.
Let me give you some concrete examples: what if a product manager asks you to use a particular technology from vendor X, even if the requirements in your project demand a completely different solution. Or suppose, engineers from different locations prefer to follow their own local interests instead of contributing to the overall project objectives.
You may be surprised how often software architects have to deal with such issues. And, of course, this also holds for the other roles - architects are by no means better beings than developers, testers, etc. And I claim that political issues pop up in every development project with more than one person being involved. But what can we do about it?
In my experience, the only possibility is either to quit your job in case the political quarrels eat a lot of time and resources and there is no chance, no matter how hard you try, to stop these quarrels. I bet that many of the 70% software projects that allegedly fail, fail to a large extent due to such issues.
The other possibility is to establish an open team culture with all people involved abiding to the rules of openness. Some of the rules could be: (1) no hidden agendas, (2) project goals over all other goals, (3) the project manager is empowered to decide all project-relevant aspects, (4) all issues are addressed in an open manner with all involved persons, (5) every project member must be treated with respect.
Obviously, we could fill a whole book with such recommendations. Interestingly, it does not matter what kind of engineering process a project is following. Even in a pure agile setting such issues appear.
Maybe, we too often ignore that engineers and other stakeholders are human beings with various experiences, competencies, social skills, personal intents, and opinions. Thus, there is large chance of conflicts in a project team. For example, in a recent project some people were appointed architects and some others key developers. A couple of key developers complained not being appointed architects because they felt like second-class citizens. It did not help to explain that architects and key developers are just different roles, none of these roles considered more valuable than the other.
We often hear a lot about technologies, concepts and methods. In a project and in every professional career these aspects often are less significant than social and other non-technical skills. Architects should always keep this in mind.
No comments:
Post a Comment