2 March 2018Comments are off for this post.

5 reasons why nearshoring in Poland is valuable for the Nordic companies

The Nordic tech industry is expanding each day. No wonder, technology is playing a significant role in this region, both in private and professional life.

We are seeing more and more startups being founded in the Denmark, Sweden, Finland, Norway, and Iceland. More ideas are being born in the heads of young entrepreneurs, which are being supported by a significant inflow of venture capital.

But the technology is not only related to the young Nordic companies. Digitalization has become a more popular “word” in many large corporations, who are making sure to follow current technological trends to keep ahead of their competitors.

So, you have a vision for your new project and products. But who will build it? Well, developers of course, but then a much more significant problem starts to appear - How can you find them?

According to the Hays Global Skills Index 2016the Nordic region is facing a serious tech talent shortage. For example, Denmark is expected to fall short of 19,000 IT professionals by 2030.

Finland currently has an immediate need for 7,000 software developers, and according to the Finnish Information Processing Association, the country will lack over 15,000 skilled professionals by 2020, causing about €3-4 billion in lost GPD per year.

And let’s not forget Sweden. Statistics Sweden estimates there will be a shortage of 30,000 engineers by 2030 and it has already outpaced the USA as the country with the highest labour market stress level.

Based on Hays Global Skills Index 2016, Statistics Sweden and Finnish Information Processing Association

 

Developers in the Nordic region are becoming a scarce resource, and most companies are already feeling it. So how can we face this challenge? One word comes to mind: Outsourcing and more specifically Nearshoring. Recently published Whitelane Research about outsourcing in the Nordic Region states that the appetite for outsourcing is growing - over 44% of respondents plan to use this service more.

Still, as a Business Developer at Setapp from Poland, I constantly communicate with clients from the Nordics and some of them still hesitate to nearshore their development to Poland.

Let me provide you with the most important benefits of nearshoring in Poland:

1. Poland has the most talented developers in the world

According to the Hacker Rank Polish developers are in third place in the global ranking after China and Russia. Considering how large those two countries are, achieving such a result is a huge success. I recommend reading the whole Hacker Rank article because it also provides a detailed ranking of the Best Developers by domain. Polish programmers also dominate various other areas.

It makes sense to develop your project with the best, right?

hacker rank

2. Possibility to obtain professional expertise based on industry experience

When an idea for a product is born, then you probably ask yourself the question: How should we build it to make it successful? Poland is becoming a major European Tech Startup Hub and more successful companies are being born there from industries like FinTech, IoT, Travel, Media, E-sports, Healthcare and more. This confirms that Polish developers know how to create meaningful software and they will be sure to make your product successful too.

3. Talent supply

Remember at the beginning when I mentioned how Nordic countries are facing a severe tech talent shortage? 70.6 K, is the number of  IT students in the 2013/2014 academic year, according to GUS (Central Statistical Office in Poland). Polish tech universities graduate over 15,000 new specialists annually.

More students are aware of the benefits of becoming a developer, so their motivation to learn programming languages is increasing. As a result, the number of well educated IT professionals are growing. It gives the potential outsourcing partners the possibility to gain access to such a valuable talent pool.

4. Communication and cultural fit

Communication and a good cultural fit are one of the leading concerns of many Nordic companies who seek external help. Poland, Denmark, Sweden, and Norway share the same Time Zone CET, and Finland only has a one hour difference (EET). So there will be no need for evening calls.

Also, developing in SCRUM ensures that you are able to communicate with the development team on a daily basis. Regarding the cultural fit, Poland is an open-minded country with a lot of experience in doing international business, so communication is at a very high level. Moreover, 90% of developers speak English very well and many companies provide English lessons for them.

nearshoring in poland

5. Stable economy and similar law

After the fall of the communism, the Polish economy started to grow significantly. Poland has a very stable economy in Europe. So when you want to move your development to Poland, you don’t need to worry about an economic crisis, political problems, or natural disasters. Poland also adheres to all EU copyright and IP (intellectual property) directives. Due to these updated legal matters, there are fewer risks involved.

Conclusion

You may be surprised why I didn’t mention the low costs. Let’s face it - it is obviously an important reason but these days companies more often put the value of the outsourcing partner over the costs. Having a trustworthy tech partner from Poland who is ready to share his professional expertise can be highly valuable for you and for your customers

Still hesitating? Setapp is currently in long-term partnership with Egmont - one of the leading media groups in the Nordic region. But don’t just take our word for it, listen to what Mads Donkin, Egmont's Product Owner, has to say about cooperating with us:

testimonial egmont

 

 

Since such a well-known company chose to nearshore their development needs, do you agree it’ll help you too?

P.S. while you're here check out our blog posts on the best practices for software development:

 

nearshoting poland

1 February 2018Comments are off for this post.

How to effectively form agile teams in your company

Many of us work in software development companies that use agile practices and frameworks. For most of us, it works well, and we’re satisfied with the results. However, most agile frameworks are not complete methodologies, and therefore don’t include solutions to all of the problems. For example, how to form new teams, how to educate clients and how to organize your work as a PO etc. In this article, I will present my view on forming agile teams within a company.

To do this, I will assume some typical scenarios. We have a company with several projects on the go, and one of our new clients is close to making a deal. In this situation, we have to fully prepare for software development - we have to form a team. There are many ways to handle this process, so let’s find the one that will best suit our needs & capabilities.

1. Ideal Scenario 

First off - the ideal situation. Imagine you have a dozen agile developers who are good at self-organisation, are technically skillful and have advanced soft skills. If you have such a group, you can simply arrange a meeting with them and the new Product Owner, who will present the product vision and high-level requirements. Together they should be able to determine the necessary details, skills, and technologies, and enable the developers to self-organize into team(s), based on many factors, including:

  • their feeling of the ideal team size (which depends on the scope, possible parallelization of tasks, required time/budget and other factors)
  • required skill-set
  • other project-dependent factors (like available budget, special requirements etc.)
    In reality, most organizations/developers are not mature enough to follow this process in every detail. So we have to aid it in some way to make it happen.

2. The real world scenario

A more real-life scenario is that a group of developers (potential future team) will meet with a client/PO, but will be accompanied by a Scrum Master and/or other experts (like team leaders, seniors, technical managers etc.). They will aid the process by facilitating the developers’ decisions, suggest solutions, or, as a last resort, make decisions if none are made by any group members.

How much of the decision-making is done by developers depends on the maturity of the agile mindset across the organization. By that, I mean how skillful the developers are themselves (technical + soft skills), how much practice they have in self-organization, the level of trust inside the company (do managers trust developers’ decisions?), and how proactive the developers are at achieving goals.

Our goal is to make decisions with all parties involved. So in the future people will be able to make decisions for themselves. If somebody is affected by a decision then give them the ability to make a decision about it! They will be the ones who have to cope with the consequences, so why should we make sub-optimal choices for them? If we don’t trust our people, perhaps we should stop and think about it for a second. That can be a very limiting factor for our company growth and scalability.

While you're here, check out our latest job offers. We are still looking for a Scrum Master.

3. Agile organisations

If an organisation has been following agile practices for a long time, then it should already have several agile teams working on products. It’s safe to assume that some of these teams will be finishing work on the product sometime soon.

Keep the development team consistent

The best practice is to try to keep the development team composition unchanged, because every change will have a temporary negative impact on the team’s efficiency, due to repetition of the process of team forming & normalizing. It’s especially prevalent if we decompose teams entirely and assemble them from scratch with every new project - efficiency will be sacrificed by a huge amount, people will have to re-learn to work together (see: The Seven Wastes of Software Development) etc.

So in practice, you should be able to frequently re-use an already existing team, maybe with some small-scale changes to their composition. An existing team will be more efficient than a new one because:

  • people already know each other,
  • they have very good communication between them,
  • they know how to collaborate and what to expect from each other (as if they are one big family).

It requires months or even years of working together to achieve this. So if you already have it - don’t destroy it and try to make good use of it.

Focus on teams, NOT individuals

Agile organisations should really focus on the team, rather than making decisions about individuals as if they were separate entities. Idealistically, all people in the organisation should be well-connected as if they were one big team (“family”). In practice, interactions in such an environment will be very complex, and because we have limited time, focus & resources, we need to structure this approach by introducing a smaller concept of a team, which consists of no more than about 10 people. This approach can be of course scaled further into a bigger organisation, but that’s a topic for another article.

4. Anti-patterns

Like with all agile processes, we should try to avoid making decisions by people who will not be involved in the final usage of the product.

A typical anti-pattern here is to make behind-the-door decisions by the CEO, sales department or technical leaders etc… What usually happens next is that a group of people (the “new team”) gathers together and they shortly discover that decisions were far from optimal. So they quickly become frustrated. This may mean reworking things or create serious doubts about whether there was any point in using the effort already put in. This results in lower performance, higher cost, and eventually in less trust in management’s decisions and competences.

Summary

To help you remember the uppermost practices, here’s a short summary:

  • Build your teams with skillful/capable people from the beginning. I can’t stress this enough - if you don’t, it will be almost impossible to make up for it later
  • Take care of your teams - don’t divide them, don’t terminate them - cultivate them and help them grow
  • Try to make your decisions as close to the source as possible. The best decisions are made by people directly involved with their outcomes
  • During the growth of the team’s organisational skills: facilitate their decisions and help them, until you’re satisfied with results that they can achieve themselves
  • If all done right, in the end, you will have autonomous teams, which don’t require micro-management. It'll give everybody the ability to focus on other areas

P.S. If you would like to learn more about software development methodologies then check out some of our other blog posts, including:

How to effectively use timeline to plan and monitor your sprint

Is Planning Poker a perfect estimation technique in scrum?

 

setapp career scum

 

25 January 2018Comments are off for this post.

Four valuable practices for a better code review

Agile is all about constant improvements. We do retrospectives, we improve our delivery pipelines, we make our work more transparent, and we also do code quality improvements.

The most famous code quality improvement practice is code review. Code review is basically a process of verifying and improving your code quality. It not only helps you make your code better but also helps to educate your teammates. Code reviews can differ in many ways. You can use different tools to share changes and comments or you can just do a face-to-face review and fix everything in real-time.

The pitfalls of code reviews

Bad code reviews can harm your team and lower software quality if you don’t apply them properly. How come? Code review is a communication tool. People are fragile, and people make mistakes. Connect the dots.

If you are too sloppy, you will end up with messy code. If you're too rigid, you will break the team unity and create a stalemate. So, how can you overcome these problems? Here are some tips.

  1. Order your code review goals
  2. Be precise and descriptive
  3. Be motivating and give a good example
  4. Automate as much as possible

1. Order your code review goals

Code review will not fix all code flaws. You need to focus on the most important things.  What is the most valuable outcome of a code review? There is no obvious answer. For instance, a team may value discovering vulnerabilities over improving code readability. If you order these goals, you can focus on important stuff. I suggest writing down all the code review goals, and order and share them across the team. A list of goals may also highlight bad practices the team should abandon or things that should be covered by using another tool other than code review.

Here is the example of an ordered code review goals list:

  • Discover architecture issues
  • Discover performance issues
  • Inspect changed APIs
  • Improve code readability
  • Teach good practices
  • Find naming mistakes
  • Discover bugs
  • Discover vulnerabilities
  • Find typos
  • Find code style issues
  • Laugh over sb else’s code
  • Spend some time on sth else other than programming

You can agree on goals in many different ways. One of them is to create a stylesheet. For instance:

style sheet code review

2. Be precise and descriptive

You find a code issue or you may write a two-word comment to fix it. You may also describe:

  • What is wrong with the code
  • How does it impact the solution
  • How to fix the problem

Which approach is better? The rule of thumb is to answer these three questions. It improves developer experience tremendously. Developer experience is very important, especially if you work in a distributed team.

You could ask how many lines of code you can review on a single day. The intention is obvious: to stay focused. But we are not creating simple procedures these days. Our code is split into functions, classes, modules, and sub-applications. You can set a lines-per-day limit. However, it might prevent you from seeing the bigger picture. I suggest checking your code review goals and decide if a lines-per-day limit makes sense to you. If you run into a code review size problem try to focus on a single goal, starting from the top of the list.

3. Be motivational and give a good example

As I said before, a code review is a communication process. You communicate possible code flaws. Your teammate communicates if he agrees with you or not. Sounds simple, right? Unfortunately, it can get really messy when emotions get in the way. There are a couple of problems.

First of all, software developers are often tied to their solutions. You know this image, right?

richard's software guide

If you try to force your approach, you might end up arguing about spaces vs tabs.  You know you're right. Your colleague knows he's right. You're both wrong. What is the outcome of such an argument? Wasted time and higher tension for sure.

The second thing is that developers try to work like compilers by finding all the mistakes and waiting until your teammate fixes them. It tends to punish minor flaws while ignoring major improvements. How is your teammate suppose to know that he should repeat the very same approach the next time?

The last issue is also connected with the compiler-like code review. If the pull request creator won't fix all the comments, then you won't approve the PR. The code review comments should make the product better. The product gets better when the team gets better. If you push your teammates too hard they will start treating your requests as too rigid and ignore them. There is no point commenting on issues then.

The productive way of doing code reviews allows step-by-step improvements. You want to experience better CRs? Start changing your behaviour first. If you follow the rules below, you will share the positive and professional attitude across your team. The rules are simple:

  • Stop treating code personal.
  • Compliment good solutions.
  • Gradually improve your coworkers' skills & knowledge.

4. Automate as much as possible

A code review requires huge amounts of attention. Fortunately, there are lots of tools that can make your life easier. Many code flaws have been discovered by code analyzers. Some of them point out code style issues, whils others discover possible vulnerabilities or performance issues. Some of them find spelling mistakes and words that are not allowed in your public API code docs.

We can recommend a couple of tools if you work on .NET/JavaScript stack:

  • StyleCop.Analyzers - a tool for C# applications that searches for code style issues
  • ESLint - a tool for JavaScript code that makes JS syntax more strict (e.g. by enforcing semicolons at the end of statements)
  • SonarQube - a continuous integration tool that searches for common code flaws (duplication, vulnerabilities etc.)
  • custom .NET Analyzer- you can write your own .NET code analyzer that works similar to StyleCop.Analyzers but is focused on your custom needs

Remember that automation is more valuable if it works on all developers' machines as well as on the CI server.

Conclusion

There are plenty of ways to improve your code review. However, the most important thing is to be aware of your team and product needs and craft the code review implementation adequately. Always keep in mind that code review is a communication process - the better you explain it, the more value it gives. In order to reduce the scope of conversation, automate validation of repeatable stuff that the team have already agreed on.

OUR OFFICE

Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

OUR OFFICES

POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICES

PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICE

Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

 COMPANY DATA

Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICES

POL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.
VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICES

PL: Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

ISR: 220 Hertzel Street, 7630003 Israel

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

OUR OFFICE

Wojskowa 6, 60-792 Poznań, Poland
+48 506 798 998
office@setapp.pl

COMPANY DATA

Setapp Sp. z o.o.

VAT ID: PL7781465185
REGON: 301183743
KRS: 0000334616

PRIVACY POLICY

klacz
Clutch award badge
topdizajn
svg-image
svg-image
svg-image
svg-image
Instagram Icon
svg-image
svg-image
smart-growth
european-union

©2020 Setapp. All rights reserved.