How to Build a Scrum Team with Contractors?

Within companies that use Scrum properly, the organization is built around, cross-functional, self-organizing teams, with fluid team dynamics, who are given the freedom and responsibility to think of a strategy they believe will result in the best product. Everyone around the development team is focused on supporting and facilitating the teams in building the desired product. In consultation with the Product Owner, the Development Team themselves decides what to work on and how much they can handle during a sprint. This results in a clear focus and the opportunity to obtain a sustainable pace of continuous delivery.

So far so good.

The fact is that a large part of organizations uses contractors/freelancers. They have got a core of employees and around it a flexible layer of contractors they can easily up or downscale. In this turbulent age with rapidly changing business- and market conditions, organizations are almost obliged to have this flexibility. Next to this, an increasing amount of people with specific knowledge and skills also choose to be independent. They are not willing to work for companies for years in a row but want the freedom to switch assignments and engage in new challenges and environments continuously.

As mentioned before, Scrum is based on cross-functional, self-organizing teams. Having a fixed, stable team sounds nice, but isn’t the reality. A team will always have changes in its composition. Development Teams use their self-organizing capabilities to make changes whenever required. Consulting other roles (Product Owner, Scrum Master) or departments (HR, Finance, etc) when required.

Taking responsibility for its own team composition gives them the opportunity to become a strong team instead of a group of individuals. They experience ups & downs together and know each other’s qualities and personalities. But how do you build such a strong team, when a large part of the team consists of contractors? Is it actually possible to build a true team when contractors are part of it?

The short answer is: yes, this is definitely possible! But… there are some arguments that should be taken into account.

1. Be cautious with up or downscaling. Often management considers contractors as the first ones they can get rid of when for example there’s a lack of funding. Although this makes sense, management should be careful not to up or downscale continuously. This will have a devastating effect on the team’s productivity. But also the contractors won’t truly buy in because of the continuous uncertainty. Only change the team’s composition when the reasons for it are completely well-founded.
2. Treat contractors the same as employees. Differentiate as little as possible. For example: invite the entire team when there’s something to celebrate or the company is having fun offsite. Involve them with everything that might be relevant and reinforces their relationship with the company.
3. Focus on collective ownership of the product. You don’t want any desultory parts that don’t fit the bigger picture. Of course, a professional contractor will always keep an eye on the entire product. But the importance can’t be emphasized enough. From the beginning, explain the product vision, backlog, and roadmap and hereby stimulate collective ownership.
4. Explain the cultural values and principles of the organization. A contractor should understand what type of organization he became part of. What are the values and principles that should be lived up to? What is the recommended behavior? Are there any team agreements that must be followed? This should already be pointed out during the job interviews; it will increase the chance to hire someone that really fits the team.
5. Accept that also contractors need some slack. Contractors are human beings (yes, really…), and human beings can’t be productive all day long. Even contractors need to relax, have a chat at the coffee machine, or play table football. Let them enjoy themselves and have fun. They’ll be twice as productive afterward.
6. Ensure you hire a studio musician. Don’t hire a rock star. But when hiring a new team member, focus on attitude instead of aptitude. Some contractors might be brilliant and have in-depth domain knowledge, but they choose life as a contractor for a reason. Teamwork isn’t suitable for everyone.
7. Set up a boot camp for quickly settling in new team members. The boot camp should act as a kick-start and include sharing knowledge, fixing the necessary tooling, and acquaintances with all the relevant colleagues. This ensures every contractor is up and running in no time!
8. Give everyone the same permissions. Sure, some information might be confidential and can’t be shared. But don’t create stifling workflows around permissions with lots of dependencies and therefore risk. Concerning the tooling of a team (e.g. Jira, TFS, Github); spread the administrator role amongst different team members. Make sure also contractors have permission to deploy within the present development infrastructure. This not only increases the trust within a team but also prevents having key man exposure.

What is your experience with having a contractor on the Scrum team? Or if you are a contractor, what is your experience with the arguments I’ve mentioned?

Originally published at www.barryovereem.com on March 21, 2015.