11

On the one hand, the agile approach stresses a tight-knit team that holds each other accountable and accepts collective ownership of the project.

On the other hand, companies use contract programmers so that they can manage the peaks and valleys of funding without laying off actual employees. If there is a shortfall in funding, the contractors are the first to go, even if they are fully integrated members of the team (and there are employees are not). Companies also only like to keep contractors around for a limited amount of time. This is somewhat mitigated by the possibility that some contractors could be brought on as regular employees.

Thus my question of whether there is a fundamental contradiction of having an agile team with a mix of employees and contractors, and the vastly different statuses that entails?

EDIT: The answers are indicating that I may not have expressed the tension I'm facing well, so let me take another shot.

I'm a permanent employee. The agile approach (at least as implemented here) encourages me to see all team members, both permanent employees and contractors, as equal members of a cohesive team. The corporate approach to contractors encourages me to see them as expendable resources to whom we shouldn't become overly attached.

I'm curious how others have resolved this tension.

Improve this question
2
  • I don't know if it's a fundamental contradiction, but it can sure make things a challenge. Commented Jan 20, 2011 at 19:51
  • 3
    Agile approach is all about common sense really. It does not mandate. There are such things as swing players, and there are non-perfect processes. Commented Jan 20, 2011 at 19:58

5 Answers 5

Reset to default
0

Many teams work only with agile contractors. Some companies like ThoughtWorks are based on the idea to "sell" agile teams. We are a team of 10 contractors working for a big telco, all from the same contracting company.

Where I saw problems was when there were 2 body-rental companies in the same team... after a while the team became problematic (nothing to do with agile anyway).

Improve this answer
2

Yes, this definitely can work. The trick is to:

a) Structure the contracting arrangement properly -- if you are paying for piecework then the contractors have little interest in doing much more than slapping things together to put fewer hours into the "piece"
b) Sell your management that not every cent they pay for goes directly into the product -- there will be some training/planning/discussion going on that will be on the clock and ultimately improves said product. This was the hardest part for me.
c) Pick the right contractors -- the whole agile thing starts to pay off if you can continually hire the same crew.

I would also generally contend that this sort of scenario is greatly helped by agile practices -- if you have people coming and leaving the team all the time, being able to check out, fire up and start coding is even more important than it otherwise is.

Improve this answer
2

In response to your edit, there are different sets of eyes to look at the situation. So to help clarify any potential confusion, it helps to understand which perspectives apply.

From the development team perspective, there is no difference between contractor and employee. We are all on the same team, and we all have the same goal. Adding and removing team members will have the same disruption whether they are employees or contractors. All team members have the same responsibilities.

From a management perspective, there is a difference. The company is trying to protect its most precious resource--employees. For that reason, the company will prefer to keep its employees over its contractors. If a contractor proves invaluable to the team, the company will likely attempt to convert the contractor to employee. These types of decisions live outside the day to day development process.

Agile processes are more concerned with the day to day development activities, and managing how you deliver a quality product. The agile processes are less concerned with management responsibilities such as hire/fire/contract decisions and more concerned with how we use the resources at hand.

Previous answer

It's not a fundamental contradiction, but it does present some training challenges. Agile processes foster a very natural mentoring environment. Essentially the staff programmers would end up always being the voice of experience--at least as it pertains to corporate culture and the specifics of how the team does agile.

Having a regular ebb and flow of contract programmers is going to present the same challenges whether you do agile or not. You have to educate the contract employee on how you do business--this includes development processes and billing. You have to educate the contract programmer on the current design of the system so that they can begin contributing as quickly as possible. The hope is that contract employees are quick studies, and can start contributing to the project really quickly. On-the-Job-Training (OJT) works pretty well here.

What it boils down to is that you will take an initial productivity hit when you hire new developers and contractors until they get up to speed. The more you do it, the more it negatively impacts your team's performance. Hense, the old adage "Adding more developers to an already late project makes it later". (I believe that was Fred Brooks, unless he was quoting someone else).

Improve this answer
2

As a contractor who cares very much about Agile and producing excellent software, I can promise that there are contractors out there who will never produce slap-dash code if they can help it, and always put their heart into whatever they're working on.

The trick is to find those contractors. Look for evidence that they're prepared to go that extra bit further - blogs, speaking engagements, open-source contributions, workshops, recommendations, etc. Ask about their previous Agile experience, and look for evidence that they love their work. By and large we understand that we're temporary hires, and some of us like this, using our time between contracts to hone our skills and expand our knowledge.

If you can find really great contractors, they'll enhance the cohesiveness of your team rather than detracting from it. Keep us in place for the duration of the project, then let us go as the team ramps down. We'll take a holiday and be around for the kick-off of the next project, if you need us.

Improve this answer
3
  • My point isn't that contractors produce lousy code. My experience is that in a typical shop, the average skill level of the contractors exceeds that of the in-house programmers, at least in terms of pure programming chops. Commented Jan 21, 2011 at 22:25
  • 1
    My problem is in establishing the type of relationships that Agile requires when upper management regards them as expendable. Commented Jan 21, 2011 at 22:26
  • 1
    Get the consultants, along with any other great devs, to teach what they know; that way the average skill level of everyone is raised. We are expendable. That doesn't stop the kind of relationships you need from forming. Worrying about contractors disappearing and treating us differently as a result might, though. Commented Jan 22, 2011 at 14:54
0

You are perfectly right when you said that temporary contracts affects the team negatively. In fact, velocity is bound to a particular team configuration. Any new arrival or departure invalidate the velocity calculation you did for months.

However, it can work when contractors are not temporary. I worked on project where the team were build on 95% contractors with one or two employees. Contractors were there for 2 or 3 years till the project is released. After release the employees do the maintenance. This way of working is very common.

To summarize:

Agile, and especially Scrum will provide all its benefits in a stable team.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.