In my last post, I discussed setting up a remote software development team as a pragmatic solution for resolving local technology talent constraints, and gaining budget flexibility. If your business is struggling with hiring developers or you are looking for more flexibility in managing budget and resources, then this topic will interest you. In this article, I outline some distributed team models that I’ve worked with, along with their applications and best practices. Using this information, you may be able to envision which model best suites your organization.
Here are the models I’ll be covering:
- Remote independent product team
- Product team with local technology lead and remote developers
- Product team with local and remote developers
- SLA team
Note: Our customers utilize dedicated contracted development teams that manage their developers in one remote office, often in Eastern Europe or South America, as well as the U.S.
Remote independent product team
Independent Product Teams are units where members have a common set of product or systems responsibilities, and are not dependent on other teams to be productive.
In your organization you may have multiple teams, each focused on different systems. Or you may have one team that works on multiple systems. The Independent Team model entails carving-out a set of systems and making your remote team responsible for them.
This model has some distinct advantages:
- The team can cycle more quickly through challenges. This is because the domain knowledge is structured to be available among this team (more below).
- The team takes greater accountability and ownership. Being responsible for delivery and quality of these systems, the team is fully accountable. Every win is their win. Every loss is their loss.
- The team is happier because they make more autonomous decisions, and their contribution to the business and its customers is more evident.
The highest value development teams I’ve worked with have frequent and well-structured access to business and domain experts. They function in accord with business goals, and adjust quickly to ever changing product priorities and customer needs. When you have a central office with a small team, you can achieve this informally. But as your team grows, or if you take-on a remote team, structuring the right roles and processes to enable consistent alignment with business goals, is critical to achieving high value.
With remote teams, there are a few ways to accomplish this:
You position a Product Owner in the central office. As expressed in Agile Scrum, she is responsible for maximizing ROI by identifying product features, translating these into a prioritized list and continually re-prioritizing and refining the list. The Product Owner actively and regularly interacts with the development team, which is in a remote office. She executes Scrum inspired processes such as planning Sprints, conducting iteration reviews and attending daily stand-ups.
If you’re considering running a larger remote team, say 6 or more members, then adding a Business Analyst to the remote team can improve productivity. He works closely with the centralized Product Owner to keep the Development team operating efficiently. The Product Owner may focus more on higher-level Product Management activities, issuing general feature requests. Then the remote BA works closely with the development team to refine those requests into more detailed user stories and tasks, while performing other activities such as systems and data analysis or facilitating user experience design.
As a third option, in some organizations it makes sense for the Product Owner to be located with the remote team, and coordinate with stakeholders in the central office. This can be effective when stakeholders have more experience and comfort in managing by outcomes, as opposed to project iterations. The remote Product Owner takes on greater independence and responsibility, and has a high-degree of trust from stakeholders.
Challenges and best practices
- Trust in the remote team is an absolute necessity. The reality is that trust takes time to develop. Sometimes a remote team will work in a staff-augmentation model for a while prior to spinning off as an independent project team. Some engineering contractors will assign a team manager, who can help develop trust and expedite the relationship. Quick tip: It helps greatly to have an annual in-person gathering with at least two members of the team.
- Team composition is critical. Both local and remote managers need to work together to balance the team’s roles and skills.
- Independent teams operate best with experienced Agile practitioners who leverage established methodologies for aligning team activities with stakeholder directives.
- Stakeholders need to make a concerted effort to relay (a) the pulse of the business, and (b) product vision to the remote team. This communication can be built-into the Sprint Reviews when both have opportunity to engage with each other. Product vision enables the team to make better long-term decisions in their day-to-day engineering work.
Product team with local technology lead and remote developers
Consider this model when your system has legacy components where domain knowledge is needed to guide developers. Or if your team is modernizing your platform and your internal tech lead or architect wants to steer the execution. This model also assures that a local technical resource is at-hand.
Advantages
- A pragmatic model when the software complexity is high. The internal tech lead can structure projects and tasks that enable the remote team to be productive early-on, while learning the intricacies of the platform.
- Well suited for organizations that want to retain tighter control over engineering practices and execution.
- Once the remote team has proven their ability to be productive, you can transition them to more independence. For example, you offer them greater flexibility to make architectural decisions, within constraints that you define.
Challenges and best practices
- When the internal tech lead becomes the primary conduit of communications with the remote team, the team’s performance largely depends on his leadership capability. Careful selection of your internal lead is critical. Extroverted leads with strong people skills perform significantly better than introverted leads.
- There’s often reluctance among internal tech leads to manage a remote team, mainly due to their concerns about the team’s technical skills. No one wants to struggle with a team that isn’t suitable for the project (including myself). The most important step is selecting the right team. Your remote developers need to be as talented, proactive, communicative, and passionate about their work as your centralized team. Otherwise you’re putting your project at risk. If you need assistance finding such a team, this is where TeamFound can help!
- A best practice is to arrange in-person visits to build relationships and trust, for one or two weeks during the first 90-days of the project.
- I’ve written a guide for leads of remote teams with further recommendations.
Product team with local and remote developers
When your internal development team simply needs additional developers on your project, this model may suite you. This is classic staff-augmentation. It’s also a common entry point to the more independent models.
Advantages
- Simplest way of adding capacity to your team
- Usually requires the least amount of internal changes.
Challenges and best practices
- One challenge is when your internal development team has little or no working processes. If your team is well practiced in an Agile methodology such as Scrum or Kanban, then your team could be very well prepared. But some teams function more informally, especially if they’ve been centralized for a long time. It’s a good sign if your team utilizes SDLC software, team communication software (such as Slack or Hipchat), and code repositories. Essentially, the better organized and more disciplined your team is internally, the easier it will be to work with distributed developers.
- Agile trainers generally suggest keeping Scrum teams together in one geography, to facilitate easier “teaming” activities, for better team performance. I agree. This is a “best case” scenario. But it’s not the only way to run a Scrum team. I’ve worked with teams who function quite well across geographies and timezones. When team members have good “remote skills” – yup, that’s a real skill-set (see below) – they can perform quite well in a distributed model. You don’t have to look far to find well known examples. Automattic (WordPress), Basecamp, Zapier, Github have written extensively about their distributed engineering teams.
- “Remote skills” are a reality, and having them is proving to be a valuable asset to organizations. They are a combination of empathy, communication abilities, and team playing. If your company offers the opportunity to work from home on occasion, or if you already have distributed team members, then it’s likely your team has developed these valuable skills, and can accommodate additional remote workers more successfully.
SLA Team
Agencies who structure their budgets on a per-project basis may prefer Service Level Agreements (SLAs) for each project or group of projects, rather than hiring or contracting dedicated developers. They may bundle other service requirements into these SLAs such as 24/7 managed services and incident management.
Advantages
- Project based budgeting
- Can be utilized by companies with small budgets
Challenges and best practices
- Finding the right provider. It’s not easy to find a match of both technology skills and provider service model.
- Good knowledgebase and procedural documentation has greater importance because the remote team is not dedicated to your project.
In conclusion, there’s a lot of diversity in remote or distributed team models – they take many shapes. This post is an attempt to structure and express to you some of their differences. Feel free to reach out to me if you have questions or would like to discuss your project.
Team Found 