Outsourcing, nearshoring, and offshoring are gaining more and more trust in various business sectors for a reason. Building an in-house team takes a lot of time. Instead, we can use the help of specialists qualified in their fields, paying only for the work done and effectively securing our interests. This model of cooperation is becoming increasingly popular, but if you are just starting cooperation with an outsourcing company on a day-to-day basis, you may have many questions regarding the principles of implementing a joint project in this model. This article will help clear up any doubts. We hope that after reading it, you will get rid of any concerns about the extended team and you will be sure that this is what your business needs.

Some time ago, an article appeared on our blog in which we discussed the issue of improving communication with developers. They play a key role in the implementation of IT projects, but there is often a CTO or project manager between them and the client, who we cannot forget. At that time, we shared some advice with you on involving developers in the project and improving communication with them. Today we would like to focus on the general principles of the client's cooperation with the extended team. What does the work routine look like? What aspects should be taken care of so that the project goes according to plan? What should both sides require of each other? We will deal with these issues today.

Transparent and effective work structure

Software development, especially when a client decides to cooperate with a software house, is a process in which it is worth setting out the exact rules of communication and ways to go through the various stages of the project from the very beginning. The absolute basis will be to determine when the employees are available, what time they will report on their progress at work and when they will achieve specific milestones that make up a given project. There can always be changes, blockers, new circumstances to be explained, and only good communication based on a solid structure can help you face adversities quickly. Programming solutions largely depend on knowing the exact needs of the client and technological possibilities, so many things clear up along the way. That is why in bPol we focus on an Agile approach. It allows you to improve communication and treat yourself as partners. Mutual trust is a very important element of cooperation between the software house and the client, and Scrum allows for full transparency for both parties. Regular daily or weekly meetings allow you to control the project on an ongoing basis, report any concerns, summarize successes, and thus simply build a better relationship based on partnership principles. Even if something goes wrong with the developers or the client, we can react quickly, find solutions, reach agreements, and be clear about the situation. 

Here are the forms of communication that are in line with the Scrum methodology worth using:

Daily scrums

Status meetings are especially important for developers. Thanks to them, everyone knows exactly what to do, when the deadline for specific tasks passes, where the backlogs occur, and what threatens the delivery of the project on time. It is important that a daily takes place at a time when everyone can join the meeting, and that each team member can speak on a topic that is important to him.

Sprint planning 

Planning is very important in Scrum. Work is divided into cycles called sprints. Each of them starts a meeting during which we plan priority activities for the next project implementation period. It is here that key decisions are made and appropriate solutions are adapted to them along with a better understanding of the client's needs. When working on a project, it is worth writing down challenges that need to be discussed during sprints. This makes it easier to get rid of blockers and complete the tasks waiting in the backlog faster.

Sprint review

At the end of each sprint, there is a meeting known as the Sprint Review Meeting. During this event, the team presents the results of work to date, which in Agile terminology is referred to as Increment. The definition from the Scrum Guide reads: "The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.” At this stage, we confront the expectations and effects of work. The client may appear at such a meeting, but the most important will be the presence of a team of programmers, scrum masters, and product owners. It's not only time for a demo, asking questions and feedback. The Sprint Review Meeting plays a key role in building team confidence and boosting morale.

Sprint retrospective

The last element of the cycle is a retrospective that takes place after the Sprint Review Meeting. At this stage, we talk about all the elements of the project that can be improved in the future. Everyone gained new experience, learned something, or paid attention to something. This is the best time to share feedback with others. The discussion about the improvements that may appear in the next sprint allows for continuous development and is very beneficial not only for a single project but also for future software house activities.

A satisfied client is one who is kept informed

Taking care of good and transparent communication in the software development team, one must not forget about the client. After all, it is the company that hires the nearshore team to be satisfied with the final product! Under no circumstances can the customer be kept at a distance, and certainly not as a disturbing entity. Regular update meetings should be established at the very beginning of the project, allowing the client to follow the progress. This should not be a courtesy, but a real initiative to build mutual trust that will pay off for both parties. With each project, there may be unplanned complications generating delays. A transparent explanation of each situation (both successes and unforeseen events) allows you to manage the project more effectively, to finally deliver it in the best version without the stress that the client learns about a mishap. Honesty really does pay off. Sure, it is the quality of the final product that will decide how the client will perceive the software house after the end of the cooperation, but its trouble-free course based on trust significantly contributes to the effective work of the team, quick introduction of changes, and solving issues.

The art of dealing with complications

In an ideal world, the Scrum Guide solves all communication problems, there are never any errors in the code, each project is completed prematurely, the client is so pleased that he pays 50% more than the contract provided for, and the software house adds new functionalities to the product for free. Unfortunately, we do not live in a perfect world and sooner or later there will be cooperation where something goes wrong. It's good to know what you can do when something doesn't work, but still, leave the project unscathed.

A fresh look at the problem

Using the services of the extended team has the advantage that a quick addition of a new person in a crisis situation to the project is not a big problem and in most cases does not generate additional costs for the client. Engaging an expert who can take a fresh look at what has been done so far is very often a great way to spot solutions that others have overlooked. It is sometimes worth asking for help from a Software Tester, Project Manager, or DevOps who works in the same software house and has spare capacity. The new perspective can bring a breath of fresh air to the project or indicate alternative solutions. Employees involved in the project should be constructively criticized and not be too full of themselves. Treating an outside expert like an intruder can only make things worse. If an individual has the authority of a specialist, it will be easier for project staff to view it as mentoring rather than disbelief in them. The involvement of such a person can also be an added value for the client who will appreciate the software house's care for the successful delivery of the project.

To prevent fires instead of extinguishing them

When it comes to communication problems, it's worth remembering that everyone has bad days. People are driven by emotions and there is no point in getting involved in disputes and quarrels when, for the sake of the project, you can simply let go and clarify the problematic situation as soon as possible. A clear and specific presentation of your arguments and expectations will benefit both sides. If someone is at fault, they must be given a chance to rectify the mistake, and most often a compromise is achieved. However, it must be remembered that there are also situations with no way out. Sometimes a cold profit and loss analysis is the final solution that leads to the dissolution of the collaboration. If the software house has any doubts about the commissioned project, it is necessary to talk about it at the first meeting. A "get a deal and then worry" approach can be devastating. Perhaps the doubts will be dispelled by Technical Due Diligence, audit, or appropriate training to help understand a problem. It is worth using some auxiliary solutions and it is better to prevent problems than to fight fires later.

Work in the post-Covid world

Finally, we left a thread that we would like to develop in the future as a separate article. The percentage of people working remotely has increased significantly since 2020, and it is worth taking a look at the current practices and challenges related to the fact that meetings are held via webcasts, and communication takes place through the exchange of messages, phones, and project management platforms. In one of the next posts on our blog, we will look at work in the post-Covid world, but today we would like to refer to a few tools that will help improve the previously discussed methods of cooperation when implementing a project remotely.

Already at the stage of the first meeting with the client, all details regarding remote cooperation should be agreed upon. There is no shortage of tools on the market, so it is necessary to determine which platforms will be suitable for both parties. If the client insists on solutions that are in some way limited, it is worth persuading him to use proven solutions that will facilitate communication. There is nothing worse than technological limitations that could have been avoided by simply choosing better services (which sometimes are available for free). What should you take care of? The first piece of the puzzle is the project management platform. It can be Trello, Jira, Basecamp, Asana, Clubhouse, Kanbanize, or Notion. There are many solutions on the market. It would be great if we could find something that is already known and liked on both the part of the software house and on the client-side. It is also worthwhile for both parties to be able to communicate, not only by phone. Choose a tool that will allow you to use the chat. It could be Slack, Rocket Chat, or if text communication is kept to a minimum, any popular messenger. The last basic tool for information exchange should be a secure cloud on which files and materials will be collected. Without these three basic tools, it is difficult to imagine remote project implementation nowadays.

Whether you're working remotely or meeting live, remember to backlog, prioritize, and keep everyone involved in the loop. It is worth setting fixed dates for meetings and avoiding organizing them at the last minute. Communication is the basis of everything here, so always in case of any doubts, it is worth both asking questions and explaining certain solutions. When you build trust and work out the right working methods, your project will run more smoothly - whether you are meeting live or during video calls. And we will talk about remote cooperation soon. Stay tuned!