Poster

Owner:Alexey Krivitsky

LeSS Adoption at Poster POS Inc. in Times of COVID-19 and War

Author: Alexey Krivitsky
Mentor: Viktor Grgic

Preamble (by Candlelight)
About Poster And This Case Study
Product Development Before LeSS
Designing the New Organization
LeSS Flip Event
First Twenty LeSS Sprints. Observations and Lessons Learned
The Path is the Goal
- P.S. Russian Warship, Go F… Yourself!
References

Remember to let her into your heart,
Then you can start to make it better.

“Hey Jude”, Lennon/McCartney (actually, just McCartney)

Preamble (by Candlelight)

December 2022 in Dnipro, Ukraine. The employees of Poster POS Inc are gathered to celebrate the company’s 9th anniversary of “simplifying business management” - that’s how they call their mission. The event is held by candlelight because due to recent (and often) shelling by the Russian forces, the blackouts have intensified.

Among many other things, Poster’s CEO, Rodion Yeroshek, is sharing some data insights. And it is unbelievable. Only during the first week of November during the wartimes Poster managed to onboard 100 new restaurants in Ukraine.

That’s what true resilience is. Everyone is proud and sure of the victory on both fronts: the business and the real one.

Looking back: the whole year of 2022 was challenging. On March 1 (a week after the full-fledged Russian invasion) Poster blocked the accounts of 10,000 Russian taxpaying businesses, losing 50% of its B2B clients.

2022 had more dark moments: Poster lost its profitability for several months, and being self-funded it had to lay off some people. And to increase adaptability in the face of extremely high uncertainty and an unclear future the remaining five feature teams switched to one-week Sprints.

It has been almost a year since I, Alexey Krivitsky, stopped actively supporting Poster in their LeSS adoption journey. As an org consultant I spent more than six months with Poster, its teams, and management, helping them embark on the journey of deep change, owning it and making significant reorganization. That change observed by me is the scope of this case study.

And now it is a year since we had parted ways and I am learning about their recent experiments and improvements. To me the rate of the systemic improvements they’ve done is unprecedented:

It is common to see the teams working together sharing high-value work. And sometimes the team boundaries are not clear. In fact, right after the LeSS Flip during the first LeSS Sprints described below all the teams were able to work on the critical set of related product changes together. For comparison, before the LeSS adoptions each team had had its own set of local priorities within their narrow scope of work (a component or a subsystem). Back then it was impossible to make sure all the teams focus on high-priority work all the time. That inability of the organization to deliver value and stay flexible was one of the key driving factors for the change described in this case study.
It became normal to see customers (restaurant owners and employees) on regular Multi-team Product Backlog Refinement sessions (PBR) and Sprint Reviews. During these workshops participants grew a shared understanding of customer needs and product changes by creating user story maps on the spot with developers and users in face-to-face conversation. For comparison: a year ago inviting a customer to such sessions was just unimaginable due to the high technical “how” focus of the meetings rather than a customer-requirements “what” focus. And 1.5 years previous such meetings hadn’t existed at all as there were no feature teams and shared multi-team work had been barely and rarely possible.
Recently, the teams started to run separate multi-team design sessions (“how” workshops); that contributed to making the PBRs 100% customer-centric and problem-focused “what” workshops. For comparison, a year ago, PBRs were confusing due to mixing the problem and solution contexts.
Systemic shared work on quality has resulted in that now, not more than 20% of teams’ overall capacity is spent regularly on customer support duty (compared to 50% a year ago).
Many, if not all, features are developed with built-in feature flags that can be controlled remotely (a year ago, that was only a dream of several people). This results in an ability of staged roll-out of features whose impact/usage metrics are being observed by the teams.
The core parts of the product are constantly collecting data from user behavior that can be analyzed in real-time, and custom dashboards can be configured when needed. A year ago, data collection was ad-hoc and most product changes were made without a way to measure their real impact.
And many more systemic changes.

It is hard to believe that only 1.5 years ago (before the summer of 2021), all the Poster teams were component-oriented and narrowly specializing with dedicated team-level backlogs and backlog owners per team. Back then, Scrum was seen as a team-level method with all the resulting dynamics.

So, how did it happen? What has created that wave of change?

This case study is a detailed story that highlights the key events and insights that led to the creation of the new organizational system at Poster. In this new system, there is a strong focus on the whole product, where constant systemic improvements are the norm. As a result of these deep organizational changes, the overall organizational adaptivity and resilience has drastically increased. This can be witnessed by the business success of Poster even during wartime.

About Poster And This Case Study

Scope Of This Case Study

This case describes a journey of a Ukrainian-based SaaS company Poster POS Inc striving for global optimization in product development with Large-Scale Scrum (LeSS).

The change process started around May 2021 with the C-level team attending an online Certified LeSS Basics (CLB) class and accepting the principal LeSS ideas: a single Product Backlog being learned about and worked on during a common Sprint by all cross-functional cross-component long-lived customer-facing teams – for high adaptability towards constantly changing business environment. In June 2021, they made a strategic decision to adopt these principles in the R&D department of the company. My engagement as an Organizational Consultant / LeSS Coach / Scrum Master lasted from May 2021 to January 2022 and is the scope of this case study.

This case study focuses on the following aspects of the LeSS journey:

Preparations for LeSS Adoption and LeSS Flip Event
These chapters will describe the driving factors behind the adoption of LeSS, and the process we followed to restructure and prepare for the first Sprint
Observed changes during the first 20 LeSS Sprints
Our key experiments, struggles, and wins presented in the most open and frank manner possible.
Remote work and LeSS
The challenges and workarounds in adopting high-bandwidth inter-team collaboration in a 90%-remote working environment due to COVID-19 pandemics.
Expansion to the Definition of Done
As an essential measure of the company’s progress towards perfection.

Inspiration and Appreciation

This case wouldn’t have been possible without my mentors and friends of the way. Special thanks to Viktor Grgic being my mentor in writing this case study.

I’d like to thank the entire LeSS Community (and, of course, the Candidate LeSS Trainers discussion group) for raising our bar for real change.

Company and Business Context

Poster POS Inc. is a cloud-based SaaS automation for small-to-midsize businesses in the hospitality industry, also known as HoReCa (Hotels-Restaurant-Catering).

The company was founded about 9 years ago (as of writing this case in 2022). It was started in Ukraine as a pivot from another business in the domain of the discount marketplace. The story goes that while integrating discount handling with different restaurant management software, the Poster founders-to-be realized how badly the restaurant domain was automated. They decided to pivot and enter the niche: automation of the end-to-end lifecycle of restaurant businesses.

The small- to medium-sized companies operating in the HoReCa niche provide a big opportunity for automation services, especially in developing countries, like Eastern Europe and Latin America. This is true for several reasons. Firstly, small cafés are looking for effective and easy-to-use, plug-n-play solutions to automate their customer service and the back-office processes. Secondly, in the developing marketing, where the government is constantly fighting with tax avoidance, there is a lot of constant development in the field of fiscal legislation. And this flow of changes is bringing in a steady burden and overhead for the businesses. As an example, sending just-in-time digital receipts to the tax authority for every client transaction (digital fiscalization) became mandatory in Ukraine in 2020. That has resulted in a large demand for modern, easy-to-use digital solutions (in contrast to the old hardware registers that can be seen in supermarkets).

Yet, fiscalization is just one of many processes made easy for businesses by Poster. The vision of Poster is “simplification with automation” of the entire set of business processes (in the HoReCa niche, for a start), so they can be “administrated from a pocket”. More on this – in the Defining the Product Broader chapter below.

In 2021 (right before I joined) the company had just survived numerous COVID-related lockdowns on its main markets and had 190 employees with around 50-people in product development. The company has surpassed 20’000 B2B customers (making it a ratio of roughly 90 customers per employee) and with over 1.2 Million restaurant checks processed per day.

COVID-19 and Remote Work

The location of the Poster’s head office is in the beautiful city of Dnepr in the southeastern part of Ukraine. Throughout the company’s history, they were hiring only in the head office. But during the pandemic, they changed the model and started to hire remotely as well. So by summer 2021, there were already several developers who had been hired to work remotely and who have never met their colleagues face-to-face. And that was the direction the company was heading to – a so-called hybrid mode. A mix of on-site and remote work.

Looking back at this decision: those remote employees were the first ones to be laid off, when the company faced a temporary crisis due to the war in 2022. Doesn’t that illustrate how loose the human connections are between the people when they don’t work face-to-face?

Already back in 2021 as of the start of the LeSS adoption, the hybrid mode of work was already bringing challenges. But due to the lockdowns and the urgent need for change, the preparation, the LeSS flip, and the first Sprints could not be done fully onsite. More on the challenges of remote work in the case study: Colocated, Remote, or Mixed Teams and Remote Meetings and Multi-Team PBRs.

Product Development Before LeSS

The following chapters describe the company’s work mode before the introduction of LeSS and the key driving factors for the change.

Component Development before LeSS

Before LeSS at Poster, six to ten teams were operating at the level of components and subsystems. They varied in size from 2 to 12 people based on the size and complexity of components they worked on. Sometimes, as a reaction to some urgent business needs, temporary project teams were formed.

Some examples of the teams before adopting LeSS:

A team for a restaurant-check-printers subsystem taking care of the hardware- and firmware-related aspects of fiscalization (producing and printing fiscal checks)
A team for a restaurant-stock-handling subsystem enabling business administrators to manage the stock and their supply chain
A team for a website constructor, allowing clients to create their white-labeled websites with online menus
And other specialized teams with a similar relatively narrow focus

Being a developer in one of such teams, you typically work in one or several git repositories, treating that piece of code as your teams’ codebase. Overall, there were over 40 different repositories owned and maintained by different teams.

During my first encounter with the teams at Poster, I considered them to be pure component teams. Later, after learning more, I have figured that some of them were somewhat more advanced in terms of the Feature Team Adoption map (see below). While some teams were purely built around a single component, others were capable of building specific customer requirements within the product subsystems (e.g. adding a QR code to a check, changing the way taxes get calculated for alcohol drinks, etc.).

As the illustration above depicts, before the LeSS adoption, the teams worked within a given subsystem/component (the vertical axe) such as fiscal operations, point of sale, website constructor, etc.

That work (on the horizontal axe) included activities from analysis to design, coding, and component/subsystem testing. Test engineers, who were spread across the teams, occasionally got together to perform product-wide system testing. There were no separate testing or architect groups. But there was also a single visual designer and a technical writer “shared” by all the teams when needed. An independent two-person ops-team was also there, taking care of the cloud infrastructure.

The teams, in most cases, solely owned code repositories and possessed limited domain knowledge. Due to the modular system architecture, often, the subsystems could be released independently of each other. Isolation of the teams over time resulted in various languages, frameworks, automation styles, branch practices, and release tactics used applied at the level of a specific code repository.

Those painful differences and unnecessary added complexity became obvious once the cross-component features teams started to work across different code repositories during the LeSS Sprints. Those conflicts drove the technical improvements, standardization and simplification. See Engineering Community and Pull for Engineering Practices.

Product Owners at Team Level

Historically at Poster, Scrum had mistakenly been seen as a team-level framework, so most of the teams before the LeSS adoption had its team-level Product Backlog and a team-level Product Owner.

To avoid any confusion with the (real, scaled LeSS) Product Owner for the entire Product, in this case study the role of the team-level Product Owner will be referred to as a “Team Output Owner” (or TOO for short):

Video: Dysfunction of Team Product Owners — Misconceptions of Product Owner on Youtube

The TOO role is inspired by a widely spread in the industry. At scale, this leads to teams who in fact work on the same product pulling work off different priority lists, having their own focus and narrow scope of ownership. This inevitably results in suboptimal results at the scope of the whole product, such as duplicate code, bad user experience, lack of learning, etc. This is the opposite of what we are aiming for in LeSS being Scrum applied at the product level, with multiple teams striving for global optimization.

Scrum’s original idea of product centricity (via a single Product Owner and a holistic Product Backlog for the entire product) is diminished by an organizational design with TOOs. Such an organization breaks down into silos – organizational pockets each working off their locally prioritized team backlogs. In such a fragmented organization due to decreased transparency and high information scatter, it becomes hard to see the bigger picture and make decisions that optimize global concerns. Lacking a broader understanding of the product, busy-ness and the velocity of individual teams become key metrics that drive the fragmentation and segregation in the company further and more. With time and size, the barriers between the teams grow higher, increasing misalignment and the need for inter-team coordination. That coordination gap typically can’t be filled in by teams themselves (due to a lack of understanding of global concerns and lack of global focus) so external-to-team managers-coordinators are introduced to manager inter-team interactions.

Eventually, because of the forementioned dynamics, organizations that apply Scrum at team-level tend to get more complex and slow, diving into a vicious cycle of adding even more roles to deal with the surfaced problems. But one negative dynamics triggers another and another way, eventually creating a very complex net of causes and effects. The next chapters highlight some particularly important ones that were affecting Poster, still being a relatively young and small company.

OKRs and Contract Game

Poster is a company of unique inner culture, a great spirit. But despite everyone’s wish to work closer together, ostensibly some invisible forces were pulling the teams away from each other.

Educating everyone is the first recommended step in a LeSS adoption. And over the course of several months of preparing for the LeSS Flip, it became apparent to many team members and managers during the numerous trainings, workshops and informal discussion, why the teams were unable to work jointly together on customer features and why their workload was unbalanced, causing bottlenecks and waiting.

People behave the way the system allows them to, and the org structure and processes at Poster before LeSS didn’t allow for tighter inter-team collaboration. Due to narrow product knowledge and different focuses, the isolation of teams only grew over time. Each team was busy working off locally prioritized backlogs, but while everyone was doing the best they could, the overall product development system of the company showed the quality of being slow: slow at delivering customer value and slow at reacting to the changed needs of the markets.

As a result, occasionally, the management had to form temporary project groups by pulling developers out of their teams. That was the only applicable method at hand to react to some urgent changes that none of the teams were capable of solving alone. Interestingly, it was also fun to be a part of those temporary initiatives, as you could feel the importance of what you were doing and could really make an impact! Later, after changing the system and adapting the LeSS ideas of a single Product Backlog and feature teams, all the teams could feel the same, all the time. But before that, in the component teams’ era of Poster, periodic reorganizations were one of the key management tools helping to address some market emergencies.

One can conclude that the pre-LeSS product development system at Poster was not optimized for shared Product Ownership. No one but the CEO saw the bigger picture, as everyone else was focusing only on a small part of it.

To compensate for that, the CEO of Poster used top-down objectives to help organization focus on what was really valuable and important. Those objectives then were taken into the consideration by the TOOs when creating and re-ordering items of their teams’ backlogs.

Although the OKR technique, in theory, can drive positive dynamics of transparency and collaboration, I was observing how it contributed to the issue of lack of ownership and exerted pressure onto the teams that were already stressed.

The following diagram describes the part of this dynamics: how Scrum applied at the team level, introduction of team-level backlogs and owners negatively contribute to shared Product Ownership. And how this makes management unwillingly fall back onto the “proven” methods of top-down decisions, pushed down deadlines and control - the only methods that seem to somehow work in such a disintegrated system of local concerns.

Poster had quarterly product planning cycles driven by OKRs. From the systems thinking perspective, such a process add-on is a quick-fix aiming to minimize the negative tendencies of local optimization individual teams working off their backlogs. And despite some positive aspects of increasing clarity on the company’s high-level ambitions and goals, OKRs, in my observation, make product management much less direct.

OKR method re-introduces the “management by objective” (the 11th out of the 14 points of Dr. Deming was to eliminate it, see References. Using OKRs contributes to replacing feedback-driven and incremental development with big ambitions and quarterly deadlines.

At Poster, the objectives of some OKRs were set as pure goals and the teams had to come up with key results as specific product changes. Other objectives were formulated as scope rather than goals. But in any case, once the key results are formulated and set, they all tend to be seen by the teams as fixed scope. And then the monthly and quarterly OKR reviews drive the fixed time aspect of it.

Management via fixed-scope & fixed-time projects (no matter the modern terminology) in software development has a strong negative effect on the product quality. And it also contributes to creating an internal contract game where the business orders work from the R&D, as per the cause-effect diagram above.

See the next chapters for more analysis on the quality aspects of product development at Poster before LeSS.

High Defect Rate

I was told that historically, the company has been having a relatively high rate of product defects, and it has been eating up a significant portion of the development capacity. When talking to the developers and managers about that, I heard numerous (superficial) explanations for that. For instance: many people correlated the high defect rat with the high complexity of the product domain. Following this logic, the defect rate in even more complex domains (i.e. rocket science) is skyrocketing no matter the intellectual efforts of putting it down?

Indeed, the product domain of HoReCa is relatively complex due to the number of external endpoints and various business rules: the tax department, external accounting systems, etc. But such a plausible correlation (low product quality to complexity of the domain) isn’t actionable: it serves as a mere excuse and offers no improvement direction.

Some people at Poster communicated another explanation for the high defect rate: “at Poster, we are trying to provide the best possible customer experience, so we are reacting to all kinds of client issues, thus having to spend a lot of time on them”, they said. Yes, Poster, like any other young and self-funded company, is heavily dependent on the satisfaction rate of its clients – a prerequisite for product-led growth and long-term success. But again, it doesn’t drive the improvement thinking.

Of course, it is unlikely that there is a simple explanation of why the defect rate was that high, for otherwise, the company would have already resolved that issue. But what’s more insightful than looking for simple explanations is to try to understand the system dynamics.

What was causing the defect rate?
Was the defect rate growing or decreasing over time?
Was there any seasonality in the data?
Were some delayed effects that contributed to the issue and were naturally hard to spot?
Were there any vicious cycles (reinforcing loops), that were making the things worse over time?
Were there any structural organizational elements in place that made the engineers exhibit some detrimental behaviors and ignore the quality problems?

The following chapters cut through the complexity of the matter by highlighting key aspects of the system’s dynamics at play.

Internal Product Complexity

Developers under pressure are prone to look for easier and quicker solutions.

The following diagram below depicts these dynamics:

Systems Model - Pressure and Contract Game

The above-described “contract game” (caused by the OKR review cycles) created pressure on the development teams with fixed-scoped thinking. Being under pressure, developers tend to cut corners, think more short-term - skip applying well-known engineering practices that make things easier over time for saving time now to meet the looming deadline. Eventually, those small, mostly invisible actions will accumulate and increase complexity of codebase over time. Eventually having a delayed negative impact on the overall development speed (aka feature velocity) and hence worsening the ability of the R&D to meet the deadlines.

Systems Model - Pressure and Contract Game Cycle

Such a dynamic describes a reinforcing loop (a vicious cycle) where over time the pressure on the developers will contribute to slower speed that in its turn will also make the pressure grow. Furthermore, the ever-growing product complexity and rushing results in developers making more mistakes (even when applying the “fast and quick” changes).

These and other factors lead to deterioration of the overall production system. As a result, Poster, having less than a 10-years old codebase, was constantly spending around 50% of its development capacity on critical product maintenance instead of adding value to the customers.

Engineering Practices

There is a common belief in the industry that teams with narrow code ownership (e.g. owning components or microservices) will take a good care of their code better. In theory, this is plausible, as owning something often results in taking care of it.

However, as observed in software development organizations, component teams tend to produce low-quality software. This is counter-intuitive for many managers who advocate for component team organizations. One observed reason is that component teams typically have low-quality standards. This happens because they are not getting familiar with other parts of the codebase (owned by other component teams), hence having a lack of references to higher coding standards and good engineering practices. That was also the case as Poster. Different teams used different approaches to designing, coding, testing and deploying their pieces of the system. The spread of good practices was impeded by narrow code ownership practices.

To make things worse: as component teams keep working on the same portion of code for a long time, they have a good understanding of it, can remember what it does, and hence are less likely to work on improving its comprehensibility and maintainability.

This dynamic of component team organizations makes systemic, long-lasting improvements to the overall codebase less likely, despite the good will and the efforts of the management to create a high engineering culture.

The following expansion of the cause-effect diagram depicts how component teams contribute to the ever-growing complexity of the product.

Product Stabilization Period

At the beginning of the summer of 2021 (a few months before the LeSS adoption) Poster management decided it was time to pause adding more features and focus on stabilizing the product. A high-level goal and a metric was to bring down the number of product defects. Indeed, if teams’ velocity keeps dropping, running a company-wide product stabilization initiative sounds promising.

For around six weeks, all teams paused any feature development and tried to close as many major sources of defects as possible. After those weeks, the flow of defects improved slightly. Some root causes of major bugs were found and eliminated, some portions of code were rewritten, critical auto-tests were added. Yet, the bug flow remained high, causing a lot of development capacity to be wasted on bug fixing. There is no shortcut in recovering from low quality.

Although product stabilization periods increase product quality, they cannot be seen as systemic improvements as they don’t change the habits and the overall dynamics. On the diagram above, the relationship of the variable “frequency and duration of stabilization periods” to the “internal product complexity” is marked with a “QF” notation, meaning a quick fix, something that works but doesn’t change the system.

An “interesting” unexpected side effect of the introduction of product stabilization periods, where feature development is paused, is that they reinforce the “feature hunger”. The pressure exerted onto the teams is likely to go up on once they resume working on the customer features, thus reinforcing the same negative practices that had created the need for the stabilization in the first place.

The later chapters of this case study describe how the structural changes (within the LeSS adoption) systematically improved this situation.

Quality of User Experience

But it was not just the internal product complexity and the rate of defects that were eating up teams’ capacity. When the teams are rushed, they don’t just produce worse code, they also make worse decisions, that affect the easiness of using the product - the user experience. As the result, the customers misunderstand, misconfigure and misuse the product features, and then ask for help. In its turn, a high flow of customer issues and feedback adds more load onto the customer support and then onto the R&D teams, eating up their capacity even more.

One particular related observation at Poster was that many product features, once shipped, have never been significantly improved afterward. Thus staying forever in what I call an “MVP-limbo-state”, offering minimalistic and unoptimized solutions to customer needs.

Such a dynamic is not uncommon in the industry. It can be seen in so many places that the rather positive term “MVP” (coined by the Lean Startup movement) has a very much negative connotation these days.

So, what is preventing a product development organization from continuously improving its key asset – its product, based on customer feedback?

Let’s recap the dynamics that we’ve analyzed so far:

Because the rate of introducing new features is low and the appetite for new features is high (see the diagrams above), the product management creates ambitious product development plans (feature roadmaps). Those plans are then pushed them down onto the team-level Product Owners (TOOs) and teams.
Because of the lack of decision-making power of the TOOs, they have no choice but to execute the received plans and respect the given deadlines (usually guided by quarterly/yearly set objectives).
This results in a dynamics known as a “contract game” – where business orders work from the R&D with fixed scope and deadline.
Therefore, the TOOs and the teams find themselves in a constant rush to build and ship new functionality to satisfy the “contract”.
The cause-effect diagrams above illustrate how such pressure makes developers cut corners, lower their engineering standards, and eventually worsen the codebase (increasing internal product complexity).
Periodically run “stabilization Sprints” don’t change the overall dynamics and the internal product complexity increases, making development slower and harder over time.

And there is another aspect to this dynamics - it is not just the internal product complexity that is growing. The rush to push more features faster also makes TOOs and teams start working on the next things sooner, without having the time to receive, digest and properly react to the customer feedback.

An example:

Once an MVP of a feature (F1) is shipped, a team shifts to the next thing on their list (F2).
When customer feedback on F1 is coming in, the teams are already in the middle of building something new.
Therefore, that valuable customer feedback on F1 is seen more as a distraction, loss of focus and damage to the roadmap.
Some pieces of the feedback cannot be postponed and requires immediate team’s interventions for fixing.
Other pieces of the feedback that can be postponed got collected and stored for later, typically as new Product Backlog items (F1 v2).
This impedes the ability of an organization to constantly improve its product.
And the habit of shipping half-baked solutions gets into the company’s DNA.
An internal side effect: an ever-overgrowing Product Backlog with “F1 v2”, “F2 v2”, … that is getting harder and harder to manage.
An external side effect: customers unsatisfied with the perceived quality of the product (user experience), they complain, increase load on the product support & teams, lose loyalty and eventually look for other solutions.
Despite everyone being busy working, the pressure to ship more features and improve the product quality grows, making developers rush, cut corners or put in overtime.

The cause-affect diagram below depicts the core aspect of this dynamics.

Overall Development Capacity

Because of all the listed factors and dynamics, by the time of the LeSS Flip at Poster, around 50% of development capacity had to be spent on product support – fixing customer-facing and internal product issues.

See the entire cause-effect diagram below:

Quotes from Employees

Below (and throughout the case study) are quotes from team members and management representatives on the situation at Poster before LeSS.

Alexander Hohol, a full-stack developer:

In Poster, cross-functional teams are formed around the parts of the product. For example, I work in a team that is engaged in the internal structure of our point of sale. We never work on other features, but only on the things within our field of ownership and expertise.

Yuliia Kastierova, a QA engineer:

When one of the QA engineers goes on holiday, the other QA people have a slight fear of not being able to help that team due to the lack of knowledge in a given component. Quite often, it is necessary to postpone product releases until the tester, an expert in the desired topic, is available again.

ILLIA Kovalchuk, Head of Engineering

In order to start working on something new that was requested by the business, it was necessary to create a dedicated team for that sole purpose. During the lockdown of 2020, we had to pull 6 out of 45 engineers to be able to start solving the things that the company’s survival depended on. That was not sustainable.

Designing the New Organization

Optimizing Goal

Digging into the company’s history, it came to my knowledge that a few years before the LeSS adoption, there had been a Scrum-inspired transformation from a pure component team structure to more subsystem-oriented and somewhat cross-functional teams. This change had been facilitated by the Head of Engineering, ILLIA Kovalchuk, who got the inspiration, in his words: “to implement real Scrum with real cross-functional teams” after attending an introductory course on Scrum some years back. That change led to some positive changes, e.g. testing and automation engineers joining the teams.

Though that change was a step in the right direction, it hadn’t yield significant impact on the businesses as the development focus was spread too broad and too thin. By 2020, the leadership team was searching for a model that would allow teams to work together on what was important at any moment of time and would allow faster and cheaper change of direction.

During the pandemic, as the external business environment was undergoing radically changes, the management at Poster had a constant challenge of keeping teams focused on working on shifting priorities. The R&D was unable to react to changes quick enough, as each team had a subset of skills and had the intention to keep working on what was in their narrow field of ownership (i.e. a component, a subsystem, or a feature set). The quarterly OKR alignment cycles were not enough to make the organization change its direction at the necessary speed.

As described above, for some months in 2020, the management tried to address changes in priorities as focused projects by forming temporary “mission teams”. That experience demonstrated that despite some success with that project-oriented approach, the entire organization was still lacking what was needed by the business – an ability to adapt to changes in priorities with ease and without management interventions. The focused projects had to be inspected, canceled and reorganized every time some new significant changes to the product strategy happened. From the organizational perspective, project management was expensive, slow, and time-consuming. And from the developers’ perspectives, it was interesting and fun, as developers have intrinsic motivation to work on something of high value, visibility and impact, so didn’t mind those changes. They loved learning new things and being challenged.

In search for a way of working that would allow higher adaptivity, in May 2021 the Head of Engineering brought a co-founder/CEO (Rodion Yeroshek) and the CTO at that time (Denis Ubozhenko) to my Certified LeSS Basics (CLB) course. And the promise of LeSS (see Why LeSS on less.works) sounded very much was they were looking for:

Being able to cheaply and easily support changing direction in order to work on the continuously discovered highest value at any time: value delivery + flexibility.

The management team at Poster understood the necessity of reorganizing towards cross-functional cross-component customer-facing long-lived feature teams (see Feature Teams on less.works) working off the single Product Backlog in order to increase the adaptability of the organization.

The perfection vision of being able to change the direction of the entire product development organization simply by re-ordering items on the Product Backlog, and hence letting the existing teams learn that new work - that seemed like the right direction for Poster. The management overhead of resource management and constant reorganization would be eliminated. And the freed up energy and skills would be used on growing organizational capabilities and customer value, not on managing projects and specialists.

Owning the Change

Following their inspiration from the LeSS class, the top management set the first official message at one of the company gatherings. The message was that they would like to use LeSS to increase organizational adaptability: they want to move to a model where Scrum is applied to the product level, in contrast to existing implementation of team-level Scrum. They also made it explicit that before any change would happen, everyone would have a chance to learn the topic sufficiently enough to be able to judge for themselves if this is a good idea.

My reaction as a coach to such loud LeSS announcements is two-fold. On the one hand, I think it is important for people to understand the direction and start learning about that domain (in this case, the materials at less.works, published case studies and the LeSS books). On the other hand, such statements may create a false expectation of some magical thing that dissolves all the long-time company problems overnight.

To make org change last and be of high quality, it is known that people must own the solution, not rent it. So, my challenge as their LeSS coach was to explain the thinking behind LeSS without letting people fall into the trap of “there are ready-made solutions, we just need to trust and implement them”. Luckily, the management team didn’t oversell LeSS and kept people intrigued by doubtful - the right place for the coach to introduce the thinking tools.

The following quotes from the team members and the management team show the level of anxiety in the early days of the LeSS adoption.

A photo taken from one of the employee camps where the need for change was discussed the first time and LeSS was mentioned.

Alexander Hohol, a full-stack developer:

Personally, I got the idea for LeSS from the very beginning. I really liked that mode of work and tried to be a LeSS evangelist in my team.

The main concern I heard was that people were terrified of learning the most difficult parts of the product, such as fiscalization, for instance. There was a feeling that it would be impossible to figure it out. There was also a fear that we would drastically slow down or just plunge into pure bug fixing.

Yuliia Kastierova, a QA engineer:

Poster has a big and complex product. And of course, there were worries about how we would be sharing knowledge. Especially, in areas where narrowly focused expertise was required. These were such areas as fiscalization, work with franchises, etc…

The key questions we had were:

How can one capture a lot of new information by staying productive?

How long would it take to adapt to the new processes until they stabilize?

Who would be the people in my new feature team?

ILLIA Kovalchuk, Head of Engineering

The main message that was given to the teams at the time of preparation was: “you have some time now to bring your components to the most stable state possible so that other teams could start working with them (improve design, write documentation, fix bugs) – do what’s necessary”.

The main topic that bothered me was: how will we manage product maintenance with feature teams that hadn’t had any prior experience with some of the components?

Key Ingredients for Change

It is worth saying that I like smallish companies. The ones that are small enough to get everyone together quickly (mentally and physically) and, at the same time, already a little too big to start experiencing the growth pain.

The other thing I am looking for in my clients is the need for real change. Dr. Kotter’s 8-step Process for Leading Change has the “Sense of Urgency” and “Build a Guiding Coalition” as the first two steps of the change process. I have seen companies failing by trying to make a change without these key ingredients. Poster had had these two things in place at the start of the LeSS adoption.

Another thing that struck me very positively during the early conversations with the management at Poster: they insisted on educating everyone in Scrum, LeSS, systems thinking and the change management before proceeding with the reorganization.

LeSS adoption guides are strong on the need to educate everyone, but I was positively surprised that this idea didn’t come from me or from the outside - the management at Poster full-heartedly understood this principle.

Looking back at this decision: the fact that we had educated everyone before making any restructuring had significantly increased the quality of the adoption. See Getting Rid of Product Areas chapter for more details on this learning.

Educating Everyone

The leadership team had insisted that before any structural changes, everyone affected must be educated in LeSS. They wanted thinkers, not followers. And that was accurately what they got from the day one – team members started challenging the org blueprint draft presented to them by the management.

Having thinkers is not making things easier, but it is definitely improving things long-term. Some weeks after the training program was over, I remember overhearing developers’ conversations where they were appealing to the need for global optimization. The term ‘local optimization’ was also mentioned regularly in heated discussions about the blueprint of the organization and other process topics. So, I believe teaching systems thinking at the start of a LeSS adoption provides immediate benefits and is a must.

How did we conduct the education? We had 50 people in the R&D, then we split into 3 groups, each undergoing a 3-module CLB-like program.

Week 1: Systems thinking, LeSS principles, and optimizing goals
Week 2: LeSS frameworks and guides with a pre-class reading from the 3rd LeSS book, chapter “LeSS Story: Flow of Teams”
Week 3: LeSS adoption principles and strategies with a pre-class reading: MTS Kassa LeSS case and homework based on the reading.

Once all the group completed the first module, we would run an all-in joint session for all 50 people to focus on clarifying burning questions, confusions and also to foster owning the to-be org design via challenging and improving it.

The format of the joint sessions was the following:

Start with the short part where the leadership team would announce recently made decisions (e.g., who will take on the role of the Product Owner) and big open questions to be researched yet.
Spend the remaining 90 minutes on in-depth discussions in smaller groups (facilitated with a world café and open space) with mixed groups of team members, management and other stakeholders.

So, the format was clearly not “now the managers will tell you all how you’re going to do LeSS.” We ran those joint sessions to foster a collaborative work and, importantly, to send a message that it was up to everyone to figure out how this would work for them. Thus, we were slowly building up the informed consent on how the target org design and operating model will look like – a strong prerequisite for deep successful change.

The Product Owner at Poster

It was during the joint sessions during the education weeks, the CEO made the announcement that the current CTO would be playing the role of an interim PO until a Head of Product can be hired. (Later on, five months into the adoption because no candidate was found, the CEO took over the Product Owner role).

I must comment on this decision. The LeSS materials strongly recommend that the Product Owner and feature teams don’t have a manager-employee relationship. Instead, they must see each other as equally powered and make most of the decisions through collaboration.

In Poster, due to the relative “youth” of the company, that structure was yet to be formed, so letting the CTO (and latter the CEO) take on the (overall LeSS) Product Owner role was a temporary decision. Making one of the ex-team-level Product Owners the (overall LeSS) Product Owner would likely create a conflict that the CEO wanted to avoid at all costs.

Designing Organizational Blueprint

The Initial Org Design

The very first org blueprint that was shared with the developers by the leadership team early in the prep phase had three product groups in it:

Core B2B product (majority of effort required was in this area)
Growth area (one feature team with an expert being a “Product Owner”)
B2B2C product area (one feature team to start validating product-market fit)

Why the division? (And how eventually we got rid of it as it wasn’t really necessary?)

Update from October 2025: In the early version of the case study, I referred to these parts as “product areas,” but after a thorough conversation with Bas Vodde, we concluded that they can, in fact, be seen as projects.

The Core B2B product area was intended to be ‘the home’ where the teams would continue building and improving the existing product.

The Growth area was seen as a way to manage the work that until now had been postposed and never worked on. So, the initial idea was to have a separate team working with a dedicated “growth Product Owner”. Moreover, there was already a candidate among the product managers who’d become a “Product Owner” for that area.

The B2B2C product (the term ‘product’ was literally used here to describe it until the moment a broader product definition was found) was more of a concern of the CEO, who wanted to start exploring a new business model that had been long on hold. A dedicated team, with a dedicated “b2b2c Product Owner”, seemed like a way to unblock that innovation and finally build an MVP.

What drove that org design? The management at Poster couldn’t understand yet the concept of a (scaled LeSS) Product Owner and the (single common) Product Backlog being the ultimate solution for the forementioned problems - the most adaptive org design element that solves all the foremost mentioned issues plus gives the ability to change the direction at any moment with ease. At the start of the LeSS adoption journey the managers were unable to see how the (scaled LeSS) Product Owner, not being an expert in the topics (e.g. product-growth or B2B2C), could manage the Product Backlog and guide the teams. So, they were falling back to what they had known to work before - team-level Product Backlogs, dedicated team-level Product Owners, even though this exact structure was causing the problems that made Poster not able to adapt easily and deliver value fast.

That org design was challenged very soon by the team members after they got educated on the LeSS topics and systems thinking.

Initial Organisational Design — A blueprint of an org design (that was not implemented) with three narrowly defined products. “EM” stands for Engineering Managers. Based on Org Topologies study of org archetypes at Poster.

Defining the Product Broader

Broad product definition is an essential LeSS topic. During the 3rd training module for all engineers and managers on the concepts of the LeSS adoption, I ran a workshop to search for a broad product definition.

After some debates and systems modeling exercises, we found a strong consensus on the topic among the employees. Despite, there were different terms and definitions used, the group was converging to the following broad product definition:

Poster is a service that eases business administration for entrepreneurs in the HoReCa niche worldwide
allowing business owners and managers to administrate their business ‘from a pocket’
via automating and facilitating interactions with suppliers, government, customers (B2B aspects) and the restaurant guests (B2B2C aspect).

Such a broad definition helped everyone to see how the B2B and B2B2C aspects are in fact parts of the whole. That led to a slow-growing understanding of the LeSS principle of the whole product focus. That eventually resulted in an updated and simplified org design blueprint that we used in the LeSS adoption.

Getting Rid of Product Areas (Simplifying Org Design)

The initial idea to have narrow product areas (e.g., B2B2C or Growth) for single teams was rooted in the old misunderstanding and applying Scrum to the team – not to the product level. Lack of change in that thinking resulted in the initial idea to organize the teams into several small, isolated areas. And can be summarized as the following false dilemma:

Applying existing skills for short-term gains.
Do we want the teams to keep a narrow focus and hence work “efficiently” on what they are good at?
Acquiring new skills for long-term flexibility.
Or do we want to allow teams to work on unknown product parts that require constant learning, hence never make teams focus and deliver?

Such a formulation presents a choice between two options, that implies only one can be chosen, and is an example of a false choice.

There is the third variant - choosing both options! But how do we achieve both: applying existing skills and acquiring new ones in the same organization at the same time?

Poster wanted the teams to be able to apply their existing knowledge and deliver value fast. That was clear.

But how likely is it that there is always something important to work on that requires only existing skills? If the company accepts the idea of (single overall) Product Backlog prioritized on customer value, then they need to be ready to cope with the probable situation where the skills required to do the valuable work and the skills present in feature teams do not match.

The traditional project management approach (that had also been practiced in Poster) is to create dynamics teams by pulling people with necessary skills into a new temporary project team. But that approach is based on the resource thinking - an assumption that people have a certain predefined set of skills and learning is too slow and expensive. Luckily, Poster had experienced the negative consequences of resource thinking (described above in Optimizing Goal) and was willing to change the paradigm and start investing in long-living learning feature teams.

This new way of thinking implies that the R&D organization needs to learn to work on business priorities instead of working on something that comfortable and known, but not relevant. Hence, each feature teams will be acquiring new skills.

In LeSS, the joint, multi-team meetings serve as a just-in-time decision point where the teams agree and pull items from the Product Backlog, taking into considering their existing skills and the need for new ones. It is during Multi-team Product Backlog Refinement and Sprint Planning meetings, teams make conscious decisions and agree on what they are willing to learn and work on. As a result, some teams might decide to apply existing skills and work on what’s known, provided it is prioritized high enough. Others may pull work that requires more learning. Such a process is consistent with the optimizing goal of gaining higher adaptivity, as the teams are working on the top-priority items at any given moment and also improving long-term – making adaptivity cheaper and easier.

Back to the org design challenge at Poster with the narrow areas. The people at Poster concluded that having single teams specializing in the narrow domains (like B2B2C and growth) was inconsistent with the adaptability goal that they had identified as their target. They agreed that the LeSS adoption at Poster would start with all the feature teams (50 people in the R&D), each to include a broad spectrum of skills from the day one.

Such org design would allow the teams to embark on a journey towards the perfection state. In that state, all the teams have a broad focus on the entire customer domain and hence can learn and work on high-priority features across the whole product. So, the idea of having independent backlogs for narrow areas was abandoned and recognized as a local optimization trap.

I noticed that educating everyone during the prep months contributed significantly to this understanding and the improved org design consistent with the optimizing goal. The team members did play a significant role in that decision, as they were all trained in the essentials of systems thinking and LeSS. And everyone in the company understood and owned that org design and was ready to face the challenges it will inevitably bring.

Improved Organisational Design — A blueprint of an improved org design (that was eventually implemented) with a broadened product definition on which all the feature teams work. Additional roles defined at Poster: “EM” stands for Engineering Managers, “PM” stands for Product Managers. Based on Org Topologies study of org archetypes at Poster.

Note the number of Product Managers (PM) - these were all the ex-team-level Product Owners who stayed in the company after the LeSS adoption and were promoted to this position. See Product Owner’s Team chapter for more details on the challenges this brought later on.

Perfection Vision

During the last joint session with all the people, we ran a workshop to discuss their desired direction for change – the almost unattainable future state that everyone is drawn towards. In LeSS materials, this is called a Perfection Vision or a Perfection Challenge.

We clustered the results into four categories:

In- and inter-team work, responsibilities, knowledge sharing
Client collaboration, hypothesis testing, fast feedback, and value delivery
Employee happiness, hiring, personal development, general management
Engineering practices, quality, product support

The board that the teams created contained future-state statements like:

Each team is solving customers’ problems end-to-end.
Teams (not a separate department) do new feature onboarding for clients.
Teams to be able to work on large features together, jointly.
Auto-testing is improved.
Product metrics are being designed, built, and collected by the teams.
Teams actively practice pair programming and learn from each other.
No need for support duty for the teams anymore (see the Product Support Process)
etc.

The results of this workshop were used later at the Flip Event when we were defining the shared Definition of Done for all the newly formed feature teams.

LeSS Flip Event

Format and Agenda

Although the company was working in a hybrid mode (in the office and remotely), we decided to run the flip event in person. And we didn’t believe our luck – all but one team member (who fell sick on the eve of the date) were able to participate physically in the two-day event, plus of course, the leadership team: CEO, CTO, Head of Engineering and several heads of other departments, including client success/feature onboarding.

Our agenda for the two days was:

Day One:

Morning Check-In
Product Strategy and Product Backlog
Farewell to Old Teams
Defining Done (described below)
Feature Teams Self-Design Workshop (described below)
Teams Selecting Engineering Managers (described below)

Day Two:

Morning Check-In
Forming Communities (was not run at the event)
Mob Programming with Elephant Carpaccio Exercise (was not run at the event)
Initial Product Backlog Refinement “PBR” (described below)
Sprint Planning I and II (described below)

We knew we could continue working on the unfinished items remotely after the event. So, we intentionally created an overly optimistic agenda, trying to do as much as possible while everyone was at face-to-face work.

We had to revisit the agenda on the fly, and from all the agenda points, only accomplished the ones marked in bold. The following chapters describe details of the LeSS Flip event, including the lessons learned (obviously, rushing this event is one of those).

A separate chapter describes the work on the Evolution of the Definition of Done.

Flip Event 5 — During the face-to-face Flip Event. Near Dnipro, Ukraine.

Feature Team Self-Design Workshop

I won’t describe all the mechanics of facilitating the team self-design workshop, as we followed the format documented in two great experience reports by Ahmad and Mark (see the References). I will highlight some aspects that were contextual to the Poster.

The leadership team accepted the idea of letting the teams form themselves at quite an early stage of the preparations. And everyone at Poster was eager to see this working. Yet, although we had spent some time during the prep phase discussing the mechanics of this workshop, the morning check-in round reflected that people were anxious about this part of the Flip Event in particular.

Will they be able to create the “right” teams?
Will they be able to be in teams with whom they want to?
How will they spread some deficit knowledge among all teams?
What if they were to fail this exercise?

These and other questions were on people’s minds on the date of the Flip event.

We started with formulating a team’s ideal shape (a template for a team):

5-6 people in a team
- Frontend as a main skill (ideally 2 people)
- Backend as a main skill (ideally 2 people)
- Testing as a main skill (1 person)
Component knowledge is spread among teams as broadly as possible
Everyone in a team wants to be in that team long-term

Colocated, Remote, or Mixed Teams?

One special question that was there at the pandemic times was: whether Poster wanted the teams to be colocated as much as possible? One option was to leave this point up to the teams to figure it out during the design exercise on their own.

The thinking of the management was the following: since Poster had already started hiring remotely, they would create mixed teams where the old comers (living in the head office city) team up with the newcomers (in most cases remote employees). Thus, creating distributed teams. The mentioned goal was to “sustain the Poster culture”. It seemed more important that to create highly efficient colocated teams that can work face-to-face.

The argument of sustaining the company culture is hard to argue, and often they got to accept without being questioned. But it is essential to learn to apply systems thinking no matter how logical or sound a statement is, especially when it has a significant impact on org design.

So, what is that culture of a company? And can it be really sustained despite the growth of a company? Won’t the remote work itself be shaping the new habits and therefore creating a new culture? If so, then the culture would be changing anyway. In this light, isn’t it better to have some teams relishing the charms of colocation? On the other hand, if preserving that unique culture is that critical, was hiring remotely a good decision in the first place? Thanking broader: what are the other significant influences that shape the culture that need to be known and managed?

The working environment shapes how people see work, think of work and do the work. The environment shapes the culture of work. In a young company, the founders have a stronger influence on the culture than in the established organizations with hierarchies and bureaucracy. So with company growth and maturity over time, the culture will be increasingly affected by the structures, and less by the charisma of individual leaders.

Culture Follows Structure

So, how to sustain or change the work culture? By properly shaping organizational structures (see Larman Laws in the Reference), by applying thoughtful org design. That is accurately what is to happen in a LeSS adoption.

LeSS as an organizational system, puts in place new structures (roles and rules) that will result in a culture with the teams having a broader focus and feel shared ownership of the entire product. That is achieved by:

an earlier involvement of the teams in understanding and designing changes
teams collaborating directly with the customers and users
more self-management of the teams’ needs for coordination
a stronger feeling of ownership of the process
a stronger commitment to the engineering practices that build quality in (i.e. test automation and continuous integration/deployment)

Collocated teams would be a better fit to facilitate these changes, as learning happens easier and faster with people working at the same table, drawing at a whiteboard, mob-programming, and sharing information face-to-face powered by osmotic communication.

So, which teams to form Colocated, Remote, or Mixed Teams? We decided to voice these arguments at the team self-design workshop and let the teams figure the answers themselves. In the end, they formed several purely colocated teams, while others had a mix of onsite and remote members.

Remote Work, Learning, and Loyalty

Fast-forwarding to the first year in the LeSS-adoption.

During the first LeSS Sprints in 2021, despite that, the company allowed remote work, the teams that were colocated started to meet have office days to work face-to-face. Those teams were sharing photos of themselves working at a large shared table, inspiring others to do the same. And for some of us, within a year of the pandemic, working physically together was an entirely different (and almost forgotten) experience.

For the people who were hired during the remote times, one could almost feel in the meetings how less engaged and less integrated they felt. It is one thing to get hired to an onsite team, build your bonds, learn to collaborate and then have to switch to a remote mode of working. It is an entirely different experience to get hired remotely and never have a chance to jell with your teammates. Closing tasks is not the same as learning together as a team.

Later, in 2022, due to the Russian war on Ukraine, the company had to lay off several people. The developers who had been hired remotely during Covid-time were among the ones who were let go first. Remote work doesn’t allow building strong bonds not only between the team members (affecting collaboration), but also between the company and the employees (affecting retention and loyalty).

Team Formation

Back at the LeSS Flip event and team self-design event in 2020.

It took us two rounds of 30 minutes (20 minutes formation + 10 minutes feedback round) to form six features teams that everyone was OK with.

The teams and the management were very surprised at how quickly and well this activity went. So, the concerns and uncertainty people voiced during the morning check-in round went away very fast. That created a strong feeling of ownership and confidence that we carried to the upcoming activities of the Flip event.

There was, though, a delicate situation in between the rounds when the VP of Engineering pulled me aside and shared that he didn’t feel good about one of the formed teams. His concerns were that all the guys in that team didn’t have the “getting to done” attitude and that the teams would likely not deliver. We discussed that with him for a few minutes and decided that the best way to address his concerns was … just to talk to the team directly. He approached the team, squatted next to the guys, and softly shared his observations and concerns. To my surprise, this catalyzed a great discussion when the team members looked very appreciative and understanding. They listened to him but assured him that they did not see this as a problem and also proposed to have regular checks to catch early signs of the issue should it be real. That’s what they concluded with… Some months later, when I reminded the VP of that discussion, he smiled and said there had never been an issue with that team.

Teams Selecting Engineering Managers

Before adopting LeSS, there was a formal role of a Team Lead. So, most of the initial teams had an engineer with that title. Such a person acted as an interface between that team and the rest of the organization, making and communicating decisions to and from that team.

In Scrum, we want all team members to be equal and avoid having someone being “more equal” than others. Why? Because being equal means equally feeling valued and listened to. We want all the team members to share responsibility, not simply do what someone says. We want everyone in the team to have a chance to do what feels right just-in-time, instead of asking for permission. Having a formal leadership role within a team sucks out responsibility from other team members, slowly but steadily creating a culture of followers and doers. That reverberation of Taylorism, a so-called scientific management approach, was popular more than a hundred years ago, long before the rise of the era of knowledge workers and collective creativity. It is an outdated notion that to make a production system work, one needs to divide people into two groups: thinkers and doers. At the beginning of the 1900s, probably, that was necessary due to widespread illiteracy in the United States. But now, since the issue is long gone, our mental models need to be upgraded too. So, we don’t need to have some people in the organizations telling the others how to do things. Quite the opposite, we need leaders whose mission is to grow people and teams, but this is typically not how organizations define the role of a Team Lead.

Poster decided to eliminate the role of Team Leads. Since they believed in a flatter team structure with no titles, the idea of Poster was to introduce a notion of a cross-functional disciplinary manager to work with several teams. Such a role will have a strong focus on growing engineering capabilities of the teams. I call this macro-management. At Poster, this new role was called an Engineering Manager (an EM). See also my article “Extract Team Leads” in the References for more analysis of this matter.

Because the Engineering Manager role is engineering-related, it became apparent that people with great engineering skills should fulfill the role. That role implies teaching and mentoring, so candidates should also be good at working with others (pairing, mobbing, sketching, facilitating design sessions, etc.). Some of the initial Team Leads were chosen by the VP of Engineering as candidates for the Engineering Manager role.

One may wonder how this role interrelates with a role of a Scrum Master because there is some obvious overlap between the roles. Indeed, the upcoming chapter, Managers as Scrum Masters, explores this in detail.

At the LeSS Flip event, it took about an hour and two rounds for the newly formed teams to agree and pick their EMs based on the candidates proposed by the VP of Engineering. Initially, there was a collision of too many teams wanting one candidate to be their EM. But later, when the constraints got clarified (two teams for each EM), the teams agreed. That round was facilitated the same way as the team self-design workshop. All the managers were asked to leave the room, and we instructed the teams to call everyone in once they were ready.

So, Poster ended up having six feature teams and three engineering managers.

Creating Definition of Done

Already, during the preparations for the Flip, we spent time with the teams analyzing their current team’s Definition of Done and discussing what the shared one would look like. Creating a shared Definition of Done is an essential step in a LeSS adoption and is defined in LeSS guides as a part of the Initial Product Backlog Refinement workshop. Our Flip agenda contained a DoD workshop.

We started with collecting what currently “done” means in the pre-LeSS organization and created a shared list of things already expected by the pre-Flip teams. We called that list the “DoD 1.0”. It contained things like coding, unit testing, code reviewing, manual testing, deployment of some web components (deployment of the Android code was done separately by a specialist), UX review, internationalization, etc. That discussion raised some interesting talks between the team: “do we really do it, or do we say we do it?”

Then we discussed what we want the future DoD to be like for the LeSS product group with feature teams. During the training workshops weeks ago, we had created a draft of perfection vision with ideas on improved engineering practices. We used it to derive ideas for the future DoD.

But how to help teams start making these improvements and not overwhelm them with an avalanche of changes? One aspect of LeSS design (that I admire hugely, as it makes LeSS to stand out from other approaches available on the ‘scaling market’) is the notion of Continuous Improvement Towards Perfection. That is not a new idea at all. It is one of the two pillars of Lean Thinking. But it was made explicit as a LeSS principle to highlight its importance as a thinking tool. That is to “… keep you improving for a while”.

So, we named the future state DoD – the “DoD 3.0”, clarifying that it will take a little while to get there (we were in 1.0 before LeSS). Yet, that it is not the final state, There is none when it comes to continuous improvements.

Once we set the high standard with the “DoD 3.0”, we ran a workshop in which we pulled feasible items from “DoD 3.0” to fill in the gap between 1.0 and 3.0. We called that, obviously, the “DoD 2.0”. It would be the new state of affairs as of starting the first LeSS Sprint.

DoD 1.0 – state before LeSS	DoD 2.0 – new state of things	DoD 3.0 – perfection state DoD
How have the things been before LeSS?	How are we to work from LeSS Sprint 1? Which parts of DoD 3.0 that we believe we can start learning to do already?	What are all the bold things that we want to have in our production process eventually, but can’t pull yet into DoD 2.0.

The formulation of the DoD 2.0, in fact, served as a kick-off to the first Community formed after the LeSS flip. Creation of the DoD 2.0 during the Flip Event served mainly to clarify the team’s abilities and ambitions. Further incremental improvements to the DoD were discussed at the Overall Retrospectives and separate work sessions initiated by the temporary DoD Community.

See the chapter Evolution of Definition of Done on how the DoD did evolve.

Refining and Detailing Items

Once we were clear on the shared Definition of Done (the “DoD 2.0” as we called it), most of the Day 2 of the LeSS Flip was taken by the Initial Product Backlog Refinement (PBR) workshop. There, all the teams were learning the top-most Product Backlog Items (PBIs).

It is worth noting, that the LeSS materials recommend the Initial PBR to last for two full days. That is because we want the teams to learn together about the product and the upcoming work – to break the silos, widen their perspectives, and explore the new multi-team way of being as LeSS is Scrum for multiple teams (instead of multiple Scrum teams).

Due to the logistical constraints, we only had two days for the entire face-to-face Flip event, and we wanted to do run the Initial PBR face-to-face, while we were all together. So, we used what we had – 5–6 hours of the second day.

Here we followed the LeSS guides for a multi-team PBR:

form mixed groups of team members from different teams
cluster the closely related PBIs
and let the mixed groups refine those items together with “requirement donors” (domain experts and users)

We didn’t have the users at the event – Poster started to invite users to the Sprint Reviews and the PBRs about a year into the LeSS adoption. But we had internal experts (product managers, support engineers, customer care specialists, and selected team members) who appeared to possess some understanding of the domain problems, user needs and required product changes.

It quite became apparent that some team members lacked knowledge about the product. Working in component teams before LeSS, they knew only a given module, set of screens, a specific workflow. So, the PBR sessions became a mix of teaching sessions on how the product works now and how it must be changed. The energy was very high in the rooms, and it was not surprising to see the level of self-management that emerged: some team members realized the gap in product knowledge and initiated quick feature demos in their groups, others started to research some domain-related open questions (i.e. upcoming changes in fiscal laws in Ukraine), others started to design new workflows.

That moment, to my eyes, could be seen as an early success of the LeSS adoption. We wanted the teams to be able to work together on what the business identifies as the most important. And there they were: six feature teams were learning the product, the domain and designing the necessary product changes.

What also helped in that process is that the top-most PBIs were all related to a specific upcoming legislation change, and it has become the main theme and the company’s focus for the next 10 LeSS Sprints to come.

Still, in retrospect, it was clear to me that the Initial PRB could have been longer to provide more value. Everyone felt rushed. And that negatively resulted in a high level of unclarity about the top PBIs during the first LeSS Sprint. Those were quite complex items from requirement and technical points of view as Poster was to implement an integration with external data providers (Ukrainian tax authorities), whose fresh APIs were still poorly documented at that time.

LeSS guides recommend the Initial PBR to last “at least 2 days”. We thought we could shortcut that, assuming:

people are not new to the product (most developers have worked for several years in the company);
the top-priority upcoming product changes have been on everyone’s mind for too long;
everyone is eager to work together and learn fast.

That was clearly a mistake. Our learning eventually was that when people used to work in silos on narrow product parts for years, they simply need a lot of time to broaden their understanding of the product. First, they need to understand how the product works already. Then, they need to discover the details of the upcoming work: study new complex requirements and design how the product must be changed to accommodate them. And then, they have to spend time in speculative architectural workshops to sketch ideas on the implementation details.

As we’ve learned, there are no shortcuts to this, and the chapter Rushing Makes You Slow provides more analysis of the repercussion of shortened Initial PBR that we did. Don’t repeat our mistakes – make new, better ones!

Sprint Planning I and II

We decided to conclude the face-to-face LeSS Flip event with a lightweight Sprint Planning I and II to practice these events while altogether.

Since we knew that the teams would be working mainly remotely from now on (due to predicted upcoming COVID restrictions), we decided to do a hybrid-mode Sprint Planning I already during the Flip. There, the teams were physically together, but were working on a shared online Miro board. So, the teams were talking to each other and the experts face-to-face, used physical whiteboards for sketching and then were going back to their laptops to update the online planning boards in Miro.

The Sprint Planning I and the beginning of Sprint Planning II were conducted in 90-minutes by the end of the day two. The teams presented their drafts of their Sprint plans and discussed the needs and means for inter-team coordination during the next days when everyone will be working remotely.

The Sprint Planning II was agreed to be finalized by each team first thing the next day.

On Choice of Tooling

Historically, the company had been using Notion for all the management data and reporting – a powerful merge of spreadsheets + wiki, that provides a lot of freedom on data representation, allowing for simultaneous editing.

But because the hybrid Sprint Planning was facilitated using Miro (to simulate a large wall space that is also digitalized) the teams agreed that they would try Miro for the 1st Sprint and then see which tool to keep.

A group of volunteers emerged just-in-time at the event to work out the tooling question. That can be seen as a mission-centric, short-lived inter-team community. It worked out the tooling question during the next few days to make sure everyone was OK with the agreement.

Six months later: Poster is using Notion to store the Product and Sprint Backlogs, and Miro (a huge single board) for multi-team activities such as Sprint Planning, Retrospectives and PBRs.

Closing the Flip Event

By the end of the two-day event, most people believed that we took the best of out of the time we invested, and there was a great energy. And that’s where the LeSS Flip event left us – energized new teams with incredible challenges of mastering a broader product definition via cross-component work and an extended Definition of Done.

See the chapter on how the Definition of Done was evolving.

Yuliia Kastierova, a QA engineer:

As for me, the transition began even before the flip. The management of the company worked very well here. The guys organized cool trainings, where employees were able to get acquainted with LeSS and learn the basic principles of work. This brought a vision of what to expect from the change.

During the flip days, it helped a lot that the guys had a good planning of the transition scheme. Alexey and ILLIA had been smoothly preparing the entire department for these outcomes. And there was no sense of fuss.

ILLIA Kovalchuk, Head of Engineering

It was not difficult to let the teams form. The difficulty was in planning the work.
In our case, we had a giant task related to legislation, about which hardly any of us had heard before. We did the initial Refinement of that work right on the flip event. And I think it was a very useful experience in terms of learning to coordinate work between the teams and focus everyone on one of the most important goals for the company.

First Twenty LeSS Sprints. Observations and Lessons Learned

Organizational change is not a project with a clear end-date, but rather an ongoing journey towards perfection. This chapter highlights different aspects of the Poster journey (relevant to the LeSS adoption perspective) – the things that have been evolving and dynamics that have been observed during the first six months after the Flip Event.

Perception of Speed

Rushing Makes You Slower

This chapter is a follow-up on the Initial Product Backlog Refinement chapter, analyzing the consequences of the Initial PBR run at the LeSS Flip event.

Eventually, it became apparent a few days in the first Sprint that the selected items had high uncertainty, and some of them just exploded with more work. Obviously, we didn’t invest enough time in the Refinement of those items. And eventually, the Product Owner had to re-prioritize the work mid-Sprint and the teams had to adjust the plans and do some extra coordination activities to redistribute the shared work.

Was it a disaster? Yes and no. Our excuse was that the failures are only failures if they come with no learning. And the learnings of the first Sprint due to lack of PBR activities were immense:

The teams realized that no matter how good is the Sprint plan, it is vital to keep constant coordination because the teams and re-balance the work as the things will likely go wrong due to the reason that could not be foreseen.
The teams had started to practice the most direct way to do the coordination – the so-called “just talk” technique, which required no managers and was merely the teams’ initiative to do the coordination.
The teams had also experimented with the LeSS practice of a Leading Team, where one team would volunteer to start some complex work. Typically, they would do that by biting off a small piece to learn more about that work. Once some clarity was in place, that leading team would be facilitating further Refinement activities, sharing with the other teams their findings, and eventually, coordinating with others for the shared work. This way, three out of six teams were working on very related PBIs already during the second LeSS Sprint.
And finally, the importance of the PBRs: the teams agreed to start investing 4–6 hours weekly on the PBR activities, learning to do it right, not just fast. (The reader may wonder why we’ve chosen a weekly cadence of PBRs. Please refer to Remote Meetings and Multi-team PBRs for the details.)

On the positive note, despite all the mentioned shortcomings, the somewhat condensed PBR and Planning activities of the first LeSS Sprint, Poster did send a strong message to everyone, that can be summarized as the following:

we are here to learn to work together, and it will be different,
so no matter how much time we spend analyzing and preparing, it is impossible to have a precise 100%-clear uncertainty-free Sprint plan,
hence, it is totally fine to keep talking and learning from each other within the Sprints, re-adjust the plans when necessary and keep improving our understanding of the product, the work to be done, and the process.

Looking Retrospectively at how the things started at Poster, as a LeSS coach and Scrum Master for the next Sprints, I was pretty happy with those early failures and the resulting learning curve that Poster was on.

Going Slower is Going Faster

It was already clear during the 1st LeSS Sprint, that for the first time in the company’s history, several teams were able to join forces and work together as one on a single and most important business objective. And it was despite the drawbacks of the shortened initial PBR (described above). And over the upcoming Sprints, all the six feature teams were actively contributing to a small set of complex product changes (all related to upcoming changes in the Ukrainian legislation law).

That became possible because:

Transparency: We had a single PBL that got constantly re-prioritized by the PO, and it became apparent to everyone who nothing is more valuable now for the business than the Legislation topic.
Shared work: During the first Sprint, one team pulled the work related to a topic that was new for everyone in the company. They took a bite out of it to see the underlying complexity. Later on, that team served to other teams as a Leading Team (a LeSS practice) serving as an informed helper, and a coordinator, and enabling other Teams to join forces on that.
Shared knowledge: Regularly the Teams were running multi-team PBRs (with mixed groups from each team) that allowed for knowledge to start spreading and enabled Teams to work on what’s important, not on what’s comfortable to them. (The reader may wonder why we’ve chosen a weekly cadence of PBRs. Please refer to Remote Meetings for the details.)

Indeed, there was something to celebrate: the promise of LeSS (high adaptability – low costs of change) was demonstrated already during the very first Sprints.

No doubt, that was yet the only beginning of the journey to mastering LeSS, with deeper changes to be realized. But one thing stood out clearly at the very beginning: Poster, as a company, was now able to focus more teams to learn and work on the high-priority items than ever before in the company’s history.

About a half year later after the 1st LeSS Sprint, at a webinar with Poster employees on LeSS, they were asked by the audience if LeSS accelerates development. Obviously, it is a wrongly formulated and confusing question because, firstly, speed is not an independent variable in a complex system of product development. Secondly, it can improve or degrade over time due to various factors with delayed effects. But what is most important to keep in mind is that the performance (throughput) of an individual developer or a team doesn’t necessarily correlate with the company’s overall throughput. Large systems exert emergent behaviors that can’t be determined by behaviors of its parts. This question is a confusion raised from applying manufacturing ideas to product development. Still, people ask this question a lot.
Looking back at what we have observed at Poster, we could conclude that LeSS made it possible for all the teams to know the global priorities and collaborate on them. What is at the top of the Product Backlog can now be worked on by several teams together. This positively affects the performance of the entire production system.

Had not Poster changed its approach (switching to feature teams and to a single Product Backlog), likely, only a single narrowly specialized subsystem team would have been able to work on that top-priority legislation topic (or event worse – several teams would have worked on it sequentially). To make the things worse, it would have been only a specialized team that had later to support customer issues related to legislation (see Product Support Process) for more details on Poster’s approach to support in LeSS). Thus reducing its development capacity to accommodate the fixes. In such an organization, there would have been just one team learning the legislation subject and getting more and more specialized in it, becoming a bottleneck.

So yes, LeSS can speed up things – it facilitates and accelerates the learning. But what about delivery? Was the legislation topic worked on faster than it would have been without LeSS? That depends on what gets measured.

It is not that a LeSS company is producing more code, more features, more output. It is that such a company can now be steered much better to focus on what’s critical. And that stronger focus bound with the abilities of feature teams to learn to work on any product part – it is those things that make such an organization better at learning and hence delivering what’s important.

LeSS adoption at Poster also raised the product quality bar (via extending the Definition of Done). So with LeSS, the Poster developers now were involved in much more requirement clarification activities (PBRs). They did it in collaboration with other ‘downstream’ departments (e.g., feature onboarding, support), producing client documentation and writing more automated tests (again, DoD). They were constantly learning prior unknown pieces of the product and codebase (due to the cross-component nature of feature teams), discussing cross product concerns such as the legacy product architecture and user experience issues (due to the whole product focus)… Clearly, the developers (and the teams) at Poster were doing more work on each feature than before in order to bring the features to a higher level of “done-ness”.

So, do LeSS developers work faster? No. They work slower. They work slower because they are learning to work righter. And working righter results in working faster, in the long run.

Product Backlog Management

Overall Flat Product Backlog

Already during the first PBRs, one issue became very prominent: the PO and his team were not yet sure how to approach the idea of a single Product Backlog (PBL). In theory, from the system thinking viewpoint, the idea of having one PBL for all teams made a lot of sense for them. But once we started working with the PBL, we realized it was, in fact, a multi-level set of backlogs.

The illustration below depicts how the backlogs and their items were structured.

Wrong Product Backlog — This is how NOT to work with a Product Backlog: Prioritization on epic-level and multiple sub-backlogs for each epic’s PBIs

As outlined in the illustration above, the Product Backlog consisted of so-called “epics” (big batches of work aka projects) and each of them had its own sub-backlog where the smaller PBIs were stored. That obviously didn’t allow for prioritizing PBIs across epics. But more over – it was creating unintentional negative dynamics described below.

Iterative and incremental development implies, that one can work item by item, delivering one after the other, inspecting on the fast and early feedback, and adapting to what to get built next. This allows for fine-grained prioritization and constant deliver of high value.

Grouping and gluing the items together, no matter how logically related, impedes this process. Working in these big batches (“projects” or “epics”) creates a false understanding that the entire batch needs to be completed before it can get shipped. Thus invalidating the idea of fine-grained prioritization and slowing down delivery and learning flow.

Since the big batches mean big investments, that calls for tighter control. So, often in such an environment the teams will be asked to provide more accurate estimates and, in its turn, do big analysis and design upfront – that extra work will also make production more expensive. And the bigger the batches are, the more it is so.

The level of uncertainty in a complex domain, such as large-scale digital product development, is inherently high. And batching up the work only increases that uncertainty (i.e., more work with delayed feedback leading to more uncertainty). So, the practice of batching makes it even harder to predict the outcomes of work with any reasonable levels of accuracy, no matter how much time is spent (wasted) on upfront analysis and planning.

So, it is no surprise that no matter how good plans are on the paper, occasionally they would turn out wrong. Those “failures” would make management typically put higher pressure on teams to come up with “more accurate plans” and “more stable architectures”. Thus, making the teams spend more time planning, analyzing and speculating over architecture and estimates – instead of building, shipping, and learning on real customer feedback. All in all, such dynamics creates longer development and feedback cycles and minimizes organizational learning.

In such an obscure environment, managers can only rely on the old-school, heavyweight management techniques such as milestone-driven development with resource allocation and planning. And this added bureaucracy just adds more complexity. And now the organization is in a vicious cycle.

The fear of being wrong with the plans and the added bureaucracy makes everyone focus more on plans and the ever-growing policies than on how to do plans better. In such a “plans creating” organization, everyone is allowed to work only on what has passed the defined planning gates – on what is known, planned, estimated and approved. That kills innovation that must be at the heart of any successful product development.

The downward spiral described above are some reasons why the agile movement calls for iterative and incremental development.

At Poster, we have noticed that dynamics and had to coach the Product Owner and others to restructure the backlogs. And the only way to avoid the above described dynamics was to avoid thinking and working in batches. Structurally, we had to get rid of the epics and create a true single-dimensional Product Backlog with prioritized fine-grained items that would guide iterative and incremental development. We had to reconfigure our backlog management tool (see [Tooling]](#on-choice-of-tooling)). Luckily, our tool was flexible enough not to dictate how backlogs must be organized (that’s why, try avoiding Jira and tools alike that prescribe batching).

True Product Backlog — The true single flat Product Backlog with granular prioritization on PBIs from different themes

We solved that issue of batching, but created a potential new one: how one doesn’t get lost in a flat Product Backlog for the entire product? And how can one Product Owner manage it? There were several things from the LeSS guides and our experiments that we tried – and with positive outcomes:

We went from batching with epics to tagging individual items with themes to mark which part of the product they belong to.
We preferred slightly larger PBIs (than one would use in a single-team Scrum). This helps to keep the cognitive load of managing the Product Backlog at a feasible level. On average, during the first 10 Sprints, we had around 10-15 PBIs in work every Sprint for all the teams. We were typically refining items for two next Sprints. So adding this all up, and we got 30–45 items on top of the Product Backlog that needed to be understood and prioritized - a manageable job.

Those things together allowed for fine-grained prioritization across the single Product Backlog, that was a door to iterative and incremental development.

Product Owner’s Team

The needed change to the backlog structure (see the chapter above on the Overall Flat Product Backlog), described above, had another systemic root cause. As the people, who before LeSS had been team-level Product Owners, now, in LeSS, were seemed to be losing their power and wanted to get a grip back on to something: if not on a team’s backlog, then at least on an “epic”. If not an “epic”, then a piece of a process.

This chapter described the challenges of the ex-team-level Product Owners (that I have a lot of compassion for) as well as their individual transformational journeys (that I really admire)

As mentioned before, for clarity and to avoid confusion between the term “team-level Product Owner” (as such a role doesn’t exist in LeSS) and the “real scaled” LeSS Product Owner, the former is referred here as “Team Output Owner” (or TOO for short). See the chapter Product Management before LeSS for more analysis of this role and its related dysfunctions.

So, the TOOs at Poster before LeSS could be divided into two main cohorts:

Software developers with extra responsibilities of prioritizing a backlog of a component team.
Business-oriented specialists with domain expertise and a responsibility of prioritizing a backlog of a subsystem team.

See the chapter Product Development before LeSS for analysis of the teams at Poster before adopting LeSS and feature teams.

The 1st cohort of the TOOs were experienced developers, who at some point were given a few other developers to ‘lead’ and ended up managing a backlog for a component that they owned. This was a minority case.

The most TOOs belonged to the 2nd cohort – people with product manager’s ambitions. Before joining Poster, most of them had worked in gastronomy and entered the digital development field as subject-matter experts given a role of team-level Product Owners (essentially: Team Output Owners).

Accountabilities of these specialists before adopting LeSS included the things like:

Managing a team’s backlog
Developing and keeping a deep expertise in a specific part of the product (e.g., fiscalization)
Assisting a team with business analysis related to the backlog items
Defining solutions for customers’ needs
Managing dependencies when product changes required work of multiple teams working sequentially
Working with the CEO and other departments to align and coordinate work
Staying up to date with the legislation and competition landscape
Communicating with the existing customers to understand their needs

From the list above, one can see that the TOOs worked mostly as middle-men, team representors, product designers, business/requirement analysts and team representatives. This was creating a negative dynamics, sucking out teams’ accountability and decreasing teams’ learning, as the TOOs fenced the teams from the problem space and gave the teams task to implement. As with any middle-men, over time a system gets more and more dependent on such role.

In LeSS and with the agile-mindset in general, we believe that “the best architectures, requirements, and designs emerge from self-organizing teams” (11th principle of the Agile Manifesto). Therefore, the teams ought to meet the customers, learn about their problems, and from these interactions generate enough empathy and understanding that will help to come up with a genuine solution – a product experiment to try and learn from. Such a different mindset implies a lot of collaborating and coordination that eventually will be seen as a necessary and inseparable part of engineering – and not a burden to be delegated to external coordinators and middle-men.

After adopting LeSS and switching to the feature teams, most of the activities of TOOs were now either owned by the teams or no longer needed. Sadly, dropping team-level Product Backlog ownership and not having a dedicated team was seen by most of the TOOs as a demotion for them at the beginning of the change.

“Jobs safety over role safety” is an important principle in Lean Production. It means that because we value people, skills and expertise, we can guarantee that whoever was in the company before the structural change can be sure of their jobs. They will stay (and their salary will remain the same). But their role will likely change, and those people will have to learn to apply their skills differently in a new context – learn to add value with what they know and can.

The same principle was applied to the role of the team-level Product Owners, losing their role because of the LeSS adoption. Most of them possessed good knowledge of the domain and the product, had great analytical and communication skills – and those skills were still highly needed. The senior management of Poster wanted these specialists to stay and find a way to keep adding value in the “new world” of self-managing teams without being the middle-men.

My suggestion as a LeSS coach was to try seeing those specialists for what they were – either developers or business analysts. So, why not let them join the feature teams? One of the TOOs with a deep engineering background did, in fact, join a feature team as a developer and did greatly. But for the others, the CEO decided on a “product manager” title. He wanted them to be in his team, helping him to formulate and lay down the product strategy for the overall Product Backlog.

I can’t say that this transition went smooth – an organizational change is the sum of personal changes, and each personal change goes at an individual pace. We had many discussions with the new Product Managers on their new role. And I can recall several attempts when they tried to follow their old habits of managing teams: asking to join team’s Daily Scrums, be added to teams’ internal chat channels, calling for an additional Scrum-of-Scrums event to be organized, etc.

Product Managers felt disconnected from the Sprints and teams (compared to what they were used to before) and attempted to regain control. But the teams who felt the fresh air of self-management did not allow that. They categorically refused to let product managers inside the internal teams’ affairs. The teams claimed that they didn’t need any help until they explicitly asked for it. That was fair. The teams defended their right to self-manage and were improving in this with every Sprint.

Not being able to get engaged deep back with the teams, the product managers continued looking for something to hold on elsewhere. Eventually, they called themselves a “product guild” and started to design and formalize the “discovery process” - a process that they would own. They were claiming “formalization of such a process would professionalize product development, help the teams to avoid misunderstandings, long wasteful discussions and rework”. I, as a coach, saw this emerging and was actively doing nothing for some weeks to come. I was waiting for the right moment to intervene systemically.

The ideas of the need to formalize the “product discovery” was based on several internet-spread articles, including the white paper on how Spotify builds its products with “Think It. Build It. Ship It. Tweak It.” model (see the References for links, and read it with caution). Based on that paradigm, the product managers came up with a staged product development process and asked for feedback. In that described process that saw themselves engaging with the users and developing early prototypes that, once got validated, become a basis for involving the teams and building ‘real’ features on.

And I offered them a two-hour workshop on Lean Thinking. Specifically, we looked into the concepts of flow and process wastes that disrupt a flow: hand-offs, batching and functional groups working in isolation. We also looked at their narrow definition of a prototype, which they saw as an outcome of the discovery phase. Luckily, they were able to agree that any change in the product in fact is an experiment and that any product change is some sort of prototype that is done to validate/invalidate a hypothesis. Early prototypes ought to be lighter and cheaper due to high uncertainty, but it doesn’t mean the feature teams can’t be the ones building them. In fact, involving the teams early on will only improve their understanding of the customer problem and technical feasibility.

To my surprise, a week after, the initiative to “describe the ideal product development with a discovery stage for prototyping” was abandoned by the product managers. And the key influences in their group agreed to work from the ground up instead. They agreed to focus on the product challenges at hand rather than abstract processes, get better at facilitating the PBR events, and most importantly - observe and collect emergent practices and improve processes continuously without making things up.

Eventually, it took about four months for the product managers to find their new place in the company and start seeing the new horizons. They slowly stopped fighting the inevitable and focused on what they were good at – sharing and applying their analytical skills, facilitation, product knowledge and domain expertise. Therefore, weekly Multi-team Product Backlog Refinement (PBR) sessions became that sweet spot where they would collaborate with the teams and pass on their experience.

During the multi-team PBR sessions, the product managers were supporting the teams to understand the underlying business rules and constraints that they were aware of as domain experts and also learned to facilitate user story mapping and other requirement splitting techniques described in the next chapter on Multi-Team PBRs.

And it took about 9 months before the teams could work with real clients on the PBR. That was a mental shift for the product managers, who were slowly turning into “cocktail party hosts” rather than dependent experts and middle-men (see Kent Beck’s podcast link in the Reference).

Remote Meetings and Multi-Team PBRs

Because of the company strategy to hire remotely (see COVID-19 Times and Remote Work) and the fact that the government introduced occasional lock-downs, we had to face the inevitable – learn to run remote LeSS meetings. This chapter highlights the practices of remote meetings that we used, using PBRs as an example.

But first, let me start by listing all the possible drawbacks of remote-run meetings.

With the currently available remote tooling (Zoom-like video conferencing), the non-verbal sources of inter-human interaction are shut down or very limited. Even with the cameras on (we had this as a rule in Poster), one can’t properly read people’s body language or their emotional state. That makes meeting’s interaction low-bandwidth, centralized, and thus results in all sorts of dysfunctions.

Managing participants’ focus and engagement in a physical meeting is getting generally harder with an increased number of participants, but with dozens of people present remotely – it is becoming a real challenge even for seasoned facilitators.

So, when you read online that “remote work is the work of the future”, we can only hope that the future brings better VR/AR-tooling to our remote collaboration. Better tooling would make remote collaboration look more like face-to-face collaboration that we human beings were prepared for by the million years of evolution.

At Poster in 2020, we were using Zoom, Notion, and Miro (see Tooling) as the main tool set for remote work. We’ve experimented a lot with facilitating our meetings, to minimize the drawbacks that the remote work had introduced.

Remote meetings require more energy to stay focused and productive. To run a long meeting (e.g., Multi-Team PBR) is a very challenging activity. So, we decided to run PBRs weekly, limiting them to 3 hours maximum (instead of one PBR per Sprint, as recommended in LeSS). Moreover, the amount of learning and uncertainty of the top-priority items during the first Sprints were so big, that running PBRs more frequently helped us to keep learning faster. It also allowed us to iterate on the process of PBRs.
We did follow the LeSS guides of preferring multi-team over single-team PBRs. And most of our PBR sessions were run in Zoom break-out rooms with mixed groups. During the early LeSS Sprints, we spent about 60 minutes in an Overall PBR where the team representatives and the product managers were laying out a plan on which items which each of the mixed groups were to refine. As we learned and improved, we tried to shorten and simplify that process and eventually ended up with no Overall PBRs needed. The product managers would group closely related items before the event and on the PBRs we would simply open up N break-out rooms (one per each item group) and let the teams form mixed groups just-in-time and refine the items.
It is worth noting that we used a single Miro board for all teams and all the meetings – a shared virtual space. For a specific meeting, we mapped in Miro a map with topics and participants of each break-out room, so that people could know what happened where and could switch between the rooms when required. And in addition to the mentioned tools, all teams also had teams’ internal chats to coordinate while being on a multi-team calls.
It is important to mention that as a preparation for LeSS Flip, about 20-25 volunteers were trained on the basics of facilitation, including PBR facilitation and PBI splitting practices. So, when the teams were creating mixed groups for the PBR sessions, the teams were also making sure that each group had a skillful facilitator.
By failing and learning, we’ve discovered, that nothing makes PBR sessions less productive than having people misaligned on the current product behavior and the context of upcoming changes. So, we introduced a recommendation to start every PBR session (in a break-out room) with someone to demo the actual product to all the room’s participants first. That helped, as people in newly formed feature teams had a fragmented understanding of the product - never underestimate to what extent component development creates many small silos of knowledge.
Despite the above improvements mentioned, at times teams did struggle to split complex large items. And there was one particularly painful situation, where one mixed group had to extend PBRs several times and spent a lot of time on what they called “analysis and architecture”. The reasons being a) getting too technical in the PBRs mixing item Refinement and architecture design; b) not splitting the items properly to be able to apply incremental and iterative development. That failure and the associated lessons shed the light on the importance of applying tools like Story Mapping and my favorite one, “requirements as bubbles” - a visual implementation of the “take a bite” splitting technique.

Take a Bite — “Take a bite” splitting pattern.

Bubble Diagram — A “bubble” diagram of a complex requirement that grew into a “bubble tree” over a series of PBR sessions, where each group of leaves and individual leaves represent smaller PBIs (“bites”) emerged while detailing and splitting. The colors on the leaves indicate a level of clarity and done-ness of the items.

Product Support Process

The high-priority items at the top of the Product Backlog were not the only work that was there. There was another flow of work: the so-called “support tickets” – client issues that had to be addressed as soon as possible. A chapter High Defect Rate above explained the source of incidents and quality issues the product had before the LeSS adoption. And that didn’t disappear magically by forming new teams.

But now, the support process could be reshaped. Before, only people who knew the affected component, could work on a given support ticket. And now, as component knowledge was spread across multiple feature teams, any team could potentially work on any product issue.

That added a lot of flexibility to the planning (see below) and also drastically reduced developer’s interruptions, as now:

Poster could dedicate an entire feature team or several (not just a knowledgeable individual) to work on support tickets.
Introduce a “support duty role” that teams rotate on a Sprint basis.

There is another possible strategy for dealing with this: each team sends a pair of developers that together form a temporary support team for a Sprint. But because our teams were new, we wanted to make them stay together and jell. And nothing jells teams better than working on critical issues that the customers are facing at the same time protecting all other team’s Sprint plans. So, we introduced a rotating support role that teams could take on.

That is what we did: each Sprint Planning, based on incident metrics, the teams, and the PO decided of how many teams needed to take on the support duty; the remaining teams would work on PBIs in a Sprint cadence. Basically, that was an agreement on how to share the overall teams’ development capacity among these two work queues.

During the very first LeSS Sprints, due to the high incident rate, 50% of the overall development capacity (3 teams out of 6) had to take on the support duty. Such a high incident rate did raise plenty of debates and experiments on bringing that number down:

Better understanding of the effects the issues have on the clients:
- Why are there so many issues?
- Should all of them be really addressed?
- Could we define a better classification of criticality to have a better focus on what was really disrupting the clients?
Less involvement of feature teams via more skillful customer support:
- There was the 1st and 2nd line of customer support at Poster, represented by another department. So, what prevented those critical issues to get solved by customer support engineers?
- Could we provide better tooling, documentation and what not, so that the customer support engineers get better at addressing those issues without involving feature teams?
Smarter work on the issues by developers:
- How can we identify classes of root causes, fixing which would result in a significant decrease in the issue count?
- Can we constantly plan product improvements (addressing the issue root causes) as PBIs at the top of the Product Backlog?
- What typically slows the developers down? What are the typical touch times on the issues? How can we improve that?

Rigorous work on all the above-mentioned questions, during the Overall Retrospectives and beyond, did yield positive results. Five Sprints later, Poster was able to get down to just 1 out of 6 teams (17% of the overall development capacity) being on the support duty.

One particular aspect (that, to my knowledge, significantly helped to start changing that initial dire situation) was improved collaboration between the customer support department and the feature teams. Namely, I observed the following shift in collaboration:

Representatives of the customer support department were now invited to the Sprint Reviews, where they could better understand the changes being made to the product, understand the impact and timeline of those changes, provide valuable feedback and request a knowledge transfer session.
Representatives of the customer support department were now made regular guests of the PBR sessions, where they collaborated with the teams to learn the most affecting issues and their impacts on the clients.
Those two things above helped to discover that the customer support engineers were lacking some essential tooling and automation to be able to self-serve and resolve a whole class of data-related client issues. After those things were identified and formed as PBIs, they were got built in no time, letting the customer support department to solve a whole class of issues without involving the feature teams.

Engineering Managers

Engineering Managers Doing Gemba Coding

Engineering Managers was a new role that was introduced with LeSS adoption, with a goal of growing the company’s engineering capabilities rather than managing team work.

Like always with a new role, there were new confusion and questions.

How do managers work with the teams without managing them?
How do managers grow the engineering capabilities, actually?
How do managers stay hands-on?
And how do managers continue being great engineers (they wanted to keep coding)?
What is the difference between this role and Scrum Master?

The realization was that the Engineering Managers need to spend the time with the teams doing real work - that would allow them to learn how the teams are doing the work and help them to get better at it.

So, the engineering managers started to join teams on Sprint-basis as team members. That helped to surface numerous potential improvements, to name a few areas:

Rethinking the testing pyramid and the approach to integration testing.
Accelerating the process of training testers in coding and helping them transition to test automation engineers.
Reconsidering release/branching strategy, that worked somewhat OK when component teams worked within privately owned repos, but now because of the cross-component work a new strategy needs to be applied.
Expanding engineering skills to include basic data science work that each team needed to master to be able to measure the outcome of the features they were building.
And so on.

Managers as Scrum Masters

Right before the LeSS Flip Event, the only Scrum Master at Poster decided to leave the company. That came as a surprise. But event with him staying, we would have been understaffed, as LeSS recommends a Scrum Master to work with 1–3 teams. We had 6 teams, so having several Scrum Masters was necessary.

We tried to hire skilled people but failed. Most Scrum Masters who came for the job interviews knew how to work with a single team only and had close to zero experience with LeSS. We had to pivot.

Meanwhile, in order to better understand and address systemic impediments, I started to work closely with the group of three Engineering Managers and the VP of Engineering. They were eager to work close to the teams and I inspired them to coordination practice called Travelers to join teams on a Sprint basis. They were all experienced developers and could mentor teams on technical questions. Working closely with the teams, they started to collect a broader set of observations that were vital for improving the LeSS adoption.

Eventually, after 6 months, Poster gave up trying to hire new Scrum Masters and realized that the group of the Engineering Managers plus the VPoE had been de facto serving as Scrum Masters for the LeSS adoption.

Such a model of having managers as Scrum Masters has its pros and cons, but in Poster it was the only possibility, and we tried hard to make the benefits outweigh the disadvantages. We shall see yet which hidden and delayed effects such a model has on the organization.

Engineering Community and Pull for Engineering Practices

Pain of Long-Lived Feature Branches

The practice of long-living feature branches (LLFB) breaks the idea of continuous integration, even for a component team owning its repository. This dynamics is well described in Martin’s Fowler’s “Patterns for Managing Source Branches”. But a component team might not experience that pain as bad as several feature teams who are trying to collaborate on the same part of code in a single Sprint. Let me illustrate the LLFB practice in a component team setup and in a feature team setup.

A scenario: isolated component team making changes

Imagine a team starts to change a component by creating a LLFB. What happens if by the end of the Sprint, the changes are not done? The team can drag the changes on and keep the LLFB open, thus making it a bit more longer-living. It is very unlikely other teams would be introducing changes to the same repository (repo), as we are in component ownership modus operandi. When the changes are done, the component team can merge that LLFB back to the trunk. The probability of a merge conflict is low, as no other team contributed to the same repo. This is a dysfunction that breaks the idea of continuous integration, makes incremental development hard and slows down feature releases. But from a view-point of a given component team, those global concerns might be visible or important. It is an example of a local optimization.

A scenario: feature teams collaborating on changes

Now imagine feature teams using the same practice of LLFB. As, any team can now introduce changes to any repo. And now it is not unlikely that a LLFB starts diverging from the trunk. It will inevitably result in potential merge conflicts - a pain that any team can feel and observe the delays caused by this. The severity of the pain is a function of lifetime and number of LLFBs.

At Poster, in one of the early LeSS Sprints, one team was having hard times starting to work on a feature because another team still had a LLFB from a previous Sprint in some of the affected repos. And very soon the developers at Poster realized they had to unlearn the practice of LLFB. But what were the options?

Lack of Feature Toggling

But why do developers use LLFB in the first place? What stops developers from using the trunk-based development practice and avoiding the pain of merging?

At Poster, we realized that the key root-causes of having to use LLFB was lack of feature toggling capabilities. That is, the developers had no way to isolate unfinished features from releasable code but to branch out and keep unfinished work disintegrated. Lack of skills in splitting large Product Backlog items were also contributing to this. As large items took longer to get finished, a probability of having an unfinished feature by the end of a Sprint was always quite high.

A Pull for Change

Those and other findings became hot topics at the emerging engineering community at Poster. And the Engineering Managers now had a good material to work with. Before, they had to convince teams to improve. And now, the teams felt the pain and wanted to improve the way they worked themselves.

We can say that the LeSS adoption created a pull for change: old habits ought to be challenged and addressed, and better ways of developing software were to be uncovered. As the engineering practices started to mature, so did the Definition of Done.

Checking with Poster teams a year later: they have introduced feature toggling, and now a feature gets designed and built in a way that its release can be controlled on a per-user basis.

In-product feature metrics are also now a part of the feature development - teams are learning to build in metrics to measure user interactions and impact of the features.

Evolution of the Definition of Done

This chapter focuses on an aspect of this LeSS adoption - the evolution of the Definition of Done that I’ve witnessed over time at Poster. I do believe that the diff in the DoD over time is one of the greatest metrics to watch for in any Agile adoption. But especially in LeSS, where the expansion of the DoD over time can result in structural changes, e.g. dissolution of so-called “undone departments” (functional silos).

Feature Onboarding in DoD 1.0

A chapter above on Initial Product Backlog Refinement describes our high-level approach to agreeing on the shared DoD. This chapter is dedicated to a specific and probably one of the most important DoD improvements that happened at Poster during the first 10 LeSS Sprints.

Feature onboarding is the Poster’s way to call a chain of processes that needs to happen after features get physically released to production to make sure clients actually start using them. That typically includes things like:

Informing clients about new feature releases.
Providing learning materials and workshops to the clients and also to the internal customer care staff.
Helping clients configure and start using the new features.
Troubleshooting clients’ attempts of feature usage.
Gather early feedback and improve on it fast.

Historically, that pieces of work have never been in the hands of the development teams. It was a dedicated specialist group that covered that area – an ‘undone department’ as we like to call it in LeSS, to highlight a temporal and rather a negative connotation of such groups.

What’s wrong with a dedicated specialist group doing some work that is clearly not software development activity and, hence, is designed not to be a part of the development process? The following dynamics were at play at the pre-LeSS Poster organization:

Feature onboarding was usually done via a no/low-code solutions that send client messages and highlights product interface changes, hence was not seen as development tasks;
… as a consequence, it was not seen as teams’ duty (or part of the DoD 1.0).
The teams controlled physical releasing of features to servers
… but controlling (switching on) feature onboarding information was in the hands of the “onboarding group”
Due to a rather complex feature release process (slow roll-out with canary releases), it was typically unclear for the onboarding group who of the clients have access to the features already and who doesn’t
… and because two different groups have parts of the information, it typically took some time to clarify feature release status
… also to stay safe with displaying feature onboarding info, it was better to be later than early (as not of the clients might have physically gotten the feature yet)
… and all of that caused delays between a) the moment a specific feature was released and b) was known to be released to the users.
That, in turn, delayed the moment the customer started to use new features
… and, of course, delayed feature feedback.
To make things worse, the developers used to start working on the next feature before getting and reacting to the feedback on previously released stuff because it was not clear to them as well how and when onboarding happens.

That’s why this part of the DoD – feature onboarding was so hot when we started to discuss the perfection vision and next steps. Likely, during our initial discussions, it became clear that there was a strong consensus about this issue and its systemic fix – giving parts of the onboarding process to the teams.

Feature Onboarding in DoD 2.0

Although it was clear that the Undone department dealing with onboarding would remain after the Flip Event, the teams agreed to include some tasks of onboarding that were initially out of their DoD:

Teams to improve communication of feature availability.
Teams to develop internal documentation that can be used by the onboarding staff to craft onboarding messages.
A feature is called done, when at least one client is using it successfully.

These were some of the first steps towards the perfection vision.

Improvements Raise New Impediments

During the early LeSS Sprints, teams embraced the new notion of the onboarding process, teams developed all the necessary documentation, and tried to reach out to the clients directly for onboarding.

That was a historical revelation. But as expected, it has immediately revealed some systemic impediments. One of them is the lack of special tools for teams to select suitable clients from the client base satisfying all the necessary hardware/software requirements. Reminder: Poster is in B2B business, so clients are restaurants with a rather unique software/hardware ecosystem.

In the spirit of LeSS, that impediment got addressed during one of the early Overall Retrospective. As a result, a cross-functional group of volunteers got together to resolve it. For that particular issue it was agreed that teams would initiate onboarding by selecting customer IDs (based on some requirements like hardware models and so on). And then involve specialists from the Customer Care department to help with phone calls and arranging for feature testing. Once that connection to the customers was set, then it would be teams to work directly with that customer, help with the set-up, gather feedback and iterate over the solution.

The onboarding department which had been historically alone on that battlefield was positively surprised and celebrated that change. Of course, they were still there and were responsible for producing educational content like the YouTube videos in multiple languages. But by expanding the DoD to writing internal and client manuals, and reaching out to the alpha-testing clients, the teams started to minimize hand-offs and speed up feedback cycles.

A short video clip below (in Russian) illustrates one of the first features Poster built, released, and onboarded just a few Sprints after the Flip Event.

The Path is the Goal

It is needless to say that we are still at the very beginning of a long and exciting journey ahead of us. We are committed to experimenting and applying critical thinking to assess our progress. And hopefully, one day we will be able to add a chapter: “50 LeSS Sprints Later…”.

And to highlight that we are not done and that the path to perfection vision is infinite, below are some observations from Poster colleagues on the recently observed challenges.

Kirill Reketskiy, Product Manager:

We had recently a precedent when an item that was taken to a Sprint was identified by a team as badly refined. So, it was taken off the Sprint for another PBR session to consider the new knowledge the team acquired on how to refine it better.

Furthermore, we have seen cases when at the PBRs we cannot find suitable product solutions or to find any solutions. We have introduced a new status for PBIs in the overall Product Backlog called “Prepare for PBR”. That is when a product manager needs to research a problem, works out the underlying reasons, motives of the necessary change, analyze whether there are similar cases within the product so that the UX stays congruent…

P.S. Russian Warship, Go F… Yourself!

Obviously, this wasn’t a part of the growth strategy, but on the 1st of March 2022 (a week after Russia started the war on Ukraine on the 24th of February 2022), Poster blocked the accounts of 10’000 Russian taxpaying businesses. The blocking feature didn’t just block Russian taxpayers to access the product, but was also educating them on the real matter of things – it was the war of the Russian Federation against the sovereign country of Ukraine.

It took just several days for the company to change its global strategy and exited its largest market, losing a good half of its customers. You never know when and how you will need to adapt. So be always ready can pay off anytime!

In the fall of 2023, half a year after losing 50% of its customers and within 200 days of the war, Poster returned to being a profitable business.

Strong resilience comes with high adaptivity.

References

Change process:

Kotter: https://www.kotterinc.com/8-steps-process-for-leading-change/
Ahmad Fahmy: Gemba Sprints
Craig Larman Larman’s Laws of Organizational Behavior
Alexey Krivitsky: Studying LeSS Adoption at Poster with Org Topologies Scans
Dr. W. Edwards Deming: The 14 Points and “Out of Crises”
Alexey Krivitsky Extract Team Leads

LeSS Flip

Ahmad Fahmy: How to form teams? A story of self-designing teams
Mark Bregenzer: Teams Self Designed
Alexey Krivitsky: Org Topologies study of org archetypes at Poster

Technical:

Martin Fowler: Feature Toggles (Feature Flags)
Martin Fowler: Patterns for Managing Source Branches
Paul Hammant: Trunk-Based Development

Requirements:

Alexey Krivitsky: What if I tell you requirements are like bubbles?
Alexey Krivitsky: Try Impact-Driven Product Backlog

Product:

Kent Beck: Product Thinking podcast
Henrik Kniberg: “How Spotify builds products” (use with caution!)

Other Resources:

Poster

LeSS Adoption at Poster POS Inc. in Times of COVID-19 and War

Table of Contents

Preamble (by Candlelight)

About Poster And This Case Study

Scope Of This Case Study

Inspiration and Appreciation

Company and Business Context

COVID-19 and Remote Work

Product Development Before LeSS

Component Development before LeSS

Product Owners at Team Level

OKRs and Contract Game

High Defect Rate

Internal Product Complexity

Engineering Practices

Product Stabilization Period

Quality of User Experience

Overall Development Capacity

Quotes from Employees

Designing the New Organization

Optimizing Goal

Owning the Change

Key Ingredients for Change

Educating Everyone

The Product Owner at Poster

Designing Organizational Blueprint

The Initial Org Design

Defining the Product Broader

Getting Rid of Product Areas (Simplifying Org Design)

Perfection Vision

LeSS Flip Event

Format and Agenda

Feature Team Self-Design Workshop

Colocated, Remote, or Mixed Teams?

Culture Follows Structure

Remote Work, Learning, and Loyalty

Team Formation

Teams Selecting Engineering Managers

Initial Product Backlog Refinement

Creating Definition of Done

Refining and Detailing Items

Sprint Planning I and II

On Choice of Tooling

Closing the Flip Event

First Twenty LeSS Sprints. Observations and Lessons Learned

Perception of Speed

Rushing Makes You Slower

Going Slower is Going Faster

Product Backlog Management

Overall Flat Product Backlog

Product Owner’s Team

Remote Meetings and Multi-Team PBRs

Product Support Process

Engineering Managers

Engineering Managers Doing Gemba Coding

Managers as Scrum Masters

Engineering Community and Pull for Engineering Practices

Pain of Long-Lived Feature Branches

Lack of Feature Toggling

A Pull for Change

Evolution of the Definition of Done

Feature Onboarding in DoD 1.0

Feature Onboarding in DoD 2.0

Improvements Raise New Impediments

The Path is the Goal

P.S. Russian Warship, Go F… Yourself!

References