These are the slides with some notes from my talk about software architecture when developing in an agile way. Contents
Max wants to get feedback about the architecture and the software his team built often and as early as possible. Earlier feedback means that the team can correct its course earlier and thus reducing waste caused by building the wrong stuff.
Max’s team adopts continuous delivery to delivery changes of any kind (features, bug fixes, experiments) as quickly as possible to the stakeholders to get feedback. Even if the team uses prototypes (paper, wireframes, clickable prototypes), real feedback can only be gathered by real users using real software in real scenarios.
Being able to deliver changes quickly and safely at least to a demo system is essential. Automation helps to eliminate human failures and that everybody on the team can deploy a change quickly.
Max’s team sits together regularly (e.g. every other week) to discuss about the architecture. The team looks at the architecture in two different ways.
First, the team looks back into the past and discusses how well the architecture supported building features. How could the architecture be changed to better support future features that are alike past features? The team then adapts the architecture accordingly.
Second, the team look into the future – the features that are likely to get implemented. The team then anticipates how the architecture will support them in implementing these features. If needed, the team changes the architecture. Be sure to look far enough into the future – 2-3 months – so that there is enough time to develop good ideas. Good ideas need time to form.
Another form of getting feedback about the architecture is to perform an assessment. That can be done by the team themselves by checking whether the architecture still fulfils the quality attributes requested by the stakeholders (see initial requirements workshop earlier).
The team can write non-functional tests that check whether the system is fast enough, can handle the load or is still installable to a certain environment and so on.
Finally, the team has the option to go for a more formal review by an expert or maybe a software architect from another team. An external view helps to break Groupthink.
Now that Max’s team gathers feedback, they should make sure that the software keeps being flexible so that the feedback can be integrated into the product. Continue reading: Changing requirements and technologies
[…] How to get fast feedback […]