Skyrise’s Outsourcing Decalogue

Today we want to share with you the ten factors that we consider the key to a partnership-based outsourcing cooperation.

I. Communication is everything

It may sound obvious and trivial, but communication is the most important thing. Communication that is corrupted or doesn’t work is one of the most (if not the most) frequent causes of cooperation failure. We learned it the hard way. We won’t pretend that we never made any mistakes in this area. We’ve made a lot of mistakes, but that also means that we have a lot of material to learn from. We truly believe that honest and open communication is the key to success. In our understanding “honest and open” means that we put special emphasis on communicating problems as soon as possible. We know that problems happen no matter the precautions taken, but addressing them as soon as possible decreases the risk and increases the possibility of finding a satisfying solution.

Designing a good communication model that works for both parties is essential in a good cooperation. You can see some examples in some of the points below.

II. It’s neither about us nor you, it’s about the team

One of the key factors of a successful cooperation is not only understanding that we work as a team, but we also act as a team. Even if we provide only the development force, developers need to feel that they are part of the team. They need to feel appreciated, involved in decision-making processes (e.g. the design of the solution) and be a part of the information flow (they want to know what’s going on). By making sure they feel like team members, the customer can get their full commitment and they will feel responsible for the project’s success.

But is it possible for this to work when a team operates from a remote location? Well… we won’t lie – it’s certainly more difficult, but not impossible :) There are some conditions that need to be met to make it happen. Some of the most important ones are:

  1. The team needs a dedicated person that will be able to answer their questions almost instantly (or at least will be able to take actions that will result in providing the answer). Based on our experience – it works best if that person is available locally at our office (e.g. the Proxy Product Owner).
  2. The team needs to be in touch with the Product Owner. Remote synchronization meetings are not enough. It is essential that the Product Owner periodically meets with the team in person. It can be in order to present them with the status or condition of the project, talk about upcoming events and plans, or simply socialize with the team. It gives the team a clear signal that somebody actually cares.
  3. If there is a Proxy Product Owner on our side, he has to communicate with the customer’s Product Owner daily. They also have to periodically (e.g. every 2 months) meet in person to discuss the plans for the forthcoming period. That way they can break away from their ongoing tasks and focus only on the issue at hand.
  4. Mutual respect and understanding is the key to achieving success. This applies especially to cultural differences. If you won’t find a common ground here – the cooperation will fail.

III. Not only “what”, but also “why”

Over the years we have learned that it’s extremely important to not only know what we must do, but why we have to do it. It’s essential at every step of the software development process.

  1. When analyzing and describing the change – to design a solution that will solve the customer’s problem, satisfy their needs and prevent scope creep,
  2. When proposing a technical solution – to adjust it to the actual needs and prevent over-complicated ideas based on wrong assumptions,
  3. When developing – to see the goal and the bigger picture, keep up the motivation and awareness of the developers (system feel),
  4. When testing – to verify not only the output, but also the possibilities of the solution to provide the expected outcome,
  5. When providing a solution for an acceptance test – to see the customer smile and hear “that is exactly what we needed”.

IV. Trust, but control

Having control over the commissioned work and a clear picture of the current status is crucial for customers. We design our cooperation model in a way that incorporates many synchronization methods.  Usually it involves:

  1. Periodic (e.g. weekly) status meetings – where team representatives (usually leaders) meet with the product owner to discuss the status and current challenges,
  2. Daily stand up meetings (inside the team and between the proxy product owner and product owner) – to briefly discuss the status and planned work,
  3. Ad hoc meetings – whenever it’s necessary, to clarify arising issues and remove problems or risks,
  4. Appropriate IT tools that allow every involved person to quickly check the status of the work in progress (e.g. Kanban boards in JIRA, messaging tools),
  5. Time reporting that accurately shows what the team spent time on.

Of course, the number of meetings and the tools that we use are always adjusted to the needs and challenges of every specific client.

V. It should not only work, but be easy to work with

The current software development market is evolving rapidly. It puts more and more emphasis on the usability of provided functionalities. When a user has to struggle every time he needs to use the system – the solution is quite far from being successful. True value can be delivered only when the user can do his job efficiently. That is something that everybody in Skyrise understands and fights to achieve. Even Project Managers (howeverhard to believe ). We put a lot of effort into designing the solution in a way that ensures that we provide the value and appropriate outcome. We help our customer at every step of the way: verifying the idea, performing user research, preparing and verifying wireframes and graphical designs and analyzing the feedback from production (and more). It has become a significant cooperation success factor lately.

VI. Our work, your property

We are very attached to the solution we design and provide. We treat it as a child entrusted to us. Although we have thousands of ideas on how to provide it with a bright future, we know that it’s the parent who makes the final call. We are only there to help. The owner of the system should have a full understanding of what was developed and how it works. To achieve this:

  1. We insist on having at least one person dedicated to the system on the customer’s side,
  2. Before starting the implementation, we discuss the change in order to find a common understanding of all the people involved,
  3. We agree on what will be developed and what the final output will be,
  4. After implementation, if necessary, we provide a demo of the functionality,
  5. The customer is involved in acceptance tests.

No matter the work configuration, we do everything so that our customer won’t lack any essential knowledge about the system.

VII. Providing a different perspective

The best type of cooperation is when it’s possible to combine the best of both parties. This allows to achieve something that was not achievable or not visible before. One of the worst sins of cooperation is when one party is passive, just taking and trying to perform tasks assigned by the other party. We always want to help build better products. We are always active. You can say “but you don’t know your customer’s products, so how can you contribute?”, and you’re right… to some extent. Yes, we don’t have any inside knowledge (at the beginning), but it can work to our advantage. If you work with the same product for a very long time, you start to see that product from the same perspective all the time. Because we don’t know our customer’s product that well and we have worked with a lot of different products, we can provide a different perspective. This allows us to see the problems or generate ideas that the customer can’t see. Being an active partner is awesome!

VIII. Embrace change

“The only thing that is constant is change”, is the motto that we live by. IT projects are unpredictable and change is inevitable. Instead of trying to prevent it or fight against it, we learned that the best way to handle change is to be ready for it. That, of course, doesn’t mean that we ignore the risks. On the contrary – the successful handling of “change” is knowing and mitigating the risks. In our everyday work we incorporate Agile practices of software development. We encourage our customers to look at requested changes from a “provided value” or “behavioral change” point of view. We divide them into smaller chunks and define MVPs. That way we can plan our work to deliver the value to the end user as soon as possible. In a short time we can validate new functionality in a real-life environment and react to feedback based on real usage.

IX. There is a world beyond functional changes

We have been working with some of our customers for several years. This means that we know “technical debt” all too well and we know how to handle it. Huge refactoring (AKA redesigning) that will fix everything is costly and from a business perspective – almost impossible to perform. We try to work in a way that will not increase the technical debt and if possible – decrease it. The war against technical debt is partisan rather than a big, decisive battle. When analyzing the functional change, we always think about enhancements that can be introduced to improve the system. When we see big obstacles, we suggest putting more effort (for some time) into eliminating one or two of the biggest problems. That way we can increase the velocity of the team or decrease the complexity of the system. We never try to solve all the problems at once. Of course, every suggestion is analyzed and agreed on with the decisive person on the customer’s side. 

X. In Agile we trust

Last, but not least. Skyrise is an Agile company. We believe that following Agile significantly increases the possibility of succeeding. Don’t get us wrong – we don’t think that Agile is a silver bullet that will magically solve all of your problems. However, we do think that by following the agile principles, finding solutions becomes easier. We are also very pragmatic in this area. We don’t follow only one agile framework (such as Scrum or Kanban). We treat them all as a toolbox and we choose the appropriate tool to do the job. Usually we apply the best practices from the frameworks that we think will work in a specific situation. After all, Agile is not about following frameworks. Agile is a mindset concentrated on following the ideas standing behind the Agile Manifesto.

In our opinion, the most important thing about the software development process is to learn (as soon as possible) and adjust. It’s crucial to periodically evaluate the way of doing things, determine the flaws, search for solutions and implement them. This can be achieved by planning and executing retrospective meetings. Doing so, we never make the same mistakes twice.

Simple, right?  And we know what you are thinking right now: “It’s just marketing jibber jabber. There is no way they can live by those rules”. Well… that’s fair. Just remember, that if you don’t believe us – you can always try us out by yourself

What are your opinions and golden outsourcing cooperation rules? Maybe you don’t agree with something? Don’t be afraid and leave your comment below. We are a group of smiling people (really! see here: and we will gladly address all of your doubts!

Ready to create better software?

We are constantly working on new interesting projects.

Maybe yours will be one of them?

Share This