For many IT enterprise architects, the term “agile” (or “Agile” as it is in the IT world) will raise an inward groan. The methodology that has been used for over a decade in software development has proved an incredibly useful way of raising productivity and keeping coders happy in their work.
But when it comes to enterprise architecture (EA) – designing an IT system that will help a company hit its goals – the Agile approach to IT work, that often requires changes in scope and timelines, can complicate how EA teams are staffed and how new architectural designs are devised.
A recent networking session among CEB’s network of enterprise architects found that overcoming five essential barriers to EA engagement with Agile teams can help lead to better organizational outcomes:
Help Agile coaches align to EA goals: Organizations typically launch Agile by bringing in external consultants to train staff on practices such as pair programming, stand ups, and Agile story point estimation.
To make Agile work with EA, some organizations require external coaches to go through an architecture roadshow to build their awareness and learn architectural best practices so that they promote and support EA’s goals.
Define how agile projects will be governed: Governance in an Agile context should not be viewed as an event but rather as ongoing guidance toward the desired outcome.
To protect against risks in Agile projects, leading EA groups enable architects to come up with a list of assets up-front that will be potentially affected.
Rethink your architect resourcing model: The pace of change and the level of uncertainty about final requirements in Agile projects strains limited EA resources. EA leaders struggle to allocate staff across the spectrum of projects that require architectural guidance.
As a result, EA groups must fundamentally redefine how those architects get involved to create more capacity. Some EA groups triage Agile projects to understand whether they require more or less involvement based on early indicators of risk, while others do lightweight check-ins between sprints.
Communicate the value of EA’s support: Like other activities in which EA participates, Agile processes often involve a diverse array of stakeholders who have varying levels of understanding of EA’s value.
EA must clarify that its involvement is essential for achieving business outcomes and that EA can play a role without hindering the speed or flexibility of the Agile team.
Teach enterprise architects to work in a hybrid environment: Most organizations today work in a hybrid environment where some of their projects follow the waterfall methodology and others follow Agile.
EA should develop architectural artifacts that can work in a hybrid environment where architects have the flexibility to tailor recommendations based on individual project requirements.
Going the Whole Hog
Some EA groups have gone beyond adapting EA to suit Agile practices and actually use Agile principles in their own work, especially in how they create artifacts or prescribe recommendations. The following are a few ideas that have come up in recent CEB research conversations:
‘Minimally-viable’ architecture “contracts” between EA and the project team at project initiation, which outline bare-bones thresholds for what a solution can and cannot do architecturally
Standards creation that is neither fixed nor cyclical, but done iteratively with stakeholders.
Prioritizing a backlog of EA tasks and workflow items, and continously reviewing where EA needs to focus its creation of refrerence architecture, or roadmaps.