Agile Architect – An Oxymoron
Gojko Azdic builds on the work of Nick Hines at ThoughtWorks to suggest the need for a specialized role called an Agile Architect. Yet another role – this is what we rail against being carried over from Waterfall/RUP world. Gojko defines the role of an architect to:
On the topic of evaluating software architects, the final argument was that a ‘good architect needs to spot refactoring risks and to know how much it will cost later to refactor‘. Again, this architect figure somehow appears in an agile context, now effectively possessing the power to decide whether to do the simplest thing possible or to build more structure into the solution. Answering questions from the audience about up-front design, panelists somehow came to the conclusion that the architect shouldprovide‘enough design to keep the development going smooth, identifying the risks along the way‘. To perform this continuous design, an architect should be one step ahead of the team, always providing other developers with enough insight so that they can implement the next set of stories.
I think we would all agree that there is value in sketching out the layout of the applications components in advance of writing them – assuming we allow the design to evolve as we start to understand the problem better. I differ from Gojko and Nick in thinking this isn’t just a role for a single person. Every member of the team shares this responsibility. As soon as someone is named the architect several things happen:
- We stop taking responsibility for the problems we see, instead we say: "Oh that’ the architect’s concern"
- Now we have a team member who is first among equals. Her special status means that we’re less likely to question her ideas/decisions.
Creating a new role doesn’t seem justified. We’re better off coaching the team to spot and discuss architectural issues on their own.
If you enjoyed this post, subscribe now to get free updates.
Update Pete Brehens has mentioned this post in the most recent Carnival of the Agilists
Did you love this post?
Then please share it!
March 26, 2007 at 2:37 pm | Pete Behrens
Mark,
Good question, however wouldn’t this compare to saying that a Scrum Master is not needed for the team because they should all be responsible for the process?
I would argue that just as a Scrum Master is a critical roll for a team to facilitate the Scrum Process and help the team learn to own this responsibility, an Agile Architect may be used to help a team learn these architecture/refactoring best practices. The best Scrum Master (and I would argue Agile Architect) would be the one that embodies his knowledge into the team so they can do it themselves and the Scrum Master (or Architect) could move on to other more important things.
My $0.02
Pete
March 26, 2007 at 3:30 pm | Mark Levison
Pete thanks for the comment. In terms of the role you might be right however I’m wary of the of the title. I would prefer the role to be “Architectural Coordinator” – which implies that the person isn’t solely responsible for anything. My real concern is that the Architect title allows other team members to abdicate their responsibilities.
Cheers
Mark Levison