The role of the architect in Scrum
Last friday I gave a Masterclass called 'Lean Agile Architecting' to architects. Very interesting masterclass and a couple of things struck me. The issue for architects in an Agile environment is their position and responsibility. The thing with the change from waterfall to agile is that architects feel their role is being undercut, the team just goes fast and are only paying attention to the Product Owner. The standard answer they seem to get is: 'then join the team', but they feel reluctant to do so, and most of the times they can not fully commit (full time). So they pass, and they feel miserable about it, since now this Agile project is going to make mistakes, and can not learn from past experiences and their expertise. The answer lies in the closer observation of the definition of Agile and Architecture. Going agile is not the same as going fast, as the Agile Manifesto's first principle says:Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.So not just fast (early), but continuous too! And that's the whole point of the position of architecture in Scrum/XP/Agile. In order to be able to continue to go fast, we have to make sure we mind our architecture, since architecture is:
The set of design decisions that minimize the cost of development, maintenance and use (my definition, close enough to Grady Booch's)So the whole point is that architects make sure that teams can go fast now and ever after, and that the cost of use and maintenance is proportional to the development investment. So architecture is not a stable deliverable or document, much better to speak about architecting; the process of keeping the architecture aligned with the product development and agile process. Architecting is about identifying stakeholders that might be overlooked by the team and Product Owner, such as Support, Legal and 3rd party vendors. Architecting is about challenging the Product Owner and team to go slow, in order to be able to go fast by high quality standards, such as readability, 95%+ test coverage, early integration and performance testing, refactoring and the boy scout rule. So architects, make sure you identify and represent stakeholders, and get their points on the Product Backlog (yes, it may contain non-functionals) by working closely with the Product Owner. You are a major stakeholder! Assist the team by making them go slow for a good reason, namely to serve previously overlooked stakeholders. There is a subtle balance here, if in doubt go fast with the Product Owner, and only address the issue when velocity drops because of technical debt.
