10 Suggestions for the Architect of an Agile Team

Tom Hollander, a Solutions Architect at Microsoft Australia, held a presentation entitled The Role of an Architect in an Agile Team at TechEd Australia where he discussed  what he does as an architect leading an agile team.

When talking about the role of an architect, Hollander means a “solution architect’ or an application architect. He does not refer to an enterprise architect or a specialist one (specialized on a specific field like messaging or infrastructure). 

Hollander’s team has a 4 week iteration process with a stabilization period – code freeze for a few days - at the end, practices daily stand-up meetings, continuous integrations with daily builds followed by automated tests, and is employing a number of roles:

• PjM – is the Project Manager, similar to a Scrum Master, making sure the team is following the process.
• PdM – is the Product Manager, also known as the Customer or the Product Owner, determining what the product is supposed to be
• Architect – a solution/application architect
• Dev – the development team
• Test – the test team
• UX – the User Experience team
• Release – the Build and Release role taking care of the building process

Hollander has come up with a top 10 list of things for a solution architect to be successful in an agile team:

1. “Just enough” upfront design – except for very simple projects, a certain amount of upfront design – 1-2 weeks - is absolutely needed based on what type of application is - web app, smart client, mobile or batch –, what are the basic functionality requirements, a long term solution or an intermediary, temporary one. The purpose of the upfront design is to decide: what technology to use – for example, ASP.NET or MVC –, what type of application - a 2-tier, a 3-tier or a service-oriented application –, accessing the DB – stored procedures, Entity Framework, LINQ, DI. All that can be contained in a short document for reference.
2. Start with a vertical slice – means starting with a small piece of functionality – a logon page, for example – which cuts as many vertical layers as possible in order to tie together all the technology pieces decided during the previous phase. This will demonstrate that the design decisions are correct and all pieces are working together, and will represent a pattern for developers to follow when developing the additional code. If the initial design decisions turn out to be inappropriate, now it is a good time to change them.
3. Just-in-time design each iteration – At the middle of a 4-week iteration, the project manager, the product manager and the architect should meet to discuss the requirements to be addressed during the following iteration, to make sure they all agree on them, what is more important is put up in front, and everything is understood. That discussion goes on for a week in the background of the current iteration. The following week, the last of the current iteration, the architect reviews the requirements for the next iteration, making the necessary design decisions so the team can start working on them the following week. If the requirements are quite different from previous ones, then the architect does some prototyping, writing some code as a proof of concept, writing some diagrams and putting it all together in a 5-page document for reference. This is not meant to do detailed design decisions made for the developer, but rather to make sure the new requirements fit into the big picture.
4. Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for the team, solving difficult problems that might bog down the developers. The architect should be in contact with every developer each day, knowing what they are doing and helping them if there is a coding problem. This is especially needed when dealing with developers that don’t like to ask for help and try to solve problems on their own with the price of spending an entire week with that. This kind of relationship also applies to the PjM and test/build/release team.
5. Write code! – The architect should know what’s in the code in order to have a better idea on the impact of his decisions. He can also figure out when a refactoring is needed. A code writing architect has better credibility with the development team. That being said, Hollander does not believe in role dissolution. He still thinks an architect remains an architect, and he’s not necessarily as good at writing code as a regular developer.
6. Be involved in everything – It is good for the architect to be involved in all meetings related to his project: design, development, code reviews, requirements planning, etc., because he can have a larger and more clear perspective on what is going on, and he can help the product manager to avoid making wrong decisions in an early stage by informing him/her on their possible outcome.
7. Drive a culture of quality – A successful team, one that anyone would like to be part of is one built on a culture of quality: nobody cuts corners, nobody checks-in sloppy code, if there is a major flaw in the design it won’t pass unnoticed, all are honest and open, looking for the best outcome of the entire team. Hollander admits that it is hard to build such a team, but it is possible. Firstly, the architect should establish some rules in the beginning, rules are are not going to change over time because a developer happens to not like them. One example is the decision to write unit tests. Another is having a code review before each check-in, including the code submitted by the architect. If the code is not accepted by the reviewer, which can be anybody in the team, the code is not checked-in.
8. Know when changes are required – The architect should be very flexible and ready to make design changes when they are required. It may be that an early solution is no longer appropriate, or new requirements demand a different approach.
9. Shield the team from external randomization – While this is usually the job of a project manager/Scrum master, the architect can get involved in protecting the team from external requests that tend to divert the team’s focus and take time from actual work. One example could be various requests coming from the operations team wanting certain things to be done in a certain way, and their requests are not always reasonable or something that has to be implemented.
10. Write docs … but only if someone needs to read them – Hollander is not the adept of documenting everything, nor one of writing no documentation. He thinks there is necessary to have a balance, writing the amount of documentation that is actually helpful and is read by someone. Documents are good to remember detailed design decisions like a data model. Iteration design decisions, while they are discussed with the team at the beginning of the iteration, it is recommended to be saved in a 5-pages document for the developers to go to if one of them does not remember what the architect said. This also helps new people working on the project long after the initial developers and architect moved to another project to understand why some of the decisions were made. 

As a conclusion, Hollander said the architect should make sure he is part of the team in theory and in practice. The architect is not supposed to write all the code, only a small portion, he is not testing or deploying it, but he is rather making sure the entire process runs smoothly.