Handling Architecture in Scrum

To further explore the discussion about the role of architects on Agile projects that Sergey talked about earlier, I wanted to share a few ideas that I think are applicable to smaller and medium sized teams.

Let’s assume you have a Scrum team that needs to build a complex solution. Maybe you need to guarantee 99.999% uptime, or handle 100K concurrent users, or make the application extendable while minimizing maintenance costs. Whatever the complexities may be, let’s look at our options.

Option 1: The Architect completes his work before development starts. This won’t work, since each small change request (small from the Product Owner’s perspective) may not fit with the existing design. You would need to start over, or to reserve to nasty tricks that will lead you into trouble in the future (and what was the point of spending all that money on architecture if you still have problems?).

Option 2: The Architect starts working a couple of sprints ahead of the team, and feeds them some diagrams, presentations, documents and the like. OK, this is better, but still not quite good enough. The Product Owner may decide to rearrange backlog items so that the team may be required to start building things architect hasn’t designed yet. Or a story that is slated to be developed in the next sprint will have been “slightly” changed.

Option 3: Have no architect at all and let developers decide what to do as they go along. Works pretty well – that is, if all you’re doing is whipping together a web page or preparing a quick demo for your investor (and many other cases). This could work even for a more complex application, but only provided the team is fairly compact and there are a couple of senior people on the team who can lead the rest in right direction and keep things on track.

I’d be pretty happy with Option 3, but then we would need to fire the Architect. That’s probably not good since he’s a nice fellow and also can make valuable contributions to various projects. Which brings us to Option 4.

Option 4: The Architect is part of the Scrum team. He sits in the same room with the team and can produce his diagrams on a whiteboard, napkin, back of the envelope, etc. or explain things by gesticulating wildly. He doesn’t invest weeks and weeks in creating design documents that become obsolete before they are even finished. He understands that developers don’t like his fancy design because it makes them work on weekends, not because they are dumb. And all these guys talk to each other all the time – fancy that!

OK, now feel free to start accusing me of knowing nothing about Scrum, because all team members are supposed to be interchangeable, yada yada yada. Well, I’ve read the book, and it says another thing in there that is way more important: Scrum is agile. You can play with it and adapt it to your needs.

If an Agile process is stopping you from doing what you need to do, be Agile and change the process.

Download Case Study

Contact Us



Cambridge MA

1 Broadway,
14th Floor,
Cambridge MA 02142

hello@firstlinesoftware.com +1 877-737-7178


The Hague

Louis Couperusplein 2,
4th floor 2514HP,
The Hague

hello@firstlinesoftware.com +31 70 512 1899


Sydney | Brisbane

12 Creek Street,
Brisbane QLD 4000

hello@firstlinesoftware.com +61 2 8111 5900
United Kingdom

United Kingdom


Cowley House,
12 Black Jack Street Cirencester
Gloucestershire, GL7 2AA

hello@firstlinesoftware.com +44 7771 787840
Czech Republic

Czech Republic


Na Hřebenech
II 1718/8,
140 00 Praha 4

hello@firstlinesoftware.com +420 721 537 689
Czech Republic

Czech Republic


Centrum, Šumavská,
Šumavská 416/15,
602 00 Brno

hello@firstlinesoftware.com +420 721 537 689

Send us a note

We'll do our best to answer within one hour