The architect’s effectiveness to drive sound architectural decisions and reconcile tradeoffs that positively impact the quality of software solutions can be inhibited when development teams are immature and appropriate quality assurance process and tools are lacking. Teams that must adapt their agile software engineering approach to fit non-agile organizational structures and business contexts find this challenge particularly apparent.
This experience report shares insights and lessons learned from a yearlong effort to work with newly formed agile teams to standardize on quality assurance practices and tools across projects for a customer who is new to agile development. It presents a set of process, skill set, and infrastructure changes driven by architecture quality attributes that enabled our teams to become more productive and more effective in engaging with the customer. While challenges remain, our teams today are better equipped not only to map quality attributes such as performance and integrate-ability to specific development activities but also to manage and measure these attributes.
In presenting these lessons learned, we structure the talk into three sections. First, we briefly describe our business context and development environment for teams working directly on several customer solutions. We then provide details of the quality initiative that introduced new quality practices, infrastructure, and development skills to the teams, while highlighting several of the challenges we faced. Finally, we share insights and tactics, from an architect’s perspective, that can help with these challenges, particularly the ones related to agile, architecture, and driving quality attributes for a non-agile customer.