Role of Architect in Agile Team

None of the Agile, Lean or Scrum principals have a formal definition of responsibilities for a Software Architect. Some companies take it to the extreme and not hire a architect at all. Others that do hire one are not clear on architect’s role within the agile context.

Do you need an Architect?

Well, at a very fundamental level, whether to have an architect or not depends on:

1. The size and complexity of the project
2. Duration of the project – both in terms of development and maintenance life cycles
3. What is at stake technically, i.e are there any critical requirements that the project MUST meet in order to be even considered worthy? Does it need a specialist position to be looked after?
4. Are the developers skilled enough to step back from coding and look at the big picture? Or do they always tend to start coding the first idea that comes to their mind?
5. Is there technical leadership in the team? If not, can the developers step up and take decisions that have a wide and long lasting impact?
6. Does the PO have a technical understanding to come up with not just the business level features but also the non-functional features?

Often, the stakeholders and the managers do not have a technical background to understand the complexity of the project and the importance of good architecture. The tendency is to believe that the developers can keep “coding away” to deliver the project. The developers also believe that they can keep “coding away” and handle things as they come by. After all, isn’t Agile all about adaptability, quick delivery, developing with no long term vision in mind etc? Right?

WRONG.

What could go wrong without an Architect?

The afore mentioned beliefs have seen many a projects fail. With no architect (or a person who handles similar responsibilities) in place, things might look rosy in the first few sprints(when minimal functionality is being delivered), but will take a turn for the ugly as sprints go by.

An Architect needs to avoid massive changes in every sprint.

As time goes by, to make a change in the code becomes a nightmare, because the code was being written with a tunneled vision of the system, by ignoring the wider system and by ignoring what’s coming in the future.

There would be no framework in place, no standard practices, each part of the code will be written with different assumptions in mind because each of the developers have different ideas. The modules will not scalable, implementing simple features takes a lot longer time than expected.

The stakeholders then begin to wonder why the technical team is unable to deliver at the same speed as in the beginning of the project. The scrum master goes crazy over why the team’s velocity is dipping with each sprint.

In agile, the fundamental principle is that things could change quickly and the team needs to adapt to those change.

However, an architect’s role is one of the few that needs to swim against the tide and avoid massive changes in every sprint.

It is also one of the few roles that needs to have a long term vision of the product, beyond the next couple of sprints. Add to the mix ever changing requirements, project deadlines etc and you have a role that deserves more attention it currently gets.

The above are just a small list of the reasons why it makes sense to have an architect. Now a more pertinent question for this post is : What is the role of the architect, specifically in the agile context?

Roles and Responsibilities of an Architect

An architect’s role in agile is an extremely challenging one, made more complicated by the fact that it is not well defined. In a traditional definition, the architect is only responsible for the architecture of the product.

Well, here are are some important considerations for an architect in an agile environment.

1. Understand from the stakeholders the product to be developed and the high level features needed.
2. Understand the time lines i.e. release dates. Even the architect should be working against project deadlines, else they tend to be preachers!
3. Understand future product plans – things that are not of immediate concern, but need to be considered in advance.
4. Any restrictions in terms of technology – either because of company policies or because certain technologies are not permitted in the client environment.
5. What are the external systems that the product needs to communicate with?
6. Understand the team’s skills (Ignore this at your own risk!).
7. Check if any developers are to be hired or trained.
8. Based on the team’s skills, decide on technology stack to be used for the product. In order to help in this process, create prototypes.
9. I personally think the architect should code at least prototypes, else I see no credibility in the decisions that the architect takes.
10. Re-evaluate technology choice, create more prototypes.
11. Decide on the tooling i.e. what tools will be used by the developers to build the project.
12. Decide on what code quality enforcement need to exist.
13. The most important aspect is to: Create the high level architecture and solution. This solution needs to be as flexible as possible to cater to changing needs as the sprints go by.
14. Work with the PO and SM to understand what features need to be implemented in the near feature i.e next few sprints.
15. Work ahead of the development team at least by 2-3 weeks and decide on a strategy i.e. an architecturally correct approach to implement the user story.
16. Work with the PO team regularly to make sure both understand how the solution is going to be. Discuss the drawbacks, advantages etc.
17. Take a pragmatic approach to arrive at a solution that suits both the business and the technical needs of the system. Is open for new ideas from both PO and developers.
18. Create “technical” user stories that the PO might have missed or needs architect’s help to write.
19. Support the development team.
20. Bridge the gap between the PO and the development teams. An important aspect in doing this is to manage conflicts between PO and development team. The PO/SM are always going to push for quick development, it’s the architect’s responsibility to make the POs understand the “proper” way of approaching the solution through the right architecture and software development principles.
21. After the development team has completed implementation, review their work and make suggestions.
22. Always stay up to date with both PO as well as development team’s work.

I have tried to list these items in a generally accepted chronological order, however in the software world and especially in agile, one size does not fit all. In bigger companies, these tasks might be shared by many roles. In smaller companies, it is generally the architect who handles the below responsibilities.