Setting up Dedicated Software Engineering Teams

Summary

Global information technology outsourcing (ITO) is a USD 556.67 billion market, and despite fluctuations up and down, it is poised to grow to USD 937.67 billion by 2027.

And what is driving this growth? The fast rise of new technologies (Artificial Intelligence, Internet-of-Things, Robotic Process Automation, blockchain, and deep learning)  and the lack of in-house information technology engineering.

Software application development and testing is one of the most popular outsourced IT functions. There are different collaboration models available, but one of them stands out in particular: the dedicated team model. It's a collaboration model that can bring a lot of benefits in the long term, but one that comes along with a number of challenges.

So we wanted to explore how the dedicated team model works, what are the benefits and the risks that come with having a remote dedicated software engineering team and how to best set up one.

download-guide

 

1. Why do Companies Outsource in 2020 and Beyond?

When it comes to deciding whether to outsource or not, the cost saving is still a factor on the table wit’s not as high on the priority list as it used to be. According to Deloitte's 2018 global outsourcing survey, it’s not even in the top 5 reasons to outsource. As Forbes Technology Council points out, there are a number of motivations outside of cost reduction that leads companies to outsource.

  • Faster time to market - With an estimated demand of 600,000 specialists within IT programming at European level and growing,  acquiring the needed technical skills in-house might take too long, increasing product time to market.
  • Ability to innovate faster - Deloitte’s 2018 global outsourcing survey surfaced an increase from 20% to 49% between 2016 and 2018 in the number of organisations moving additional services to providers as they innovate. Also, 43% of the organisations surveyed in 2018 said they made innovation a key component of the contract, compared to 21% in 2016. 
  • Access to the right expertise -  according to Gartner analysts, one of the top priorities for CIOs in 2020 was finding the right talent. 
  • IT operations are taking focus away - having to interview and assess engineers’ skills, hire and manage them can take away CTOs’ focus from innovating and product development, whereas an external partner has this capability well built-in.

 

2. What are Dedicated Teams?

In a dedicated team model, also known as a managed team or customer team, you will work in close cooperation with an outsourcing provider to create a team that will work integrated with your in-house one. Both your company and the outsourcing provider share responsibility over execution and deliverables.

Because  the managed team acts as an extension of your own in-house team, this model requires trust, great communication and compatibility .

In a dedicated team setup, both your company and the provider share responsibility for deliverables and most of the time team management. 

When is the dedicated team model best suited?

  • When you’re building a complex application and the scope of work is not well-defined upfront because requirements change often. In a customer-centric world, companies need to respond fast to users’ feedback and requirements for new features. Thus the product's specifications will evolve along with the product.
  • When you want to retain full control of the product vision. 
  • When you have an in-house technical leader with relevant experience. As responsibility is shared with the outsourcing partner, you’ll need to have an experienced in-house product owner, product manager or CTO to lead the entire engineering team.

The dedicated team model differs from the project-based model and staff augmentation model, in terms of scope, client involvement, execution responsibility and more.

IT-outsourcing-collaboration models

 

3. The Benefits and Risks of Dedicated Teams

Having an external engineering team working integrated with your own team comes with many benefits, but some risks as well. When you have the full picture from the very beginning it becomes clear whether a dedicated team is a good fit for your organization or not.

Benefits

  1. A flexible extension of your own software development and testing organization. You’ll have the flexibility to change the structure of the dedicated team, adding more QA engineers, for example as well as scale the team up and down (given reasonable notice to the outsourcing partner).
  2. Maintain industry knowledge long-term. Once you’ve established a relationship with an outsourcing partner, the dedicated team builds up knowledge in your industry vertical and transfers that knowledge to new team members.
  3. Avoid the hassle of handling your own outsourcing facilities.
  4. Full control over development. As the dedicated team works integrated with your team and communicates on a daily basis, you retain more control over the software development and testing processes.
  5. Shared responsibility increases engagement. Sharing the burden with a partner for deliverables and outcomes keeps the managed team equally engaged and reinforces the idea that everyone is responsible for the quality of the work they deliver.
  6. Improved communication & efficiency over time. As with any business relationship, communication with a dedicated team will take some time to refine and improve. But as both teams settle in and everyone gets to know each other, you’ll benefit from more efficient communication. You’ll know when there is an issue well ahead and how to plan the next sprint better.
  7. Shared project management and management time. As the dedicated team is most of the times being coordinated by a team leader on the ground, you’ll have one less item to handle.
  8. Access to knowledge and various technologies. As new technologies emerge, it’s difficult to keep up and employ developers with various skills. A software outsourcing company, on the other hand, deals with different clients, projects and technologies and has access to a larger pool of technical skills.

Risks

As much as 68% of all software projects fail - they are delivered later than estimated and overrun their initial budgets. When it comes to outsourced software development, 20 to 25% of all outsourcing relationships fail within two years, and 50% fail within five, according to Dun & Bradstreet’s Barometer of Global Outsourcing.

So what keeps the rate of failure in outsourcing at these levels?

  • Expectations misalignment or unrealistic expectations. What will success look like 6 months into the outsourcing relationship? How about 12 months in? Not being very specific about what is expected to happen can lead to disappointment and frustration. Whether it’s launching a set of features by a certain date or onboarding a number of team members, you need to let your outsourcing partner know what is expected to happen.
  • No process in place or weak processes. Agreeing on working methodologies, deployment and testing protocols as well as how day to day operations will happen takes away uncertainty and everyone knows what they are supposed to do.
  • Communication gaps. Day to day communication and alignment on product progress are the best solutions to keeping all team members, in-house and remote alike, engaged and eliminating any roadblocks that might come up.
  • Company culture misfit. Just like any other business relationship, having a compatible company culture with your outsourcing partner can make a world of difference. Regardless if you value transparency, an open management style, proactiveness or speaking out, finding a partner with a similar mindset will make your life easier.

 

Additionally, CIO identified a few other risk factors that can make or break a successful outsourcing relationship.

 

  • No partnership contract - treating your outsourcing provider as a third-party vendor rather than a partner equally invested in your success.
  • Unclear milestones - failing to set up clear milestones and expectations for each release iteration.
  • Inadequate skills - not making sure that the selected ITe vendor has the requisite skills and experience. Looking at the vendor’s certifications, ongoing training programs, industry and functional experience should be criteria in your selection process.

dedicated-team

4. Setting Up Dedicated Teams - What our Process Looks Like

At Wirtek, we adopted the Agile principles for software development back in 2006, being one of the first IT companies operating in Romania to do so. We’ve embraced/embedded the Agile mindset into our company culture. Just as Agile is about people over processes, at Wirtek we use the same underlying principles for setting up dedicated teams, but are flexible to adapt this process to each client specific needs. This process always starts with understanding needs and requirements, creating the core team and eventually extending it.

wirtek-dedicated-team-process

Understanding the clients’ needs

When we onboard a new client, the first step is to connect the client’s team with one of our Services Directors in a product discovery session. Their role is to understand the client’s unique context and explore important aspects such as:

  • Current status of the software product - is this an entirely new product or an existing one that the dedicated team will be taking over?
  • Does the client need help with the entire software development process or with specific areas? This will help both parties understand better also the type of roles we would need to have in the team - Scrum masters, software testers, UI designers, etc.
  • What are the technologies used and needed?
  • Does the client have a development team or do we need to build one from scratch?

 

Creating the core team

The next step is to determine the configuration of the team that we will need to build. This is where the process might vary, depending on whether the client already has a development team in place or not and whether we are dealing with a new product. 

We are usually start off by creating what we call a core team; the roles that we would look to bring into the core team can be:

  • Product owner that will lead the product development. 

In particular, when the client has a new software product and no in-house technical team, then we’ll need to ensure that we have a product owner in charge of  defining the functional requirements among other things. In our own experience, this is a role that should ideally sit within the client’s team. If the client doesn’t have someone to play this role (as it might be the case with non-software companies), we’ll be able to appoint a team member in Wirtek, with the necessary skills to define requirements or user stories. To help our clients manage the business side of the project we also have Certified Scrum Product Owners who can act as product owner proxy on behalf of our clients to ensure that the product “gets out”.

  • Software architect 

We also advise bringing in a software architect to the dedicated team, who will be in charge of creating the product architecture, ensuring  quality standards are met (such as ease of use, scalability of the application etc.). Even when we're dealing with an existing application, the software architect still plays an important part, as he will help us understand what can be improved in the current architecture. The architect can stay with the team in the initial stages, or he can continue working within the dedicated team.

  • Scrum master 

The scrum master will help the newly created team to get organized in their day to day activities: create a backlog, assist the product owner in defining the requirements, estimations, handle team meetings and more. 

Extending the core team

Once we have the core team in place, we will focus on bringing the rest of the team members.

We strive to create a balanced team in terms of seniority, gender and experience. From our experience, we learned that the best performing teams are made up of people with diverse backgrounds (engineers that worked on enterprise products and engineers who worked on smaller applications), gender and seniority levels (mixing seniors with mid and junior engineers).

We find that the synergy between them is beneficial to both the team and the product.

5. Managing Remote Dedicated Teams Effectively

Working with a remote team can be daunting, especially if this is your first experience or if you’ve had a previous negative outsourcing experience.

What we have learnt at Wirtek is that having a client onboarding process in place, setting up clear expectations and communication channels helps build trust and foster a healthy collaboration.

In the sections below we will walk you through the most important elements of working with a remote dedicated team and how we deal with each area.

 

1. Development Methodologies

There are various software development methodologies in use at the moment, but most companies choose between the traditional way to develop software or the Agile philosophy.

Being an early adopter of Agile principles in Romania, since 2006, our preferred way of working is Agile. While we recognize there is no such thing as one size fits all, especially in a dynamic world as the software product space, what you’ll find in this section is based on our own experience and preferences.

At Wirtek we have Certified Scrum Masters and Certified Scrum Professionals to help our agile teams properly use the agile methodologies as well as improve the way Scrum and other agile methods are used in the projects.

  • We work with a product backlog consisting of user stories, each user story being organized by its urgency and importance by the product owner. The effort to implement each user story is estimated by the development team and refined along the way.
  • During each iteration, we plan what features we will be working on.
  • During daily standup meetings we talk about roadblocks encountered and what each team member will be working on for the day.
  • At the end of the iteration, we demo the newly launched features (usually to the sales and support team, but anyone interested in the customer team can join). We collect the feedback we receive and incorporate it into the backlog and then move into the next iteration.
  • There is a product roadmap in place, typically defined for the next 12 months, that we constantly maintain.

Because we follow the agile principles, the development teams are self-organized. The team inside Wirtek works integrated with the customer team, acting as one development team. 

The distributed development team meets daily during the Scum meetings and also during the rest of the Scrum ceremonies:

agile-ceremonies

  • Sprint Planning – a meeting at the beginning of each sprint, where the content of a sprint backlog is defined and the entire team commits to deliver at the end of the iteration
  • Sprint Review – a meeting where all interested parties can see what was done in the last sprint and and give feedback; the adjustments, if any, will be part of the next planning session.
  • Sprint Retrospective – a meeting where the entire team reflects upon what went well in the previous sprint and what should be improved or done differently in the next one. It is not an evaluation of any kind but an opportunity to reflect, learn and improve.
  • Daily Scrum Meeting – takes place every day and it’s a discussion about what the team achieved the day before and what it will do during the current day to achieve the sprint goal, as well as potential impediments.

 

Well-defined working processes aside, it’s the principles that matter most for us. When we build dedicated teams, we employ the agile principles for software development and map those over the client’s own processes - this has proven to work best for our clients.

 

agile-philosophy

 

2. Setting the Infrastructure

Working remotely has never been easier, thanks to the various collaboration and communication tools. Version control and issue tracking application make it easier to collaborate on software development.

Setting up the client’s infrastructure in place is an important step and we stay flexible in adapting the client’s tools. The tools that we use most often and love are the ones listed below.

Communication & presentations - tools to help us communicate fast and easy with each other

  • Slack 
  • Microsoft Teams
  • Outlook

 

Issue tracking – tools that we use to manage tasks and issues during development sprints

  • Jira
  • Trello
  • Azure DevOps

 

Version control – tools that allow teams to track changes to a set of documents. They are critical to every software development project, where several people concurrently make changes to the same files.

  • GitHub 
  • GitLab 
  • BitBucket  

 

3. Software Product Documentation

One of the most common concerns our new clients share is the fact that they don’t have fully written product documentation and how that will impact their dedicated team ramp up time.

The good news is that we can work together on defining the product specifications, as we have learned that a collaboration between our clients and a Wirtek Scrum master or proxy product owner is the most efficient solution.

In most cases, our clients don’t have product specifications and in those situations, a Scrum master or proxy product owner in Wirtek sits down with the client’s product owner and works on defining specs. This offers us the opportunity to learn the client’s product as well as the industry at the same time.

We aim to keep just enough documentation and to keep it “live”: documentation created and maintained in the tools we use, rather than written on paper. The most popular tool used in Wirtek for documentation purposes is Jira. In Jira we maintain a product backlog that describes how the software product should work, based on user stories.

Product documentation exists beyond specifications in various places:

  • Within the code: the software architect starts inspecting the code and shares the learnings with the rest of the team during what we call “weekly study groups”.
  • Code review: every new engineer that joins the remote dedicated team does code review with the purpose of learning & sharing the knowledge with his team, beyond identifying and correcting potential errors in the code.
  • In the release notes: with every sprint, we create release notes documenting what has been delivered.
  • Within acceptance tests: based on each user story, together with our client we define criteria that the story needs to meet in order to be accepted.
  • Definition of Done: we are documenting each release so that we know a feature is 100% finalised.
  • Retrospective meetings conclusions: we brainstorm and create a list of actions items to be addressed during the next sprint to make sure they are visible to the entire team.

 

Bottom line is that when there is little to no documentation, Wirtek takes the task of creating it and we aim to maintain live documentation within the tools we use, rather than on paper.

dedicated-team

4. Software Quality Assurance in Wirtek

In this section, we will try to give you an overview of how we view the software quality assurance process in Wirtek, how we define quality standards and how we make sure we deliver great quality software products. 

Before we dive in, it’s worth mentioning that for us, quality assurance means more than just the quality of the code deployed: it’s about the quality of the documentation, how we formulate specifications all the way to defining acceptance tests and testing. As an IT outsourcing organization, we are oftentimes involved in creating a product’s architecture from scratch, defining specifications, and so QA is more than the quality of code - it extends across every stage of the software development process.

Every client and organization we work with is unique, their specific industries demand specific software product requirements. 

Because of that, every time we onboard a new client, the dedicated team defines what QA means together with the client. To that extent, we can say that each team and project in Wirtek defines, monitors and implements QA differently, but they all rely on the same underlying principles. 

 

So what are those principles to define software QA?

  • Formulating requirements - we make sure to put in enough details so that we are later able to make accurate effort estimations. Formulating requirements is the form of user stories (“as I user I want to solve”) enables us to understand what a feature should do.
  • Definition of Done - each engineering team decides together with the client what Definition of DONE means to them, when is a feature correctly implemented. 
  • Tracking estimations - we strive to keep accurate track of time and create accurate estimations. This will enable us to know how far along we are until completing the sprint’s goal.
  • Organizing the backlog - we keep an organized backlog, so that we can track progress and know whenever we are off track. This usually falls under the Scrum master’s responsibilities.
  • Writing code - we follow a well defined product architecture, and ensure the architecture was followed through code reviews. We employ different development approaches such as TDD or behaviour driven development, that allow us to do different validations before implementing functionalities. 
  • Acceptance criteria - based on specifications, we define the conditions a feature needs to meet in order to be accepted by the client. For example, you can define that a login functionality is accepted if when a user enters an email address or password that doesn't meet a certain format, he receives an error message.  
  • Quality of code - when writing code we make sure it meets certain attributes: Correctness, Reliability, Adequacy, Learnability, Robustness, Maintainability, Readability, Extensibility, Testability, Efficiency, Portability. 
  • Code reviews - the entire dedicated team reviews the code a developer implemented. All the improvement comments are documented and the developer needs to go through all of them, make changes where needed or argue why some comments should not be implemented. Only after all comments are resolved does the code go through another round of testing. 
  • Testing - we do testing not only at the end of each sprint but also during the sprint, that way we can spot issues early on. We decide, based on the values added to the team and product whether we should automatize parts of the testing.
  • Retrospective meetings - part of the Scrum ceremonies, the retrospective meetings help us refine and improve our working process by looking at what worked well and what didn’t.
  • Daily meetings - they enable the dedicated engineering team to communicate with the product owner, understand what needs to happen and implement accordingly. Better communication translates into an overall better product.

Learn more about how we approach software testing and what our testing process looks like.

 

How do we define code quality?

  • Right competencies and mindset to understand what software system we need to build
  • Definition of done (the code meets the requirements, code is reviewed (for extensibility, maintainability, readability, etc), and tested (unit tests, functional tests, integration tests, performance tests), code is ready for deployment)
  • Code review process – pair review, team review
  • Tools to assists whenever we can automate some processes such as Visual Studio, ReSharper or Sonar.

 

What are the checks we use to ensure consistency in code quality?

  • Code review process
  • Functional testing
  • Integration testing
  • Retrospective meetings

 

Being loyal to the Agile principles, the entire software engineering team, both distributed and in-house, is responsible for the overall quality assurance of the software product.

While the entire team is responsible for the overall quality of the product and features released, team members have different involvement levels in different areas:

  • The product owner and the scrum master are responsible for the backlog and for defining requirements
  • During sprints, developers are in charge of code reviews
  • The entire team is in charge of constantly improving the way they work, based on what the team learns during the retrospective

6. Mitigating Risks with Dedicated Teams - How to Select the Right Partner

Selecting the right fit partner for outsourcing your software development can be a lengthy process, but ensuring you choose the best fit for your company and goals will pay off in the long term. Rushing to sign off quickly with an outsourcing company just to discover a few months into the collaboration that they are not what you were looking for is more expensive and difficult to undo.

Criteria to Select the Right Partner

As you start researching and evaluating different providers, here are the main points to consider.

criteria-to-select-right-partner


  1. Partnership mindset

When the outsourcing provider thinks of your collaboration as a partnership, they are equally invested in your success. In this mindset a close relationship and communication are crucial. To understand where potential providers stand relationship-wise, you can ask about how often they communicate with clients, how they address issues when they arise, how they ensure the distributed engineering team is aligned with the client. 

 

Here at Wirtek, we believe that the quality of our client relationship matters just as much as the quality of the delivered services. Because of that we dedicate time and effort to building and maintaining partnerships with our clients: around  25% of our current clients have been working with us for 10+ years.

 

Investing in our client relationships comes with a number of benefits:

  • it enables us to understand their needs, find solutions, challenge them when are confident we have a better solution or approach 
  • when we understand what our clients need, it’s easier to find and put the right people in the right team, at the right time
  • it increases the team’s commitment, people feel part of something bigger than just delivering billable hours. They are part of our clients’ business and equally responsible to make their product a success. 

The way we see client relationships is that we become an extension of their own engineering team. When you are a Wirtek client, you get a team that works with you as if it's your own. And this changes everything, from the way we interact to the level of involvement and attention we give to our client's business.

 

  1. Communication and collaboration

Good communication fosters a good relationship, especially when you work with a team that doesn't sit in your office. 

So when doing due diligence, make sure to ask about day to day communication, how the dedicated team stays aligned on goals and what needs to be done, but also how the management team deals with issues when they arise, how they respond, how they addressed issues with other clients in the past.

 

  1. Company culture

When working with a dedicated team that is integrated with your own in-house team, being aligned around the same values makes a world of difference. Imagine that your company values for example a direct, straightforward approach to communication and you would choose a partner that prefers an indirect approach - communication would most likely be hogged down by different styles and expectations. 

Asking questions related to company values, working preferences, and how things are done in the company can help you understand if a provider shares important values with your own organization.

In Wirtek, our core values are:

  • Commitment: putting people first, committing to delivering quality and clients' success, assuming responsibility for our work, go the extra mile.
  • Common sense:  say things as they are, do the right thing, respect each other, lead with integrity.
  • Proficiency: we dare to be creative and try new approaches, keep on learning, share knowledge, take initiative, be Agile.

 

  1. Agility

Modern software development organisations embrace the Agile principles for software development, as it allows them to deliver product features faster, in a more predictable way and keep the software product aligned with the business goals.

Therefore you should make sure to ask potential providers how many years of experience they have working with Agile, which methodology they prefer, if they have certified Scrum masters or not.

 

  1. Training and employees’ development opportunities

In a world evolving at fast speed such as the IT space, training and learning opportunities are not a “nice to have” anymore but a “must have”. 

Asking questions around training programs, learning opportunities and knowledge sharing in the company can reveal how much an outsourcing provider invests in training and learning.

 

  1. Technical fit

This one may seem quite obvious, and yet is worth mentioning that you should confirm if a given provider has the requisite skills and experience. You will want to ask about certifications, technologies they master and level of experience.

 

  1. Employee retention

Employee retention is a big signal to look into, as poor employee retention signifies there is something potentially wrong such as a toxic culture.

Not to mention that having a poor retention rate could mean delays in delivery, spending time over and over to integrate new team members and in the end a higher cost.

 

  1. Testing the relationship 

Before jumping in a long term commitment, it can be useful to ask if providers offer the chance to do a pilot project first and then go into a long term commitment such as  a dedicated engineering team.

 

  1. Previous experiences

Asking about previous collaborations, how those evolved and even speaking directly to one of their current or former clients can give you a good feeling of the providers’ professionalism and way of doing things.

 

  1. Company size & scaling up

Understanding how large a provider’s organization is and how fast they can scale up a team and hire can help you decide if that is a good fit considering your goals. There is no wrong or right answer, but if you are a small or mid business, working with a large outsourcing provider can be challenging to receive full attention, alongside much larger clients. On the other hand, if you need to set up a large engineering team fast, that can be challenging for a small or midsize provider.

 

What Makes an Outsourcing Partnership Successful?

In our experience, our most successful collaborations share some common traits:

 

  1. Alignment on company culture and values.

When we think and act in a similar manner, working together becomes easier. One of the things our clients appreciate about working with us is the fact that we dare to raise questions and come up with solutions, which in turn means better outcomes for our clients and keeps our people at Wirtek engaged & motivated. So for us being able to meet a potential client in person and trying to understand their business, challenges and culture help us determine if there is a good fit.

 

  1. Working processes

Having clear processes in place gives everyone on the team predictability, everyone knows what is expected of them and how things will happen.

 

  1. The approach to solving issues when they arise

As with any commercial relationship, there will be issues and roadblocks. Our approach in Wirtek is to be very open and honest about where we stand and come up with solutions. When we find a similar mindset in our clients, we know we can overcome these challenges faster.

 

  1. Having a dedicated person to lead product development

The product owner or the person within the client’s organization that leads the product development plays an important part in a good long term collaboration. They understand the business and the product, priorities and can make decisions faster. When there is no such dedicated person on the client’s side, decision making takes more time, and that in turn causes delays in implementation and eventually ends up hurting the team’s morale.

 

  1. Quality of interaction and communication

Quick, timely responses from the client help speed things up. Also, the willingness to meet the dedicated team, bond with people and form personal connections makes for a smoother working relationship.

 

dedicated-team

7. Success Stories

Spectralink

We have worked with Spectralink, a leading provider of enterprise mobility solutions, since 2009, providing quality assurance services for their DECT handsets and servers. In the beginning our partnership began with a team of just three engineers doing QA, but as Spectralink’s products portfolio grew, so did the opportunity of our partnership. 11 years later, we are managing two dedicated teams for Spectralink, in charge of equipment testing and DECT server embedded development. 

Spectralink picked Wirtek to be their quality assurance partner as we were a well-known and experienced provider of software development and testing in the telecommunications industry.  We were able to offer the technical expertise required as well as the capability to ensure stable and predictable service delivery on projects.

Read the rest of the case study here.

 

Innomate HR 

Innomate HR is a robust human resources platform that enables organizations to manage their end-to-end HR processes.

Finding, recruiting and retaining motivated software engineers was difficult in a competitive employment market as Denmark, particularly for a small business, so Innomate was looking for a reliable software development provider. Our collaboration with Innomate evolved from a pilot project to running a dedicated development team for close to 11 years now. It is one of the longest collaborations we had in Wirtek and some of the strongest team connections were formed here.

Read the rest of the case study here.

 

Get in touch to discuss how we can help you