Under what conditions will organizations derive the most benefit from the AAS best practices?
None of these practices in isolation will enable agility at scale. They are meant to be orchestrated together. Improving visibility and understanding into high priority concerns for the system under development and understanding the technical challenges hindering their development early on and continuously is what enabled agile development practices to succeed in its initial context. Carrying that to scale means making sure the technical barriers and enablers are clearly communicated through not only team practices but through the working system as well. When an organization neglects the following factors, the effectiveness of AAS practices, and of Agile more generally, may be severely limited:
1. A technical infrastructure that empowers the teams to collaborate. An infrastructure that supports such things as configuration management; issue and defect tracking; and team measurement and analysis are extremely important for Agile and AAS practices. For example, a large Agile project with distributed teams may lack something as simple as a standard virtual-meeting capability to support daily standup meetings.
2. A management culture that empowers and trusts team decisions. Agile practices assume empowerment of development teams. Technical decisions made at the development level should be trusted and propagated to other teams and management that might be affected. More generally, communication barriers must be removed, and management must create a culture that removes silos, particularly around interdependent work. One key is ensuring that team members have the training and mentoring they need to make sound technical judgments. Teams must be empowered and encouraged to define their own work processes, define the measurements they will collect and analyze, and regularly evaluate the quality of their work and gauge the progress made.
Strongly hierarchical decision-making organizations may experience significant challenges as they try to transition to such a culture: development teams may be used to being told what to do and may experience unease taking the initiative, and their management may remain uneasy in granting teams that initiative.
3. Visibility. Agile is all about achieving visibility early and continuously and recognizing and addressing risks in a timely way. The challenge with knowledge work is that though work processes may be “proven” across a range of circumstances, they nevertheless represent theories of how the work should proceed (theories that can improve with time); thus, team processes should be measured, monitored, and adjusted as needed.
One key to greater visibility and understanding is to make all team artifacts that contribute to the development of the system broadly accessible to everyone in the project. Many open-source efforts now employ social coding environments—such as GitHub—that provide full transparency into each developer’s work. More generally, it is not possible to fully anticipate who needs to know about team progress and issues, now or in the future, and thus the environment should make working code, team and project backlogs, and quality-attribute priorities visible to all.
Robert L. Nord
Robert L. Nord is a senior member of the technical staff at the Carnegie Mellon Software Engineering Institute (SEI). He is engaged in activities focusing on agile architecting, architectural technical debt, and effective methods and practices for software architecture. He is coauthor of the practitioner-oriented books Applied Software Architecture and Documenting Software Architectures: Views and Beyond and lectures on architecture-centric approaches.
Ipek Ozkaya works to develop, apply, and communicate effective methods for software architecture and agile and iterative development to improve software development efficiency. At the SEI she is the deputy lead for the Architecture Practices (AP) initiative and the technical lead for the the Value-driven Incremental Development research project.