A full-fledged detailed LeSS case study of Poster POS Inc. that happened in times of COVID-19 and the war.
Part 2: "Designing New Org"
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 Fake Requirement Areas (Simplifying Org Design)
Perfection Vision
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. The 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 sais:
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 sais:
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 sais:
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 Fake Requirement 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 (one feature team to start validating product-market fit)
Why the three areas? (And how eventually we got rid of them as they were not necessary?)
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.
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 Fake Requirement 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 Requirements 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?
Posted 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 small Requirement 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.
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
Results of Perfection Vision Workshop
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.
End of Part 2.