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
Need more details?
Fill in the form and we’ll contact you as soon as possible.
David Tedford has over 20 years of sales experience within the IT/software industry. He excels at being immersed in a customer's environment, understanding his customers requirements, crafting solutions to meet those requirements, and ultimately providing solutions to his customers.
Senior Vice President
As the head of business development for First Line Software, Vladimir heads up business development in Western Europe and Russia.
Vladimir began his career in IT in 2002, when, as a student of Faculty of Automation of Computer Science of the First Electrotechnical University (ETU “LETI”), he began his work at The Morfizpribor Central Research Institute (CRI). Vladimir joined the StarSoft team (predecessor of First Line Software) in 2004 as a Junior Software Developer. As he gained experience with more and more projects, he was promoted to leadership roles.
The Hague, Netherlands
Praha, Czech Republic
UK Business Development
Richard has over 15 years of sales and account management expertise in the IT and Tech sector. He has worked on many outsourcing engagements with global companies.
Gloucestershire, United Kingdom
David is a business development professional with more than 20 years’ experience as a specialist in the acquisition of partnerships and IT/software services for associations, not-for profits and corporations in Australia, New Zealand and USA. He has specific expertise in the healthcare, legal and hospitality industries.