We are always using simple framing models to clarify our thinking. These framing models is to help us:

1. examine closely associated concepts in a conversation without ambiguity of language.
2. to explicitly isolate conditions where the deliverables & engagement model of an EA Team changed

Isolating where an EA Team’s engagement & deliverables allows us to continually refine our EA Capability Atlas and EA Capability services. High functioning EA team’s are optimally configured to improve their fitness.

The Six Agile Use Cases explore different conditions where an EA Team must be changed.

Six Agile EA Use Cases

At Conexiam we are constantly working to develop Navigate and Predictable EA. Our development comes from multiple project team working to develop consistent our consistent approach. We are most careful when we are agreeing. Too often overlapping use of terms allows people to think they have an agreement.

Use Case 1: Use Agile Method to develop EA

In this use case the EA Capability is configured to use agile methods to develop an Enterprise Architecture.

Conexiam Predictable EA is an example of this use case. To help understand that an architecture is used to support decision making, we routinely refer to the useful work product as the “Advice Binder”. This binder is optimized to purpose and problem. It will be consumed in in several different ways.

This use case will largely impact execution of all ADM phases to develop Architecture.  This use case is dependent upon the outcome of Preliminary Phase, and the structure and execution of the EA Capability.

Use Case 2: Use EA to Define Enterprise’ Agile Approach for Change

In this use case the Enterprise Architecture is used to structure how the Enterprise performs change. Products, Sprint team structure, velocity, alignment with all change approaches are performed.

The questions be addressed are what change, what development should follow which approach. In the case of agile methods, questions such as the Product, Sprint team structure, velocity are all answered.

This Use Case is largely exercising the TOGAF ADM’s Phase F, G & H based upon a Strategic or Portfolio architecture.

Use Case 3: Use EA to Guide Backlog & Sprint Planning

From the perspective of Enterprise Architecture & TOGAF, all implementation, prototyping, pilot, project and agile sprints happen with Phase G. Best-practice EA will produce an enterprise architecture replete with a solution delivery notebook, gap, control, architecture specification and work package. This material needs to be described in terms fit for the backlog: Epic, User Story and Architecture Runway.

The Enterprise architecture will contain a set of gaps, work packages to fill these gaps and limitations on the creativity of implementations teams’ freedom to perform the change. It will include traceability to drivers, goals, and priorities outside the purview of the product manager and customer.

In classic agile, the customer-driven Epics and Users stories fill the back-log. The customer provides prioritization criteria. The self-organizing agile team prioritizes work.

This use case uses the enterprise architecture to provide non-customer-based backlog and guide prioritization in sprint planning.

In this use gap Epics and User stories derived from gaps and work packages. External dependency constrains prioritization, acceptance criteria and exit criteria. Overriding priorities may be provided.

This use case mostly exercises the TOGAF ADM’s Phase G, Implementation Governance: in plain language within Phase G an implementation team is informed of the work they need to perform and external constraints on their freedom to perform the work. How the EA Team communicates is driven by the organization of the implementation team.

The critical element is aligning EA governance activity with agile change model. The momentum of the sprint team must not be impaired.

Use Case 4: Use EA to constrain Agile Sprints

This use case is largely exercises the TOGAF ADM’s Phase G, Implementation Governance.

Following best practice EA Governance the essential question is:

1. Did the agile team reasonably interpret the target architecture’s documented guidance and constraint: Y/N?
   • If yes, their interpretation should be accepted as compliance and any issues addressed through a change to the architecture
   • If no, develop a recommendation to correct the situation.

This is a key point. Good architecture can have multiple implementation choices, and the agile team is not required to adhere to opinion. If the implementation choice is a reasonable interpretation, it should be judged compliant. If something was left out of the architecture specification that is not the agile team’s problem. It is the EA team’s problem, they need a change to the approved architecture.

The critical element is aligning EA governance activity with agile change model. The momentum of the sprint team must not be impaired.

The Gaps, Work Package Strategy, Controls and Architecture Specification guide and constrain sprints. They must be written and presented in terms that the agile team can consume. Controls and Architecture Specifications are typically rendered as acceptance criteria and exit criteria.

Use Case 5: Use EA to solve Dependency

In this use case the Enterprise Architecture is used to address dependency & impact across agile teams.

This use case is distinct from Use Case 4, because it changes how the EA team engages. Often where there is dependency it will be between where different change methods (agile & waterfall) are used in different parts of an enterprise and where choices within a sprint can have cascading impacts.

A key role of developing architecture to support Solution Delivery is to identify and address these dependencies before an agile team trips over them.

In Use Case 4, a success measure is ensuring that momentum is not be impaired. In this use case one team’s momentum must be balanced against other agile teams, operational units and teams that use other change methods.

This use case largely exercises the TOGAF ADM’s Phase G governance & change order activity. Frankly,  best practice EA Governance avoids granting exemptions to architecture cross-team dependency challenges that were not identified are the most common area of architecture exemptions.

Dependency issues are the EA team’s problem, they will need to perform work to dig the organization most effectively out of these holes Addressing these problems requires careful attention to superior architecture, Controls and architecture specifications expressed at Principles.

Use Case 6: Developing EA that enables an Agile Enterprise

In this use case the EA purpose is constrained to require acceptable Target architectures to prioritize agility.

Frankly it has nothing to do with any agile methods. Many agile organizations we have worked with don’t use agile change methods.

We draw heavily from Supply Chain & Disaster Response as high agility touch-stones. We use 5 attributes for agility (drawn from sports & military research):

• ALERTNESS
• ACCESSIBILITY
• DECISIVENESS
• SWIFTNESS
• FLEXIBILITY

This use case exercises Conexiam’s Navigate Agile Enterprise Atlas. It optimizes architecture development for agility through a specialized viewpoint library, stakeholder engagement and concerns.

Bluntly, this use case is dangerous if it does not align with the true preferences of an organization’s powerful stakeholder’s.

In terms of TOGAF, this use case is most focused on the TOGAF ADM’s Phase G & Phase H value realization activity, where change must be aligned to creation and sustainment of an agile enterprise.