We consider an Extended Team successful when it satisfies following three key criteria:

  • There is alignment with the business
  • There is a closed feedback loop between the team and the business
  • The team is autonomous while operating on a technical level

Alignment is a critical contributor to the success of an Extended Team. Who in their right mind would transfer critical technical work to a group of people in an off location who are not aligned with the company goals and vision?

Most of our alignment efforts are spent on making sure the Extended Development Team understands the value of aligning with the business and know how to do that so its aligned  with short and mid-term goals and visions of the business. Short term goals and vision are defined by the length of a single SCRUM sprint (usually two weeks) and mid-term goals and vision are defined by the length of three to six SCRUM sprints (to the maximum of three, four months).

We discovered teams are most effective while keeping closely aligned with the tactical level of business planning, a good understanding of the operational level and a mind towards the strategical level which is fully being taken care by the leadership team of the business.

In order for the team to be able to align itself with the needs of the business a closed feedback loop needs to be build between the Extended Development Team and the Business. Usually in classical business models work would flow downstream from a higher level of the company into a lower but the feedback of the work would take months to arrive, often too late for the business to correct problems or exploit opportunities.

Placing a keep doing note during retrospective meeting held at the end of the sprint in a scrum managed project. Scrum is an agile project management method mostly applied to software development projects.

The Retrospective

We are firm believers in the SCRUM model of building software. The framework itself provides ample opportunities for closing the feedback loop and giving business opportunities to correct problems and exploit opportunities. The daily sprint planning, sprint review, the sprint planning session, product backlog grooming and the team retrospective are all excellent mechanisms where the business and the team can interact with each other and enable the free flow of information.

We believe that in the case of Extended Teams we need to go a step further. By nature distributed work breaks the regular communication flows of an office floor. And people seem to have an inherited aversion of working and talking with a person which is not in the same room with them for a longer period of time. And yet we believe a constant communication stream is what is needed for this model to succeed.

We encourage the development team to issue calls to the business whenever the need arises, we really try to limit and exterminate all assumptions towards the needs and wishes of the business and focus to instill the habit of talking to the business in order to find out what the business really needs instead of guessing.  We build several communication channels in order to enable this flow:

  • Text only – for group discussions and fast one on  one textual chats, using tools like Slack
  • Voice – using tools like Skype and Google Hangouts where texting is too slow and inefficient

Thus we build a habit of fast feedback and fast correction of problems. The development team doesn’t wait for two weeks to raise a problem or make an opportunity visible, it acts immediately based on the agreements and priorities set in concordance with the business.

The third pillar of our success matrix for an Extended Team is team technical autonomy. We believe IT is a critical part of any business endeavor and that it directly affects its success and failure. In order for the business to achieve the maximum IT can offer it needs to put a certain level of trust in the expertise of the people it hired. The team knows what corrective and preventive work it needs to do in order to reduce the amount of unplanned work the team will need to do in order to deliver a constant stream of business value down the line.

A usual antipattern business often take is to consider IT a cost center, putting stop to and micromanaging the technical choices the team makes into how to deliver value and even more putting stop into corrective and preventive work which would have prevented problems and higher cost down the line.

Given the nature of an Extended Team this habit would lead to even more problems related to alignment and closing the feedback loop. A team which is prevented to do the work it knows it needs to do is a team which is going to be reluctant to communicate with the business. A team which need to ask permission for a technical matter from a business person in a distributed location will be a team which will not be able to deliver business value at its full capacity and full quality.

Thus we believe that enabling team technical autonomy is a critical criterium needed to achieve team alignment with the business vision and closing the feedback loop which will enable the business to exploit opportunities and correct problems when they arise.

Your thoughts?

Go top