Embracing Agile Practices(Part-2): Architecture Design Sprint

12 min readJul 30, 2023

In my previous article, I described the problem and the ADS approach to solving the problem.

Disclaimer:
Whether consciously or unconsciously, we often adopt various methods to simplify our tasks and enhance business processes. There is no one-size-fits-all approach, as what works for one organization may not suit another. The key is to innovate and customize existing industry standards to meet our specific needs. Ultimately, the primary focus should always be on delivering high-quality products or features to the right customers at the right time. To facilitate meaningful discussions about business matters and processes within our industry and across organizations, it’s essential to have a common understanding of the terms and terminologies we use. Let’s continue to strive for excellence in our agile practices and drive positive outcomes in the world of enterprise architecture.

You can read the first article of this series here: https://dilankam.medium.com/embracing-agile-practices-part-1-the-significance-of-agility-in-enterprise-architecture-3f17b95cbf84

Here, I will discuss each step of 5 days of ADS in detail.

Day 1: Understanding

Day 1 workshop walkthrough will be as follows;

Business decision maker presents the business context and the key drivers for the program.
The solution architect presents the overview of the high-level architectural capabilities that play a role in enabling the check processing value stream. He/She also described the key technical components and the conceptual view of how the solution hangs together in today’s world. He/She then highlighted some of the key architectural risks and issues that exist in the relevant context.
A business analyst/Product Owner or Domain expert will present more detail on the operational aspects of today’s solution, the business scenarios, and the workflows involved. He/she also identifies the key stakeholders who work to make the check processing value stream work effectively. He/she will be presenting a recent firefighting incident that was caused by new accounts posting logic introduced as part of an unrelated change in the payments processing system that inadvertently impacted the check processing. He will make attention to the operational risks, the key person dependencies, and the overall flakiness of the current solution.
The agile coach or facilitator will note down key points from all three presentations mentioned above and post-it notes, typically using one post-it note per point noted. He/she stick it on a random part of the wall that was closest to where he/she is standing. He/she urges other team members to do the same and explain that this is something that the team would continue to do throughout all workshops and that these points would be reviewed periodically and would be used to guide the workshop sessions forward.

Also, the facilitator will introduce the idea parking lot, which is a space on the wall where the teams could park important discussion topics and ideas that are not an immediate priority for discussion, but something that could be important to review and be picked up at a later time.

Then the team got together to define the goals and the anti-goals. The goals were the items that the team should focus on, and the anti-goals were the opposite. The anti-goals function as a guardrail that would ensure that the discussion does not slip into adjacent topics that are not relevant to the present architecture sprint.
The goals and anti-goals were worded in business terms so that the business value of the goal was apparent to all. Then the team members took turns for the goals that they believed passionately in, and after every member had a chance to voice their opinion they voted using the three dots method to determine which goals should have higher priority over the others.

In the three dots method, each individual has three votes, and he or she casts the votes by placing a dot or an asterisk on the items on the board. The individual may scatter his or her three votes across three different items, or even cast two or three votes on the same item.

Once all individuals have had a turn to vote, the labeled priority of the items, as viewed by the team collectively, can be inferred. In this case, the top three goals were deemed must-do, which is non-negotiable and of the highest priority. The next three were deemed should do, that is the second level priority. The rest were deemed as nice to have.
The team members then distributed to each other a brief one or two artifacts that they had prepared in the run-up to the ADS. This was based on the existing knowledge they had about the domain from the perspective they represent or from research done in the area, or through information gathered from any reliable sources available to them. Each team member will be shared the artifact they had prepared, and each took about 5–10 minutes to walk through the artifacts and briefly described its contents to the team.
Then the team will be segregated all information they had dotted down on the sticky notes on the wall into three categories, namely facts, assumptions, and questions. These data points, if you remember, were based on what the group dotted down based on the information gathered through the above sessions. This process required each team member to introspect deeply to actually make the distinction between facts and assumptions.

The categorization of facts, assumptions, and questions on the first day of ADS looked approximately like this. Please note that this categorization at this stage is by no means set in stone, and individual items can move across facts, assumptions, and questions as the group traverses through the various activities, in the upcoming sessions, spanning the entire week.

The final task for day 1 is for the team to come up with a single problem statement that describes briefly what the team should attempt to solve. This involves individual team members articulating a problem statement on their own, initially based on the information they have gathered so far. And then, working as a group to create an aggregated problem statement that best represents the multiple perspectives.

Day 2: Identifying the Problem (Framing/Reframing)

Day 2 of the ADS process corresponds to the framing phase in the innovation process framework. The objective for day 2 is to start the day with the problem which the team came up with, by the end of day 1 and identify what area of the related problem frames.

Framing and reframing are activities by which the hidden dimensions of the problem and the aspects of the problems don’t normally meet the eye. The process involves exploring the problem statement, from the perspective of meaning, use, and usability. Some of the techniques that the ADS teams in this process include;

1. Challenge mapping.

Where challenge mapping is the process by which the team picks apart the identified problem statement by asking the following questions. Why, why else, and what is stopping us? The why and why else questions point us to the more underlying or broader context in which the problem is framed, and this is something that will help in thinking of other approaches to solve the problem.

It seems as if there are infinite possibilities for solving problems. Thus, overall this kind of analysis helps us establish the deeper context and meaning of why the problem even exists, why it is worth solving, and the range of solutions that exist for the problem. Then what is stopping us? the question is used to analyze the problem to identify the tasks involved in actually realizing the solution. It offers insights on what needs to be done, and what capabilities need to be added, replaced, uplifted, or removed.

2. Ethnographic research.

This method requires the team to actually visit, observe, and speak to the people manning the check processing workflow within CFBC. It involved observing the actual work in progress as it gets done through different stages in the value stream, and the touchpoints within the value stream, while interviewing people with the intention to understand first-hand how the process works today by observing work as it gets done, specifically making notes of the various milestones within each value stage, and identifying the automotive services or human actors that interact within the value stream to progress the tasks, and eliciting other problem frames that have not be identified, especially focusing on the human-centered aspects.

3. Stakeholder empathy mapping.

This mapping method is the process by which the team describes the key human actors in the value stream, and describes their professional and personal attributes, their emotions, and experiences as they attempt to get their jobs done. This helps the team to tease out and grasp the human dimensions of the problem frames. The team articulates one stakeholder empathy map for each significant stakeholder group.

4. Stakeholder journey mapping.

The objective of this exercise is to get even deeper into the end-to-end experience of each stakeholder within the value stream, as they try to get their job done. This is derived from a framework prevalently used in the industry called customer journey mapping. The stakeholder journey mapping extends this framework to all stakeholders, internal and external to the organization, who play a role in the value stream. It describes the various touch points for the stakeholders within the value streams and captures the experience from various dimensions. Overall, it describes how the stakeholders interact across these touchpoints, and how they experience each part of their journey. It is also important to understand which stage of the process is painful, delightful, or somewhere in between those two emotions from the stakeholders’ experienced point of view.

Day 3: Synthesizing

In this phase, the team needs to narrow down the solutions/concepts discussed in previous phases to one solution and alternative approaches. The team will be given time-boxed opportunities to:

Review the goals and the anti-goals section collaboratively to see if any goals had emerged, or if their previous assumptions on the goals and anti-goals had changed based on any of the discussions that they had in the previous day.
Review the facts, assumptions, and questions section on the wall to ensure that it reflected with current thinking of the group.
Go through the idea clusters that they had created, and filter each idea based on whether they corresponded to a goal or not. If they did not correspond to a goal, they were either taken off the wall or if the team thought it was still a great idea to pursue at another time, they moved it into the ideas parking lot.

The team will be having the opportunity to represent the holistic solution concept that the team would recommend for implementation. It can be individual, paired, or group of members within the team. But the concept should be based on various ideas within the ideas cluster on the wall and prepare a storyboard for these ideas. They represented their concept in a comic strip format or flow diagram or sketched wireframes.

Then there will be time-boxed sessions where the team presents each storyboard in terms of how the solution concept solves the problems and answer questions from the rest of the team members.

then teams will be asked to use the three dots voting methods to cast their votes on the concepts that they liked best, given the desirability, feasibility, and viability criteria, and hence identify the concepts that the team thought were most promising.

The objective here is not to select one winning solution concept, but rather to develop an overall concept that best solved the problem and represented the best value for the business. At the end of the session, the team had a very solid solution concept that seemed to be at the intersection of desirability, feasibility, and viability.

The teams were then split into pairs based on individuals who had the closest affinity to their respective job functions. This is in no way a prescriptive or recommendation of how the individuals should be paired for the next exercise, but it has to be viewed as an example. Each pair were asked to develop different artifacts such as;

The architect and developer team were asked to develop an Architecture Canvas, which is a single-page snapshot of the overall architecture and implementation considerations.

The business analysts and the UX specialist teams were asked to develop the Process Flow indicating the viewpoints for the proposed solution concept and any UX sketches to represent the human touchpoints and the overall experience.

The senior business manager and domain expert were asked to develop a Business Change Canvas.

Now the teams will be given a time box to discuss any incongruences between these models and smooth out any rough edges that stood in the way of developing a holistic solution concept. The facilitator will be invited a number of stakeholders including the business owner for all systems in the domain, and other significant stakeholders across the checks processing value stream for a quick playback of the solution concept that the team had just modeled, in order to solicit the first level of feedback into the process.

The team also will be having a quick retrospective before concluding the session.

Useable canvas templates.

Architectural Canvas

2. Business Change Canvas

Days 4 and 5: Realizing/Prototyping

Days 4 of the ADS process focus on the realizing phase. On Day 4, the team reviews the solution models that were developed on Day 3, considering feedback from the external playback. They create stakeholder journey maps and identify key improvements. At the end of day 3, they use job stories to decompose the design problem, and then create a story map that describes the progressive realization of the solution.

Then team will identify the key differences and improvements that the stakeholder will experience with the target state solution agaist the current state of the architecture.

Architecture Development Sprint (ADS), the team creates a story map that outlines the progressive and incremental realization of the solution. This map is built around key high-level job stories identified in the Architecture Canvas, forming the backbone of the target solution. The team’s focus is on proving the architecture and demonstrating it to stakeholders, which constitutes the “walking skeleton.” They identify a combination of job stories and user stories necessary to reach this milestone. Additionally, the team defines stories for the Minimum Viable Product (MVP) and the Minimum Awesome Product (MAP) to cater to real customers and consumers. The day concludes with a high-level plan in the form of a story map, to be presented to stakeholders for feedback and input. As always, the day ends with a retrospective to reflect on progress and improvements.

On Day 5, the team adjusts the story map based on feedback and develops at least one walking skeleton prototype to demonstrate architectural feasibility. The team concludes the first-ever architecture development sprint with a working prototype, a clear target experience, and a high-level plan for realizing the solution.

Conclusion

The Architecture Development Sprint (ADS) has proven to be a transformative and invaluable approach for enterprises seeking to achieve greater agility and success in their architectural endeavors. By embracing a hypothesis-driven, iterative, and collaborative process, organizations can effectively address complex problems and design innovative solutions. Through the ADS, cross-functional teams have the opportunity to explore, frame, and refine architectural challenges, leveraging the power of diverse perspectives and expertise. The emphasis on stakeholder empathy, journey mapping, and job stories ensures that the solutions remain deeply human-centered, enhancing user experiences and business outcomes. Moreover, the ADS provides a structured framework for continuously validating and adjusting the architecture to meet evolving needs and goals. This article has shed light on the key principles, activities, and benefits of the ADS, demonstrating how it fosters a culture of innovation, adaptability, and continuous improvement within enterprises. As organizations strive to navigate the ever-changing landscape of technology and business, the ADS stands as a beacon of agility, guiding them toward architectural excellence and sustainable success.

Please note that building agility into the process of architecture development does not automatically fix the architecture itself. The next article will explore how the program incorporates agility and evolvability into the architecture.

You can see the part 3 of this series here: https://dilankam.medium.com/embracing-agile-practices-part-3-the-architectural-agility-c0d220604ef8

Resources:

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days — Jake Knapp

2. Becoming an Agile Software Architect: Strategies, practices, and patterns to help architects design continually evolving solutions — Rajesh R V