The Best Option for Handling Architecture in Scrum

To further explore the discussion about the role of architects on Agile projects that we talked about earlier, lets share a few ideas that 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 the 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 the right direction and keep things on track.

We might 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 other projects. This 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 us of knowing nothing about Scrum, because all team members are supposed to be interchangeable, yada yada yada. Well, we’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.

Learn more about Custom Application Development with First Line Software