As part of the TIAS Management & Organization program, Polarising and the Dutch Portuguese Chamber of Commerce partnered to host a Workshop on the subject HR policies and the IT labor market challenges to this year’s TIAS finalist executive students of the Management and Organizations Master’s course in Business Systems.

The event took place on the 24^th of November at Polarising’s Lisbon headquarters and the day started with a welcome note from the TIAS management board, reiterating the importance of the initiative and presenting the results of a first assessement to Polarising.

After that, Polarising’s Netherlands Country Manager Yvonne Kubbinga gave a presentation on our business, portfolio and challenges, that was followed by a brief explanation of the workshop session that would next take place.

The workshop is the highlight of the TIAS Management Program, since it has the purpose of analyzing and discuss a specific organizational theme: this time it was focused on the current challenges Polarising’s HR face to attract and retain talent.

About TIAS and the Management & Organization Program.

TIAS School for Business & Society is a Netherlands international top-ranked business school focused on delivering executive education for professionals, managers, and organizations.

By cooperating with international partners, TIAS integrates specialist knowledge from other foreign business schools and promotes visits to organizations that can share their business perspectives on organizational management and best practices. About the session, Joke Bijhorst, Marieke Abbink, and Ruben Barten from TIAS agree that it was

“(…) a great experience; we had an interesting discussion with the Portuguese management of Polarising and our fellow Dutch students from TIAS. Together we came to new insights about working with the next generation!”

This is a statement of TIAS’s goal which is exposing executive students of the Management and Organizations Master’s course in Business Systems to an international context. Through their research they’ll be able to provide new insights and propose further actions that can be implemented by each of the organizations they meet with.

Polarising’s and CCPH partnership.

The relation between the Dutch Portuguese Chamber of Commerce and Polarising has been building itself since we started our direct operation in the Netherlands in 2019.

The Chamber of Commerce has been organizing study trips for managers and finalist students of the Executive Master of Management and Organization of TIAS Business School for many years. According to Marjon van Dinther, Director of the Dutch Portuguese Chamber of Commerce:

“TIAS has been our client for over twenty years. Besides organizing study trips for Management and Organization we have also been working with Health and Public management, as well as Education. We think that Portugal offers a diversity in interesting case studies and sectors, varying from the start-up ecosystem, public and nonprofit institutions to large corporations.“

The purpose of these sessions includes several meetings between the group of Dutch participants and Portuguese organizations from various sectors in the Lisbon/Setúbal region, with the purpose of:

• get an independent reflection from foreign managers from different sectors.
• discuss topics that are of interest within different management areas of an organization.
• promote the interaction between a diverse and qualified group of people.
• inspire action and collaboration between the students and company’s employees.

Being a technology IT Services company, Polarising positions itself as a strategic partner for nearshore operations at low risk. Our clients are international and mainly from Europe, Middle East and South America. The core of our business are people: it’s their knowledge, human skills, ambitions and motivations that interest us, so that we can reach to their needs and be prepared to offer them the right opportunity to start, especially for younger generations.

As the host of this session, Yvonne Kubbinga adds

““(…) what a great pleasure it was to meet the TIAS group. During the workshops we had an interesting discussion on how to improve our HR policies. Also, I enjoyed the feedback that the Polarising company values are really hitting the right nerve. Next to this there were some interesting ideas on how to improve, such as sharing our values during the sales process more clearly.

I guess this habit of making lists is not new. Perhaps because in contemporary societies we need to make sense of everything, to establish achievable goals that allow us to measure progress, providing some kind of control.

2020 is no exception: with the end of another year approaching, we are ready for a wrap-up and a new soundtrack! And what a year. It’s a well-known fact that this is a historic year, for the worst reasons. And not just to the music but all sectors.

Indeed, the impact that the Covid-19 pandemic will have is yet to be assessed. And its consequences are evident in all areas of our lives, from personal to professional.

Image: inspired here.

Track 1: Hapiness is a warm gun.

But honestly: was it really all bad?

So the entire world was caught in a quick and vertiginous roller coaster. What we expected from the future wasn’t even close to the result of the previous year’s balance sheet. But aren’t plans supposed to change?

As to what music is concerned, so many artists have reinvented themselves from their homes, giving live-streaming shows on Facebook and other plarforms. The RHI Stage was one of those inniciatives, that also allowed the audience to pay their work using the RHI app developed by Polarising.

Many achievements in science have been remarkable; in record time, a new covid-19 vaccine is being distributed as we speak. And the drop in carbon dioxide emissions over 2020, even unintended, is creating more awareness and effective policies around climate change.

Track 2: Don’t stop me now!

Although at Polarising we are used to remote work, it was hard not to get together. Especially for major events and monthly happy hours. There is nothing that better showcases our company’s culture like when we can meet, since we are dispersed by different clients and projects throughout the year.

But would you believe that we did it? Of course, considering such an unusual change of context we also had to change our mindset: if we can’t be physically in the same space, let’s make sure we’re all doing the same thing at the same time!

That’s how we celebrated (or shall I say: cooked!) Christmas dinner with Chef Chakall live from his El Bulo. Or toasted to the rentrée with the Checkpoint Kit we had delivered at each one’s home so we could make a collective toast via Teams.

On June 1st the office reopened complying with all the rules. But it was necessary to implement a process that allowed its access safely. So, we created Polarising’s Registration app.  Now we use this power app to manage the office capacity and everyone can go to República, if they choose so.

In this Polarising Best of 2020 we can’t forget births, we’ve welcomed many babies! The company expanded its business operations to the new Netherlands region, and many new colleagues joined our team.

We quickly reorganized the Champions Academy to a remote format, when they just had started a few days before. And we hosted two virtual Boardgames championships, as well as more of our internal knowledge-share TALKing Sessions than in a “normal” year.

Track 3: 1999 going on 2021.

So you see, there’s always a silver lining. Stopping to reflect is important and healthy: how else can we know what we’ve achieved and what we still want to achieve?

It’s time to turn the hourglass again and get ready to welcome the new year! But before that, did you do your best of 2020 list yet? While you’re at it, remember to put on some music

Ana Rebelo
Head of Brand and Communication

Every year we gather a group of smart IT ladies and I return inspired and motivated to continue the road to digitalization. This year we did the same and got together in the Netherlands to an entirely online web event.

In fact, this year’s Web Summit had an agenda full of empowering and inspiring women. Starting with the opening speech of Ursula von der Leyen, President of the European Union. She emphasized how 2020 is the digital decade by excellence, having forced governments and companies to advance years of innovation because of the Covid-19 pandemic.

Another amazing session was hosted by Apple VP of Environment Lisa Jackson and Nobel Prize Malala Yousafzai. They’ve spoken about Apple’s and Malala Fund research project on the impacts of climate change on girls and young women. And the power of education to build resilience to future crises.

It’s all a matter of perspective (or not).

It wasn’t the same. Having a full online experience in such an exclusive event like the Web Summit has its downsides. It’s easier to press pause; to lose focus and get distracted responding to an urgent email. But most of all, I truly miss the energy of meeting people. And to wander between the pavilions, amazed with everything I see and engaging with other companies.

Of course, there are also immediate benefits to an online conference. I can name a few of them that are mostly time saving: no queues to get lunch and jumping from one session to another very easily! Also, being online gave me the chance to “be” at the speakers’ homes. So, I felt inspired more on a personal level.

Undoubtedly, technology is now perceived as a game changer. The urgency to embrace technology is here to stay. And we need to adapt, people and companies, make the most of it, and find new ways of getting the job done.

I was impressed with many of this year’s Portuguese speakers and tracks, like Inês Silva from Portuguese Women in Tech, Outsystems’s CEO Paulo Rosado, João Borga from Startup Portugal, José Neves from Farfetch, and Luis Castro Henriques from AICEP. All of them with such successful stories about their tech companies and ready to embrace this paradigm change in their businesses.

Brand new year, brand new wishes.

Last month I started working for Polarising. We are used to work remotely, but normally we combine this with personal meetings. Which makes working together easier, more productive, and more fun at the same time. Jason Fried from Basecamp explained it well: remote work is not the same as replacing office work by online work.

Working remote should free up a lot of time for thinking and balancing our lives. It allows us to mature ideas and write them, share them strategically and only expect a call when there is something to discuss. But the synergies that we create by going to the office and discuss ideas it’s equally important, and crucial to a solid company culture and goal achievement.

I look forward to next year immensely. Web Summit and sneakers are already in my agenda. But I’m certain that we will learn a lot from this years’ experience and achieved new breakthroughs.

Yvonne Kubbinga
Polarising Netherlands Country Manager

This announcement is aligned with Polarising’s ongoing strategy of expansion, having already subsidiaries in the UK and Germany, and business development teams in Belgium and Spain.

Yvonne will be focused on leading Polarising’s operation and managing new business opportunities with clients and partners. She will work together with Renno Koopmans, Business Development Manager for the Northern European region, and an experienced team of expert software Developers and Agile Business Analysts in Portugal.

Passionate about multicultural environments, Yvonne Kubbinga is a result-oriented Technology Director with 25 years of experience in managing multidisciplinary teams, high-level operations, and software development nearshore and outsourcing projects.

She is also a Board Member of non-profit Dutch organizations, such as Pole 4 and Stichting OOK Begeleiding, providing leadership training for young people and supporting highly intelligent autistic people.

Quoting Yvonne: “I’m excited to take on this challenge and work together with a team of nearshore experts and technology professionals, like Polarising has. Not only will we expand our client portfolio, but we’ll certainly have fun doing it!”

You can contact Yvonne Kubbinga at yvonne.kubbinga@polarising.com
Renno Koopmans at renno.koopmans@polarising.com
or Polarising at info@polarising.com

Welcome to Polarising, Yvonne!

To be agile you must focus on several elements such as the continuous value of your product, the constant adaptability to changes in the requirements, the capability of delivery on a short term, the interaction between all the project actors, the end-users and the self-management competence of the teams, among others.

Well, now you kind of know what is to be agile… but do you know how to make sure that you are really doing it?

And please, don’t answer that you “just know” because you feel you are a “flexible and fast thinker” … This is not a job interview, and believe me, when you need to justify to the company board why Agile is the way to go you will need data, numbers, facts! Because information is power.

Be multidimensionally agile.

First you need to know what to measure exactly, and for that you must understand for which dimensions the Agile methodology looks for in a company and how those dimensions are impacted and, subsequently, how to evaluate or measure them.

There are four dimensions impacted by Agile and each one of these dimensions will be the platform to check different pulses:

Let’s start with Business. Here you will measure effectiveness by assessing how your delivery is reaching the goal. We could make a giant list of agile metrics, but let’s keep it simple!

Choose a major question instead: Are you solving the business needs? The Fitness For Purpose Score is a good way to check that. You must understand the customer’s purpose for consuming what you’re offering. Then, you can create the appropriate fitness criteria metrics. You can set this score, considering: Net Fitness Score [NFS] = % satisfied customers – % dissatisfied customers

Another valuable metrics for effectiveness are the Pirate Metrics: acquisition, activation, retention, referral, and revenue. Maybe you will encounter some products where some of these indicators won’t fit, just apply the ones that do. Check this cool illustration to help you understand these 5 steps really quick:

Image: Startup Metrics for Pirates by Dave McClure

Let’s now travel to the next dimension: Organizational, where you will measure efficiency. This is the moment to put your team under the microscope and evaluate their overall performance.

One of the most important agile metrics that will help you do this is the Lead Time: how long are you taking from “To Do” to “Done”? This is one of the easiest, simplest, and accurate metrics you can use, especially when you are supporting your tasks management with Kanban methodology:

Image: Kanban Board

You can apply the metric to the total time from the point of agreement to the point of delivery and/or to how long the tasks/features last in each phase. It’s also important to verify the Waiting Time (how long an item continues between the conclusion of one phase to the next one).

You should associate the Lead Time with others like, WIP (Work in Progress) and Throughput. The WIP considers what is “Ongoing” but also the tasks from “To Do” to “Done”. By attending to this you will help your team to focus on finishing the tasks already started before starting new ones.

The Throughput will tell you the average work units per time units. It will help you, for instance, to know how many items your team can deliver in a week and if that number is increasing or decreasing through the life cycle of the project (so you can identify either possible blockers and facilitators of their workflow).

Image: The Lead Time is improved by shrinking the WIP

Let’s now check the Technical dimension to see the excellency of your work. Meaning: does your team works fast, but has the result real quality?

The measures you use here are known and not exclusive of Agile: how many bugs do you have? How much of the product do your tests cover? And what about the infrastructure? Is it robust enough to support your product? Does your code have 15.000 lines that you just realized that aren’t used for anything?

If you work for an IT company and still need explanation on how to measure this, maybe you should rethink your career … just kidding! (no… for real, question yourself!)

For last, but not (at all) the least, we imperatively must look at the Cultural dimension to check the ecosystem. To be agile your organizational culture must be agile. There is no way to jump this step.

How happy is your team, the organization in general, the project participants? Is it even possible to measure emotions? Oh yeah! For instance, through Burnout Tests or the Happiness Radar, using just a simple white board where your team members can mark the areas they’re happy, neutral or unhappy about. Ok, it’s a little corny, but I’ll take my chances… just feel your team’s heart!

Image: Hapiness Radar

Don’t be just any agile-cherry on top.

As you can see you have many metrics to check up your agility (and we are just giving you a few examples), so please don’t go crazy and megalomaniac and start applying every metric you know every step of the way!

Last piece of advice, simply follow these two rules:

1 – Be aware of toxic metrics: don’t start measuring a team member or comparing teams. This will only undermine your environment. Promote collaboration, not competition.

2 – Take it easy, understand which metrics make more sense to your team/project/product and start your own agility barometer!

Now, you are ready to go.

Dulce Monteiro
Polarising Business Analyst

Contact Polarising for tech that works: info@polarising.com

However, the IT industry is still maturing and some of the management models in place are relics from fellow engineering areas, applied to the challenges of a fast paced, quickly evolving, and always changing world. IT professionals could drastically benefit from a management model suited to the industry reality, and that is where the AGILE methodology with SCRUM comes rushing through the door.

So, what is Scrum?
Scrum is a framework that can help you develop, deliver and sustain complex products. It consists on a set of roles, events, artifacts and rules that bind the framework together to achieve a continuous delivery with the highest possible value. It also gives you the ability to analyze the work that has been done and identify points of improvement for future developments and releases.

Who takes part in Scrum?
Scrum teams are given the ability to choose how to best accomplish their work, rather than being instructed by individuals outside the team. They have a set of elements whose combined expertise assures that goals are accomplished without depending on others outside the team.

This model is designed to improve flexibility, creativity and productivity, so this team should have a specific development team with 3 to 9 elements that combine a set of skills required to deliver a ready and shippable product increment.

The Product Owner is also an important element, because it manages the product backlog and makes sure the development team has a clear understanding of those tasks.

This team is headed by a Scrum Master, who is the servant-leader of the team and educates on the scrum theory, practices, rules and values. It also coaches other development teams and helps the organization to adopt the Scrum values.

Also, it helps the product owner making sure all development teams are in in-sync and aligned, understanding all together the goals, scope and priorities.

When does the Scrum team meet?
Events are an important part of Scrum; in fact, you have a short meeting every day and three more each week. “What?! That’s a bunch of meetings, nobody has time for that! I’m getting out of here…” Wait. All events in scrum are time boxed and optimized to deliver the maximum value in the shortest time. Here’s how:

• Sprint Planning. During planning, the work to be done gets decided and packaged onto an artifact called the Sprint. Sprints are time boxed and should contain fully analyzed tasks with a closed scope estimated from two weeks to one month.
• The Daily Scrum. This is the part where you stretch your legs! Daily scrum is a 15 minutes time boxed event, held every day with the purpose to inspect progress and remove development obstacles, while improving communication between them.
• Sprint Review. At the end of each Sprint, a review is held for showing the produced increment to the stakeholders, with the objective of collecting feedback and give input on additional features that can add value to the product.
• Sprint Retrospective. The cherry on top of the cake! This event is an opportunity to identify points for improvement and work on removing non efficient practices.

Going through this for the first time may seem like a hard process to implement. Maybe you are thinking about the cost of having a scrum master, or the hours spend on scrum events, but if you give it a chance you may discover a process to improve your teams efficiency and the relationship with stakeholders. At Polarising we are using the Scrum methodology every day and already having good results. Read more about scrum on the official scrum guide and give it a go.

Tiago Diogo
Software Engineer at Polarising

Is there a right and wrong approach for a specific type of business? First, let’s check each one out.

Point-to-point Architecture
Already in the category of legacy architecture, this was the most common architecture in the early 2000’s. It consisted in the integration of data from several applications, using a specific channel for each integration flow. This means an ever-growing number of channels and connections between systems, making it difficult to manage the Integration Platform.

Simple to design and implement, this type of middleware might be a good option for low scale integration scenarios where change is predictable. Otherwise, it’s not a recommend architecture, since it has high maintenance costs per each application added, leading to the redevelopment of each connector to each application. It was this lack of scalability that led to what it’s usually referred as a “spaghetti” architecture.

SOA (Service Oriented Architecture)
To face the challenge of scalability, SOA emerged as an approach that allowed to decouple all integrated applications by exposing their functionalities as services. Each service can then be used as a small building block to compose larger functionalities and systems, leveraging on a centralised Enterprise Service Bus and standardised messaging. This aims to ensure high service reuse, with easier governance and change management, since changes can be performed only on ESB-level and abstracted from other systems.

This type of architecture has become mainstream for the last 15 to 20 years in what concerns to integration and has allowed several companies to easily integrate their systems and those of external partners. But on its downside, SOA has proven itself hard to govern in not so controlled environments, creating similar services and wasting its reuse potential.

Governance requires the definition and enforcement of a strict set of rules, usually by an Architecture team or a SOA Centre of Excellence. This is something that most companies wrongly see as an avoidable cost, leading to an ungoverned SOA that can easily be also compared with a “spaghetti” architecture.

Microservices Architecture
This “newcomer” shares several characteristics with a SOA architecture, aiming to achieve some of its goals. And it does so with the promise of a simpler architecture, easier to govern, more scalable and better suited to the advent of cloud computing.

How? Well, it’s precisely here that you can find the difference between a SOA service and a Microservice. Where in SOA, services are seen as mere building blocks of one large platform/framework that can be used to orchestrate larger functionalities and processes, Microservices are completely independent entities that can evolve on different lifecycles and be developed in different technologies, also following a different sets of rules, scaled as needed, without impacting each other.

While this leads to a more flexible architecture that can easily scale and adapt to a company’s evolving needs, there is a growing risk of losing control of microservices and ending up with a set of unmanageable services, again resembling a “spaghetti” architecture – where have we heard this already?!

A few more architectures or variations could be named, such as an Event-Driven Architecture (EDA) or a Database-oriented Middleware (for which Polarising developed PortaTM, a Java-based software that allows the exposure of Stored Procedures as Webservices).

In the end, the often-unanswered question is what’s the best architecture. From my experience it all resumes to determine the best approach for each scenario. Although being the “next best thing”, a Microservices architecture is far from being ideal to every business. SOA is a proven architecture, suitable for most scenarios but it requires strong governance to evolve properly. And even a point-to-point architecture can be suitable in some small-scale scenarios, even though it has fallen in disuse.

It’s clear to me that only with experience are we able to access such scenarios and determine the best option. One should always investigate past projects for lessons learned, understand what best fits the next project/challenge and avoid following the “new buzz” just for the sake of being the latest trend. I could name a few companies that are always implementing the “next best thing” and end up with a large set of legacy integration platforms and a nightmare to manage in the future… But I won’t;-)

Hugo Pascoalinho
Polarising Consultant

Fortunately for me, I’m a Business Analyst and I’m part of the SCRUM team within my company. And from where I stand, a Business Analyst role is important regardless the methodology in use, especially in any software development project.

A SCRUM team is multi-disciplinary; it must include all the necessary skills to deliver each sprint. A Business Analyst can take on a role within the development team or play the role of Product Owner, depending on the needs of each team. I’ve been in both situations.

According to Scrum.org “A Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team.” This means his main goal is to deliver value and to do so it’s important to understand the customer’s business, its processes and needs, establish the main objectives and prioritize. Finally, using the time and budget available to deliver the maximum value with the help of the development team.

I can’t help but think that it’s the same definition of a Business Analyst and that on SCRUM the Business Analyst is the Product Owner!

After understand the customer needs, a Product Owner (Business Analyst in SCRUM) is responsible for:

• Feed the product backlog which is the artifact that represents the understandable object; it is what represents all the necessary changes to maximize the value to delivery.
• Identify which backlog items will bring the most ROI possible to the customer’s business, prioritizing the backlog items.
• Follow up with the customer on every interaction, so he can know if what’s being delivered is really bringing value and help him understand how to increase processes performance.
• Ensure that each item of the sprint backlog includes all the necessary information, so the development team can address all customer’s needs.
• Know how to say NO to the customer and the development team when needed, be realistic and make decisions.

You also hear that SCRUM has no functional specifications because the team must be agile. But does this mean that an agile team can’t grab a piece of paper and pencil and draw a context diagram, a process or an algorithm, to better understand what to implement? Is it required that the solution is in everyone’s mind to be an agile team? I’m sure it will depend on the needs of each project but for me it works this way:

• What documentation will bring value to the customer?
• In what way the development team will have better understanding of the job in hands?
• Documenting in detail will bring further value?

Only when answering these questions, I can decide on how to detail each backlog item. The specification of a functionality can be a user story, a flowchart, a state machine, an entity diagram, a use case, a picture of a paper drawing and so many other things. The Product Owner is responsible to analyse and decide what make sense and each situation.

When is clear that the Product Owner cannot deliver all specifications needed he could decides to include a Business or Functional Analyst in the development team. They can assist in product specifications tasks and even in the quality assurance process (specs, test specs and test execution). This means that whomever takes this role becomes part of the development team, having tasks assigned in each sprint. The detailed specification of a feature must be made in previous sprints prior to the feature implementation or even in the same sprint.

Same applies to the test process; it’s the Product Owner’s job to prioritize each task in order to maximize the delivered value, as well as the deployment team productivity.

By using SCRUM we’re able to iterate, delivering smaller chunks and getting feedback along the way on how customer needs should be addressed.

If we compare traditional approaches with agile methodologies, what are the main differences for a Business Analyst? According to Dave Saboe, the way to change the mindset of an Agile Business Analyst is:

• understanding that conversations matter – conversations are more important than documentation.
• expect change – In a traditional environment, you want to manage change. In an Agile environment, you expect change.
• Focus on customer value – Understand what the customer wants, his needs and exploring various options, being able to prioritize work based on that value.
• Do just enough just in time – Instead of getting a big design up front before we move along, we work in small increments doing just enough just in time.
• Have a team focus – I need to stretch my skills, step outside my role, and see what kind of support the team needs.  On an Agile team, we succeed or we fail as a team.
• Have a bias towards action – We do just enough analysis just in time and then take action.

Value… I’m always talking about value: SCRUM it’s about Value! Business Analysis it’s about Value!

Márcia Catarino
Polarising Business Analyst

• Learn about the customers business, analyze the current state/environment to discover the reason why a change is needed (what he really needs and not what he thinks he needs).
• Understand what could bring value to the business and define the way to meet that business need.
• Work with the technical team to build business cases with possible solutions.
• Support the definition of a possible architecture for the system.
• Elicitate requirements with the right stakeholders and confirm them before implementation.
• Define and model requirements that are possible to be developed.
• Evaluate the impact and implications of the proposed requirements and design changes before asking the development team to implement them.
• Support the development team to specify the technical solution, helping them to organize the documentation.
• Specify a solution with the right level of detail, so both the development team and the customer can understand the solution.
• Specify a solution in which each feature makes sense individually and integrated with the system overall.
• Be able to follow and to give support to the development team.
• Define the right tests to quickly find the defects that most influence the delivery value.
• Report issues with sufficient detail to reproduce the problem, consult the database, system logs, source code or even debug, helping the development team to understand the problem.

If organizations had someone with this profile in each project they could deliver more value to the customer with less development effort – are they aware of this? Well, Polarising recognizes that competent Analysts and testers are essential for projects to succeed. We make sure that the project delivers the maximum value t the same time we help customers to reduce  their development costs. At Polarising it is possible to build and develop these competencies in-house because we acknowledge their relevance to our customers. So, everyone here knows… Analysts really can make difference!