Individual Involvement Of Krzysztof Niewinski

Working at this Polish FinTech was one of the most important periods in my career as a Scrum Master and LeSS Coach. Thanks to the efforts of many people, we have built one of the most adaptive Polish companies that works in the LeSS Huge framework.

I joined the company in 2013 as a full-time Scrum Master and spent 2 years there. At that time, we had approximately 300 employees, including approximately 150 software engineers. My work was focused mainly on improving engineering practices and increasing the quality of Scrum in teams. I and many other Scrum Masters in the company believed (as ex-programmers) that technical excellence is a necessary element for multi-team work and organizational agility. At the time of my leaving in 2015, Greg Hutchings (LeSS trainer and coach) joined the company and for the next 2 years, Greg helped the company understand LeSS, including teams, CxOs, and management, and to see the impact of local optimization, broaden the product definition, and guided the company towards greater agility in delivering value to the market and pursuing new market opportunities.

The company changed from having many Scrum teams each with their own long-term backlogs and single team product owners into a unified and aligned multi-team organization (in a LeSS-Huge setup) :)))

Interestingly, for most of my work in the company, neither I nor other Scrum Masters knew what LeSS was :) We just wanted to build a highly adaptive company with a strong engineering culture. We took care of a number of improvements that largely prepared the company for the subsequent adoption of LeSS, which was supported by Greg in 2015-2017.


The most important experiments I was part of:

0. Change in the organizational structure

The first big change was a structural change, from technical component teams into value-driven (business and user-centric) teams. It is true that I was not an initiator of this change, because I joined the company during it. Nevertheless, 3 locations were created, with a total of 13 fully colocated, user-oriented, cross-functional teams. Unfortunately, we didn't understand the impact of a broad product definition back then, so each team received its own Product Owner and its own micro Product. Fortunately, every micro product was user-oriented. Mostly related to a financial flow. It was my job to maintain this change toward agility and deepen it.

1. Scrum

We took it seriously. With the org structure change, the culture changed. A very important element of this cultural change (that I was taking care of) was:

- devotion to developers of ownership of the code and decision-making about changes in architecture

- no architects or other technical roles external to the development team

- stop project thinking and stop doing projects

- start product thinking

- maintaining stable, collocated, long-lived teams

- having PSPI every single Sprint

- learning from every PSPI

The engineer finally has recovered an influence on how to build software :) Yey!

As I mentioned already, unfortunately, we didn't understand the impact of a broad product definition back then, so at that time each team got its own Product Owner. Of course, these Product Owners were more Business Analysts (which I understood much later).

Though perhaps this intermediate step was needed by the company to swallow the enormous change that was happening and prepare for the next step of broadening the product definition. Which actually happened 2 years after with Greg's support :)

To sum up, 13 Scrum Teams started using Scrum on their own, around their own micro-product (which luckily had trackable profit, its user group, etc.) in the shared code environment.

2. Collective code ownership

It was very important to allow each engineer to make changes in the code of any component. Because in the beginning it was scary ;-) the practice of pull requests and code review was established by (still existing) "component owners". As knowledge of components grew, "Component Owners" transformed toward "Component Mentors".

In the beginning, we used the 'Gerrit' nomenclature to denote the level of "trust" in the person changing the code:

'+2' meant someone who knew the component code well, could make changes themselves, had to do code-review, had to teach others about the component's code and design

'+1' meant a person who did not know the component code well and that person's changes had to be reviewed and approved by the '+2' person.

Interestingly, this led to the dynamics that developers tried to learn the code of other components (they were finally allowed to) to get the '+2' level of some dependent components. It was worth it because the '+2' level gave them the ability to code themselves, but also eliminated dependencies, delays for the team, and reduced overall suffering.  ;-)

To learn about the component code, we used a technique known in LeSS as the Traveler. A Traveler joined another team and worked with them full time for a Sprint or two, and then the traveler returned to his team with higher knowledge, thus reducing dependencies, and giving his team independence in carrying out the work.

3. One Branch

Another big change was that developers learned the Continuous Integration technique. Interestingly, it was not about the tool, but about the behavior. You code, you integrate frequently. Multiple times a day. Over 100 people have been changing the code simultaneously at that time.

4. One environment

Instead of the classic structure of environments such as: N x Dev env, Test env (in X different versions), INT env (in Y different versions), STG env, Prod env ;)))), we managed to reach an agreement that the most important environment in the company is one, common INT environment. The new change was integrated there every few minutes and after each change, automatic tests (int, e2e) were started. A company-wide policy of "Work Priorities for Every Engineer" was established:

Priority 0 - you rescue the production

Priority 1 - you rescue the Integration (INT) environment

Priority 2 - you do your Sprint Backlog work

After a few (dozen) weeks, we managed to catch the rhythm, and every day we had a new, shippable version of the product.

Thanks to containerization (Docker), each team could have its own temporary development environment, which sometimes made it easier to introduce changes.

5. Test automation

Naturally, with the above, Continuous Integration and One Branch forced the creation of deployment and testing automation. After each commit, light, quick tests were launched immediately, and every night, heavy and extensive tests (Sanity Checks) were carried out. In the morning we received a test report and if needed, and in accordance with the policy of "Work Priorities for Every Engineer", we (everyone!) first had to fix the INT environment before starting working on the Sprint Backlog.

Let me repeat this: After a few (dozen) weeks, we managed to catch the rhythm, and every day we had a new, shippable version of the product.

The company's management together with the Product Owners decided to deploy the new version of the Product on the production env once a week. It was a huge improvement because in the previous years the company had one deployment every 9 months…. this birth was always painful in the past ;-)

6. Zero Bugs Policy

At one point, we gathered all the bugs into one Backlog (one queue), and successively each team took some Bugs into Sprints. In about 3 months, out of several hundred bugs, only a few remained.



The above changes and many other initiatives allowed multiple Scrum teams to work independently on their own micro products and in the shared codebase. Once we got the rhythm, we started to see the problem of local optimization per team. We tried to get all 13 Product Owners to cooperate more, but it wasn't going well.

It was the end of my adventure in this company, in the middle of 2015. At the time of my departure, I understand from colleagues that Greg joined the company as a consulting LeSS coach and trainer.  He introduced LeSS, helping people in R&D to gain awareness of local sub optimization, improved delegation and trust, and broadened the understanding and use of agility into sales, marketing, operations, HR and finance. 

Over the next 2 years, the company has extended the product definition to the boundaries of the company. One product in the company was defined, one Product Owner, one Product Backlog, and initially 3 small Product Areas (which later turned into 2 larger Product Areas with a dedicated Area Product Owner each).

This Polish FinTech company today continues to do really good business in the world and I am proud to be associated with it!