“The best architectures, requirements, and designs emerge from self-organizing teams.”
– One of the agile principles.
Whenever I see an offshore delivery project where the architect is super busy on implementing/coding a particular feature and has little time to communicate with the development team, most likely the project is running into trouble… So, what should architect do in offshore delivery project?
The Architect should act as bridge between the customer and development team
Due to the time zone differences between the offshore team and customers, the onshore architect is naturally responsible for working directly with customer (and business analyst) to define functional and non-functional requirements, including identifying and resolving conflicting requirements.
On the other hand, architect should also work with the offshore development team to ensure that the requirements and the high level design are fully understood by the team. During the development, offshore team usually will ask requirement questions. Architect should be responsible for answering those questions in time.
The Architect plays the coach role to support the team
The architect is usually the most experienced person in the team. This does not mean that he should take over the most difficult tasks as a super individual contributor. The architect has much more important role to play – supporting the team! Specifically the architect should:
- Provide guidance to the team on detail design to ensure that the team’s implementation is compliant with the architecture design. He should encourage offshore team members to participate in discussing about the design thus contribute to the architecture.
- Listen to the feedbacks from the development team, pick out the good ideas of each side, and help the team see the advantages and disadvantages of each proposed solution then come to a consensus.
- Review the code the team submitted on daily bases and provide feedbacks to the team. When he finds any coding/quality issues, provides comments to the team for correction in time (instead of correcting them himself) so that the team can learn and avoid making the same issues in the future tasks.
- Help the team to overcome technical difficulties. This does not mean that architect should take over the difficult tasks from the team members. He should provide some directions (e.g. sample code, articles, and so on) to support the team to overcome the road blocks.
Good Practice – One effective way of mentoring the team is to have onshore architect travel to offshore site to pair work with the offshore team members for a while (let’s say 3-4 weeks) during the early stage of the project. This can be very effective (and efficient) to help the team to understand the business context and reach the consensus of the solution. Most of the issues, risks, and misunderstandings can be discovered and resolved in the first place, which will often resulted in less amount of rework later on. More importantly, this helps on building the trust relationship between the architect and offshore team members, which lays a solid foundation for their collaboration during the whole project.
In short, the architect should always have the overall view of the system the team is building to ensure the system is evolving towards the right direction iteration by iteration.
Very practical! Just one question. Since its all agile, should an architect learn the skills of project manager as well?
I would say yes. At least Architect should have some leadership and collaboration skills so that he can work effectively with the offshore team.