Within companies that use Scrum properly, the organization is built around fixed, cross-functional, self-organizing teams 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 themself 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 nowadays organizations consist of contractors. 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 rapid 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 fixed, cross-functional, self-organizing teams. The best teams have a stable composition for a longer period and thereby have the opportunity to really become a strong team instead of a group of individuals. They've experienced ups & downs together and thoroughly know each other’s qualities and personality. 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.
- 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.
- 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 a fun offsite. Involve them with everything that might be relevant and reinforces their relationship with the company.
- 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.
- 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.
- Agree upon a quality-driven contract. For sure, the contract shouldn't be a 'killer contract' that causes distrust from the beginning. But defining the desired technical and functional quality upfront is possible. Fix quality and of course don't fix scope. This prevents uncomfortable conversations afterward and separates the professional contractors from the average ones.
- 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 and have fun. They'll be twice as productive afterward.
- Ensure you hire a studio musician. Don't hire a rock star. But when hiring a new team member, focus on the 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.
- Setup 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!
- 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 the 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 in the Scrum Team? Or if you are a contractor, what is your experience with the arguments I've mentioned?