This is the second in a series of articles which will summarise my last half decade of hiring/outsourcing/offshoring experience as Head of Technology at the Cogworks.
Introduction
Outsourcing is typically a last resort strategy to augment your current capacity. It is costly and can have a lot of drawbacks. In this article I'll give a couple of examples of how we handled outsourcing in the past, followed by some tips help improve the outcome.Silo'd Outsourcing
It is very temping (and easy) to simply hand an entire project to a freelancer or company. The problem with this silo'd approach is that often the code will come back written / architected in an unexpected way. It could be so obscure that you cannot maintain it, or don't want to maintain it.
Many years ago we outsourced to a company (who will rename nameless) who wanted to use a code-first package. We were sceptical about the approach, but the company told us there would be significant time saving. They assured us that the code-first package could be removed after launch. So we let them do it.
Fast forward to post-launch... They handed back the project and it was an unmaintainable mess. Even something as simple as changing the label of a CMS field needed to be "code-first", and hence require a code deploy. Worst of all... the code-first package was mangled so much into the code that it was like trying to separate flour from a cooked donut.
We learned never to just hand a project to another company again.
Extreme Integration
During the busiest growth phase I experienced, we were outsourcing 13 projects to freelancers and smaller agencies. Internally we only had 4 Umbraco/.net developers and 2 Frontend developers. It was a tripling of our capacity over night.We had so many projects that we couldn't outsource fast enough. We were so stretched that we literally only had 1 developer per project for the majority of the time, while also needing to field support/emergency requests of sites which we maintained. It was stressful, but we learned from our earlier experiences.
This time, outsourced (remote) developers & companies were integrated into our daily routine, and treated as normal core developers. They were subject to all the stand-ups, code reviews, meetings etc. Our core developers all became gatekeepers, and they were all overseeing quality of up to 3 projects each, including the project which they were already actively developing on. The entire development team was in charge of ALL projects collectively, so all core devs were helping each other get their projects delivered.
This of course resulted in the core devs having significantly reduced capacity for their own projects. However, the benefits were worth it in our case. All the projects were delivered with a consistent quality, the code was maintainable, and everyone had enough knowledge of all projects to jump in to help.
Tips to Ensure Quality Outsourcing
- Try to go back to the freelancers / companies you have worked with before, or ones who are recommended to you
- Ensure your core developers are the gatekeepers of code quality, overseeing outsourced code quality.
- Don't just hand over a project to be worked on in a silo
- Where possible, integrate the outsourced workers / companies in your daily routine
- This ensures less friction, and promotes better communication
- Ensure the development team (as a whole) is actually responsible for the quality of outsourced work
- Your development team will need to maintain it in the future
- Don't just hand over a project to be worked on in a silo
- This ensures less friction, and promotes better communication
- Your development team will need to maintain it in the future
Final Thoughts
In my opinion your development team needs to own the outsourced product. They need to figure out how it can maintain quality control during the development. This does necessitate a time drain from your internal team, however the project will have more predictable outcomes, and will be more maintainable in the future.
No comments:
Post a Comment