I have mused a little about this on [http://dearjunior.blogspot.com/2009/07/not-enforcing-architecture.html] about the impossibility to enforce architecture.

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.

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.

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.

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.

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.