How do you think we should handle 1 external collaborator/developper within scrum method ?

For example : Should we isolate the tasks that he must do ?

  • 2
    Why do you feel a need to treat this person differently? – JeffO Mar 24 '17 at 18:26

If the scrum team is mature, this is a matter for them to decide. The goal would be to do whatever is best to help the team achieve their goals. Remember: there are no bonus points for sticking to a methodology, even scrum. Point #1 of the agile manifesto is "Individuals and interactions over processes and tools".

Without knowing more specifics, I think you should treat this person as a normal part of the team. They need to be involved in the daily standup, and they need to call into sprint planning, demos, and retrospectives. Ideally you would set up some sort communication channel so that they can be part of discussions whenever possible (eg: slack). This can provide challenges if they are in a very different timezone, but it should be possible to adjust everyone's schedule to have at least a little time that overlaps.

As for isolating the tasks, I would say you shouldn't do anything special. The team will probably figure out what works best for the team and do that. If what they chose (eg: to isolate tasks or not isolate tasks) doesn't work, the retrospective is a good chance to fix that.

  • Totally agree with your point of view. +1. But the problem is that SCRUM is becoming even more buerocratic that many old waterfalls. Processes, tools and fixed rules prevail. Or, I would say, you think agile but not scrum. – Gangnus Jun 20 '17 at 11:16

1. Methodological point of view

From the methodological point of view, an external developer is just a team member like any other. Handling him apart and isolate will only make the team less effective.

2. Legal constraints

From the legal point of view, it depends on your jurisdiction. In most European countries for example, handling an external contractor as if it were your own staff is strictly illegal (even if in the IT branch this is quite common).

These restrictive laws were adopted in the last century in order to avoid that employers circumvent agreements with union by lending staff from other companies that is less protected. Of course, in the IT world, where contracted consultants or developers are often more expensive than own staff and have better work conditions, this seems nonsense. But the old laws still apply.

According to this principle, subcontractors should subcontract: they should carry out independently tasks that are well identified assigned. The key element is that they act independently and not on orders of the own staff.

Fortunately, in a scrum team, there is no real subordination, each team member contributing with his opinions and his part of work. So back to point 1 :-)

Disclaimer: this is not legal advise. It's only a personal opinion from an IT professional based on his own professional experience. For legal advise, consult a lawyer or a qualified legal expert in your jurisdiction


First, consultants do need to be closely managed. The goals of a consultant are not the goals of your organization and having clear agreements of what is to be worked upon is valuable. You can use scrum, weekly Skype calls, a project plan, or even just a check list. The key issue is to never be in a case where you don't understand what task the consultant is working upon.

That said, including a contractor within your scrum is generally fine as long as you end with an understanding of what he or she will be doing and that is what you want done. If the outcome tends to be "restructure this code without immediate benefit" or worse "restructure this code to use a new framework that may help in my next consulting gig because all the cool kids are doing it", you need to dictate more than allow independence.

If you feel you have lost control of a contractor, lose the contractor. Trying to reel them back in never ends well.

  • Do you think that scrum requires peers have to control each other ? Do you hire consultants that you can't trust ? And don't internals also have their private agenda sometimes... I think that daily scrum, peer review, group design, TDD, version control, etc... are plenty of means to grasp sufficient understanding and knowledge on the different parts that are developed including those developed by consultants. – Christophe Mar 25 '17 at 0:07
  • Er, that's quite a troll. It's sufficient to say "I disagree". – Charles Merriam Mar 25 '17 at 17:04
  • oh ! Sorry ! I don't want to troll (i would have written strong and nasty affirmations) but i wanted to show what's the reasoning behind the disagreement. Having spent half of my career as consultant and half as internal, I know both sides of game, and i tend to overreact to the stories of the bad-consultants-you-have-to-control. Certainly there are consultants who try deliberately to create a long term dependency, but it's not fair to generalize. And i've also seen staff members trying to secure job or salary increase with same tactics. – Christophe Mar 25 '17 at 18:33
  • It's not the malicious "I want a dependency" people, though they exist. It's the "I have not drunk the Kool-aid, and think first of my career." that needs to be watched. I find consultants much less likely to speak up when lost, more likely to grab the newer but less appropriate tool, etc. There is grounds for caution, but not stereotyping. – Charles Merriam Mar 25 '17 at 20:13
  • Transparency and accountability are critical parts of scrum. And we are building a TEAM--team members that work in a silo, away from everyone else, are not real team members. So an "expert" who works remotely and estimates a task as a 2 but doesn't have it done after a few days, should be expected, like any other team member, to explain "hey I am having a problem here" so the team can rally around and help, if they can. I also work to eliminate those silos of skills as much as possible. So I am not a fan of the "remote expert" approach. – Curtis Reed Apr 24 '17 at 21:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.