Large organisations often struggle to achieve the benefits of Agile when deploying products that require enterprise-level planning and collaboration.
Acquisitions create local agile/iterative development processes. There is often a lack of common governance and oversight as well as effective collaboration and co-development across teams and business units.
Architecture roles are insufficiently empowered to provide the necessary visibility and influence to coordinate and understand interaction points.
An Architecture Driven Agile framework allows organisations to leverage local practices while achieving enterprise standards and performance levels.
It has three key areas which are “breaks” from traditional agile: architecture, release planning, and governance.
Other frameworks such as SAFe (Scalable Agile Framework) exist to enable the scaling of Agile while maintaining alignment with Enterprise Architecture.
No “one size fits all” – successful implementation of any framework needs to be fitted to the various layers and needs of the business.
Large organisations scaling Agile are facing challenges coordinating:
- Architecture-Agile Interaction
Architect interaction is inconsistent. Architects are being brought into the project too late.
Architects are not given the “big picture” or roadmap of project user stories. - Architecture proposed changes impacting scope may not be fully communicated
Architecture deliverables are not integrated into team execution activities.
Architecture deliverables have primarily been used for governance purposes. - Architects are not engaged in Agile processes
Teams are not bringing Architects into key Agile activities such as backlog grooming or sprint planning.
Interaction is more ‘transactional’ rather than collaborative. - There is not enough guidance on Architecture interaction with Agile projects
Teams are uncertain about how to engage Architecture for modeling/design changes, reviews during Sprints, data requirements.
Architects are unclear on Agile resources roles/responsibilities.
The following are questions that normally surface when large organisations adopt Agile:
- Should certain types of architects be able to code and pair with developers?
- How can architects that have traditionally delivered artifacts with all requirements in hand adapt to a more Agile, iterative approach where only parts of the requirements are defined?
- We have a limited number of architects available to support the growing number of Agile delivery teams and some of them require a dedicated architect. What is the best model for effectively sharing architects across teams? Should we grow our practice and offer dedicated architects?
- Agile delivery teams have been requesting new tools (e.g. Rally) , new JavaScript development libraries (e.g. AngularJS), new source code management software (e.g. Git) and several open source frameworks that are not part of our approved software stacks and do not align with our tools roadmap. What is the most appropriate course of action to address those requests?
- Agile delivery teams expect infrastructure projects that take weeks to be delivered yesterday, how do we deal with those expectations and requests? They think cloud and virtualisation will give them what they need but they do not provide any requirements.
- Agile Teams are asking for a mirror of the production environment – how do we respond to that when we have data privacy constraints?
In order to properly support the scaling of Agile across the organisation the Enterprise Architecture Operating Model and governance structure needs to be adjusted.
