Hi,
There is no doubt that in today's "Digital Economy," high organizational adaptiveness has emerged as a new competitive advantage. Today, the key capability of an organization has become generating, testing, and replicating innovative ideas more rapidly, more cost-effectively, and with less risk than competitors. Your business can become highly adaptive as well, and I am eager to assist in unlocking your company’s potential.
Who I Am:
I am a LeSS Coach, consultant, and software engineer. I have been professionally involved in building software products and helping organizations improve through the application of Lean and Agile principles since 2005. My experience spans various organizations such as Allegro Group (& PayU), as well as smaller companies including Uncapped, VRenetic, Finevare, and HRS. I have also worked with large corporations like ERGO, Orange, UPC, and CircleK. I actively promote the LeSS (Large-Scale Scrum) framework in Poland, an approach that facilitates collaborative large-scale product development. Additionally, I am a regular speaker at conferences, a writer, and I organize LeSS community meetings in Warsaw.
What Exactly I Do:
If your organization is struggling with collaboration among teams, groups, and departments; if you employ dozens, hundreds, or thousands of individuals, yet find that the pace of achieving results is sluggish; if you have tried the "Spotify" model or other turnkey solutions that have not lived up to expectations; or if altering course or seizing opportunities creates confusion, incurs high costs, and demands a significant effort, thereby diminishing the value delivered to your customers, then I am here to help facilitate change.
My role is to help you identify the root causes of the issues. I aim to expose the inconsistencies within the work system that create wastes and guide you in implementing changes. To be candid, this usually involves modifications to the organizational structure, policies, and consequently, people's behaviors and applied practices. The result of this transformation is an increased adaptiveness and capacity for your organization to deliver exceptional value in the market.
Organizational adaptiveness, often referred to as Agility, is associated with elements of the work system such as:
- Clarifying company priorities and understanding how to contribute to their realization, thereby eliminating overproduction, waste, and confusion.
- Empowering teams to autonomously focus on what is currently most essential for the company without micromanagement, reducing delays, effort, and frustration at all levels that arise from changes in direction and priorities.
- Streamlining decision-making processes, which leads to the reduction of delays and facilitates change.
- Implementing suitable engineering practices that accommodate frequent changes, enhance the quality, and expedite learning, discovery, and value creation.
- Cultivating a culture of information sharing and experience exchange to eliminate bottlenecks, decision points, and dependencies.
Collectively, these elements shape a learning organization that becomes a formidable competitor in the market.
How to contact me:
krzysztof.niewinski@procognita.pl
krzysztof.niewinski@gmail.com
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!