The past couple of days, people have talked to me about architects. There are a couple of statements I have heard:
- agilists don’t do design
- we (my architect team) are supposed to work as a team with the developers as a self-organizing team. How can we do that, and still tell the teams that they need to do something differently?
This is all based on a couple of misunderstandings, I think. I will try to straighten them out here.
“Self-organizing teams can decide everything by themselves”. This is obviously wrong. If this is the case, then what is the product owner for? The team decides how to make something, but not what to make.
Mike Cohn wrote someting about this yesterday on his blog. There is obviously at least one proponent of agile – with a proven track record – who also thinks about up-front design, which means the teams around him are not all reactive. YAGNI, but you just might want to think about things for a bit anyway.
The product owner is one thing. Something similar applies to the scrummaster or the agile coach. People seem to think these characters don’t wield any power. This is also bunk. The scrummaster controls the direction of the team, almost in a tayloresque. The major difference is that the team is allowed to set their own pace. The same thing applies to the scrum coach – whoever thinks coaches have no influence is obviously not one.
I have to admit I am not a purist. I think there is a need to have a technical function – something like a product owner – to handle technical alignment and nonfunctional stuff at the system level in large projects. I don’t really care what this character is called as long as both the development teams and whoever is exercising the function are in agreement on what this function can and cannot do. I will continue to call the function “architect”, even if this will lose me some hardcore agilists.
Whoever is in a function like this should take care not to become just another developer. This is the first mistake any developer who is tasked with a different job makes. Once the problems start cropping up, it is very easy to fall back into the job you know how to do. I have seen this happen many times – and I did it myself, back when I started out as an architect/techie. The primary task of an architect is to ensure the teams are aligned. Life will become hard if this task is left unfulfilled.
This is where life gets hard. I don’t believe it is possible to get this technical alignment to happen without being a hardcore techie. I absolutely abhor non-developer architects. Still, I am saying techies who get this kind of mandate need to keep at least partly away from being a developer. Feel conflicted yet? You should. This is a very hard balancing act, which is compounded when teams do not agree and there is a need to be a part of all teams and none to be able to get things moving forward.
A coach achieves this by actively not delivering opinions. There are several ways of trying to handle this conflict, ranging from becoming “an opinionated asshole” who never delivers anything of value, going for the more military imperative style, through a coach-like style. Not everyone can adopt all of these styles, and I am not sure any of these styles are right in all situations either. Most architects lack psychology knowledge, and are ill-equipped to do their task.
I am reading “the greatest show on earth” by Richard Dawkins. On page 217, he muses on the building of cathedrals in the context of evolution:
An architect designs a great cathedral. Then, through a hierarchical chain of command, the building operation is broken down into separate departments, which break it down further into sub-departments, and so on until instructions are finally handed out to individual masons, carpenters and glaziers, who go to work until the cathedral is built, looking pretty much like the architect’s original drawing. That’s top-down design.
Bottom-up design works completely differently. I never believed this, but there used to be a myth that some of the finest medieval cathedrals in Europe had no architect. Nobody designed the cathedral. Each mason and carpenter would busy himself, in his own skilled way, with his own little corner of the building, paying scant attention to what the others were doing and no attention to any overall plan. Somehow, out of such anarchy, a cathedral would emerge. If that really happened, it would be bottom-up architecture. Notwithstanding the myth, it surely didn’t happen like that for cathedrals. (Footnote: My medieval historian colleague Dr. Christopher Tyerman confirms that this was indeed a myth that was invented in victorian times for idealistic reasons, but that there was never a scintilla of truth in it.)
This is a wonderful book – go read it.
So, it seems that our profession is now creating the same myth that was created a long time ago by (parts of?) the building industry. I am guessing whoever built cathedrals in victorian times did not perpetuate this myth, but builders of smaller things – things requiring architecture that could easily be handled by a small handful of people – could have used this myth to cut the architects out of the loop. You can still buy a small house without getting help from an architect. I wonder if there are any failed cathedral projects out there where a bunch of masons went wild?
Our problem is that the development business is very new. We don’t know how to define an architect role in a way that works yet, and we don’t know when we need to have this role around. I have a hunch that most who get this right are doing what they are doing by the seat of their pants.
I would also guess the definition of what a software architect should do is situation-dependent. Some teams produce useful installation instructions without being prompted. Others are completely at a loss and need a bit of guidance. Some teams are whipped into stopping their QA processes in favour of producing more functionality, and are never allowed the time to correct the shortcoming.
My own shortlist of candidate areas for guidance is:
- System-level QA
- Performance
- Versioning
- Deployment
- Technology platform (as in “all subsystems should use the same OS and middleware to reduce operating costs”, not “use junit 4.3.1″)
- Arbitration of interfacing conflicts
- Tracking of delivery by external parties, if applicable
- Moderation of time-to-market demands by showing the cost of skimping on structural quality
- Establishing an expectation of the lifespan of the software
I am writing an architecture mandate right now, where I am trying to find the balance between owning nonfunctional requirements, letting the teams be agile (or not, if that takes their fancy), and still opening the door for support if they need and/or want it. If I go too far in one direction, the mandate turns into a big ball of mud which won’t help anyone. If I go too far in the other direction, there won’t be room for change if there turns out to be a need for it. I am going to try to get reviews of the mandate every three months to try to get the whole thing right.
If you have any thoughts on this, please feel free to leave a comment.
I agree 100% that a project needs someone to care about your shortlist. However, like you talk about, the most effective way of being an architect is to guide the whole team to think about the right questions, rather than to give the solution. In the same way as the Scrum Master is supposed not the lead the team, but to coach the team.
Maybe it is better to think of this as a Scrum Master duty. The Scrum Master challenges the team to think about their own process. Why not also challenge the team to think about the quality of their product?
Most of the architects I’ve met were also decent scrum masters and most of the scrum masters were either decent architects or at least aware of the questions they had to ask the team. Questions of architecture are appropriate at some retrospectives, and some retrospectives could be just about looking at the architecture.
Having tried both, I’d much rather be a ScrumMaster/architect than an architect on a team that has someone else as the ScrumMaster. The overlap between the roles is too great to know when you need to step in and when you need step back to avoid getting in the way of each other.
We agree – mostly. I think there is a very good separation of roles between the product owner and the scrummaster. The project owner gives the “what”, the scrummaster can make it happen, often by doing architecty-like stuff.
Traditional architects are a bit different. They are usually also requirement originators for nonfunctional stuff. I think it is extremely easy to muddy the waters because of this. A nice workaround is to try to get the product owner to also give the nonfunctional requirements, but that takes a whole lot of effort for non-technical product owners, and I can see that some product owners would think I should just go away and get it sorted myself.
I also see teams struggling to get cross-team architectural issues sorted, especially when they try to work with non-agile teams, or with product vendors.
I am not even sure I want to give the title “architect” to someone in particular. I am leaning towards some kind of cross-cutting team where you carefully remove all the agile words and give them a list of deliverables to get sorted out, where you try to use the language that is common across the teams, and where the managerial meetings are cut to the bone.
I guess they would need some kind of project manager/scrum master. We may agree after all.
The way I see it, the architect in agile world take on more the role of a facilitator. This facilitator aid the empowered teams to make wise decisions by pointing out all interests that need to be taken into account when choosing between options. I think your list of “System-level QA [ensuring testability], performance, etc” is a good start of what interests the architect inject when needed.
I also like the “mediator/arbitrator”-role you point out. I see this as the only realistic agile way to make systems interact in a way that emerge into an enterprise architecture
If we take agile seriously I think it is important to keep the team empowered, and this put some restrictions on “traditional” ways of working as an architect. I have mused a little about this on [http://dearjunior.blogspot.com/2009/07/not-enforcing-architecture.html] about the impossibility to enforce architecture.
I’m not sure “project manager/scrum master” is a good place to put the “/”. Project manager is closer to product owner than to scrum master. But be that as it may.
Nonfunctional requirements and “cross-team issues” are no different from other requirements. These should also be on the product backlog if they have a value and a cost.
Some nonfunctional requirements may not be on the product owner’s radar, and it may be good to have people on the team who have this perspective when the backlog is being written.
Dan:
Good post. Me like.
In your post, you write about taking the consequences. What consequences do you usually hang over the heads of your teams? Isn’t this despotism with silk gloves on? “Please do as I say, or else”?
An even harder question: What do you do if the team doesn’t do the right thing, the consequences consequentialize upon the team who then shrugs it off, and you still don’t have a solution? Bigger consequences?
I think one issue with the traditional architect role is that it has both too much and too little power. The traditional role tries to mingle both a kind of product owner-ish role with a coach/scrummaster function. I think it is excessively hard to get these two kinds of powers to flow nicely in one function.
To make it worse, a traditional architect has very little power over a team. The product owner proper has real power through the budget he controls. The scrummaster usually has at least some power over the composition of his team. An architect has neither. This sounds to me like a receipt for failure.
Seems I am full circle. Need to go another way.