Agile and Incremental Design: Part IV

What is Agile Design?

An Agile approach to the design, test and development of software exploits feedback loops which are kept intentionally short.

Here the design is performed iteratively and testing, through BDD (Behaviour Driven Development), is allowed to influence design and coding. Feedback loops are present and used. In fact design, testing and coding are just different perspectives on the same activity. We are able to take comments made in a demo and reflect them in the backlog elaboration for the next sprint.

During this time the activity is constrained by a well-defined set of non-functional requirements (NFRs) and an architectural blueprint that is a living document. Implementation of the architectural blueprint is achieved through Architectural Stories, which are treated like User Stories. These technical User Stories are sometimes called enablers The maintenance of the blueprint can be done through the User Stories or as part of the architects day to day activities. This involves everyone in the architectural effort.

The objectives of design and architecture as described in the rest of this paper will be to utilise the skills and knowledge that current developers, designers and architects possess and apply it in an agile environment. This represents a starting point to people making this journey, but allows them to add true value into the software being delivered.

There is clearly a difference in the way Agile design and development works as compared to other approaches, and it is shown to be successful. But it is not magic and will not work without commitment and effort. Agile represents the experience of software efforts through the decades and continues to learn and improve. Perhaps you can contribute to that as well?

So What is Agile Design

The application as identified by its backlog and architecture defines a point at which software creation can begin. As shown in Figure 2, software creation consists of executing stories, which contain elements of design, test and coding. Some stories are enablers, which build on the architecture. Architecture and design show how elements interact with each other and the details of the elements themselves. Aspects of design include:  

1. The overall design approach, including the technical infrastructure
2. Identify design patterns being used
3. Identify the actors of the system and the roles they perform
4. Identify the constraints from the NFRs and describe how they are being approached
5. Document what is known in advance because we might as well
6. Identify implementation decisions such as languages and products used
7. The initial architectural 4+1 (Or whatever way the architecture is being created)
8. Create a roadmap for communication of our intentions

All this is good stuff, but why do we design software in the first instance? In the traditional approach the most important aspect of a design is that it passes the review cycle to allow progression to the next phase. Providing a design is considered a project deliverable, despite the fact that not a single line of working code is available for customer feedback at this time.

In an Agile world, design is a form of collaboration and communication. It is an active process focused on directly producing working software, as compared to focus on a document or review gate. The agile design document is a record of the conversations and the decisions made. These conversations are traced to user stories and architectural enablers through the requirement hierarchy. Therefore the design prepares the framework for recording design conversations regarding these stories.