Technical Alignment Process within Enterprise Application Chain - Part 2 - Alignment steps - Preparation

When you need to implement something which has an impact on other systems in the chain an alignment is needed. In this situation your Technical Lead initiates the alignment and leads the alignment process by organizing and running the meetings (technical spikes). For this process to be effective, you can follow some base guidelines outlined in this article.

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

Preparation steps for a Technical Alignment

• What you need to have before you start: You'll need to have a clearly defined issue, feature or improvement requirement. The key question which you should have an answer for before you start alignment preparation is: What do we need to solve? How should we solve it comes later in the preparation process;

• Start it in documentation, update documentation: Your team is probably using some software to collaborate with other teams and write technical and project documentation (Confluence, some type of a Wiki, ...). Technical alignments are usually done through a combination of mail communication and group calls. There is a lot of information flowing during the alignment process which needs to be filtered into development requirements at the end of the process. The easiest way to do it is to have "Meeting minutes" document after each alignment session and to summarize conclusions from mail communication after some part of the solution becomes clear and agreed upon by all involved teams. For this purpose, you'll need a section in your project's documentation where you can put notes and requirements for all currently active technical alignments. Otherwise, your requirements will get lost in e-mails and notes.

• Formulate the base of a solution idea: If you need to lead the technical implementation of some solution, it's important to have a clearly defined idea of what and how it needs to be done. It's recommended that developers first investigate possible solutions either through investigating the issue or by building requirements for a new feature/improvement from scratch.

• Narrow down possible solutions and be prepared to implement any of them: If there are more than one possible solutions, narrow them down to those which are technically feasible. If you don't like some solution or implementation method or the team is not confident whether it can be done or not - rule it out as a possible solution. When alignments and technical spikes start, you already need to have a clear information on what exactly needs to be done so you can know the impact on other teams/systems in the chain. Proposing a solution which you are not ready to implement only adds confusion to the alignment process. You need to be confident about the solution you are proposing.

• Have team meetings if needed: Team meetings and brainstorming sessions for a feature are a great way to clearly define goals and possible implementation methods for a feature. If you feel that the investigation will last for a decent amount of time and can't be done alongside current workload in the sprint, request an investigation user story to be created. The result of the story should be proposals for solutions and it's best to have them documented. This documentation will later serve in the alignment process and creation of a user story (or stories).

• Assess the impact on other systems: Once you have a set of possible solutions, you'll need to assess whether your solutions could have an impact on other systems. Don't spend too much time on analyzing whether there is an impact or not. That would become clear on the first alignment session, because team leads from other teams are the ones who need to understand your proposed changes and assess whether it has an impact on them or not. If you even remotely think that some application in the chain might be impacted, include their Technical Lead in the alignment process.

• Prepare the list of contacts: A Solution Designer is the first contact that you need to have. Solution Designer is responsible for planning and overseeing implementation of the solution on application chain level. If needed, a Solution Designer will create high level architecture for implementation of the solution for other teams. You will also need contacts of potentially impacted teams and their Technical Leaders.

Tip: Keep the list of contacts in your project's documentation or team collaboration space. All team members should have access to all relevant contacts.

• Include and keep the Product Owner updated: Even early in the preparation process, your Product Owner should be informed about the issue/feature that needs to be implemented. The only information that a Product Owner needs are why something needs to be done and whether you have potential solutions for it. If needed, the Product Owner could be asked to prepare an investigation story (for which you'll need to provide an estimate in story points).

• What you should have at the end:

1. What are you trying to solve?
2. A list of possible technical solutions.
3. A page in your documentation which describes the problem and potential solutions. You will use and modify this page during the alignment process.
4. Contacts for other teams or team leads and a Solution Designer.

The next article in the series will describe the actual Technical Alignment process.