Technical Alignment Process within Enterprise Application Chain - Part 3 - Running the alignment

In the previous two articles, we've seen what are technical alignments, who is involved in the process and how Technical Lead's preparations should look. It's now time to wrap the subject up and describe the process of running the alignment.

This article is written from a perspective of a Technical Lead and is intended for Technical Leads, Team Leaders and developers.

The Alignment Process

But first, let's take a look at what we'll need to have at the beginning of the alignment process. From the end of the previous article, we can see that four key things are needed:

• An answer to the question: What are we trying to solve?
• A list of possible technical solutions.
• A page in our project's documentation which describes the problem and potential solutions.
• A list of contacts of other teams and a Solution Designer.

When we have all of the above, the alignment process can start. The steps are:

• Contact a Solution Designer: The first step of starting the actual alignment process is to contact a Solution Designer and present your idea. A Solution Designer needs to know why you are requesting a change, the rough (high-level) plan of possible solutions and which teams you predicted to be impacted by your solutions. After you provide all this information, ask the Solution Designer to provide an assessment on whether other teams could be impacted. Agree with the Solution Designer on who should organize the first alignment session (you or the Solution Designer). Agree with Solution Designer and your Product Owner whether a support story needs to be created for other teams.

• The first alignment session: All potentially impacted teams should be present on the first alignment session. You will present the change and potential solutions in this initial meeting and gather feedback on which systems are impacted. All systems which are not impacted are not mandatory to participate in the future alignment sessions. Those who are impacted will stay in alignment sessions as long as necessary.

• Run the alignment sessions until its completely clear to all involved teams what needs to be done and how: The goals of alignment sessions are:

1. to narrow down the list of possible solutions to the most feasible/best solution for all involved systems. Even if that solution is not the best or simplest for your team, if it's agreed on during the alignment process, your team needs to be ready to implement it. That's why it's important to propose only solutions which are acceptable for your team and for which your team team has an actual implementation plan;
2. to create an implementation plan for your team;
3. to create an implementation plan for other teams;
4. to have enough technical details and requirements for creating user stories which will describe the solution in such detail that all developers would have enough information in the story and can start working on the solution after refinement;

• Provide the results of the alignment to your Product owner: Product owner should be able to read and understand requirements for the agreed solution and break down the requirements to individual user stories. If needed, provide help and feedback to the Product Owner about which stories are needed.

What you should have at the end:

1. Documented clear set of requirements and technical details.
2. Breakdown of the feature to user stories.

This concludes the series of articles about technical alignments.