In the last week, I have been listening to a lot of reasons why Architects should not be involved in code. They don’t have the time. It’s not in their role description. They’ll get bogged down in specific applications. They should spend their time at a higher Enterprise level.
So through a full vertical slice, there is a point through which they don’t want to go as it is too far down. I suspect that this point is above anything that requires a knowledge of current technology and implementation thereof as it is based on documentation and models. These models are supposed to then enter the sprint as a user story where the Agile Architect takes over the responsibility of its delivery. So our architects are stakeholders and the Role of the Agile architect moves over to the most senior developer in the team.
For the rest of the discussion, I’ll give some points I and others think is important to an Agile Architect.
First is the 10 things that Tom Hollander thinks is important to an Agile Architect.
10. “Just enough” up front design
9. Start with a vertical slice
8. Just-in-time design each iteration
7. Trust your team… but be there for them
6. Write code!
5. Be involved in everything
4. Drive a culture of quality
3. Know when changes are required
2. Shield the team from external randomization
1. Write docs only if someone needs to read them
Nearly all these are also this post by Peter:
http://agilescout.com/the-role-of-the-agile-architect/
Architecture Is a Frame of Mind
The War Room Is Where It’s At
Listen First
Mentoring
Shepherd the Team
It’s All About the Code…
Peter is a little more direct and dismissive of the Ivory Tower Architects.
“The agile architect must understand the current state of the software and know where it is going. He must spend his time with the team and be involved in all aspects of the project. The days of the ivory tower architect, sitting in an office producing diagrams and documents that may or may not be relevant, are dead.”
The only thing I asked from our Architects was to be directly involved using Pair programming for the first vertical slice. So that they can have a closed feedback loop with the developers during the time when the trend for the solution will be set and the architecture concept is set and tested in the code.
During this first vertical slice a few trends are set:
The coding standards are started for the solution.
The first unit tests are written.
The first pattern implementation occurs.
The architecture becomes reality.
The trend for the whole project is set. A trend not easily diverted from. Bad coding standards set during this time are kept consistent until the project’s end. Lack of unit tests becomes an overwhelming problem until adding a new one becomes a nearly impossible task as the code simply doesn’t allow for it.
But I suspect that from the Ivory Towers perspective the lowly actual delivered software code is not really relevant or worth the time spent on it. Shame the poor maintenance developers and users can’t share this perspective.
Christchurch Scrum 