Scrum and the Emergent Architecture

Scrum and the Emergent Architecture :

• Scrum has an iterative-incremental approach to software development and the focus is on shippable software at the end of every Sprint. In the domains of software design and architecture this leads to a major shift, i.e. from prescriptive and upfront to emergence. Designs and architectures grow and change as applications and products grow and change.

Emergent Architecture :

• The Development Team should handle architectural and infrastructural concerns as a part of other Product Backlog Items or through independent architectural and infrastructural items during each Sprint. Doing a lot upfront in order to make a comprehensive and reliable architecture at the beginning of the project is a type of waste. Handling architecture should be done continuously based on the learnings that emerge during the Sprints. It is obvious that it uses more effort at the early Sprints and decreases during the middle and last Sprints. On the other hand, during each Sprint, the team should try to produce at least one potential releasable business functionality in order to get feedback from customers. Therefore, they should do business functionality items and architectural and infrastructural concerns simultaneously throughout the project.
• The Development Team should have some guidelines for deciding and handling architectural and infrastructural concerns. In addition, in a Scrum Team, there is no title. All members are a developer. Therefore, the Tech Lead, Software Architect, Senior Architect, and Chief Architect are wrong if they were in a Scrum Team. Furthermore, the Development Team is cross-functional means it is not dependent on external resources (e.g. CTO, Chief Architect, Tech Lead, or shared architecture team) and the team has all required skills for development in itself. Finally, there is no special time at the beginning of the project. The Team works from the beginning of the project through Sprints as their work containers and through each Sprint they try to produce at least one potential releasable business functionality in order to get feedback from customers.
• The Development Team is responsible for creating the architecture. The architectural and technical design discussions start as early as sprint planning and continue throughout the sprint as the design is being implemented (i.e. coding/construction).
• The Applications overall architecture is not designed upfront, as the actual implementation of it emerges. The emergence of the Architecture is based on guidelines and agreed principles. The System’s architecture is decided throughout the project, as understanding emerges and the Development Team learns more about the project. Also Scrum also does not acknowledge anything called as Sprint 0.
• Handling architecture should be done continuously based on the learnings that emerge during the Sprints. It is obvious that it uses more effort at the early Sprints and decreases during the middle and last Sprints.
• The System’s architecture is decided throughout the project, as understanding emerges and the Development Team learns more about the project.
• Since the Architecture is always an ongoing process and subject to change, the Development Team should have a set of Guiding Architecture Principles that every Development Team member understands and follows when writing code.
• The Development Team plans some time each Sprint to discuss the architecture needed for the features planned in that Sprint.

Layering Cross – Cutting concerns :

• Cross – Cutting concerns (concerns across different layers / modules / classes within the application) should also be addressed. Example of some concerns are:
  • Performance & Scalability
  • Layering/partitioning Quality and validation
  • Reusability, Reliability, Availability, Serviceability, and Performance
  • Concurrency
  • Security
  • Maintenance
  • Error Handling
  • Logging
  • Caching and Transaction Management

Layered Architecture benefits include :

• Simplicity – The concept is very easy to learn and visible in the project at first grasp.
• Maintainability – Layering increases maintainability of a system by isolating functional responsibilities
• Layering makes it easier to reuse functions
• Consistent across different projects – the layers and so the overall code organization is pretty much the same in every layered project.
• Guaranteed separation of concerns – it is very easy to separate the concerns and the associated code organization with respect to the concern submitted.
• Browsability from a technical perspective – when one wants to change something in some/all objects of a given kind, its very easy to find and they’re kept all together.

Emergence :

• The process of the coming into existence or prominence of new facts or new knowledge of a fact or knowledge of a fact becoming visible unexpectedly.

More informations for the Scrum PSD certification here.