It’s not really about the offshore
When working with an offshore development team, or indeed any development team it is essential that there is strong technical and product leadership in place.
Yes, it’s true that in the agile world, there is much talk of self-organising teams, and yes, that is something you should look for in team dynamics. A team with a high degree of autonomy will still need leadership, and still need ways to resolve issues if they are to organise in the right direction, one that matches your product vision.
With an offshore team, I firmly believe that an offshore model does not in itself create any problems. It merely amplifies existing issues and makes them more obvious.
Ambiguities, lack of direction, and other queries or issues will be harder to resolve if people are more disconnected or if team responsibilities are not clear.
In order to have an effective team, there needs to be clarity in a couple of areas
Product clarity is about making sure that the upcoming work or backlog in an agile world is in good order. This can only happen with a clear product vision and agreement on priorities.
With clear vision and priorities, there can be a clear work priority and clear goals for the team to deliver against.
This work is hard and requires just the right level of product detail to be provided.
If there is too much detail at this stage, then work is going to be very slow and unable to adapt to changing requirements. Most teams do not suffer from this problem.
If there is too little detail at this stage, then whilst the work items may be described at a high level, there will likely be not enough information to truly understand the feature requirements and therefore implementation requirements. This will lead to just-in-time product design, and often causes more issues than it solves.
Products developed in this way tend to have a high degree of inconsistency and require frequent rework.
Technical clarity goes hand in hand with product clarity.
With a clear product vision and roadmap, we can form a clear technology vision and roadmap to truly support the product.
We can make decisions on the target architecture, and ensure that this architecture evolves with the product development at just the right pace.
It is critically that we don’t attempt to under, or overdevelop the software architecture.
The development team need clear direction and to understand what expectations exist.
Software architecture, especially in an agile world, is often poorly considered or misunderstood. It should not be a cumbersome effort. It should support and underpin the team’s development work.
These areas cover input and pre-work required for the team to succeed, the proactive work. In addition to this, there needs to be a level of reactive leadership to respond to questions and issues inflight. Again, this level of feedback needs to happen at both product and technical level.
Product feedback needs to be timely, yet not rushed. If product questions from the team require a level of analysis, then it either means completely new information has just been provided that invalidates prior product design, or that the required level of product clarity was not present.
There should never be a case where the product team do not fully understand what features will actually look like once developed for any work in progress.
Product feedback at this level should be about making minor decisions, clarifications on the detail of each feature. Things like which button style or layout do you prefer, suggestions on text, exact timing on schedules etc.
Technical feedback at this level again needs to be timely and should not block the development.
Technical feedback should not involve making significant architectural decisions. This should already have been made.
The feedback at this level could involve providing clarifications, or examples on how to implement particular architectural or design patterns and technologies.
The feedback for a technical lead is also a review process. Not reviewing for style necessarily, but reviewing against non-functional requirements, ensuring that the system design, separation of concerns, unit test coupling etc are all being understood and implemented correctly.
Technical feedback is about ensuring technical quality is maintained throughout the project, and supporting the development team to deliver this as efficiently as possible.
Between product, and technical, pro-active clarity, and more responsive feedback, a development team can be fully supported and focused on delivering the product vision.
These elements aren’t always easy to put in place, and I’ll go into more detail in future posts as to what implementing this can look like.