find-right-software-development-partner

One simple tip to help you find the right software development partner

We often wonder why companies choose to outsource software development. In most cases, there are two reasons: firstly, lack of qualified specialists or no access to them, and secondly, cost optimization. While the first reason is sensible, the the later one, i.e. following only the financial criteria when choosing a service provider, might not bring positive results. Speaking from experience, we’ve had many inquiries from clients who have based their decision merely on the price. They’ve entrusted their idea to companies offering the lowest quotes or to freelancers and in the end, this has cost them more than money: they’ve lost a chance to launch their business in the right moment. I think all of you will agree with me in that aspect. Those companies simply forget about end users and their satisfaction.

A needle in a haystack

If not price, then what? To be honest, software development companies promote themselves by similar keywords: high quality, great communication, always on time, and agile methods; they usually have similar prices too. So, how are you going to find out that you’ve chosen the right software development partner for your business? There is a simple solution: you need to make sure that the team you outsource believes in your idea and wants to be part of it! Sounds good, right? Certainly, but how to measure that? In my opinion, it’s quite simple: by a number of conversations and questions during the preparation of the product proposal. This is the best indicator of the team’s agility.

The proof is in the pudding

I’d like to show you a brilliant example demonstrating how to make a success of an inquiry which should have failed but didn’t. We were asked to create an e-commerce system for a company located in Saudi Arabia. The technologies they required were different from our specialty. However, as always, we made a video call to present our company, define the requirements, and prepare the Product Canvas (a tool we use to identify the product’s features). Then, we gave the first estimate, consulting the client all the way through. That resulted in the invitation to Dubai for a workshop which was supposed to take place two days later.

Workshop

We had an hour to organize a team for that expedition. Crazy? Perhaps, but nothing builds understanding and trust better than face-to-face meetings and conversations. In Dubai, it turned out that the client’s deadline was much earlier than it had been previously mentioned – 18 weeks before the deadline that we had estimated. That was quite a difference, but the question was: are we able to fulfill the client’s needs within this tight deadline? The best way to find an answer to that question was a discussion.

During the workshop, we determined the MVP scope including all the must-haves; we asked plenty of questions and received plenty of answers. One of our greatest achievements was reaching an agreement concerning the technology – we could use Symfony, which is XSolve’s specialty. Armed with knowledge about the product, we returned to Poland and kicked off the project.

Proposal

Within one day, our developer team created a proposal for a solution, which was then presented to the client and swiftly signed off. Here are some numbers illustrating how important the talks in Dubai were:

  • in the first estimates we talked about 540 working days; eventually, they were reduced to 120 days;
  • the first schedule assumed the completion of the project after 24 weeks; eventually, it was shortened to 6 weeks; planned release date: 26 April.

How was that possible? Simply by a conversation.

trusted-software-development-partner

Nothing builds understanding and trust better than face-to-face meetings and conversations.

Obviously, except for a good plan, we also had to find the means to make it real. It turned out that we had no team available within the deadline required by the client. Another obstacle? Not for Team XSolve. Thanks to an open dialogue with one of our developer teams, who were about to complete another project, we agreed that they start working on this new project after hours. And the most surprising part? It was their idea!

Process and Team

The team was motivated and had so much commitment to the client’s idea that they started programming after hours, on their own initiative, even before any contracts were signed.

It is worth to mention that our developer teams are well-integrated groups who’ve been working together for a long time. The level of collaborativeness and communication is very high resulting in a brilliant working environment for the client as well as internally at XSolve.

The team which took up the project were so excited by the challenge that they took the risk and at the same time increased the chance successfully completing the product. “Collaboration over contract negotiation” – the team said, as they decided to get cracking with the project. How did that story end? Very well, of course!

A simple formula for success

How was that possible? I will repeat that simple formula over and over again: discuss, converse, and engage in a dialogue. Not just at the beginning, but throughout the whole process of cooperation, which in our case is based on a technique called Scrum. It favors communication and provides effective tools: daily meetings, sprint planning, retrospectives, and reviews.

Cooperation

The client’s visit in our office in Gliwice had a significant impact on the course of works as well: apart from the opportunity to talk directly, we also were able to strengthen the relationship between the team and the client.

Summary

If I were to advise you on how to find the right partner for outsourcing, I would tell you to count the number of the conversations you’ve had and questions you’ve been asked. The bigger the number of these exchanges, the more credible are the values which IT companies list on their websites.

The cooperation with the Client described in this article started from one team of four people; now, we have two self-organized and cross-functional teams consisting of nineteen engineers and two Scrum Masters.

In the nearest future, we’re planning to establish a new team of developers who will work on a mobile app project. These numbers are the best proof that successful collaborations are built on effective communication.

Written on 14 July 2017 by

Paweł Kaiser

Paweł Kaiser has 7 years of experience in IT working with development teams both as a Scrum Master and a Product Owner. For the past couple of years, he has been supporting XSolve’s clients, helping them to achieve their business goals as the Customer Success Manager.

Paweł Kaiser has 7 years of experience in IT working with development teams both as a Scrum Master and a Product Owner. For the past couple of years, he has been supporting XSolve’s clients, helping them to achieve their business goals as the Customer Success Manager.

  • Great job and congrats to your Veteran Developers! This is a perfect example of what motivated and driven team, having freedom of choice, can achieve.

    If we could only participate in such projects on daily basis, software forged that way would be irresistible and closer to perfection. And who knows, maybe a typical working day from 8:00 until 16:00, usually from the same office, could become less common in our profession.

    I advocate for remote work, at location and times chosen by each team member. My only concern is, how and who would be able to manage such a dispersed and extraordinary team of individuals? Are you willing to try? 🙂

    • Karolina Kolodziej

      Hi Tekmi, thanks for your comment. Yes, our guys were pretty amazing in that project.
      The strength of our teams is that they are not dispersed individuals. We work in close-knit dev teams in which core members know each other very well and have worked other projects together. This allows us to achieve high performance stage much quicker. This also means that they are more willing to take up the initiative like in the example above. Do you work remotely yourself?

      • I favor working remotely, but sadly it’s not always possible. Sometimes it’s the lack of trust from the client side. Sometimes it’s the problem with tasks/stories, which are poorly defined, exposing lack of design or prototyping. Sometimes it’s project/requirements, which emerge or change too rapidly. Sometimes it’s the system which is unstable and crashes unexpectedly.

        Looks like many factors are against my preference. However I made one observation so far – when you need to prototype or come up with a fresh solution, when lots of deep thinking, focus and studying is needed, then working remotely shines. I couldn’t read a 400 technical book from Monday until Friday at the typical noisy office, while I easily can during a single weekend.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies.

To find out more click here

Ok, Thanks