Co-Development News & Articles

How to the Reduce Productivity Tax in Outsourced Software Development

In theory, using an offshore, outsourced software development team sounds great, since it’s hard to recruit and retain local talent. Adding people from another location supposedly gives you the flexibility of faster ramp ups, ramping down when you need to, and access to good technical talent. The problem is that it’s not that easy.

You must consider the overhead of collaborating while living in two different time zones, the challenges of communicating with people you’ve never met, and that unsettling feeling that you aren’t accurately measuring the productivity of staff you can’t see. We refer to it as the “productivity tax” associated with working with an offshore software development and testing team.

Narrowing this gap and reducing the productivity tax is a challenge we welcome. By lessening this bothersome tax, we are able to offer our clients all the upsides to outsourcing software development without the downsides. Every company we work with is different, so the solutions we come up with are unique to individual clients and how they prefer to operate. Here are a few examples.

Challenge #1

Not only is the outsourced software development team working from a different location, its members don’t work the same hours as the internal team. Communication is limited and the client doesn’t always feel supported.

Solution: When you have software development teams working in different time zones, there is a big benefit to having one or more key technical contacts always available to the client. The client then always has someone who can answer questions and address issues during its business hours. We refer to these as “unstructured meetings.” We also use time zone overlap to hold grooming sessions, sprint planning, and retrospectives. This “always on” technical contact structure also helps solve the next common challenge.

Challenge #2

We’ve got two software development teams (one internal to the client, one outsourced) that have never met or worked together before. It’s a nightmare getting everyone marching in the same direction.

Solution: In addition to daily standups, planning, and retrospective meetings, we invite every team member to two key “structured meetings.” In one meeting, we discuss development problems we encountered, design decisions we made and why, the result of code reviews, and other topics that are more development centric. In the other meeting, we talk about the bugs that were identified, those that were not caught early on, test automation strategies, and other issues related to testing. Yes, it’s an investment to involve every member of the team and conventional wisdom would lead you to believe we are adding a heftier productivity tax. However, in our experience we’ve learned that these meetings improve productivity. Everyone understands the purpose behind the goals to achieve and the reasons behind the decisions that are made, plus they learn from one another by solving problems as a group. With teams in two different time zones, we plan for some overlap every day for structured meetings and more at the beginning and end of each sprint.

Challenge #3

If you can’t see your outsourced team, how do you know how good it is and whether it’s efficient? You may not be used to managing people who aren’t right in front of you. How do you know how they spend their time?

Every day is different for engineers, who face different problems and challenges. They may spend their time working on planned tasks or reworking a user story from the day before. It’s a common and very natural question for the client to wonder whether team members are making good decisions on how to spend their days.

Solution: In addition to the structured meetings discussed as a solution to challenge #2, opening up communication among every team member in unstructured meetings provides greater visibility and further reduces the productivity tax. We leverage tools like Lync and Skype in addition to traditional email. It has been a surprise to us to realize how important video conferencing is in bridging communication gaps and building a sense of team. It’s dramatically different when you can see the person you’re talking to. When clients are regularly exposed to every member of the team, they experience firsthand how their remote team members brainstorm solutions, solve problems, take ownership, and are willing to jump in and help with issues as they arise. We are able to eliminate doubt and trust issues no longer exist.

It is true that there are sound reasons why team members are supposed to be in one location under the tenets of Agile development. Being in the same place makes it easier to get on the same page and work as one unit. But in the real world, we can’t all work from the same office. While the details of the solution may vary slightly from team to team, the objectives are the same. Get your people talking and working together. Do whatever you can to bring everyone together to work as one team. It may seem like a big investment and you may think you’ll spend less time coding and testing, but you’ll see pretty quickly that increased productivity results.

At Integrant, we are committed to helping our clients reduce the Productivity Tax through our proven processes. Learn more about how Integrant makes outsourced software development efficient and effective.

Modifying Agile Development for Distributed Software Development Teams

While we all work under the principles of Agile development, each software development team adopts its own modifications to Scrum, Extreme Programming (XP), or Lean, to name a few. With years of trial and error, working for many different types of clients on a range of projects, we’ve learned a few lessons about what works well for distributed teams. We co-develop with client teams based in the U.S. while our teams work from Amman and Cairo. Here are two examples of what has worked well for us and may help you in an outsourced, offshore, near-shore, or distributed custom software development team environment.

Example 1: Modified Pair Programming

We successfully implemented a modified version of XP to support business knowledge transfer and deeper training on the domain. Our modified version works really well for environments where the business, domain, and application knowledge are complex and deep. In the truest sense of pair programming, one software developer writes the code while a second reviews it while it’s being written. For distributed software development teams in two locations, we modified the method and paired software developers in two different locations. One developer wrote the code and at the end of his day, passed it along to a developer in the second time zone with notations including an explanation of code blocks and anything his partner developer would need to know.

There are several benefits to this method:

  1. A software developer with more business or domain knowledge is training a less experienced developer while still efficiently writing code.
  2. Team members back each other up much more effectively with more people understanding a wider range of requirements.
  3. By “passing the code,” developers have a bit more accountability, which means more pride in and ownership of their work, knowing colleagues will be seeing the quality of their code.
  4. With two teams in two time zones, coding hours are around the clock. Modified pair programming makes us more efficient as a team.

Important factors to keep in mind:

  1. Adoption can be a bit of a challenge in the beginning. Software developers by nature like to start and complete a task. As you can imagine, there can be objections in the beginning, as developers may be concerned about the overhead of explaining or justifying their individual approaches. It can be difficult to get everyone on board with the idea of sending unfinished code to a new set of hands. The concept requires everyone to be really comfortable with full transparency.
  2. The most critical factor in adoption by your developers is positioning of the method and support for them as they try it out. Be sure you pair developers appropriately and respond to any concerns your developers voice as far as communication, talent match, etc. In our case, once our teams tried the method for 2-3 sprint cycles, including adjustments and modifications to ensure good pairing and protocol, they felt good about producing better code faster and really embraced our flavor of pair programming.

Example 2: Swarming

We combined the concept of swarming (everyone on the team works on the same story at the same time) with our flavor of modified pair programming noted above to maximize business impact with every sprint. How does this improve efficiency? For one of our projects, we were experiencing some challenges in fully completing all user stories in each sprint. Since a user story has to be 100% complete to release it to production, our very productive team was not looking as efficient in the eyes of the business or the client.

With swarming, we give the Product Owner full control over prioritizing the team. We work as one unit on each user story and the team is not allowed to move on to another user story until the current one is complete. There are exceptions when the team is blocked, such as may occur due to unclear requirements. In this case, the team is allowed to move on and come back to the user story with roadblocks. With swarming, we finished and released the most important user stories with the highest business impact. Combining this technique with our version of pair programming means we are able to develop custom software around the clock and finish user stories very quickly.

One Team

Both pair programming and swarming strongly support the effort to realize cohesion between the software developers on two teams who have never met one another, are working in two different locations, and are operating in two different time zones. Putting an emphasis on working as one unit, backing one another up, sharing knowledge, and keeping each other accountable creates greater efficiencies at every stage of each sprint.

Learn more about how we effectively manage distributed software development teams.

What Makes a Great Engineer?

One of the most important qualities differentiating one custom software developer from another is engineering talent. Companies that seek to extend their internal engineering teams by outsourcing software development are going to be especially concerned with ensuring their external engineers are not just good, but great.

We have a very specific recipe for what makes a great engineer: passion + discipline + communication + collaboration + education.

Passion to Solve Problems

Great engineers must be passionate about using technology to solve problems. In a production system, great engineers have a comprehensive understanding of the system’s architecture and what it’s doing. They maintain an eye for detail, withstand any changes or major issues, and respond accordingly to the best of their ability.

For those learning a brand new system, great Agile engineers can perform many functions and tasks, and are passionate about using the technology to solve problems.


Beyond the passion and drive, great engineers have discipline. They understand how to maintain, scale, and grow what they’ve built. As great engineers, they think about all of this while having pride of ownership and a high commitment to their work.

Communication, Collaboration

Two other critical components that separate good from great engineers are communication and collaboration. Software development is usually team based, and those two attributes are essential to teamwork. It’s also important that engineers not limit themselves to a box; they should think outside of it and progress beyond their prescribed work titles.


Higher education is an important start to becoming a great engineer. It presents an invaluable opportunity to learn the craft and speaks to discipline, given the commitment needed to earn a degree. Engineering students learn more than just the tools to do a job, but a way of thinking about problem-solving and analyzing the world around them. Great engineers never stop learning; after obtaining a degree they continue to add to their skill set through webinars, white papers, online research, and conferences like Microsoft.

Hackers Need Not Apply

What can hold someone back from becoming a great engineer? We believe the primary obstacle is having a “hacker” mentality. It’s great to be passionate and productive, but engineers must think about the software they work on as more than prototypes, but parts of production systems that will be used by millions of people one day. They can’t and shouldn’t throw something together that just does its function. Great engineers take responsibility for ensuring their software is safe, secure, scalable, and maintainable—not merely an end result.

If your engineers want to outsource with engineers like ours, extend your team with Integrant. If you’re an engineer who’s got what it takes to be part of the Integrant team, send us your resume.

Outsourcing Software Development: How We Handle the Challenge of Spotting and Keeping Great Engineers

Making the decision to outsource software development is just the first step toward enhancing your team’s ability to meet deadlines and produce quality end results. The next step—a crucial one to be sure—is choosing the partner that can provide you with top-notch engineers who are encouraged to maintain long-term relationships, lessening the bothersome and expensive occurrence of turnover.

We have a well-defined process to recruit and retain talented engineers—because we know our clients count on us to provide them with people who are just as skilled and committed as their internal team members. Identifying the right engineers is critical, but so, too, is providing them with more than just a nice paycheck to keep them around.

We begin the recruiting process by ensuring engineers possess the required technical and soft skills, which includes having a good foundation, being an excellent communicator and having experience working on enterprise-level complex projects. In addition, we look for people who are:

  • Passionate about technology
  • In love with learning
  • Dogged problem solvers

These criteria are non-negotiable. Even those with deep technical experience won’t be hired if they don’t possess all three qualities. It’s a deal breaker.

Our Development Manager and Quality Manager dig deep during interviews to weed out candidates who we find unsuitable for custom software development. The questions they ask are designed to separate those who give textbook answers from those who clearly have hands-on experience.

We want to hire people who speak openly about hurdles they’ve faced and exhibit good critical thinking skills in explaining how they’ve resolved issues they’ve encountered. We also like to know what engineers are reading, learning and tinkering with in their down time.

Fortunately, we have the benefit of a large pool of candidates to choose from; we filter through thousands of applicants to cherry pick the best. Once they’re hired, we must do all we can to retain them, to ensure we protect our clients’ investment in our outsourced software development services.

As previously noted, good pay alone won’t ensure talented engineers stay put, as their expertise is highly valued. Thus, in addition to good compensation and benefits, we offer our engineers the opportunity to work with peers they respect and on projects that are challenging—and our extremely low turnover rate reflects the success of this strategy.

We’ve heard it said that smart, lazy people make good engineers—since they work smarter, not harder—but that doesn’t fly for us. Since we work at a fast pace with a high build rate and continuous change, there’s no room for laziness; we expect our engineers to work smart and hard.

Finally, we ask our clients to pair us with really talented engineers and to challenge us to perform at the same level. This helps us retain great talent because the best engineers will only stick around if they are learning and growing.

What is the difference between IaaS, PaaS, and SaaS?

Cloud services are typically offered in three variations:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)

A business can utilize these individually or as a hybrid combination. The model that works best for you will be dictated by your goals and requirements. The common thread in each service is outsourcing your in-house load of responsibility. When you utilize the cloud, you lift the burden of managing your own software.
IaaS provides an environment where you may deploy virtual machines. The benefit is not having to manage infrastructure. IaaS will still require you to manage your VM’s, handle security, pick the operating system, and maintain your data and application.
PaaS let’s you focus primarily on code and data. It gives you an environment where you can run your code without having to install your own VM’s. Management and maintenance of the virtual layer are handled by the provider who deploys your code on your behalf.SaaS is a way to outsource everything involved. You don’t have to build a platform; you don’t have to manage it. You simply subscribe to a provider’s software service and they handle everything else.

Meet Ben Lacomble: An Interview with Integrant’s Vice President of Enterprise Applications

As one of the original founders of Integrant, Ben Lacomble has been with the company since the beginning. He now serves as Integrant’s Vice President Enterprise Applications, overseeing the success of every project. We’d like to give you a chance to hear from Ben himself about his background and how he’s contributed to Integrant’s development and growth.

What was your experience in the industry prior to starting Integrant?

I originally began as a developer working in the Petroleum and Telecommunications industries. After several years, I moved into lead positions, managing the software development teams. From there, I eventually migrated from develop management to project management.

What was your role when you founded the company?

When we started Integrant, I handled analysis and design. My primary focus was working as a system architect to design large-scale systems that spanned multiple departments within an organization. This involved designing solutions that would unify multiple departments with one dynamic system.

What is your role with Integrant today?

As Vice President of Operations, my primary role is managing Integrant’s project and account managers. I ensure that projects are running smoothly and that our methodologies are optimized and upheld by our teams. When necessary, I will work with the team to adjust methods if the project requires it. Ultimately, it’s my duty to make sure each project is successful.

How did your early experience inform methods at Integrant?

As a development manager, I dealt with development teams who were handling system analysis. What I found was that the analysis was incomplete. It wasn’t accurate and it didn’t really dig into the requirements for the project. Without actually delving into what the users wanted, it would take several attempts to get the client what they were after.

With this limited approach, the team had to wait for client feedback and then implement a revision. So, I saw much room for improvement to the process, especially in the way we interviewed clients. Now, our process at Integrant requires analysts to get more in depth with each client. We ask the right questions and guide them through the process of explaining their needs and wants for their system.

How have you been instrumental in developing Integrant’s successful service delivery model?

Having worked so extensively as an architect alongside clients, as well as development teams, I gained a comprehensive understanding of what’s necessary to achieve efficiency from both sides. This dual perspective gave me the insight to tune our delivery model. What I found was that the development process has to be as complete as possible for a client. They should have a deep view into their project, something they wouldn’t normally get. Allowing visibility into the process gives both the client and the development team a much more efficient partnership. It translates into fewer mistakes, and a quicker, more intuitive result.

Another aspect I’ve contributed is the questions we ask our clients. They may not always know what information they need to communicate to make sure the development team is fully informed. So it’s the responsibility of the vendor to guide the client by asking intuitive questions. My experienced equipped me with a great understanding of which questions are necessary. Asking these questions guarantees that our team understands what the client wants and needs. It’s yet another way we cut down on revisions and are able to get the client what they want quicker.

What are you particularly proud of in terms of Integrant’s accomplishments?

I’m very proud of the longevity our systems have had. Most of the systems we’ve implemented have a long lifecycle, giving great ROI to our clients. For me, it’s a validation that our methodology works.

I’m also very proud of the team we’ve built. From the project managers, to the development teams in Jordan and Egypt, we have an excellent team backing up our methodology and proving how well it works.

Integrant Renews Microsoft Gold Competency for Application Development

Since its founding, San Diego based custom software development firm, Integrant, has enjoyed a successful partnership with Microsoft. This year, they are welcomed again as a Microsoft Gold Partner, making Integrant one of Microsoft’s most highly accredited independent technical support providers.

Renewing the Gold Competency Partnership annually requires Integrant to meet Microsoft’s elite standards each year. The partnership requirements include offering Microsoft products and services, employing staff members with technical expertise in a comprehensive range of .NET applications, and a portfolio of work demonstrating expertise in these competencies.

Integrant CEO, Yousef Awad explains that, “Integrant’s philosophy on competencies has always been to encourage ongoing education. Obtaining certifications along the way is simply a byproduct of that.” The standard for achieving Microsoft competencies involves intensive training, rigorous exams, overview assessments, and licensing. Additionally, the company must report a minimum of five customer references, employ a CSAT Index survey to measure performance feedback, and maintain revenue requirements.

After completing intensive certification requirements, Integrant has once again renewed their partnership as a Microsoft Gold Certified Partner for Application Development. They place among the top 5% of all Microsoft Partners with these achievements. As a Gold Partner, Integrant gains access to all of Microsoft’s cutting edge tools and programs. This opens opportunities for the company to offer their clients custom applications at affordable prices, without having to sacrifice top-notch quality. The partnership benefits both the company and their clients by cutting costs and boosting productivity. Businesses can invest confidently with Integrant, knowing that certified professionals with a history of distinctions are responsible for developing their custom technology.

The Microsoft Partner Network originally started as the Microsoft Certified Solution Provider program in 1992. Though it has evolved over time, the program is designed to make resources available to a wide variety of technology companies who build their business around Microsoft technologies. Microsoft’s company partnerships are categorized into Silver and Gold Competencies to showcase the proficiency of a business’s primary skill sets.


Yousef Awad: An Interview with Integrant’s CEO

Yousef Awad joined Integrant as a co-owner in 1998. Initially responsible for transitioning the company from an onshore-only consulting center, he has transformed Integrant into what it is today: a world-class, custom development firm, with two offshore development centers. Read on for some insight from Yousef on how he came to Integrant and his vision for the company then and now.

What positions did you hold before starting Integrant and how did this experience inform you?

I started in technology as a database administrator, handling security for the banking industry. I worked for both Bank of America and Great Western Bank. During this time I learned how to work in a very structured environment with highly
qualified security measures, where the ability to maintain up-time was critical. In that type of environment, things move slowly in terms of development changes. Every update has to be well planned and thoroughly tested. I learned the structure of the environment and how to guarantee a high level of security and quality through extensive planning and testing.

From there, I moved to Mitchell International to manage their database environment. With this transition I learned the big requirement differences between a large corporation and a small business. I brought with me a lot of the culture I learned from the banking industry, but had to keep in mind the agility that was necessary for smaller companies.

Finally, I began consulting and worked for a consulting group for almost fifteen years. It was this experience that led me to co-found Integrant.

What was your vision for Integrant?

As a consultant, I learned the incredible value that businesses can get when bringing in an outside company to help solve issues. It gives a business the resources to add skill sets without disrupting their day-to-day operation, and provides an alternate perspective. My vision was to bring this value to companies with a model that was much improved based on my experiences.

One aspect I saw lacking in the industry was teams that didn’t have much experience working together. When a team is put together just for a project, they don’t have adequate time to develop. This leads to a lot of problems and setbacks because communication and collaboration are rarely automatic among a new team. With Integrant, I wanted to eliminate these setbacks and risks by establishing a strong core team. I wanted to grow the company by hiring into the team. This team could be broken into multiple teams, but they would all be trained to work together. That way we would never have to put a brand new team on any project.

Another thing I didn’t like was that vendors rarely put their own skin in the game— they weren’t carrying any of the risk involved. When I started Integrant, I wanted our systems to be built on a fixed bid so the client knew what to expect. If we went overtime it was going to cost us money, not the client. This serves as a motivator for us, and it also gives the client a concrete understanding or what they are paying for.
If we go over budget, that’s something we should pay for.

Why did you see the offshore model as important? What inspired you to start the offshore office?

The main reason offshoring was important to me was it provided an affordable opportunity to build a cohesive team that would work together long-term. What I didn’t want is to have costly bench time between projects because this is always reflected in the cost for the client. I wanted a scenario where we could afford to have an excellent team on staff even if we didn’t constantly need the entire team for every project. I didn’t want to have to give up team members or have the cost of bench time roll over to the customer. That was the main driver.

Another factor was the lack of resources at the time we moved offshore. It was getting very difficult to find resources domestically. So, offshore offices gave us a much better pool of developers.

What are some of the significant changes you have seen throughout the years at Integrant?

Our understanding of how to successfully offshore and outsource has really grown and improved with time. Offering this model to clients requires a lot of commitment on our part. You can’t simply walk into an offshore company and expect to build a team from scratch in six months. A team of ten people can take up to a year to put together. So our approach to this model has really benefited from the challenges we’ve had to navigate over time because we’ve learned what works and what doesn’t.
What do you think has been critical to Integrant’s success?

It’s our staff and the team environment within the company. It starts by ensuring that our team is happy in their workplace. In turn, they care about the quality of work they do. Our team cares about our clients and cares about supporting each other. If you care about your work and you do your best, clients want to partner with you.
Which of Integrant’s accomplishments are you particularly proud of?

I’m very proud of the fact that many of our clients originally came to us for small projects and continued to work with us on increasingly bigger projects. That speaks volumes because it shows we’re delivering what we promise. I’m proud to say that we retain 80%-90% of our clients for a long period after their initial project.

What is Cloud?

The Azure cloud platform is a remote resource where you can run your code, store data, and operate services. The approach is about scalability. It’s about increasing resources quickly to meet needs, and decreasing when you’re not using them.


The cloud lets you scale small or large on the same set of infrastructure, while providing users access from a variety of devices. It allows you to handle workloads that would be difficult and costly to handle in-house.

How does my code run in the cloud?

To run your code in the cloud, it must be delivered in a format that complies with Azure’s data center. Once this package is prepared, you request the number of servers and the amount of processing power you require. Essentially, you make an order for everything you would need in-house to deploy your application and hand the order off to Azure. From there, Azure allocates everything according to your request.
Once they’ve set you up, Azure keeps your resources fully maintained. In the case of failure, they have you safeguarded. If you need more or less bandwidth, you simply increase or decrease your allocation.