On my two last jobs, I've been on the customer-side in the contracting business.
My current place of work uses contractors to extend our capabilities, to get more people when the load is high. Recently we've had one contractor used for development people, and another contractor used for (exploratory) testing people. The contracting is really that - getting the right people.
In my previous place of work, the whole organization I worked in was built around controlling contracting. Little to none was done in-house. The focus was not on people we'd contract, but the next incremental change with a fixed price and externalized responsibility. Whole different ballgame that I don't necessarily believe in.
Since we now focus on people, I'm looking at interesting differences and more of a feeling of success - as much as there is success in developing software with all the uncertainties. There's two differences that stand out in particular:
With a very recent contracting project, we're requiring monthly visible plan, monitoring the work remaining for the tasks to be complete and a burndown chart. When we see that the work remaining grows, we don't start a hassle of going over the budget - we adjust the budget or the scope. We know the people we have, extending our own capabilities, have not worked with our product before, and putting too much effort into guessing right the effort needed and making them heavily accountable would steer our focus away from the great product to protection. They deliver continuously, and we try to treat them in the same way we treat our own people.
It was interesting to see that a week into development, we could already adjust the schedules and talk about the real pace in which we think we may be able to proceed.
The contactor delivers us code that is supposed to do what we've defined, at least in the ballpark. If it would do something completely different or inadequate, and we'd provide no on-time feedback through testing, they'd be ready to redo it any time - since all work is billable by hour. But we'd be the one missing our schedule window, which is much more relevant than showing responsibility against a fixed price work order.
Accepting people, not deliverables
Our product is created by people. If they're skilled, it tends to show in the results. With contractors we've adopted an early feedback approach, where the acceptance is about looking at what people produce by peers. The long-term developers look at the contractors newcomers code, with detailed comments on making sure it fits our expectations of a maintainable product.
It was great to listen to developers fuzz over the insightful solutions our first new joiner brought into the code. I could feel the energy of seeing the positive sides, learning how things could be done we had not considered, with a few comments about ideas we had failed to communicate on playing with the rest of the codebase.
It was also great to listen to developers giving not so positive feedback on our second new joiner, as this was less than a week into development. Listening in on the trouble with structures, I'm sure the team collaboration will help people grow to the needed direction. And most insighful for me, as the team's tester was how smart it really is to look at the code when accepting and not just the black-box functionality.
I was personally looking at whether we got unit tests or not, but for now, after first increment, they are still promiseware. But the task of adding the unit tests was the first thing to start the new increment with - same practice as with the local team in this case.
When we know the people deliver and accept them, it's a lot easier with accepting what they deliver to production. Our process is such that the developer can't assume there would be a second opinion available on the side effects, but most of the testing is done as "own testing" by developer.
My current place of work uses contractors to extend our capabilities, to get more people when the load is high. Recently we've had one contractor used for development people, and another contractor used for (exploratory) testing people. The contracting is really that - getting the right people.
In my previous place of work, the whole organization I worked in was built around controlling contracting. Little to none was done in-house. The focus was not on people we'd contract, but the next incremental change with a fixed price and externalized responsibility. Whole different ballgame that I don't necessarily believe in.
Since we now focus on people, I'm looking at interesting differences and more of a feeling of success - as much as there is success in developing software with all the uncertainties. There's two differences that stand out in particular:
- Incremental planning with focus on work remaining
- Accepting people, not deliverables
With a very recent contracting project, we're requiring monthly visible plan, monitoring the work remaining for the tasks to be complete and a burndown chart. When we see that the work remaining grows, we don't start a hassle of going over the budget - we adjust the budget or the scope. We know the people we have, extending our own capabilities, have not worked with our product before, and putting too much effort into guessing right the effort needed and making them heavily accountable would steer our focus away from the great product to protection. They deliver continuously, and we try to treat them in the same way we treat our own people.
It was interesting to see that a week into development, we could already adjust the schedules and talk about the real pace in which we think we may be able to proceed.
The contactor delivers us code that is supposed to do what we've defined, at least in the ballpark. If it would do something completely different or inadequate, and we'd provide no on-time feedback through testing, they'd be ready to redo it any time - since all work is billable by hour. But we'd be the one missing our schedule window, which is much more relevant than showing responsibility against a fixed price work order.
Accepting people, not deliverables
Our product is created by people. If they're skilled, it tends to show in the results. With contractors we've adopted an early feedback approach, where the acceptance is about looking at what people produce by peers. The long-term developers look at the contractors newcomers code, with detailed comments on making sure it fits our expectations of a maintainable product.
It was great to listen to developers fuzz over the insightful solutions our first new joiner brought into the code. I could feel the energy of seeing the positive sides, learning how things could be done we had not considered, with a few comments about ideas we had failed to communicate on playing with the rest of the codebase.
It was also great to listen to developers giving not so positive feedback on our second new joiner, as this was less than a week into development. Listening in on the trouble with structures, I'm sure the team collaboration will help people grow to the needed direction. And most insighful for me, as the team's tester was how smart it really is to look at the code when accepting and not just the black-box functionality.
I was personally looking at whether we got unit tests or not, but for now, after first increment, they are still promiseware. But the task of adding the unit tests was the first thing to start the new increment with - same practice as with the local team in this case.
When we know the people deliver and accept them, it's a lot easier with accepting what they deliver to production. Our process is such that the developer can't assume there would be a second opinion available on the side effects, but most of the testing is done as "own testing" by developer.
