Why an Agile Engagement Model?

Working Page for the Engagement Model Working Group – All Materials are DRAFT.

A very short but basic definition of an engagement model is how we as architects interact and collaborate within an organization. And is there a better way to find inspiration regarding interaction and collaboration between people than in the agile and lean mindsets?

In addition, an engagement model allows architecture activities to be explicitly and directly defined in objective terms using a clear set of guidelines. Given the long standing friction between Agile and Architecture (or at least Big Architecture) this allows the agile organization to explicitly define how architects interact in and out of the SDLC. Organizations which do this are more likely to succeed in both practices.

For instance, as found in two of the Agile Manifesto principles:

#4: Business people and developers must work together daily throughout the project

#6: The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation

And finding the values of strong leadership, clear purpose and employee engagement among the foundation pillars of the “House of Lean” it’s quite clear that the agile and lean mindsets has its place within organizational development. And therefore also its place within an engagement model for IT architects and especially very much aligned with the Human Dynamics foundation pillar of the ITABoK.

How we as architects, with different roles and specializations, find our place within an agile or lean mindset is a different story. On the contrary, architects have been rejected by agile teams (or we have alienated ourselves). For instance, looking back to the Agile Manifesto once again:

#11: The best architectures, requirements, and designs emerge from self-organizing teams

Architecture is great, but no room for architects, right? First of all, we must understand that at the time the Agile Manifesto was created, it was written from a pure software development perspective. And as architects we know that software architecture is only a small part of our profession. But we’ll get back to the potential conflict between agile and lean organizational development and the architect profession further on among the lean and agile engagement pages. First some definitions of what agile and lean really is all about. If your new to agile, or curious about the values and principles behind here’s where to start.

The picture below gives you an idea of a lean and agile adoption of an engagement model. As the core associate engagement model, also the agile adoption takes a middle-out approach on architecting a solution. Capability evolution is an iterative process, so regardless whether you as an architect take a top-down or bottom-up approach on architecting solutions and engaging within the enterprise, you follow the plan, build, run and manage feedback loop, in benefits realization and value creation.

The picture allows you to navigate through descriptions of both agile and architecture artifacts and processes that helps you as an architect to engage in an agile manner:

Iterative Development Quality Attributes Business Case Scrum Kanban Agile Modeling

Note: The “Iterative Lifecycle” and “Capability Evolution” graphics are trademarks of the Agile Business Consortium