Fine tuning SAFe with architecture

Most organizations view their digital transformation as a top priority. Many are full speed ahead with their digital transformation using SAFe or another agile approach to deliver their information technology projects. Yet “83% of leaders struggle to make meaningful progress on their digital transformation,” according to Gartner.

Too often, architects and agile teams work in silos, as if they were conflictual approaches. It does not need to be this way. This article intends to show how harmonization between architecture and agile teams can contribute to the delivery of successful projects.  Architects can prioritize strategic initiatives from other initiatives by identifying key but problematic business capabilities using value streams and several measurement techniques. Architects can also decompose value stages defining a value stream into sub value-stages and breakdown business capabilities into sub-capabilities several levels deep for further exploration, refinement and precision.

Business and enterprise architecture model elements can accelerate and enhance with details the description of requirements, epics and user stories. Finally, architects can detect, signal and eliminate duplicated sub-projects or sprints that can appear in different Agile Release Trains (‘ART’).

What is Scaled Agile Framework (SAFe)?

Lean and agile development approaches and enterprise architecture may seem to be two conflicting disciplines to deliver software initiatives at first glance. In reality, they can be very complimentary. Agility allows rapid reaction times and expedient delivery of initiatives in a continuous flow to keep-up with quickly changing corporate environments. Using an analogy, agility allows you to run extremely quickly. On the other hand, architecture allows you to see far enough so that you do not hit a brick wall at full speed, while your running with agility.

One of the most used and thought-out agile approach, called Scaled Agile Framework, has started integrating some architecture into its methodology. In brief, SAFe is a knowledge-based framework for delivering solutions that brings business value, scales agile practices, and incorporates lean principles and practices into an organization.

This framework provides requirements teams and business analysts with a way to decompose strategic value streams and deliver focused value using ‘Agile Release Trains’ development teams with typically between 50 and 125 people to reduce software development cycle time. SAFe provides comprehensive guidance to develop better systems and software in large organizations more rapidly. This framework is getting very popular and seems to generate positive results as shown in numerous case studies.

Agile architecture

Harmonization between architecture and agile teams can contribute to the delivery of successful projects.  This is why the Scaled Agile Framework recognizes the need for agile architects. “Agile architecture is a set of values, practices, and collaborations that support the active, evolutionary design and architecture of a system. (…) Agile architecture supports Agile development practices through collaboration, emergent design, intentional architecture, and design simplicity.

Like agile development practices, agile architecture also enables designing for testability, deployability and releaseability. It is further supported by rapid prototyping, domain modeling, and decentralized innovation,” according to Scaled Agile, the creators of SAFe. Agile architects can be either business architects, enterprise architects, solutions architects or systems architects.

As pointed out in this article entitled “Agile Architecture – an Oxymoron?”, “it would be a mistake to expect that you can simply take traditional Enterprise Architecture delivery and ‘bolt’ it onto a framework such as SAFe (…) – and then deliver architecture at key points in the agile process. The highly collaborative nature of agile delivery, the need for squad autonomy and self-serve, no hand off points, and the concept of minimal viable architecture all require a corresponding change in the way enterprise architecture is developed and delivered so that it too honours the principles that are reflected in the Agile Manifesto.”

In SAFe, combining Emergent Design, Intentional Architecture to agile practices (Scrum and Kanban mostly) is referred to as the Architectural Runway, from which the technical foundation is extracted to create business value.

The enterprise architects’ role in SAFe is to provide architectural governance, technical direction, collaboration iteratively, and a complete solution deployment strategy across all SAFe value streams at the portfolio level, creating enabler epics, which are large portions of work made of several user stories as shown in Figure 2 below, to enable desired business and technical changes.

As for the solutions architects or the systems architects, they then begin to lay the architectural runway for the SAFe value streams by creating architecture blueprints with a system view, based on the direction provided by the enterprise architect. Part of this involves creating a future state for the architecture, then developing a transition plan ideally with increments to improve the organization from its current state to that future state.

Business and enterprise architects can be instrumental in the delivery of sophisticated projects with there ability to accomplish these following four tasks:

1. Prioritize strategic initiatives,
2. Decompose high level value stream/value stages and business capabilities,
3. Assist in defining epics and user stories using architecture model elements, and finally
4. Eliminate sub-projects or sprints duplicates.

Strategic initiatives prioritization

Business and enterprise architects should engage early ideally before the beginning of the Scrum and Kanban continuous delivery pipeline used in SAFe. Architects should make sure to link every value stage of the SAFe Value Streams to its enabling capabilities, information concepts and its various departments and business units to clarify how the business really works.

By starting on early into a project, architects can prioritize strategic initiatives from other initiatives by identifying key but problematic business capabilities enabling value streams using several measurement techniques. As indicated in this 5-minute blog entitled “The Relationship Between Business Architecture and Agile:”

“Business architecture applied to agile programs helps teams in setting a foundation on the highest priority capabilities and work on insuring alignment to the strategy of the business. It does not get in the way of the team, but rather works along side with the team to be better prepared and speed up the team rather then slow them down. It applies agility and the success of the team to the highest value parts of the business.”

This way, business and enterprise architecture strengthens SAFe at the portfolio level by defining what strategic agility must look like and how to do it. Without proper architecture, agile teams must predict, imagine, try and manage a single future that is based on many unknowns.

Daniel Lambert

Decomposing high level value stream/value stages and business capabilities

Business and enterprise architects can also decompose value stages defining a value stream into sub value-stages (if necessary) and breakdown business capabilities into sub-capabilities several levels deep for further exploration, refinement and precision. This decomposition will allow the elaboration of much more precise epics and user story definitions at a much more rapid pace.

Furthermore, architects can also align value streams/value stages to impacting strategies and objectives, triggering or participating stakeholders (including personas and customers from various market segments), mapping business processes, delivering value proposition (often made of various products and services) and enabling capabilities.

The same can be accomplished with capabilities, as shown in Figure 1 above, that shows the properties of the Contact Management capability, knowing how a capability is aligned with supporting applications, created information concepts, enabling process, impacting strategies and objectives, impacting initiative, etc.

Daniel Lambert

Defining epics and user stories using architecture

Business and enterprise architects also need to translate the business strategic themes of their organization into more detailed epics. By putting more resources into architecture at the beginning of the SAFe process, the likelihood that the program delivers systems and software more useful to its business users increase significantly.

The modeling executed by architects also facilitates the epic owner’s efforts. When an epic or a user story is approved to move from the backlog for review and further business analysis, the epic owner has the responsibility of creating a lightweight business case according to SAFe. This involves examining the size, the impact, and the exact benefits of the epic for the organization.

By using the business and enterprise architects’ detailed model, epic or user story owners have a far better understanding of the business scope of their epics and of the benefits the epic will deliver to the organization, as shown in Figure 2 above, where over 90% of the words describing a user story are elements of the organizations business and enterprise architecture model and where all the properties of the architecture element can be viewed as shown in Figure 1 above. This speeds-up the business analysis ability to expedite the epic or user story to its next phase.

This consulting role of the business and enterprise architect within the SAFe value stream and program levels is not limited in assisting epic owners and business analysts. The same consulting role by architects could be accomplish with solution managers and product managers among others.

Elimination of sub-projects or sprints duplicates

Business and enterprise architects can finally detect, signal and eliminate duplicated sub-projects or sprints that may appear in different agile release trains. Some SAFe programs may have well over 10 independent Agile Release Trains running in parallel, each one of them with typically between 50 and 125 people, delivering their tight milestones all in about the same time.

It’s very possible that some of the sub-projects, scrums, or Kanbans in one agile release train could be identical to other parts of a totally different Agile Release Train. Architects often have the appropriate tools and mindset to find these duplicates making it possible to allocate these resources elsewhere instead and increasing further the efficiency of SAFe programs.

Architects and agile teams should stop working in silos. Their approaches are complementary, not conflictual. The harmonization between architecture and agile teams can contribute to the delivery of successful projects aligned to corporate strategies.