Poster POS Inc. (or Poster) is a cloud-based SaaS automation for small-to-midsize businesses in the hospitality industry, also known as HoReCa (Hotels-Restaurant-Catering).
The business was founded in Ukraine around 2013 and has shown a very high level of resilience since then. The HoReCa industry has been severely affected by Covid-19 and by the Russian war on Ukraine in 2022. Still, the company restored its profitability and even grew its B2B clientele in Ukraine during the wartimes.
In 2021, the company has undergone serious reorganization, striving to increase its adaptability. Poster was inspired by the ideas from Large-Scale Scrum (LeSS), such as global optimization with a whole-product focus and delivery of high-value work with customer-facing feature teams.
This case study analyzes that transformation journey using Org Topology™ Scans (org scans). It covers three distinguishable organizational designs:
Org scan of the status quo in Poster before the LeSS adoption, "Team-level Scrum"
Org scan of the envisioned initial LeSS-Inspired blueprint (which drawbacks we timely rethought and eliminated)
Org scan of the improved LeSS-Like org design implemented in 2021 as the scope of this LeSS adoption.
The following chapters describe these three OT™ scans in detail.
Heads-up! Video is Available
There is also a talk by Alexey Krivitsky from the LeSS Conference 2023 featuring some of the ideas from this article:
1. Org Scan of the Pre-LeSS Structure "Team-Level Scrum"
Before the LeSS Adoption started in the summer of 2021, Poster had around 50 engineers in the R&D department that were structured as:
a dozen of development teams varying from 2 to 6 people; teams were built around a specific technology, a component, or a feature set;
one separate infrastructure/operations team of several people;
one small designer group, whose members mainly worked on individual task lists to support the development teams with visuals and UI sketches.
According to the Archetypes of Org Topologies™, the development teams can be classified as Y1 (component development) and A2 (development of a narrow feature set). What is typical for these archetypes is that every team had an individual team-level backlog (task/feature list) that was managed by a team-level "PO". Most of the teams, especially the bigger ones, also had a team lead - an interface person for the team and the ultimate solution-oriented decision-maker. The designer group can be seen as a Y0 (individual work).
Two more departments, tightly coupled with the R&D were the "client onboarding" (3 people) and "1st & 2nd-line support" (25 people). This case study doesn't go into the details of those departments, keeping a focus on R&D and its radical transformation.
The illustration below shows an org scan of Poster product department as of the summer of 2021 with Y0, Y1, and A2 archetypes.
Analyzing the "Team-Level Scrum" Org Design
According to the Org Topology™ mapping, all the archetypes of Team-Level Scrum are at the lowest levels -- they provide close to no organizational adaptability as they are narrowly specialized in tasks and individual features. That was why Poster wanted to improve its org design and planned the restructuring.
The "Team-Level Scrum" org design is typical for many product development organizations of any size. It grows naturally as a company hires more people and forms new teams. It is also known as the "copy-paste Scrum adoption" antipattern, where Scrum is implemented as a cookie-cutter for each newly formed team. Scrum in such an organization is seen as a team-level way of working, where each team gets its own backlog and a backlog owner and starts working with iterations that are typically non-synchronized among the teams. Such an approach allows the teams to run a Scrum-like process individually. And from the team perspective, this is an efficient way of working, as it allows teams to keep focus and ownership on given product components or some narrow feature sets.
This org design is also relatively easy to implement, which is why it is so widely adopted in the industry. But as the number of teams grows, additional complexity caused by inter-team dependencies increasingly slows everyone down. Hiring professional managers and applying project management tricks just make things worse. These practices add communication layers with hand-offs, bureaucracy, and processes to an already poorly designed engine.
In such a model, even though each team has a sharp focus and might even have an illusion of progress by ticking off items from its individual backlog, the performance at the organizational level tells a whole different story. At the level of the R&D department (not just individual teams) in such organizations, we see slow delivery and low adaptability. This is a systemic view: paying attention to the interaction between the parts is as important as studying the parts.
The lack of maneuverability (teams cannot easily switch to working on new things, as they don't have the necessary knowledge and skills), causes this type of organization to hire more specialists to perform specific tasks. This makes the system even more complex and degrades over time. Our experience is that at the size of around 50 engineers, these challenges start to emerge and become painful enough to make managers want to act on them.
By the spring of 2021, the leadership team at Poster had recognized these drawbacks and was actively searching for an improved org design that would eliminate the forementioned problems.
2. Org Topologies™ Scan of Initial LeSS-Inspired Org Blueprint
LeSS promotes org design based around long-lived cross-component cross-functional customer-facing feature teams. Such teams deliver and learn much better than narrowly specialized ones. By learning to work on things that they previously didn't know, feature teams continuously improve their adaptability. Therefore, the whole large-scale product development system based on feature teams could potentially over time get better at delivery and better at learning.
These qualities enable faster value delivery and higher organizational adaptability:
Faster value delivery comes from having teams that are learning to build products end-to-end.
Higher organizational adaptability comes from teams that are learning to work on the whole product.
If the company's optimizing goal is faster value delivery and higher organizational adaptability, the LeSS-inspired org design is the most consistent with those goals.
In such an organization, the product owner will only have to re-order the product backlog items to change the course of development for all the teams. No reorganization is required to re-align the product development organization to adopt a changed product strategy. The product development organization is agile and can adapt to changing requirements just in time. Already during the next refinement session (in LeSS terms "multi-team product backlog refinement" or PBR) the teams will start learning that new high-value work.
At Poster, the leadership team plus all the developers and business stakeholders were trained in LeSS and its ideas before adopting this org design. It took around two months to arrive at informed consent on which org design to use. During that time, several org design blueprints were created, compared, and contrasted. The following illustration depicts a scan of the anticipated org design blueprint (later it was discarded due to the reasons listed below).
This org design consists of three "value areas":
B2B (the core product).
B2C (the new, innovative product development).
Growth (product tuning to increase customer activation and retention).
The B2B area was the largest and was planned to have the biggest investment. Four feature teams were planned to share a single product backlog. Very much a LeSS-like structure. This design can be classified as B3.
The other two areas had fewer investments and were to have a single team each. They are A3-level as each team would have an individual feature-centric product backlog, i.e. having a relatively narrow product focus.
No changes for the infra/ops team and the designer group were planned.
Analyzing the Initial LeSS-Inspired Org Design
As it can be clearly seen from the org scan above, several single-team value areas were envisioned (B2C and Growth), even though the leadership team at Poster had already embraced the idea of LeSS and broader product definition. What was driving the management to choose a sub-optimal org design? And what were the shortcomings of such an org design? Why not allow all the teams to work together on the entire product as LeSS proposes?
From our experience as org consultants, the most voiced arguments for creating narrow-focused single-team value areas are:
Investments & Innovation: "As we have never been able to work on X and Y, let's create an X-team and a Y-team".
Experts & Ownership: "There is an expert in Z, let's make her a product owner and give her a Z-team".
Focus & Accountability: "Teams need to have a clear focus and accountability for each component; otherwise the code becomes a mess".
Learning & Specialization: "Knowing everything is impossible, we value and need the specialists".
We often hear these kinds of objections when a LeSS-like org design is proposed. At Poster, it was a mix of the first two arguments that produced the initial blueprint.
Such arguments are hard to counter, as they stem from deep beliefs in the convictions of the leaders. They have not yet seen a different set-up than their own, and all their experiences and career successes confirm that what they already know is working. This confirmation bias automatically disproves all new ideas.
An organizational design is the sum of the mental models (beliefs and value systems) of the people who created it. But all mental models are personal. If we want the managers to own (create and support) a new improved org design, there is not much choice but to work with them to help them see new options, help them challenge, and eventually have them adapt their mental models.
The breakthrough of discarding this model and going with a simpler org design (LeSS for all the feature teams) came from a realization that B2C and Growth can still be worked on, if needed, even with all teams sharing the same product backlog simply by setting the order of the items. Also, the people from the teams voiced a strong argument supporting wider collaboration of the teams: "Let's learn to work all together as one, isn't that why we want to go with LeSS in the first place!?". To make such powerful conversations possible, during the preparation/learning phase, all the team members and the management representatives were regularly gathered for open-space-like events. That shared context helped them to uncover and collaboratively agree on many open questions. Eventually, building informed consent to start with a simpler holistic org design, is described below.
The real goal of the org design activity is to create the simplest org design possible that would still work. More processes and roles can be added later when needed. But starting with a simpler org design empowers the people to own it and improve it.
3. Org Scan of LeSS-like Org Design at Poster
It took us several months to arrive at a simpler org design with no single-team areas. An org design that everyone was happy to start with. An org design that would barely work, but was understood by everyone to own it from day one. The improved org design would have all the feature teams sharing work and working across the product. That would classify them as C3-team.
Analyzing Org Design: "LeSS for the Whole Product with All Teams"
This simpler org design covers many raised concerns above:
Investments & Innovation: In this org design, when there is a need to work on Y or Z, these items simply get prioritized and put higher on the common product backlog. And then the teams (one, several, or all) will start working on them. There is no need to create specialized teams. If, for instance, the B2C or Growth topics become the most important, nothing stops the Product Owner to put those items on the common Product Backlog and let the teams start to refine and deliver them. This way, in every Sprint, the PO can decide with the teams how many teams should be working on these topics. This creates a fluid org structure where pairing between teams and topics happens just in time. In contrast to statically defined separate org units (value areas) per topic. This way, an organization stays highly adaptive, as it can decide to jump on any opportunity without any re-organization efforts.
Experts & Ownership: Shared work on the common product backlog by all the teams leaves a lot of room for collaboration with experts. But this collaboration happens only on high-value work (just-in-time). Such a modus operandi eliminates the creation of proxy or clerk-type product owners. And welcomes the teams to work with many different experts and keep learning from them.
Focus & Accountability: Good focus and a strong feeling of ownership in teams are still possible, even if they work broadly on the whole product together. This can be achieved by applying practices of Continuous Integration, Mob Programming, multi-team work sessions, and other means of inter-team decentralized coordination.
Learning & Specialization: Specialization is great. And learning to work broadly on a product by delivering customer value is great, too! These goals are not mutually exclusive. There is no false dichotomy, as we need them both. The LeSS-inspired org design allows the teams to pull items that they are capable of doing (utilizing their existing skills) as well as working with other teams on new things (acquiring new skills).
As is seen in the next illustration of a flow scan of Poster after the change, tight multi-function collaboration and the presence of feature teams contributed positively to shortening lead times for features. A big change for the developers was expanding the Definition of Done to include non-development activities like customer onboarding. Now, a feature is seen as done only after the first customer(s) use it. That created a powerful feedback loop to the teams and affected the way they design, work on, and deploy the features.
Weekly collaborative requirement refinement sessions became a collaboration opportunity for all the stakeholders and the experts: customers, product managers, designers, representatives of the support department, client onboarding, and engineering managers gathered with the feature teams. That accelerated the processes of forming requirements. And importantly, it has ensured a much better shared understanding of what is expected to be done. This process contributed to minimizing lead times for features not only by reducing waiting for specifications but also due to minimized rework because of improved alignment.
Note, how the collaboration style of many groups has switched to facilitating, supporting the work of the heart of the new org design -- the feature teams.
Conclusions
The described LeSS adoption at Poster and its detailed org scans can be illustrated as an org topologies mapping provided below. Y0, Y1, and A2 archetypes were mainly converted to a C3-level organization practicing holistic product development and optimizing for adaptivity in learning and delivery.
Observed Adaptability and Resilience
Since the end of summer 2021, Poster and its feature teams have been operating in this new mode. They went through and recovered from the Covid-19 lockdowns. Now, as of writing, this case study in winter 2023, they have spent almost 300 days serving its impressive B2B customer base during the wartime in Ukraine. They even managed to grow their clientele, a real sign of high resilience!
Business resilience comes from high organizational adaptability. And high adaptability comes from an org design that enables and nurtures it. Therefore, org design is an essential skill to be mastered by management.
© Written by Alexey Krivitsky and published with permission from Poster POS Inc.
This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.
