These 4 terms all refer to using a service provider to source and contract remote workers on a temporary (though possibly long term) basis.
There is one stand-out – staff augmentation can be used in a more general sense. You can use staff augmentation to refer to placing people in multiple roles throughout a business. But extended team, dedicated team, and team extension refer specifically to adding people to a particular team or even a particular team project.
Off-shoring is a general term that refers to using workers of a service provider in another country to fill roles or perform role-related tasks, within your business.
Near-shoring is similar to off-shoring but it implies that the workers are located in a nearby country or time zone to reduce the management and collaboration difficulties that working across widely different time zones can create.
Out-sourcing is when a project or service that would traditionally be executed in-house is handled completely by an external service provider. The service provider is normally located off-shore in an attempt to reduce costs.
Extended team, dedicated team or team extension is when a project team is expanded by the hiring of remote team members through a team extension provider. The extended team members working remotely report to the same management as the in-house team, they work side-by-side with the in-house team on any projects, and participate in all meetings, but all their necessary resources – computers, office space, HR, etc – are supplied by the team extension provider.
Under the team extension model you are responsible for managing your own project even though the work is being done by external contractors. Under an out-sourcing model the project management would also be handled externally.
The benefits of the team extension model are that you have complete control over the project and complete visibility into how it is progressing. You can spot, diagnose and fix any problems as soon as they occur.
The drawback of the team extension model is that you need a competent project manager inhouse in order to see the project to successful completion.
The extended team model, or the extended development team model, is just the team extension model by another name. You will see both used online. Which one an author favours depends mostly on which region they’re in.
The dedicated team model is yet another term for the team extension model. It is used to make explicit that the team members you contract through your service provider are focused purely on your project. While this is the default whether you call it an extended team model or team extension model, it does serve to differentiate it from out-sourcing, where you have no control over team continuity.
The core team is made up of inhouse employees who established the project and were solely responsible for moving the project forward before a team extension is added to the effort.
The core team holds the business and domain expertise that the project relies on. They work with the team extension members under a project or product manager to complete the project and serve as a source of guidance and deep knowledge for the extended team.
A team extension creates three main advantages for a business. These are particularly beneficial when the business is following the extended development team model for software based products.
The three main advantages of a team extension are:
Unlike in out-sourcing, the management of the remote members of an extended team is handled by the business contracting them. This requires you to have an inhouse project manager experienced in dealing with remote team members.
Post-Covid this is now the status quo. But if a business has pursued a back-to-the-office strategy for their developers, care needs to be taken that the remote members of the extended team are fully integrated into the day-to-day operations and culture of the business and especially for the project they are working on.
In the unlikely event that a business believes an extended team member isn’t performing well, this challenge is resolved in a similar manner to how it would be resolved for an inhouse employee.
The situation is better than that with a standard remote employee, because the extended team member is also under local management and monitoring by the service provider.
If the problems turn out to be unresolvable, it is quick and easy to select, vet, and contract a new extended team member from the service provider’s talent pool, with extra assistance from the service provider for the handover.
An extended team can be contracted to work directly on a project. This can be in order to access expertise to develop certain features, or to shorten timelines for project completion.
Outside of software development on a business’s product, an extended team can be contracted to provide support services, such as devops for an existing team or project, and to keep important and complex applications online and available to customers.
Moving beyond software, an extended team can provide design and UX expertise early in a project, as well as ongoing customer service support and technical support once a project is online.
The big challenges in a team extension are simply variants of the same challenges businesses face with any employee. Onboarding is critical.
Having a manager or mentor available to chat or video call in order to quickly resolve the kinds of problems that show up in the early stages of employment will make onboarding easier and get members of the team extension working productively as quickly as possible.
The other major challenge is integrating the team extension staff with the inhouse team. But this can be handled by simply holding meetings, stand-ups, code reviews, etc, via video so that everyone can participate on an equal footing.
If you want more tips on managing an extended development team read our article The simple secrets to making your extended team work.
Right here. SoftwareSeni is Sydney-based and our main focus is offering extended team services to Australian startups and businesses that think like startups.
This focus is why our talent pool is based in Indonesia. It provides an extensive time zone overlap with Australia that we find makes working with an extended development team so much more effective, both in terms of quality of communication and responsiveness.
Our team of developers (as well as design, UX, devops, and customer service) is based in Yogyakarta. The city is a major learning centre with a large, well-established tech culture. This has allowed us to pick and choose our team members to build the deep expertise that will benefit any project.
We can provide expertise at scales from a part-time single developer up to a team of dozens and for any stage of product development, from ideation to maintenance mode.
If you’re outside of Australia and have strong remote team management capabilities, you might still find the quality and range of our tech talent worth the larger time zone difference.
So if you’re looking to increase your headcount and are searching out tech talent to deliver the outcomes your business needs, get in touch.
Extended Team Model – all you need to know to build the dev team your business needsThe extended team model could be the best tactic to get your startup into the market or drive your business ahead of the competition. Using the extended team model can help you grow your capabilities without eating your margin. And it is the best way to respond quickly to market changes and moves by the competition. Let’s dive into the details behind the Extended Team Model.
The Extended Team Model is an organisational structure where the core team that provides deep institutional and product knowledge is based in-house and works closely with one or more developers who work remotely.
The size of an extended team, and here we are talking mainly about extended software development teams, depends on the needs of the business.
A startup might have a core team of a single Product Manager and the entire development team is an extended team. A corporate business unit might need expertise they can’t access in-house. A business with an established online presence might need some regular devops hours to keep their website and backend working smoothly.
The extended team model lets businesses scale their hiring to exactly match their needs. As extended software development teams are assembled out of a single provider’s talent pool, that hiring can happen quickly – sometimes in days, often not longer than two weeks, rather than the months it can take to attract, vet, and interview team members with the normal hiring process.
The big differences between the extended team model and outsourcing are control and integration.
Outsourcing works like a black box. You feed in specifications and you get code or product out. There are deliverables and meetings, but you have zero insight into who is doing the coding, how focused they are on your particular project or even their level of expertise.
With the extended team model you are involved in team selection. You know who will be part of your extended team and you will know, either through testing or interviews, their ability level.
Your extended team members, if they are full time, will be devoted only to your project. Unlike an outsourced developer that you will never contact directly, extended development team members are integrated into your team. They participate in scrums, they work directly on your codebase using the same tools as the rest of your team. Your goals are their goals.
The extended team model differs from a remote team by being more consistent, more flexible and more reliable.
Here the key feature of an extended team is that every extended team member is part of the same talent pool. They come from a single extended team member provider, such as SoftwareSeni. This means they share the same work culture, have the same training (though they may be at different levels of expertise), and have access to the same resources, including dedicated HR and support. And for your business, this means you have a single point of contact to deal with for upsizing and downsizing your extended team, swapping in new skillsets and so on.
The members of a remote team won’t have this additional layer of management. You will be managing each remote team member directly with no insight into their working conditions, work habits or day-to-day productivity.
A remote team will also have to be assembled by going through the same slow hiring process as an in-house team, instead of the rapid selection process used with an extended team provider.
The extended team model has a number of advantages, some already discussed above. Speed of hiring is a big one this article keeps mentioning. Another is availability of expertise. Depending upon your location, certain skill sets might be beyond your budget or simply unavailable. Your product vision or business model might not survive these limitations.
So, being able to assemble a team with the requisite skills out of the talent pool of an extended team member provider can be the difference between success or failure.
The extended team model allows you to grow headcount without growing your footprint. All resources your extended team members need are provided by the extended team provider – computers, desks, office space.
Another key feature that makes using the extended team model so powerful is the flexibility to grow and shrink your team based on your exact needs in the moment, or to swap out extended developers for different skill sets as you move through different stages of product development.
Businesses should use the extended team model when they have a clear and detailed vision of what they want to achieve but are facing constraints across time, funding, talent or space.
That kind of covers just about every business, doesn’t it?
Prior experience in managing developers or projects and exposure to strategies for working with remote team members (almost universal now in 2023) are the two biggest requirements for using the extended team model.
If you don’t have this in-house experience you might want to take a second look at out-sourcing or hiring a software development agency like SoftwareSeni directly.
Working with an extended team is not much different from working with a mixed in-house/remote team. You face the same challenges of integrating staff into your processes and work culture, and the overhead that comes with suddenly having a higher headcount. It is not core team vs extended team, it’s core team + extended team.
As an extended team provider we have some experience in this matter. We have an article on the simple secrets to making your extended team work, and of course we are focused on helping our extended team clients succeed and are always available for guidance, support and coaching.
Right here. SoftwareSeni is Sydney-based and our main focus is offering extended team services to Australian startups and businesses that think like startups.
This focus is why our talent pool is based in Indonesia. It provides an extensive time zone overlap with Australia that we find makes working with extended development teams so much more effective, both in terms of quality of communication and responsiveness.
Our team of developers (as well as design, UX, devops, and customer service) is based in Yogyakarta. The city is a major learning centre with a large, well-established tech culture. This has allowed us to pick and choose our team members to build the deep expertise that will benefit any project.
We can provide expertise at scales from a part-time single developer up to a team of dozens and for any stage of product development, from ideation to maintenance mode.
If you’re outside of Australia and have strong remote team management capabilities, you might still find the quality and range of our tech talent worth the larger time zone difference.
So if you’re looking to increase your headcount and are searching out tech talent to deliver the outcomes your business needs, get in touch.
Agile basics for small businesses and start-upsTo understand Agile you need to understand where it came from. Building software is hard. You’re building a complex system. Bridges are complex systems, too, but they are regularly completed on time and on budget. So why does software development have a reputation unpredictable and unreliable?
The big reason is this: If you start on a bridge over a river, short of an earthquake, the other bank is still going to be there two years later when you reach it.
But in software and business, two years, even one year, is enough time for the ground to move underneath you. In two years your app might be obsolete or facing dozens of competitors. Or the underlying market has changed, your vision is outdated, and half of the software being built needs to be thrown out, another chunk needs to be updated, and your deadline is suddenly far behind the advancing market and user taste.
You end up chasing change, so busy keeping up that you never reach the finish line.
This is when Agile becomes an advantage.
Agile is not about building software as quickly as possible, it’s about releasing software as quickly as possible.
Agile is where the Minimal Viable Product (MVP) meets Lean Business practices.
Following the MVP philosophy, your product might not be feature complete for years, but when it is developed with the Agile methodology, it will be delivering value to customers within weeks. That value will increase as the Agile team continues to incorporate feedback from users, build new features, and release them to the user base on a regular schedule with a shortened cadence.
Two weeks after launch, the search bar appears. Two weeks later users have a dedicated view of their favourite items and the search bar now has autocomplete.
By structuring development to deliver a new release every few weeks the MVP increases in value to its users, but continues to be an MVP. Because priority is given to value instead of features.
To find that value, Agile relies on User Stories.
A User Story is a high level description of what an app or web site needs to do written from the perspective of a user.
The classic format for a user story is “As an X , I want to Y, so that Z“.
Here are examples of two user stories:
“As a first time home buyer, I want to keep track of houses I’m interested in, so that I can buy my dream home.”
“As a real estate investor, I want to know average house prices, so that I can spot a bargain.”
User stories aren’t technical. They are meant to be discussion points between product owners/managers and developers. Separate to the discussion the developers devise a strategy to deliver the features that support the user story within a series of sprints.
A sprint is not a period of frantic typing and programming. It’s Agile terminology for the short block of time allocated to implementing features in an app or site.
Sprints tend to be 2 or 3 weeks long. This duration is a compromise between the challenges of software development and the drive to regularly add value to the users’ experience.
If a user story cannot be fulfilled within a single sprint it becomes an Epic. Epics take multiple sprints to complete. The challenge with Epics is maintaining that continuous addition of value to the users at the end of each sprint. It can be done. It just takes planning.
“Working software over comprehensive documentation” is one of the four declarations from the original Agile Manifesto. It is not a rejection of documentation. The writers of the manifesto were all experienced programmers. They knew documentation was important.
But they created Agile at a time when the Waterfall Model was the leading methodology. In Waterfall, you plan and document everything up front. As if you were building a bridge and knew where the other side of the river is. And then your team worked methodically, step-by-step, over months and years, to implement the plan, complete the software, and release it to a market that no longer cared.
It was a methodology that sometimes saw projects spend months producing hundreds, even thousands, of pages of documentation before the first line of code was written.
Under Agile, the developers still need to know how the app is going to work, how it is meant to integrate with your business, and how your vision is to be supported.
Business rules still need to be provided, in all their detail. Wireframes need to be drawn and refined. Colours need to be specified.
Developers are in charge of implementation. You need documentation to provide the necessary details about the “what” they are implementing so they can focus on the “how”. It is one of the keys to being Agile.
Don’t make the mistake of looking at Agile and thinking it is a way of building software faster than normal. Agile brings responsiveness, not acceleration of software development.
That responsiveness requires experienced developers. Developers not just with a certification in Agile, but also years of experience with the technology and in delivering working software. It took years for the developers at SoftwareSeni to reach the level where they can deliver consistently. Learning Agile was a tiny part of that skill.
Responsiveness might also be what rules Agile out for you. If you’re not building software for a new market, or a market that is continually changing, traditional development models may work better and have a tighter fit with your company’s culture.
Your company’s culture might also be the thing that makes Agile the wrong solution for you. A top-down management style where decisions have to pass through multiple levels of stakeholders for sign-off is the opposite of Agile. Agile is about trusting the developers, trusting the conversations with product managers, and allowing a team to execute with minimal interruption.
If you’re already crafting the email chain in your head for feature sign-off, trying to implement an Agile process will be an exercise in frustration.
This article has given you the concepts you need to know when considering adopting an Agile methodology yourself. You hopefully have an insight into whether or not you can (or should) take advantage of it.
If you’re outsourcing your development, an Agile partner like SoftwareSeni can help you decide if Agile is appropriate. We’ll be happy to work with you, help integrate you into your own Agile team of developers, and apply this very effective development strategy to your competitive advantage. Get in touch.