A full-fledged detailed LeSS case study of Poster POS Inc. that happened in times of COVID-19 and the war.
Part 3: "Flipping the Org"
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
Creating Definition of Done
Initial Product Backlog Refinement
Sprint Planning I and II
On Choice of Tooling
Closing the Flip Event
LeSS Flip Event - Forming the Teams
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.
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.
During the team self-design workshop.
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.
Initial Product Backlog Refinement
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.
Initial Product Backlog Refinement (PBR)
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.
Closing the LeSS Flip event
Yuliia Kastierova, a QA engineer says:
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 says:
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.
End of Part 3.