Agile software development and agile project management have shown considerable success in helping organizations develop better software and better manage development projects in the face of changing requirements and evolving technologies. In one sense, agile is about managing rapidly changing project factors and requirements.
But enterprises face many other factors that must also be accounted for in project management and development. For example, enterprises need to manage quality, reduce technical debt, and control the total cost of ownership for each individual project. In addition, they need to manage overall IT costs, complexity, and consistency across all projects. These are factors that architecture is in place to address but, unfortunately, these aspects of software engineering and architecture are often overlooked in the excitement of adopting new agile techniques.
Integrating the perspectives of agile and architecture has been an ongoing challenge for both teams. In a 2010 Cutter Survey, I asked EA teams, “How does EA work relate to agile methods?” A full 50% of EA teams have not yet addressed agile methods or how to make EA meaningful within that context and another 34% are struggling with the issues. Only 8% of EA programs responded that they have good integration with agile methods. The remaining 8% responded with a common complaint of EA that “agile is just an excuse not to do architecture.”
However, integration of architecture with agile practices is something that we as architects must face, not simply bemoan. Right off, I’ll assert that good agile practices are not contrary to architecture. But typically we see implementations of agile that struggle with how to align with architecture and unfortunately the industry offers little guidance in this area. Conveniently, both agile and architecture are strengths of Cutter Consortium, and our teams have been working together to successfully bridge this gap with an approach that we call Total Agile ManagementTM.
First, the implementation of agile has to include architecture. This goes beyond the typical “Sprint 0” that addresses architecture and design before development begins. We also need to establish an understanding and use of architectural and engineering guidelines and patterns during development as well as a definition of “done,” which may include a small amount of validation and documentation.
At the same time, architecture must adapt to the processes and needs of agile. Heavyweight architecture specification won’t cut it. Lightweight patterns to define architecture are one successful approach but are not enough. Further coordination can occur when architecture provides tests that fit into the test-driven development environment. But the key to integration is to clearly and appropriately define the roles and responsibilities of each team, the practices that they use to carry out those responsibilities, and the engagement model between the teams.
TOTAL AGILE MANAGEMENTTM
Total Agile ManagementTM (TAM) is an approach developed by Cutter Consortium that incorporates the best practices of agile, software engineering, and architecture to address change, quality, complexity, and consistency with a unified set of principles and practices. TAM ties together the various concerns and stakeholders that are needed for agile to provide value beyond the individual project or team to do the following:
- Improve the quality and flexibility of software through the use of engineering discipline
- Reduce portfolio complexity
- Improve integration and interoperation between projects
- Improve consistency of user interaction across applications, as well as improving those applications’ management, operations, and maintenance
- Align software projects with enterprise, business, and technology strategies and standards
- Create software assets, not just software projects
TAM is based on aligning the capabilities of three key overarching practice areas — software engineering, agile development and management, and architectural development (software, product, and enterprise) — with an organization’s culture and goals to ensure that the roles, responsibilities, and interactions of different stakeholders are clear and that all stakeholders are on board. Finally, there’s hope for architecture teams that have been struggling with how to influence agile projects (and visa versa).