Monday, April 4, 2016

The art of subcontracting

When a fully staffed product (development) team is unable to achieve all of the team goals within an acceptable time frame, the team is faced with two options:
  a) Keep developing on your own and work long hours until the goals are achieved or at least until new challenging goals show up so you can work more long hours again
  b) Develop smarter by temporarily increasing team velocity through subcontracting: outsource and manage development projects instead of developing everything on your own

Each team is by definition a Project management team and each team member is a PM as soon as you start thinking outside of the confines of your own 10 typing fingers

What does "subcontracting" mean in practice?
  1) Identify potential projects by defining the needs in your team where you need help
  2) Prepare functional/technical requirements and/or specification for the project
  3) Leverage help from the Ops team to find the best external freelancer/team to complete the job
  4) Communicate with the selected freelancer/team, review their progress, provide work feedback and set your expectations
  5) Give your approval (or not) for parts of the project as it progresses, and for the entire project once it is complete
  6) Implement deliverables in production

What all can be subcontracted?
  a) Reusable UI components, shared between teams or products
  b) Backend libraries / engines / frameworks, either for internal team use or for multiple teams
  c) Modular features for owned products, i.e. an externally developed functionality that can be easily "plugged" into the product
  d) Fully integrated features for owned products, i.e. subcontractor gets full access to a separate product code branch and adds additional functionality directly
  e) Entire new products including backend functionality and frontend UI based on our standards
  f) Test automation helper apps that are unaware of the product, i.e. data generators
  g) Product-specific test automation helper apps specific to your product's interaction design

We can subcontract everything that we find complex?
Not just complex but even if you know how to do it internally and don't have enough time to do it (remember: success = results / time)

What's the difference between functional and technical requirements?
Functional requirements are your concise expectations of what you need completed

Technical requirements are your general technological expectations / tech limitations of how you want the project done

Requirements are short, generalized documents that provide freedom to outsourcers to figure out the tiny details along the way

At a minimum each project needs to have at least functional requirements defined

What's the difference between functional and technical specification?
Functional specification is a more detailed document providing more thorough expectations, i.e. interaction workflows, UI mockups, etc.

Technical specification is a technical minutia document which can define technical workflows or even entire development project UML

Detailed specifications are optional - they can either help our or make a project unmanageably complex depending on the type of the project

How should SSEs be involved into subcontracting?
Everyone in the team needs to spec-test functional requirements/specification, especially team SSE prior to starting a new project

Once a subcontracted project deliverable comes in such as an UI component, new product feature, new product, test automation helper, etc. SSE should review and scrutinize the deliverable prior to acceptance as if it was developed internally

How much work can we subcontract?
This is up to you mostly; as long as we have resources available to dedicate to outsourcing work you'll be able to suggest new projects for subcontracting and will get assistance from Operations to get started