The demands on software development are higher than ever, as evidenced by Agile, Lean, DevOps, and the many philosophies and practices employed to optimize it. When faced with a challenging development project, IT or product leaders often start by seeking outside resources with the necessary skill sets and making sure the chosen methodology is clearly established. But that can put you at risk of overlooking a far simpler question: should you tap a vendor to supply an entire, experienced software development team or use traditional staff augmentation to carry it out?
In my experience, the answer to the team-vs.-augmentation question depends on the business need. Read on for a comparison of development teams vs. a group of individuals assembled through staff augmentation for the most common (and often most critical) initiatives. While not an exhaustive list, it’s designed to give small business and large enterprises across all sectors insights into a people-first approach to the early stages of software development planning.
What’s the Difference, Really?
Collaboration and experience are the key factors for differentiating between teams and a group of individuals. Both work toward a common goal–modernizing a legacy application, for example–but established teams come ready to employ collaborative effort, regular communication, and related behavior patterns from day 1 to get there more quickly. Think of it this way: a member of a randomly assembled group can clock in for the day, pick up some user stories, then clock back out while working in a complete silo. In a dedicated team, that same person is expected to interact with several others to complete tasks instead of only being an individual contributor.
Experience is important too, not in terms of getting all the “right” people with the exact skill set you’re targeting, but people with experience as a team–working together in a collaborative manner. A good rule of thumb is to look for a team where 50%+ of the members have successfully worked together to tackle projects. Staff Augmentation, on the contrary, requires the hiring manager to evaluate soft skills of all potential team members to achieve a harmonious team. While we expect team members to be professionals and act accordingly, we are all still people; having team members how know each other already significantly reduces the risk of delays due to personal differences.
Divergent skill sets are valuable within any team. For an Agile Development Team, size of course depends on multiple factors, and I recommend targeting a ratio of roles consistent with 5 core developers, 2 business process-focused developers (aka BAs that can implement code after understanding the business process), 2 testers, and 1 fractional Scrum Master. A structure like this ensures that the team is dedicated to planning the project and maintaining their approach throughout, not just writing code. Interviewing and hiring individuals with strong, applicable technical skills is challenging enough without attempting to focus on all the potential adjacent skills to build a well-rounded team. At Polaris, experienced, vetted teams consistently deliver faster time-to-value for projects, finding the shortest paths to meet clients’ critical priorities.
Comparing Teams and Staff Augmentation for Primary Business Needs
New or Modernized Applications
For projects with a finite, 4- to 12-month timeframe, like application modernization or new custom software, it’s unusual to find the right mix of skills and it’s not necessarily in your organization’s best interest to build out a group of in-house developers to get there. This is especially true when considering that, according to MIT senior lecturer Joe Hadzima’s research, the true cost of an in-house developer can be up to 2.7x their base salary when factoring in costs like rent and equipment. Without experience working together, they may need more time to get up-and-running even with the right technical backgrounds.
Winner: Experienced Team(s)
The total cost per hour can be lower for an outsourced development team with broad ranging skill sets that include project management and communication strategy. Larger or longer projects may benefit from more than one team, modeled after the Agile Development Team patterns above. When in doubt, I prefer multiple, slightly smaller teams over fewer larger teams to foster tight relationships between team members and increase performance.
In maintaining a legacy system built on aging software, finding an established, holistic team with experience using that software can be a barrier. In the case of maintenance following a large custom software project or rewrite, forming a new team through selective hiring of specific skills may be your best bet over finding an existing team that has the needed skills.
Winner: Staff Augmentation
After delivering a rewrite at Polaris, we typically manage the transition and slowly hand the new tools over to a smaller developer group, which may be a mix of in-house and long-term outside developers with specific skills. We actively ensure they feel confident and supported to set up long-term success with the new system.
If your organization has a significant software development need, you can apply the learnings above by asking for references and verifying that at least a few key members have indeed worked together before. When speaking to those references, don’t only ask “Did you achieve what you set out for in the beginning?”, but also “In the end, was the project rated a success?”. This can help you identify changemaking, experienced teams with the means to transform your business and set up in-house staff to succeed at maintaining progress.
I’ve been on both sides of this software development teams-vs.-staff augmentation question, managing multiple in-house teams of 8+ developers each and also securing third-party software services as a manager and director at a large national company. Now, as a Senior Consultant with Polaris, I believe the mark of a good leader is not someone who doles out tasks to siloed individuals, but someone who creates efficiencies–lining up resources and establishing open communication channels so that the team they’re a part of can find short paths to success and uncover new, innovative solutions.
To paraphrase Peter Drucker and Satya Nadella: “Collaboration Culture eats strategy and skills for breakfast”.