In Part One of this series, the focus was on the advantages and disadvantages of creating a separate and distinct team for any project’s integration work, as opposed to having integration work as part of a holistic agile team. That begs the question: How can one remain true to agile, while also bringing in the technical depth and the “flexible coupling” that come from a separate team?
A productive approach is to have each sprint team focus on its integrations but to also have integration specialists as members of that team to bring their knowledge of the technology and the standards necessary to ensure a robust architecture. Technical specialists who have seen similar types of integrations before, and who are familiar with standard approaches and patterns, can help immensely. It means that subsequent project teams do not have to reinvent the wheel to tackle problems for which there already are good patterns and tools. In the context of this example, the integrations specialists should join the core agile team, and work as part of the single team.
Center of Excellence
A good way to approach this is to establish an Integrations Center of Excellence, staffed with integration specialists. One role of this team is to choose the tools, provide the advice and create the organizational standard around integrations. However, purely “staff” teams can sometimes become ivory towers, imposing their ways upon “line” teams. The best specialists learn by doing.
In an agile environment, they should actually apply their knowledge to situations that are very concrete and specific to the organization. They need to base their work on the day-to-day work of the teams that are creating the actual integrations, as opposed to creating arbitrary and abstract one-size-fits-all standards.
Another best practice for this approach—and a good way to keep the integration specialists grounded while also ensuring buy-in from both sides—is to embed some specialists from the Center of Excellence into the sprint teams developing the specific integrations. That way they become members of the sprint team. Another benefit is that this is in keeping with an agile approach to an organizational structure: instead of creating another silo of specialists, form the teams tactically, pulling in specialists as needed.
In this way, the Center of Excellence becomes a fluid organization rather than a sizeable static team, but is also the coordinator of a more comprehensive “Interest Group.” Only a few members are in the separate team—in the Center of Excellence—at any point. They may be creating organization-wide standards for integrations, or choosing specialized tools, or developing tools that can be useful to individual teams. Meanwhile, integration specialists are spread across the project or program, working in various development teams.
Another idea that works well with this structure is the idea of a guild, whose members belong to various and different teams, but who do similar work in those teams.
For example, the Quality Assurance resources or the Business Analysts from across the organization may be members of guilds, where they meet to discuss common problems faced and the solutions devised and implemented. Another benefit is that an “Integrations Guild” becomes an effective mechanism for sharing ideas and knowledge about the special problems faced within and amongst the teams. It also helps to create an informal network of co-workers who can call on each other for help, resulting in shared knowledge, less re-invention of the same solutions, quicker learning curves for new members and higher productivity.
The Center of Excellence can help coordinate the activities of the guild and to create common approaches and standards, but the day-to-day integration work is done by members who belong to various other development teams.
In the early design and development stages of a project, there is usually a greater need for specialists who have experience with certain types of issues, and who can create project-specific patterns and approaches.
That need for specialists is reduced as the project progresses and the project team tackles a more extensive variety of problems with the patterns put in place by the specialists. At the start of any project, the specialists may be intimately involved with the project team in developing the initial integrations. Once the project is underway, however, and with established approaches and patterns of work, the specialists can shift their time and energy to helping keep things on track, introducing new technologies as appropriate, and with the inevitable tough problem that will crop up from time-to-time.
In this way, the direct involvement of the Center of Excellence will be gradually reduced. As the project moves along, other developers may find themselves interested in the specific technologies they are working with, and as a result, they may wish to join the guild, creating a valuable pipeline for future integration specialists.
In summary, the objective of this approach is to leverage the benefits of an agile approach to software development and blend those benefits with the advantages of a centralized group of specialists, in this case, integration specialists. To that end, the approach aims to blend both long-term and short-term goals. It leverages specialist knowledge, while also creating accountability on the part of the specialists for the delivery of well-architected software solution. It also enables a core, but more refreshed team of specialists to look at the bigger picture, across the organization, while at the same time keeping them grounded in the requirements of real projects and, thus, close to the action. This creates a blend of strategic vision and tactical implementation, and in the process sets a context for success.
Originally published by
Read the original article here.