The Agile methods

Many software companies are moving to Agile processes from the conventional waterfall methodology for product development. The Agile methods are iterative and incremental compared to the strict format followed by the waterfall process model. In the waterfall model, it’s assumed that the requirements are final before moving on to the next phase, whereas there’s no such assumption when following Agile methods.

The Agile manifesto is as follows:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

In Agile processes, the focus is on rapid deliverables, usually within 2–3 weeks, known as iteration. Plans evolve very quickly and can change even during an iteration.

Architecture in Agile

One of the main questions in Agile is regarding architectural styles. Should that be done in the first iteration? The final? Or somewhere in between?

Developers can start thinking about software architecture during the initial iterations of a software project while leaving unknown requirements. Agile software development methodologies, such as Extreme Programming and Scrum, prioritize flexibility and adaptability in the development process. As such, the focus in Agile methods is on building a minimal, viable architecture that can support the initial set of features and can be easily modified and extended as the project evolves. The Agile team can define work items related to architectural styles and other design decisions on the backlog. (A project/product backlog is a collection of all the work items that need to be worked on during upcoming project iterations. An iteration backlog, on the other hand, contains the work items to be worked on during the current iteration.)

An important thing to note is that in Agile methods the architecture of a software system is typically not fully defined upfront, but is instead developed and refined incrementally as the project progresses. This allows the team to respond to changes in requirements or technology and incorporate feedback from users as the system is developed.

All the design decisions made throughout an iteration can lead to the emergence of a software architecture, which can become an integral part of the working software. Unlike the conventional waterfall model, there’s no special phase for designs (including architectural design) within different Agile processes. There’s no specific iteration dedicated solely to defining software architecture, neither at the very beginning of nor anywhere in between the Agile processes.

Overall, software architecture’s goal in Agile methods is to create a flexible and adaptable foundation for the system that can support the initial set of features and can be easily modified and extended as the project evolves.

What happens when requirements change?

One of the points of the Agile Manifesto states: “Responding to change over following a plan.” Therefore, whenever a requirement changes, so will all the relevant design decisions. This will undoubtedly mean more work and lower productivity, but this is only temporary. Usually, bigger architectural decisions don’t change over the course of a project; only minor changes are made to an overall architectural plan.

Documenting architecture in Agile

Another point of the Agile Manifesto states: “Working software over comprehensive documentation.” Therefore, even though documentation is important and useful to bring all the stakeholders on the same page, the main deliverable at the end of each iteration is (part of) a working software. As a result, most of the time spent during an iteration should be on the actual development of software, rather than on documentation.

However, it’s important to have discussions with stakeholders (customers/product owners) to determine whether something is significant enough to warrant thorough documentation by the development team. They have to explain why and how a document on software architecture can be a valuable part of the deliverables at the end of the iteration. Once the customers are satisfied or have granted permission, any documentation related (or unrelated) to the architecture can be completed.