This is a continuation with points 6-10 of our article from last week. You haven’t had a chance to read it yet? Do it!
What should you look for when selecting a partner? for Finding an Outsourced Dev Team? For outsourcing your software development project? Points 6-10…
6. Quality of Work – Right the First Time
Of course, like some of the other issues we mentioned in the first five points, it is hard to judge the quality of a team’s work when you are starting on a new project with a new outsourced team. But this should give you some insight into the questions you need to ask references provided by prospective vendors. There is a corollary question, however. Perceptions of quality are often colored by process and communication. If the team does not have a strong grasp of development processes and open communication with the client team, it is almost impossible for them to be successful – developing the right functionality, the first time. Developing functionality takes time and effort. Redoing work (no matter how well it was accomplished) because the functionality the team provided was not what was needed, is a loss for both the vendor and the project because of the additional cost and time spent while the work is redone and integrated with other parts of the application. Remember, every time a bit of code/functionality is delayed while other parts of the work are proceeding, it becomes a risk because it may also delay the development of dependent functionality, or worse, create unexpected consequences in code that is considered to be complete and final.
So, when we are judging the quality of work, there are three critical aspects to consider:
- Code Quality – Is the code clean, documented and extensible? Modern applications must be modular, free of stale code (dead end bits of work that were not used or successful), documented within the code (producing extensive, separate code documentation just produces a maintenance headache that will never be current and correct), use accepted coding standards and practices, and have strong automated test coverage with continuous integration and frequent push to source control repositories. Why? Because it should always be assumed by both the development team and the client that no code is “done” – even when the functionality is fully accepted. If code within the application is not easily located, isolated and documented so it can be extended or changed by another developer at a later time, the application cannot be easily maintained. It can become a legacy very quickly or worse, become a cost sink that sucks up time and effort every time the code is touched.
- Process – A development team that has well-organized, repeatable development processes and high internal efficiency will almost invariably have a better quality of work. If the team isn’t transparent and you can’t figure out how they get their work done, it is very likely there are problems you aren’t aware of and productivity is not what it should be. But, within agile, the industry-standard development methodology, this doesn’t mean a heavy process with considerable overhead. It means simple, iterative processes and individual responsibility to ensure just enough process – but nothing that will impede productivity.
- Inter-team communication – Communication is the glue that assures that the process of development and good coding practices don’t lead to effort being spent on perfectly good code that solves the wrong problem. Quality is not just bug-free, maintainable code. It is efficient, maintainable code that provides clear, usable functionality in the context of the user. There is almost no way to ensure this outcome without direct communication between individual developers, the development team, the product owner/team, and stakeholders. Stacks of detailed requirements, lengthy user descriptions, and existing process diagrams are destined to fail because they will limit the ability of the project team to work together during the project to discover the best way to embody the functionality required. Realtime, open, trusting communication and collaboration between all members of the team is essential to quality results. This communication should include elements such as mockups, walk-throughs, demos and reviews that assure that proposed solutions meet expectations and will not lead the team down dead ends.
A proposed vendor who cannot answer what their team will offer to assure their quality of work within these three domains: quality of code, process, and communication – is a risk. If they expect you to provide the answers, even if the project is successful, it will take a long time for the team to reach full productivity. If they come with answers, but cannot be flexible and creative within their framework, your team will spend a lot of extra cycles trying to work within their rules and structure.
7. Team Spirit
Like a basketball team that goes through its routines with mechanical precision but no joy or spirit, a development team that doesn’t have a positive drive and energy in the way it goes about its work not going to be engaging to work with and a respected part of the project. Energy, when it is open and in the right place, is infective – it drives every member of the project team to be better and to want to reach team goals. In that respect, team spirit needs to be fostered from the beginning of the project and encouraged to grow so it will hold through the inevitable problems every project faces at some point.
This means that vendors should come in with proposals that help the whole project team to integrate and work as one unit, rather than enforcing separations and silos. Project kickoffs with time for the whole team to work together in the same place and also spend some time off-site time together are very important in building positive energy and team spirit. When teams are separated by geography, it is even more important to give every member of the team a sense of who they are working with and that they are a critical part of the team. Team spirit is part of building a sense of responsibility and ownership in project outcomes, ensuring trustful communication and sharing in team success. Having an outsourced team that has a positive drive and spirit, that wants to do whatever is necessary to reach a win for the entire project team is an invaluable asset.
8. Empowered, committed developers
We talk a lot about agile and how it has become an industry-standard methodology for the operational process of software development. It has been around for a long time now, but there are still a lot of implementations that are “agile-in-name-only” – using the name because it is well-accepted, but in practice, unable to take advantage of its positive attributes.
But on the other side of the coin, to be fully agile means that individual developers have to be in the position to take an active, responsible role in the process of software development. When they take responsibility for the development of functionality, a user story in agile terms, they have to be fully committed to not just do the work, with the effort they specified, but also to understand the context and outcomes of the functionality from a user and stakeholder point of view. In practice, this means they must be empowered to ask questions and collaborate with stakeholders and product owners, so they can be assured they will develop functionality that will satisfy the need. It is this level of empowerment and responsibility that differentiates agile from traditional methodologies. An empowered developer is not just responsible for developing something as they understand it from a short description in a user story, they are responsible for confirming their understanding with the stakeholders and the product owner and to ensure that before they begin development, they have confirmed that the functionality they are about to develop will work in a way that fits the situation properly.
If they are properly empowered, a developer shouldn’t have to pass a note to someone to take to someone else for an answer. There should be no intermediaries. They should be able to make direct contact with the product owner or stakeholders and start the process of inquiry so they are personally satisfied that they understand the function they will develop. Of course, personal interaction is not required for every bit of functionality, especially as the project moves along and the team becomes more comfortable with the context they are working in. But, being empowered means that regardless, each developer is personally committed to knowing that if they have taken responsibility for a user story that they will also ensure they fully understand the problem they are trying to solve before they begin development.
Vendors who can provide teams for agile methodology and individuals who can work in this environment have invested in developing the processes, training, culture and communication skills necessary to assure their teams will be successful. It isn’t a one-time, per project focus – because developers have to know what is expected of them and be ready to act appropriately. As a client, if you are expecting a fully agile team and you are expected to develop extensive, detailed documentation of functionality or proposals outline a process with a hierarchy of project managers and supervisors but give you little in the way of specific information about developers, you need to question if your team is going to actually be agile, and not just going through the motions.
9. Location, location, location
The location of your outsourced team in relation to your team is still a critical consideration, even in these days of ubiquitous broadband internet and secure digital audio and video conferencing. As we’ve pointed out, the process of development requires a unified team – that is able and committed to working together to achieve project goals. In the best case, that would mean a co-located outsourced team in the same location, where team members can see each other and work side-by-side throughout the work day. But, perhaps your offices don’t have extra space for five more people and the additional facilities necessary. Depending on where you are located, additional space may not be easy to come by when you need it, for the length of the project. And – finding qualified, local resources when you need them, at a cost that fits in a project budget may also be difficult. In the end, putting together a local team may not be much different than direct hiring if you need to get a project going in a reasonable period of time at a reasonable cost.
Simply going for the least expensive resources is not necessarily a good alternative either. The least expensive technical resources are usually in parts of the world that have opposite work hours because of time differences. In software development, this means they won’t be available to chat or get on a video call – unless some team members extend their day on either side. You trade emails or use an intermediary “project manager” who can cross the gap but with that arrangement, communication fidelity is lost, and time is wasted waiting for answers and getting down to the right information. In addition, if a face-to-face meeting is required, it can literally take weeks to set up and complete because of arrangements, travel time and visa issues.
An alternative is to use resources that are in the same continental geography, making time zone differences no more than they would be if your outsourced team was a few states away – within a time zone or two. Then your team can work at the same time and you can take advantage of technology to collaborate in real time, with higher resource availability and relative cost advantages. Nearshore teams are a worthwhile alternative to consider.
Regardless of where your team is located, the requirement for real-time interaction during software development projects is real and doing without the capability has a cost both in productivity and quality. If you are looking for an outsourced software development team, consider the impact of their location on your project operation strongly.
In this last point, we’re not considering the technical constraints of communication with your outsourced team. That should be a relatively simple problem at this point. Everyone can use digital communication for voice, video and data sharing relatively inexpensively. But, if you are considering using a team in another country or geography, the communication problem comes down to language and culture. If English is not your outsourced team’s native language, they may be able to read and write reasonable English, but not comfortable in conference calls where they have to understand and exchange ideas vocally. Finding the right words and understanding in conversation involves a different set of skills than written communication. There is a level of peer pressure, cultural distance and personal embarrassment that often prevents team members from feeling they can participate fully. In these situations, they don’t engage and feel fully involved in the discussion. That becomes serious when it results in lowered productivity and misunderstood requirements. It becomes critical when it means that progress and problems are not communicated until problems are completely out of hand.
Again, in many cases, you can reduce this risk by looking at nearshore vendors who have resources that share common elements of culture, understand and have studied your language formally as a second language, and have experience working across digital communication channels in real-time. In addition, vendors that are dedicated to providing nearshore resources work with their team members constantly to improve their skills and ease their integration into collaborative environments. Like team dynamics, process and methodologies – communication requires a vendor that has programs that allow their team members to continually improve their skills and grow personally.
Finding vendor to work with you as a partner is a step that will take time and thought – about what you really need, what is critical in the long run for success. The ten points in these two articles are from interviews with our past clients but are not specific to your situation, your project. Use them as a guide, but consider them in the light of your needs and look for a vendor who is prepared to answer questions about how they will solve these issues for you. It is a good conversation to have for both sides of the table.
Scio is a provider of nearshore, outsourced software development services to our clients in North America. As a services provider, we focus on providing teams that are trained, tested and experienced in agile development and the team environment required for success. If you would like to know more about how our services could work for you, please contact us.