The following type of question is often asked to convinced agilists: “What is the role of [insert role here] in Agility?” The role that is most often inserted architect. But as for all experts, the answer is globally always the same.
What does the Manifesto say?
One of the underlying principles of the Agile Manifesto is that “The best architectures, requirements and designs emerge from self-organizing teams.” Architectural concepts should therefore come from within the team. The architect would then be a component of an Agile team.
Moreover, the vocabulary used in the Agile Manifesto seems to confirm it. It only talks of sponsors, business people, developers, users and customers. No other type of stakeholder is being mentioned.
Beyond that, I advise avoiding what Richard Sheridan calls “knowledge towers” in his book Joy Inc. The danger of concentrating a certain type of knowledge in the same specialist is well known. This is the Bus Factor (“If this person gets hit by a bus and can no longer come to work, could the team continue?”) Or its friendly version: the Lottery factor (“If the person wins the Lottery and comes to work dressed as a duck to say bye-bye boss?”)
Sheridan advises using Pair Programming to topple these famous towers and spread knowledge. Other ways (cf. T-Shaped Skills ideas) can be imagined to get there, but the proximity between the specialist and the recipients of knowledge sharing seems to be the most effective way (the Agile Manifesto insists on the effectiveness of face-to-face dialogue). This would confirm the presence of such experts in production teams.
What does Scrum say?
In Scrum, the question is even easier to answer. There are only three roles: Product Owner, Scrum Master and development team member. Everything indicates that the expert will have to be a member of the team. Moreover, the team must be multidisciplinary (be careful, this does not mean that all members of the team know how to do everything!) and must therefore have all the skills necessary for the creation of the product. If the knowledge of the expert is useful for this creation, then he must be part of the team.
What does the HEART say (not that one)?
If we use the HEART (Heart and Essence of Agile Related Theories), as a reference allowing us to determine the place of the architect in an Agile organization, we reach a similar conclusion. Indeed, the principle of proactivity aims, among other things, at minimizing risks. We have already discussed the risk of concentrating certain knowledge in the hands of a limited number of people and the possibility of mitigating it by promoting the dissemination of knowledge. To do this, proximity of the experts and the team members in charge of creating the product seems to be a good idea.
Moreover, the principle of people in HEART explains that these team members, being those who act, are best placed to know what to do. The recommendations of experts who are not engaged in the realization are likely to not be adapted, or to be unrealizable or even unrealistic. As before, the principle of proactivity invites us to try minimizing this risk. Integrating the experts into the production team seems to help their recommendations to be expressed in the best conditions since they are part of those who do and therefore those who know.
How to manage the different life cycles of experts and team members?
It is often argued that the time during which the knowledge of the expert is used is not as long as the complete product realization cycle. The architect intervenes periodically, especially at the beginning of the product’s life cycle. But if he still must be part of the team, what should we do?
There are two solutions. The theory of constraints pushes us to involve our expert in tasks that are not his specialty if his specific capabilities are not required. He could just be a developer. The other solution is to say that the expert is certainly a member of the team but not necessarily full-time. However, the risk is great to get a specialist who intervenes only occasionally, without being a real member of the team.
It is obviously necessary to involve the expert in the life of the team as much as possible. The ideal being that he takes part in all the ceremonies (I use here the classic terms of Scrum, but it is applicable to other methodologies), all the rituals, the highlights, for each of the teams he is a member of. That means he cannot be a member of too many teams at once! He must indeed follow the complete life cycle of the production carried out by each team of which he is a member.
If we now know where to put experts, and even more so the architects, in Agile organizations, we can push the initial question a little further and ask ourselves what is the place of architecture in Agility.
OK for the architect, but what about the architecture?
As much as the sense given to expertise was not very important until now (until now in the article we treated the architect as any specialist), it now seems important to me to explain the term “Architecture”.
I will not do it with originality, but use the explanation given by Wikipedia: “Software architecture describes in a symbolic and schematic way, the different elements of one or more computer systems, their relations and their interactions. Unlike the specifications produced by functional analysis, the architecture model, produced during the design phase, does not describe what a computer system should achieve, but rather how it should be designed to meet the specifications. The analysis describes what to do while the architecture describes how to do it.”
Architecture therefore seems to be a kind of commitment to the solution that comes upstream of its development. From experience, I add that architecture is a process that is not trivial (in terms of time, cost, etc.), whose result seems most often almost fixed, and which is generally realized by experts (architects).
This seems to me to be discordant with the complexity principle of HEART. This principle indicates that the creation of software is a complex problem (Captain Obvious!) This means that we cannot establish causality a priori and that trying to provide an answer to the problem changes its nature. Thus, to engage on how to make a solution a priori (and to monopolize experts for that) seems unsuited to me.
This how to do it approach in which we invested energy may become inadequate once we have seen the result of its implementation. It may be necessary to abandon the imagined architecture and move on to another type of solution; and it may not be easy. The stranded costs would then be important.
We really feel that architecture is a way of doing things designed to answer complicated problems, problems that require the follow-up of recommendations made by experts. Just the name “architecture”, inspired by the building industry, seems to confirm this impression. Should we forget the notion of architecture in an Agile organization?
As defined above, perhaps. However, one can imagine that architecture allows predicting how to be particularly tolerant to change, updates or replacements, which would limit the “solution a priori not adapted to the complex adaptive problems” effect. This would come to favoring proactivity (another principle of the HEART), the attempt to make the best of each situation, at a lower cost, in the implementation phases of the solution.
Should the architecture mutate?
However, we saw some time ago that we had a role planned to promote pro-activity within organizations: that of Agile Coach. We could be inspired to establish one as a replacement of the architect. Moreover, Robert C. Martin, aka Uncle Bob and co-signer of the manifesto Agile, is looking in this direction with his Software Craftsmanship movement in which people talk more and more of the coach (technical).
Architecture is not completely incompatible with Agility. But as organizations have to adapt, architecture must mutate, become something more adaptable, more permeable to change. This may require new skills and this is probably why we are witnessing the emergence of so-called technical coaching positions.