Recently I received an email and it went a little something like this:
This article makes a compelling case for Enterprise Architects as active participants in sprints and as close partners to developers: http://martinfowler.com/ieeeSoftware/enterpriseArchitects.pdf
Some of the points I got from the article:
As part of the development team, architects primarily act as customers
In the traditional setup, an “us versus them” attitude often exists between the architecture team and the rest of the development organization
By working together, the architects and developers can begin to appreciate their respective objectives and openly deal with conflicts when they arise.
I didn’t see anything that mentioned joining sprints. This articles speaks to the involvement from all personnel in the system delivery effort. This is a Lean principle “all hands on deck” and it advocates the inclusion of everyone right from the beginning. Enterprise Architects are not called to be involved in the physical implementation of the system but to “act primarily as customers”. This means handing down requirements and helping decided on the priority of the requirements.
I often think that the term “Enterprise Architect” is misunderstood as the “super duper technical lead”. Expecting an “Enterprise Architect” to actively engage in the development cycle and the business cycle is unrealistic. Enterprise Architects would engage at the same level as the Product Owner. Due to the diverse nature of Enterprise Architecture, technology lag can be created and having an EA trying to ramp up during development will cause more annoyance than benefit, especially when certain teams are focused on one technology and other teams are focused on a completely different technology. This is made quiet clear with the statement:
The architecture team must have a much broader perspective, because it must balance a particular application’s needs against those of the entire enterprise portfolio.
“This level of cooperation requires the same kind of resource commitment as that expected from business users.” – this is a key point.
The article is a little frustrating in that it talks about “Enterprise architects” and then uses the generic term “architect”. Each architecture discipline requires a different skill set and level of commitment. The Enterprise Architect is probably the furthest from the development effort in terms of commitment to time spent implementing, with the solution architect and software/application architect progressively getting closer to being actively involved in the development effort.
(This is not a rant on the content of the literature previous provided, just a note regarding the fact that the definitions of architecture roles has been changing over the years with other architecture roles introduced to fill the gaps.) The article is dated 2005 and “what” an enterprise architect is has changed significantly since then. A more up to date article is probably required.
A pretty accurate and slightly less dated article: http://blog.xebia.com/2011/02/28/architects-scrum-4-what-is-the-role-of-the-architect-in-scrum/
We also need to bear in mind that “Agile” is a concept and “Scrum” is an agile project management discipline. Too often we think because we are using “scrum” we are agile. The only way to measure if you are agile (according to the definition produced by the term’s founders” you subscribe to:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
This applies at all levels of the effort: architecture, analysis, requirements gathering, implementation. The primary driving force behind agile is trust. A group of people does not a team make – even if they are trying to deliver the same thing.