The Role of a Software Architect in a Scrum Team

• Tweet
• Email

• Tweet
• Email

Do architects design and plan the city, the roads and the buildings while developers build that city, those road and those buildings?

That seems to be a layman’s understanding of the difference between developers and architects. But, how does that translate to everyday life of a scrum team? What is the actual role of a software architect in the scrum team?

Think about a running system that’s already deployed in production and used by clients paying money for using it. There’s not much initial planning here that a newcomer architect can do. The city has already been built, we have the roads and we have the buildings. So, what more is there left to be done for an architect? It seems he’s not required here.

Furthermore, architecture is today understood more as a skill that should be equally distributed in the team. The developers should be capable to plan the architecture for longer than 1 sprint on their own.

Still, there seems to exist a common understanding that, although scrum developers are free to design their code, there is still a need to have an overall program design at a higher level. And it seems that this task is commonly given to the software architect. The Scrum trainers tell us that we, architects, should be really happy that they kept this role for us.

Coming down from The Ivory Tower

Didn’t architects came down from the ivory tower long time ago? Is ivory tower a symbol for not wanting to get own hands dirty or a symbol for the need to have a bird’s view over the project?

It’s possible to have both in an architect – we’ve seen that in the waterfall model.

Most of architects are anyway recruited from developer echelons. Usually a developer becomes an architect when he wants to expand his horizons and learn something about the business.

Landing among “pigs”

But how do you practically achieve both in a scrum environment? How do you define the role of the architect in such an environment? Well, you need to fight the urge to get involved into the daily business. You have to avoid the trap of being pulled in. Just remember that there are other team members being payed to do exactly that – the scrum master, the development team lead and probably some others.

How do you fight this urge?

Stop answering all the emails immediately, stop making yourself readily available for any kind of engagement that may be coming towards you from the daily business. Try to move to a quieter, less inhabited place within the office. There may not be smaller offices available but you also don’t need to share a table with the scrum master.

In a word, isolate yourself more and be less available.

As an architect, you should be responsible for an epic or a story that goes across many sprints and brings a major change (hopefully improvement!) in the system. The single-sprint features can be planned, architected and developed by the scrum master and the developers alone provided that the architecture skills are shared.

But the bigger features which need a coordination and deep technical understanding can only be done by the architect. He is responsible for coordinating the efforts with developers, analysts, testers and product managers.

So it’s important for the architect to go on and share his architectural skills as it will help him to abstract himself from the daily scrum business and allow him to have own sandbox for looking ahead and planning the future.

The more the architect’s job description is business oriented, the less is the need to “come down from the ivory tower”. For instance, a solution architect working in pre-sales needs to have a commanding knowledge of the business in the first place and not be an expert in Oracle DB tuning.

On the other hand, a software architect in R&D will probably have more programming skills and use Eclipse and java docs on daily basis. Or Visual Studio and MSDN, of course. In my case, it’s both.

Winning friends

Don’t you have a feeling that scrum is again about protecting own domains? Although proclaimed as an ultimate team-oriented methodology, it still seems that developers continue to like working on *their* piece of code building fences around their little kingdom. That’s human and it’s understandable. It is but a little less visible with external developers. They tend less to get emotionally attached to the source code repository and more to do the assigned job.

However, one thing is a constant among all scrum developers. They do whatever they want with the code – design, implement, improve and optimize without the obligation to consult anyone as long as it’s fulfilling the requirements.

An outsider (a chicken) that understands the code (which pretty much filters the choice down to the software architect) will see this as a self-governed or even anarchistic programming. An architect does not control this. But he can try to channel it. How do you do that?

It will take some time to get “recognized” among the scrum “pigs”. As an architect is, usually, not directly contributing to the code and is, also usually, not a direct manager of the developers, he needs to find other ways to earn the respect.

The way to do it is to be patient, observe and learn from the fellow developers. They solve everyday problems and they should be your friends because you can learn a bunch from them.

When you have finished a SPIKE, you naturally want to push it into the product. You need to do a lot of lobbying to get everyone on board in order to achieve your goal. Getting everyone on board will also get you respect.

So, there’s no easy way – it consists of looking ahead, coming up with smart solutions and after that, persuading the developers and the stakeholders (in that ordeer) into the validity of your proposal.

But, that’s the advantage of a scrum architect over a waterfall architect. You don’t write specs and design documents. That gives you plenty of time to do what everybody else would like to do. I mean inventing things.

The developers would love to do it and they actually do it but not as part of their official jobs. They do it on their spare time which they earn by being quick to solve their tickets. But the scrum architect is here to invent and look into the future. And getting payed for it.

How much more cool can it get?

If you do it properly, you will soon be in a situation where developers approach you to share their own ideas with you. Because now you are the official place where new ideas are being developed, channeled and pushed into the product. You are their optical cable plugged into the stakeholders (ok, do not try to picture this!) and they would want to use that. Be their friend, let them and they will be grateful and willing to listen to you.

They will, in the end, not only approach to share their ideas but also the frustration that the ideas are not implemented that quick in the product. In short, you become their confidant. Almost like a pig but without sharing the food & bed. Or source code, for that matter.

So, do not be afraid to share your architecture skills among team members. Everyone profits from that, including you. You still get to keep your business skills, the bird’s eye view, the strategic thinking, ability to communicate to stakeholders, ability to produce great presentations, ability to understand management presentation, ability to translate company goals to common language and the opportunity to represent the company in client meetings.

The best thing here is – you have no competition. Most of developers simply do not want to become architects anyway.

If you liked this post, please tweet it, share it or digg it using the buttons on the left. Thanks!

 

Last but not least, here are some resources I used as references in writing this article:

Scrum Team

The Role of the Software Architect: Caring and Communicating

SCRUM and Architecture – Do they mix?

SCRUM and Architecture – Partners or Adversaries?

Does a software architect have a role in agile, esp. Scrum?