Have a Cookie

First Line Software may use cookies and my IP address to collect individual statistics and to provide me with personalized offers and ads subject to the Privacy Policy. First Line Software may use third-party services for this purpose.

In response to a recent discussion thread I came across on LinkedIn (unfortunately it is no longer available), and to expound on the issues raised therein, here are a few thoughts on the subject of dealing with architecture on Agile projects:

  • On any complex project that is delivered using an Agile methodology, special effort should be allocated for designing the right architecture, because the textbook understanding of Agile does not provide for it automatically. The actual implementation of this approach will depend on the project at hand.
  • At minimum, architectural decisions for the upcoming sprint should be discussed and made during the sprint planning session, because without them a sprint cannot be estimated correctly. If necessary, the appropriate ‘technical’ stories should be discussed and estimated. (However, it is advisable to define user stories so that newly implemented architectural features are, indirectly, a part of normal user stories with visible GUI and testable functionality.)
  • Architectural decisions that involve specific user stories should be estimated and documented as child tasks related to those stories.
  • An experienced architect (who, as a rule, is shared between several projects) should ideally be present at the sprint planning meeting.
  • If the architect’s presence at the sprint planning meeting is impossible, he or she should review the architectural decisions made by the team promptly, ideally within one day, and approve or reject them. If the changes requested by the architect impact the estimates significantly, sprint cancellation should be invoked.
  • On large projects with a complex architecture, it is advisable to maintain a team of architects to be shared between several agile teams. This team will generate and submit specific architectural decisions to teams before each sprint planning session, and the teams will take those decisions into account as they estimate their sprints.
  • Architecture documentation, if required, should be updated by the architect at the end of every sprint, because too many changes can occur during a sprint, and any attempt to keep the documentation up to date “in real time” becomes too time consuming.
  • Unlike developers and testers, a dedicated architect should not estimate and track his/her time, because the architect’s activities are carried out in a continuous fashion, often in part-time mode, and can be hardly estimated correctly.
  • I believe that on small and medium size Agile projects, architecture can be defined during the Planning Game by brainstorming with the entire team. In more complex projects with a lot of specific requirements and restrictions regarding customer production environment, the team can still generate good architecture solutions, but in this case a dedicated architect (probably shared between several Agile projects for the same customer) can be useful, e.g. for quick review and approval of solutions generated by the team during the Planning Game.
  • Otherwise what could happen, for example, is that the team may come up with a great architecture solution for the implementation of a particular User Story that would be nice in an ideal world, but the deployment of the whole project could fail, because customer security will not allow it due to very specific limitations.

Download Case Study

Need more details?

Fill in the form and we’ll contact you as soon as possible.

David Tedford

Vice President

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.

Vladimir Litoshenko

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.

Richard Leslie

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.

David Fien


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.