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.
Update Pete Brehens has mentioned this post in the most recent Carnival of the Agilists
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
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
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