Stéphane Lichtenberger& Samuel Chapal - LeSS chez Esker

[00:00:06] Well, good morning everyone. Uh, we're going to keep warm during this conference.
[00:00:12] Uh, so we're going to present to you a feedback from Less at Esker. So Less, what is it? It's Large Scale Scrum.
[00:00:23] Uh, and Esker, that's the name of the company where we work, Samuel and I.
[00:00:31] And thank you for coming in numbers.
[00:00:34] and many. Shall we introduce ourselves?
[00:00:35] Yes.
[00:00:36] Let's go. Uh, so, as Stéphane said, I, we work at Esker, I'm Samuel Chappal. I'm a Scrum Master in an SRE team at Esker.
[00:00:48] And uh, and for my part, I've been with Esker for about two and a half years.
[00:00:52] Alright, and I'm Stéphane Lichtenberger. Uh, I've been working at Esker for over 20 years. So when I arrived at Esker, we were, uh, it's quite unusual, we were 30 and now we are 1000. This is to give you an idea of the scaling at Esker as well.
[00:01:10] Well, if you have any questions about the history, it will be for Stéphane.
[00:01:13] There you go. So what do we do at Esker? Uh, we provide a solution that automates uh repetitive or low value-added tasks in finance, uh purchasing, and customer service. So it's all done on a SaaS platform. Uh, and so what you see on the diagram, that's the marketing slide. You see two cycles, uh on the left side, the source to pay cycle, that is, it's the supplier cycle, from uh searching for suppliers, managing contracts with suppliers, purchases, supplier accounting, expenses. And on the left side, the order to cash cycle, uh so more precisely the customer cycle, from receiving an order, managing customer requests, invoicing, complaints and reconciliation, payments and reconciliation of payments.
[00:02:07] I didn't understand anything, it's too complicated, you'll have to explain it in a more basic way.
[00:02:09] So I made a slide for third-year interns who come to do internships with us.
[00:02:16] That's me.
[00:02:22] So, we work in the B2B world, meaning companies that do business with other companies. Obviously, it's a bit different from B2C where you go to a store, you buy a product, you pay for it, and you leave with it. Companies have found a much more sophisticated way to do business together with a very complex flow of documents. So that can start with an RFQ (Request for Quotation), meaning a request for a quote. Uh, the supplier will respond with a quote, then the customer will send an order. Uh, which will be confirmed by an order confirmation, a delivery notice. Then, uh, we'll send an invoice, potentially the customer can make a complaint. And then we will receive a payment notice and a payment notification from the bank. So our product, it does, uh, it processes all these this flow of documents, so there's a lot of dematerialization. And also the processes that are associated with each of these documents, uh either on the left side or on the right side. So for example, for an order, well there will be a whole purchasing process on the customer side. And on the supplier side, for an order, well we will check uh the stocks, the availability of products, prices and so on.
[00:03:44] Anyway, it's simple.
[00:03:45] Yeah. It's much simpler.
[00:03:50] OK. Uh, and so to do all that and manage these relatively complex processes, as you understood, we can give you some figures to help you locate where we're coming from. So, uh, in particular, we are part of R&D at Esker.
[00:04:05] Uh, so Esker is vast, we're only talking about the research and development part. Uh, it's about 2, it's more than 200 people in R&D who are essentially all located in France, in Lyon. Uh, we also have a few R&D members who are in the US and Asia, but for the most part, we are in France. Uh, and we are organized into Scrum teams and we have about 30 Scrum teams. We will spare you the details of the entire breakdown of all the teams. Uh, but it's to give you an idea of the size, it's uh, there you go, it's about 30 Scrum teams in Esker R&D currently. And this has been going on for some time. So as I told you, I'm more recent in the history, but uh we are at uh more than 325 sprints, which means that it's been uh
[00:04:54] it's been since 2012 that we've been iterating and doing sprints with these Scrum teams. Of course, the current number of Scrum teams was smaller 12 years ago.
[00:05:04] Yes, so 12 years ago, we started with four Scrum teams. And we had a trainer uh to whom we said, "But Scrum is made for a team of 5 to 9, and we already have four teams working on the same software, how do we do it?" And she told us, "It doesn't matter, Scrum is enough." And uh in retrospect, it wasn't such bad advice. Uh, that is to say we tried to stick to that, and then scaling, it was emergent practices of Scrum teams. And little by little, we recognized ourselves in the Less framework, but without necessarily uh starting with Less from the beginning. Initially, we simply tried to apply Scrum uh by the book.
[00:05:50] Uh, so we produce about 100 features per sprint that are put into production, so every two weeks. Our clients can inherit about a hundred features that can be activated or not. They are not necessarily all active at a given time. We have 3000 clients, 1.25 million users and 95 million transactions.
[00:06:09] So when we talk about transactions, it can be invoices, orders, delivery notices, payment notices. Uh, these are documents, it can be PDFs, Word documents.
[00:06:19] All, all the arrows of the diagram for the third-year intern, you have to explain the diagram to them just before.
[00:06:25] There you go.
[00:06:28] So we've introduced ourselves, but uh we also need to know a little about your positioning. Uh, so, who in the room practices or has practiced Scrum already? If you, if you are, if you recognize yourselves in that, please raise your hand. Wow, it's unanimous. That's great, because we said "We have to assume that people know Scrum because otherwise we won't re-explain Scrum." Thank you. If ever you're lost in uh you can ask your neighbor, necessarily, your male or female neighbor apparently has done Scrum.
[00:07:00] Alright, who here knows Less or has already practiced Less?
[00:07:05] Okay, so it's me. Nice. And another framework, are there people who have practiced another agile framework at scale?
[00:07:15] Okay, so there are repeat offenders of multi-frameworks.
[00:07:21] Okay, great. So what we decided for this presentation is uh so we told you it's a feedback. Uh, for that we will follow as a guideline the Less principles. So Less defines a certain number of principles uh which it encourages us to use. And uh we thought it was a good opportunity in fact to concretize some of these principles by illustrating how we experience them at Esker. And so we're going to follow this element as a common thread. So if you click a little bit, there you go, hop. Uh, that said, we are not going to present, we are not going to go into detail on all the principles of Less because otherwise, well, it would take us all afternoon, uh, or more. Uh, we decided to zoom in on some. So in particular, we're going to talk about a principle which is, so Less, Large Scale Scrum is Scrum. And uh, and so we'll come back a little bit to uh how much it resembles Scrum. Uh, which means you also find other principles like transparency, empirical process control which are very, very linked to Scrum, I mean they are an integral part of uh of what Scrum is.
[00:08:31] So we'll focus on this one, but you can, well, since you almost all know Scrum, you can uh uh imagine what we're talking about when we talk about transparency in empirical processes. We will talk about More with Less, of focusing on the entire product. Uh, and there are certain parts that we will skip, uh being customer-centric, that's a Less principle. Uh, continuous improvement to perfection, which concerns both the organization and the product. Uh, well, we won't focus on continuous improvement today, maybe next year, we'll see. Uh, we won't talk to you about Lean thinking, but we're at Flowcon, so it's possible you have some ideas of what Lean thinking is. Obviously, we would need an entire conference just on that, and there will be some over the two days.
[00:09:23] In Less, we also find the principle of uh of systemic thinking. Uh, of considering uh the problems from their systemic aspect, we saw a conference this morning for example which which dealt with that in the field of SRE. Uh, etcetera. Uh, and so we will focus for this presentation on Large Scale Scrum is Scrum, Whole Product Focus, More with Less, and uh Queuing Theory because we thought we should talk a little bit about queuing at Flowcon.
[00:09:56] And so to start, we're going to talk about, well, Large Scale Scrum is Scrum. So it's Scrum, but it's a slightly different Scrum because it's a Scrum approach at scale.
[00:10:07] And uh, as this principle is described in the Less documentation, uh the phrase we chose to define it is, Less is uh, it's Scrum with several teams.
[00:10:20] It's not a collection of several Scrum teams. Uh, what this principle means is that truly, the principle of Less is not to create a framework that would be built around Scrum teams.
[00:10:35] And which would add a set of principles and practices around the fact that there are Scrum teams. I don't know if you know any frameworks of this type. It can exist, uh imagine, there you go, having more, I have Scrum teams and in addition I add roles, practices and so on that make me scale.
[00:10:54] There are such proposals that exist. There you go, but so what Less really wants is to say we keep the principles and practices of Scrum and we are able to apply them at scale, almost by adding nothing. So maybe we'll make that a little more concrete.
[00:11:13] Uh, and so that's really the Less diagram that summarizes how Less works, in which you'll effectively, quite easily, find your bearings compared to the practices and roles you have in Scrum.
[00:11:28] So if I try to summarize it for you and in particular to focus on what might be, well, what's different with Less, well, the basic idea, obviously, is that Less is practiced with several Scrum teams. So here we find that each line is somehow a different Scrum team, okay? And uh, and so what allows us to scale is that we have several teams working together and working together on the same product. We'll come back to that a bit later.
[00:11:56] Uh, and in terms of, so in terms of roles, we find exactly the same roles as in Scrum and no additional roles. That is to say, we have uh development team members, uh Scrum Masters and a Product Owner. And somewhere, there's a basic principle in Less which is that these several teams will be there will be only one Product Owner who will be uh attached to these different teams. In terms of size uh for Less, uh a Less organization is between 3 and 8 Scrum teams maximum, okay? Which will have, so the team sizes are those defined by Scrum and uh which will have one or more Scrum Masters, that's something we have a bit of leeway to determine the number of Scrum Masters we estimate we need to make the teams work well. However, they will indeed share the same backlog and the same Product Owner and they work on the same product. Okay?
[00:12:58] In terms of progress, well you'll find at the beginning of the sprint uh really the same things as in Scrum. So we work by sprint, for us sprints last 2 weeks. Uh, which is the same for all teams. And uh and we start a sprint with a sprint planning. And this sprint planning is done in two parts. The first part, sprint planning part 1. It's more a step where the Product Owner will present the objectives of the sprint and where the different teams will distribute what needs to be done, will distribute the backlog items among themselves. Well, we've gotten into the habit of saying stories and using that language among ourselves. So the Product Owner arrives with a series of stories and uh and they are dispatched among the teams and it's the result of a discussion. And in the sprint planning 2 part. There, it's each team that does this part uh separately and that will work on the elements it has selected. So you see in this diagram that planning 1 is common to all teams and planning 2, in fact, is a meeting of each team separately. And with that, we start our sprint.
[00:14:07] So, roughly in the middle, there's an event called Product Backlog Refinement, PBR, which is more important in Less uh than in Scrum. We spend, in theory, it's one day for a 2-week sprint, uh in my team, for example, we spend half a day. Uh, it's an important inter-team event. So you see the inter-team events, there's sprint planning uh part 1, but part 2 is per team. And then at the end, we have a sprint retrospective that is common to all three teams, that's why there's no small black bar on the sprint review layer. Afterwards, there's a retrospective per team, so each team does its retro like in Scrum. And there is only one event added in the Less framework compared to Scrum, it's the overall retrospective. It's the only additional meeting that is done compared to Scrum, and it lasts one hour for us. And what's important is that at the end, there's only one gift, there's one potentially shippable increment, so all teams work on the same gift which is delivered to production every two weeks.
[00:15:19] So, it scales, in theory, up to 8. In my team, I am Product Owner of a Less organization of three teams. Uh, but as we told you at the beginning, we are 30 teams uh at Esker.
[00:15:36] So for us, what it brought us, well, is that it's the same roles. We haven't added any roles. That is to say, with us, there are no uh architects, lead developers, UX designers. There's only one role, it's team member uh for the teams, PO and Scrum Masters. We haven't added anything.
[00:15:55] And then it allowed us to maintain our delivery cadence. So we truly deliver every two weeks to production without adding any complexity.
[00:16:07] And then to scale to 30 teams, there's a second version of Less called Less Huge. So remember the diagram well, there will be questions at the end. No, it's quite simple, in fact, what we see on the diagram is three Less organizations stuck together with multiple teams. And uh it's called Less Huge, it allows to scale up to, I don't know how much, very much, in theory a lot. In any case, for us it goes up to 30 teams. And so in this case, there are Product Owners per Less organization, which is called Area Product Owner, that's what you see on the left, APO is Area Product Owner. Uh, in theory, there's a super PO uh who knows everything and is capable of prioritizing everything, the whole world.
[00:17:00] And in the end, the difference is also that we see there's no synchronization between the Less organizations, there are synchros between the teams within a Less organization, but not between the organizations. The synchro is done by a view on the backlog of the Area Product Owners. So each Area Product Owner prioritizes and discusses with their team. And then at the end, the difference is that there is still only one gift for 30 teams, there is only one increment, everything is put into production at the same time.
[00:17:36] Okay. So, there you go, uh thank you for staying with us after this short theoretical overview of Less. Uh, obviously, we promised you feedback, so uh the question that arises, uh, that we're going to delve into together, is concretely what we do at home. That is, we've presented the Less theory to you, we told you we apply Less, well, you'll see there are some nuances in what we do. Uh, and if we take a step back, in fact, the question that arises when we uh when we want to uh scale in Scrum, is that for me, there are really several possible alternatives.
[00:18:12] There's an alternative that resembles what we've just presented with Less Huge, which is to say I have my product which is huge, my product is growing. Because it's growing, I have more users, I have more features, uh unfortunately I have a lot of success, I'm making money and uh there are always demands and waiting. And so my product is destined to grow, and so I am uh, well, I am naturally led to just add the number of teams working on my product. So it's a scaling strategy, that is, a bigger product, I need to be able to have more teams working on one product.
[00:18:43] We are all there.
[00:18:46] And then there would be another agile utopia which would be to say, well, what's great about Scrum is the autonomy of the teams, so we really need to keep their autonomy. So we're going to have smaller products. So instead of aiming for a very large product uh that only grows, well, I break it down into smaller products and I'm able each time to have a Scrum team for each product and to distribute the workload in this way, that is, the more I scale, the more I make new products pop up and dedicated teams for that. And so with a very distributed system.
[00:19:19] And so uh the enigma for this presentation is that we are somewhere in between and uh you're going to have to guess where we are. And if you're wrong, well, you won't get the end of the presentation.
[00:19:30] There will be the answer anyway.
[00:19:31] No, there will be the answer.
[00:19:35] And so before you get the answer, we're going to talk a bit about uh a second principle which is Whole Product Focus.
[00:19:00] which only grows, well I break it down into smaller products, and I am able each time to have a Scrum team for each product and to distribute the workload in this way, that is to say, the more I scale, the more I make new products pop up and dedicated teams for that. And so with a very distributed system.
[00:19:18] And so, the enigma for this presentation is that we are somewhere in between, and you will have to guess where we are, and if you are wrong, well, you won't get the end of the presentation.
[00:19:30] There will be an answer anyway.
[00:19:31] No, there will be an answer.
[00:19:35] And so, before you get the answer, we're going to talk a bit about a second principle which is 'Whole Product Focus'.
[00:19:46] So, when we scale, what we try to do is to keep, when we scale with Less, is to keep the focus on the whole product and not on a component or a sub-part. But the definition of a product, in fact, it can also vary over time.
[00:20:01] So, if I take my smartphone for example, maybe there was a competition ten years ago or more, on the number of pixels per photo, and it was getting bigger and bigger, etc. It was quite independent of the screen resolution. Uh, if we want a good user experience, knowing that today most of the photos, 99%, are viewed on the smartphone that took them, uh, the two must be aligned. So it can be defined as different products because it's so complicated that it needs to be cut up. But we could also consider that it's only one product and that's what the customer buys in the end, that counts. So that's what we're going to focus on in the end.
[00:20:47] So what is the product at SCR?
[00:20:49] Yeah. Because there, that was the complicated part.
[00:20:54] Uh, so I talked about it a bit at the beginning. In summary, we have two solution suites, one suite for the Source-to-Pay cycle, the cycle for managing suppliers, and one solution suite, Order-to-Cash, for managing the customer cycle.
[00:21:13] So that could have been a product breakdown.
[00:21:17] In fact, it makes uh... That's our big product, S4 on demand, with two parts. And so, in the end, it's enough to put a lot of teams on that product and we scale. That's what we did in fact.
[00:21:31] Well, yes, that could have been a possibility, but that's not what we did.
[00:21:34] Uh, because our customers, they rarely buy the whole suite, that is, both Source to Pay and Order to Cash, and even they don't often buy the whole of Source to Pay, the whole of Order to Cash, but as we scale at SKR, we sell to increasingly large accounts, uh, who could buy the whole suite, but we haven't decided to have 30 teams on the whole suite because it's still quite complicated if you see the next slide, in fact, there are 13 applications in these product suites. So the applications, that's what you see there, we call it a flower at home, and each petal is an application. And that's what customers buy. So for example, they can buy uh customer order management. It's the module called Order Management. And besides, when we started with four teams, uh we were selling four of these petals.
[00:22:29] Okay. Well, that's what I was saying, that we are perhaps more on that side, that is, we managed to cut our product into small petals and so on. And then we distributed petals to our teams and we grew like that. In fact, it's uh it's elegant, I think, as a way of doing things.
[00:22:44] Not entirely, Samuel.
[00:22:47] Okay.
[00:22:47] Our customers, indeed, they buy, when they buy customer order management, uh, it's the customer services that buy this module, but they can buy several, and then often what happens is that customer services buy the three modules of customer service. So here we have customer demand management, that is, mailbox management of customer service, customer order management and complaint management, these are modules that go together. But they can also buy four other petals, uh, which would be the Invoice-to-Cash cycle. That is, from invoicing until payment.
[00:23:21] Uh, these are modules that will be rather handled by the accounting department, uh, by supplier accounting, uh, by customer accounting, sorry. And they can actually buy any of these modules, not necessarily the whole suite, uh, independently.
[00:23:41] And so that's why finally, uh, we ended up dividing the world into three, a little bit by persona or by department at our clients'. Uh, to reflect, ultimately, the buyers at our clients' and the users at our clients'. So the Source to Pay cycle is procurement management, Customer Service is customer service, and Accounts Receivable from invoicing up to payment. And finally, that makes solution suites that are a bit in-between, where we don't sell everything and we only sell one solution among the 13.
[00:24:20] And then you can see that it's also quite complicated to be an expert in all the solutions, because there are 13 applications.
[00:24:29] And so the answer to the question was approximately there, that's approximately where we are located. That is to say that it's true that we are organized in a way that, uh, we actually have a set of large products with a series of teams, uh, that work on it. We are not in the model of only small autonomous teams, but at the same time, we have not chosen a model where absolutely everyone in R&D can work on absolutely any of the 13 petals that we presented of the product, because it requires in fact uh uh knowledge, if only business knowledge and context related to that. And so we have, uh, we have looked for, in fact, a compromise. Uh, and so we're going to show you that compromise right away.
[00:25:17] So there you go, the SKR R&D looks like this. Each of the big bricks you see there is actually a Less organization, so it's a set of teams that work on the Less model. But with different scopes, and we're not completely organized in a Less Huge model either, that is, one in which all these teams would interact at each sprint, even if necessarily there is work together. But we rather have a breakdown around the big suites, so as we told you, Source-to-Pay, Accounts Receivable, Customer Service. And we also have teams that are more on the platform part, uh that you see below, and who will have a more transversal role on everything that is uh the data processing part which is a very important element for us and which is actually used by all the layers above. On the part, uh, everything that is web framework, security, etc., where we also have teams, uh, that deal with that part and that both develop functionalities and ensure follow-up of the framework used by the other teams. And then my darlings because well, it's my team in fact, there's an SRE team that ensures operations and therefore the follow-up of the platform and the infrastructure. Uh, so this is the breakdown you'll find, where you also see that depending on the perimeters, we can find between today, because it changes all the time, but between two and five teams for each of the Less team groups.
[00:26:51] And to complicate Samuel's work a bit, or the framework teams', we also have business dev teams that create solutions that I absolutely haven't talked about on this framework or partners who develop solutions on this framework. Which are not in the petals that we presented. Which are not in the petals that we showed.
[00:27:12] So, just in summary, on this part, if you want, in a quite organic and empirical way, we gradually made a breakdown which is this one today, which can evolve over time in the future, and which is not entirely that of Less Huge, even if, in fact, we still take some principles from it. What's important too is that the business teams, so for example my team is Customer Service, can intervene everywhere in the framework. That is, we can enrich the framework, it will serve other teams. There is no limit between the business teams and the framework.
[00:27:47] Okay.
[00:27:50] So, we're going to continue with another principle which we're going to zoom in on, which is, what is the operation of each of these Less groups independently? And we're going to talk about queuing theory and uh so I'm assuming that we're at Flocon, you must know what we're talking about, uh with really the principle that a queue must both be optimized, make sure that our response time to expectations is as fast as possible. And also, we're going to try to avoid creating unnecessary queues. However, if we want to optimize a queue and have a fast response time, what we need to do is to eliminate bottlenecks. So we have a difficulty with that, it's that in Less, there's a bottleneck that's hardcoded into the framework. And the bottleneck, uh, it's, it's you, Stéphane. It's me.
[00:28:47] So yes, as you saw in the Less organization, when you add a team, you don't add a PO. Uh, and I was already very busy with one team. Uh, I had work for every day, you know. Uh, so prioritizing stories for two teams is more stories, etc. So how do we scale the PO? Now there is artificial intelligence. But uh at the time there wasn't, so there was one solution: burnout. But I preferred this option.
[00:29:18] And then there's the Product Backlog Refinement, which is a very important event in Less. Uh, because it's the moment when we're going to refine the stories, distribute them among teams, uh, cut them up. And in fact, the solution is that the teams become more and more autonomous on the functional aspects. That's why in our product breakdown, we really did a functional breakdown. So my team works every day, well, the Less organization, works for customer service, uh, so they know the functional aspects of customer teams very well. The team that works on Invoice to Cash will know very well the functional aspects of accounting or finance. Uh, and it allows them, in fact, to refine the stories, to break them down, to propose stories. We discuss all of that during the Product Backlog Refinement. So teams can create stories.
[00:30:09] Simply, we review them together at the PBR. Uh, that's what ultimately allows scaling the PO. It's to delegate more and more tasks. Uh, the definition of stories, the UX, the security aspects, all of that are criteria that are written by the teams.
[00:30:24] How does a PBR happen at your place, maybe you can tell?
[00:30:26] Yes, so I took a photo, it's our whiteboard. So we gather, it's in person, once every two weeks, it's on Thursday before the start of the next sprint, so we put that three days before the end of the sprint, because that way it stays in mind for the next planning. And we meet in person, so these are delegates from each team who come to the office, so it's, for us it's in person, but it's not the case in all teams. But we tried to apply Less really by the book. Uh, it happens like that, you have the timing, there are 30 minutes where I will present the stories that can be big or small. Uh, I'm going to talk about the goal of the next sprint. Then there are 45 minutes where the teams will break down into pairs or trios on lots of whiteboards. So we have a wall that is probably even bigger than that with whiteboards.
[00:31:25] We make mixed teams, that's what you see below, that is to say that the three Scrum teams try to mix for the definition of the stories. We talk about the functional aspects in the backlog refinement and they try to refine the stories. Uh, in this event we try to identify inter-team dependencies or skills that might be in one of the other Less teams or even elsewhere at SRE or in framework teams.
[00:31:54] And the goal of all this is also to come out with a bit of a gut feeling estimation. The story is S, M or L, these are T-shirt sizes. We're not going to discuss too much if it's S, M or L. On the other hand, if it's XL, that means it doesn't fit in the sprint. And in that case, what we try to do is simply what is the first step? What is the first step we can take to tackle this story that is too big and no one knows what to do with it because it's too big, in fact. So instead of saying we're going to study the story and make a big story mapping of everything that needs to be done, we're just going to identify a first step. And we try to take this first step. And we'll see at the next sprint.
[00:32:38] And so, for the anecdote, in my team, which has quite different constraints, SRE, we have a part of the team that is in the United States, well, we do it over several days, asynchronously, remotely, that's it, two different ways of doing the PBR. And we really have this latitude for each team to organize their meetings as they wish. Yes, there are other teams that do, for example, the first part during a day, the PO presents the stories. After, there's a day where the devs work on their side, and the next day they meet for the second part. Well, there are several, you have to adapt, you know. There is no recipe.
[00:33:15] And then yes, we have, we have scripts that take notes of everything that was said in the PBR for those who weren't there.
[00:33:27] So, in this objective of per-team refinement and more globally working in Less, there is always a challenge we have with the team members. You know that Scrum is about cross-functional teams, I have all the skills needed to realize all the stories, all the backlog items within a single team. So that's an ideal. When we scale, as you can see, the perimeter of the teams only increases, the functional perimeter, the technical perimeter, and uh, and so this challenge of being versatile and knowing how to cover everything, it's all the more difficult to meet. And so it's really this dilemma between versatility and specialization that we always have to negotiate. That is to say that our goal is to have versatility that practically allows any team that is available to take a backlog item and say, 'I'm going to work on it and we're going to deliver value,' and at the same time, we know very well that there are elements on which we will need expertise and we will have, yes, queues, bottlenecks. Because in that team, there is the specific expertise on that subject that we cannot do without. So our goal is always to improve knowledge transfer within the team and to take the time to help people develop their skills. But at the same time, there is no magic formula, it's not miraculous, we cannot always have the necessary skills for any new thing that we have to deal with in the backlog and we cope with it.
[00:35:04] Not a week goes by in my team without someone talking to me about specialization.
[00:35:11] And the last, I thought it was the last, yes, the last principle we're going to talk to you about is More With Less. So what is More With Less? Well, it's probably that I give you fewer resources, but I ask you to do more. No, it's not that. Uh, so, we really talked to you about how Less allows starting with a few Scrum teams and scaling and supporting this growth. Uh, there's also really this principle of saying, we don't need many more roles and processes to treat all the problems we face. And so really the Less approach is to say, don't add complexity to your organization to solve problems, rather rely on delegation, autonomy, in fact, in the teams, and you'll see that it will solve itself, as you said earlier, just do Scrum and you'll see it will go well.
[00:36:05] You have to have faith though, but we try to have it.
[00:36:11] Uh, and so we can see that, for example, at the role level, right, that we have at home.
[00:36:17] Yes, so the roles at our place, uh, well, they are displayed, the three below you know them, the Product Owners, the Scrum Masters and the teams. Uh, associated with the Product Owner role, we have a Product Manager who is more on the marketing side. So I have a colleague Product Manager who works on marketing, sales, price lists, uh, everything commercial. And we work a lot in pairs, I'm more on the R&D side. Uh, when there are customer events, we go together. That is, we try to talk to the customer. Scrum theory was 50% of the time, the PO must talk to the customer and 50% he must take care of the team. Uh, we try to do that.
[00:37:01] And then we have a VP of R&D who plays a bit the role of Super PO. So no, he doesn't prioritize his stories as the theory of Less Huge says. Uh, it's really the POs who prioritize the stories. From time to time, he will make big arbitrations on modules, for example, if there is a product where the backlog is full and another product where it's okay, the customers are served, the flow is continuous, he will perhaps arbitrate on big functionalities. Because there are functionalities that are common to all our products, uh, for example, user management. That any team can do, and which sometimes are so big that they would drown the backlog of a product and it wouldn't be possible to do it. So most of the time it goes to platform teams, but platform teams can also be overloaded, so it can be a feature team that takes on the subject. So it doesn't happen often, but from time to time it does, and generally it's still related to the product. That is to say that it's not a feature, a functionality, sorry, uh, that is completely alien to the product on which we work, for example in customer service, we are not going to work on functionalities that are truly accounting or finance.
[00:38:20] So he will simply be there to make big arbitrations.
[00:37:41] that any team can do, and which are sometimes so big that they would drown a product's backlog and it wouldn't be possible to do them. So, most of the time it goes to platform teams, but platform teams can also be overloaded, so it can be a feature team that takes on the subject. Now, it doesn't happen often, but from time to time it does, and generally it's still related to the product, meaning it's not a feature, a functionality, sorry, that is completely alien. that is completely alien to the product we're working on. For example, in customer service, we're not going to work on features that are really about accounting or finance.
[00:38:21] So he's just going to be there to do big arbitrations.
[00:38:27] Okay, and so as I was telling you, to achieve more with less process, less effort, or at least not too much, on what we rely on, it's really self-organization. So, self-organization, or teams that manage themselves, is something you find in Scrum, and it's, uh, it's about keeping this principle.
[00:38:47] while scaling up, that is to say, again, by not adding complexity to our organization despite the fact that we are 200 now. So I can give you a few examples. Oh, if you come back.
[00:38:59] You just spoiled the rest. Uh, so, so. So, some pretty simple examples, uh, so I was telling you, it's about teams with quite a lot of autonomy, I've seen quite a few in my career in several places. I think I think I've never encountered teams that had the level of autonomy of Esker teams, especially in companies of this size. Uh, an example is recruitment in my team, when we recruit a new person, actually our process is, we're going to have a certain number of people from the team, team members, who are going to volunteer to, uh, conduct the interviews, we're going to have two interviews with these team members after the HR has passed us the profile.
[00:39:43] Uh, if these interviews go well, that the uh five, six people concerned by the interviews meet and say yes, we're going, or no, we're not going, well, we hire the person. That is to say, there's no, we don't do a counter-validation by a manager, uh, we, uh, the team has the autonomy to decide, uh, to decide who it recruits. Another example is the tools, there's a lot of freedom of choice of tools at Sker.
[00:40:12] Uh, in my team, for example, we decided to use notion, it's perhaps a tool you know, and so we function like that, we are the only R&D team to use notion. But it's a great tool, that said. Uh, and other teams have chosen other tools that correspond to their uses, uh, and there's this freedom, in fact, there's no desire to standardize, to determine a single best tool and a single best practice for the entire R&D. If a team can say why it made the request to use a particular tool or something, then it's, it's, it's okay, it can be done. Another example that is recent and that, uh, that seems important to me, go ahead, it's the constitution of teams.
[00:40:56] So don't try to read what's written, you won't understand anything. But what is illustrated there is a workshop that we did. uh in November in my team, where in fact, we uh merged two teams and so my team has grown radically, we went from 16 engineers to 24 overnight. And we had to manage that, and obviously there was the question of, well, you saw the whole diagram earlier, how do we constitute the new teams now that we've done +50%? And, uh, well, the answer was, well, you're going to do it, that is, you, the team members, you're the ones who are going to decide how you're going to constitute the new teams. So that's what we find in this table, I'm not going to describe everything, but it's a one-day workshop that we animated.
[00:41:43] Uh, in which, in fact, we challenged, we constituted small groups of three people and each group had the responsibility, what you find there in each of the sheets with lots of post-its, each group constituted a proposal for team constitution, that is, they were three and had to say, okay, tomorrow, if we start with new teams, what's the best composition for you?
[00:42:03] Make the best possible proposal with three people. And we're going to have, so here we have seven, so, and then we organized a vote, a discussion, etc., to compose that, knowing that we had agreed on the criteria that composed a good team.
[00:42:18] And that's what we find above, that is to say, autonomy, versatility, a seniority balancing, that kind of thing. So it was to determine the important criteria for the team, let the team make proposals and vote for the one they prefer, in fact, and so the choice of division of these teams. which are therefore four teams in France, well, it was done by the team members themselves and not by a manager. Knowing that it was fun because while being a usual autonomous team, well, there was a moment when some team members could say, what if the boss decided and proposed the teams to us, that would save us a very difficult headache, and then in the end, you see, it went well.
[00:43:05] Uh, the last element of autonomy, I think, that's interesting to address, actually, is the whole question of managing dependencies. Because we told you, there are at the same time, in each group, several teams, and uh, and besides, well, there are silos, you have to say it, each of these group likes, they're used to working well together. They're comfortable in their own lane, and then sometimes they have to go talk to others. We're going to have dependencies to unblock stories, to, to move forward, to, uh, to give each other the means, for example, there are a lot of teams that can depend on mine. So how do we resolve these dependencies? Well, it's a bit similar. It's, uh, if possible, we're not going to go through the leads, we're not going to go through the Scrum Masters or whatever, but we're going to define patterns that allow us to manage that. So there's one that's very simple that's described in less, it's the pattern of travelers. That is to say, to say, a team needs an expertise that it doesn't have, uh, to do a story. I told you earlier, uh, we do versatility as much as we can, except when we can't. Well, if we can't and we're missing a skill, we're going to look for a good person, we're going to tell them, if you want to come with us for the next sprint, and that person, she travels, she's going to tell her team, if it's okay for you, next sprint, I'm going there.
[00:44:17] And then I help them do that thing, it has value, and we go for it. And in fact, it's negotiated at that level, everyone just needs to be well informed, and there's no, I'm going to say words that I hate, but there's no distribution of resources between project managers.
[00:44:30] Uh, so, it's really managed at the team level.
[00:44:34] Uh, another example is communities of practice, where we can have all sorts of problems, technical or functional issues that go beyond a single team and are common to several groups, well, in that case, in fact, we set up communities of practice that will discuss that technology, these issues.
[00:44:51] and how to make it live within the R&D, and uh these communities of practice, they will potentially also be demanding and emitting stories, and they will feed the backlogs with things that will allow to evolve, use new tools.
[00:45:06] uh uh remove technical debt. And really, when we can't do it, and we realize that we have a challenge that we had never seen but that lasts for a certain time and that really requires a particular team composition that we don't have, well, we create a task force and we give it an objective and they work together for as long as necessary and then they join their respective teams and it can work too.
[00:45:32] Here are examples of transverse initiatives also multi-team. Very regularly, about every two months, we organize a tech day, uh, whose main goal is to share good practices between the different teams. and to precisely bring out from the teams' fold the good practices, whether they are technical, especially technical or organizational, and that are interesting to know by others and that it spreads in the other teams.
[00:46:05] So, to conclude, because everyone is hot now, I think.
[00:46:07] Yes, it's been hot for a long time, I think.
[00:46:09] Yeah. Uh, so, for us, the scaling of agility at Esker, one of the fundamental values of Les, is to keep agility at Esker, so Les is really Scrum with multiple teams.
[00:46:26] That didn't fundamentally change what we were doing, it's just that we started doing it on a large scale.
[00:46:32] And at the same time, we're not either, we're not either, how to say, fundamentalists of the framework, I think we take a lot of good ideas and principles and for the most part, we stick to them, but if we find it useful to deviate, well, we deviate if we can explain it, I think it's okay.
[00:46:48] So, knowing how to adapt frameworks too, it's not because it's written in the framework that you have to do it like that.
[00:46:55] So the fourth principle, queuing theory, well, it's to delegate to the teams. So all the cybersecurity aspects, there's a COP, community of practice, cybersecurity that submits stories to us at the PO. Uh, there's a COP UX, there are inter-team communities of practice, and so we delegate a lot of POs because otherwise we wouldn't be able to prioritize all these stories.
[00:47:16] And also keep this principle of staying simple, trying to do simple things, whether it's in the way we organize, whether it's in the way we solve our problems, whether it's in the technical design of our products, aim for simplicity, that's what we try to do.
[00:47:34] And thank you all.
[00:47:36] Thank you all.
[00:47:44] We're on time.
[00:47:46] Are there any questions?
[00:47:51] Hello. Thank you.
[00:47:55] Uh, I'm going to put my foot in it, since you were talking about autonomous teams, I'm asking myself the question, uh, what is the role of the Scrum Master in this case? Well, what is the contribution? For me.
[00:48:13] Uh, well, it's an excellent question. You're putting your foot in it. Uh.
[00:48:20] Well, I think, well, autonomy, well, first of all, for a Scrum team, the role of the Scrum Master is to help them facilitate their autonomy, in fact. And, uh, typically, me, in fact, when I was immersed in this environment where, in fact, I went from, uh, accompanying a group of six, seven people to accompanying 15, 16, 20, the challenges are quite different suddenly and, uh, you have to determine or distribute these efforts. So, in fact, somewhere, there's even more need for autonomy within the teams, because the Scrum Master won't be able to have the same level of support with each and every team that he can have or that I could have, for example. uh, previously, when I necessarily had smaller teams, in fact, it's a bit like the role of the PO, but we're a little less challenged, so it transforms. After, if I, if I go, I won't be able to go into details because at one point I was thinking, I could do a talk on that, but.
[00:49:20] But it's clear that there are more challenges on the interaction between teams, uh, on or on a bit more radical changes, improvements that we can go looking for that go further and that in particular will involve several teams, and so it will be necessary to align them with each other. And aligning five people is not simple. Aligning 15 of them, or even 25 across two continents, is a whole other challenge and, uh, and, uh, and it's, it's quite fun.
[00:49:52] Voilà, I hope I answered your question.
[00:49:58] In any case, I can testify that the Scrum Masters are very, very busy and don't get bored.
[00:50:04] Uh, and the teams, well, rely heavily on them precisely to find ways to self-organize.
[00:50:11] So, I'm going to follow up with a question that's a bit of a continuation of what you were saying.
[00:50:17] Uh, for me, having worked in a LESS organization, one of the big challenges we had was precisely to avoid teams specializing. Uh, and in fact, we saw that they tended, despite a bit of what we recommended, to want to anticipate, for example, to tell themselves, ah, am I going to work on this subject that is in the backlog or not? And at that moment, we saw phenomena like, only people who feel that they are really going to work on the story participate in the PBR, and eventually, it made the teams specialize. How did you fight against that?
[00:51:00] So that's why I put a slide on it, it's because, uh, it's a permanent point of attention, in fact. So in particular, for example, when we composed, I showed you the workshop where we recomposed our teams, there's a basic principle that was re-established, it's to aim for technical versatility. Uh, in my team, it's a particularly important challenge, uh, because I'm not saying that in dev teams it's easy, uh, but at the SRE level, on the infra, we have a quantity of technologies to master that is just incredible.
[00:51:32] And, uh, it's true that it's, well, I would say the first thing is that it's not easy every day for the team members, that is, sometimes they can feel a bit overwhelmed by the level of scope they have to have in their heads to be able to work on what we're doing. So, yeah, it's a real challenge and at the same time, we also see the benefit, I mean, the goal is not to be in the religion of versatility, but it's to realize that in fact, over the year, our expectations, the things we have to work on, it's very cyclical. It, it varies, suddenly we can have a big challenge that emerges and that requires certain skills, we haven't touched very little for six months, and so we have to be able to adapt to that, and what allows us to adapt to that is versatility. So, so, we set versatility as a principle, when the team members say, yeah, but it's too hard, we should all be reunited, all the experts, stuff, well, we're going to say instead, well, there are already the PBRs for this kind of thing. Make dedicated appointments for that, etcetera. Uh, and then, uh, and then it's an element of empowerment and delegation, that is, saying, well, yeah, the best expert of our techno, of that techno, he's not, you know, he's not in your team, but I'm sure you can still get there. I don't know if that answers your question, but, yeah, thanks for your question because, yes, it's actually a really big challenge.
[00:52:51] And I was wondering another question, uh, raised by, uh, the point about dependencies management and the fact that there are people who are going to move from one team to another, sorry. Uh, and so I was asking myself the question about objectives. How, uh, how, are there objective management processes, at what level and how does that adjust, adapt?
[00:53:14] The scaddles.
[00:53:18] So me, in fact, I don't really manage that. That is, I manage my priorities.
[00:53:24] And, uh, and somewhere, I have an expectation that the teams organize around my priorities. So that also answers your question a little bit. That is, if I have three teams, if there are three stories that are expected by the clients at the end of the sprint, I'm going to try to put them as priority and I'm going to propose that they be distributed among the three teams. After, they will communicate with each other to transfer the skills they don't have. Because yes, they will, otherwise they will say, well, this story, uh, it's more likely to go there because they have the skills, and then that one, oh well, that one too, and that one too, and then in the end, there's a whole sprint that goes to one team and the other two do nothing. Uh, and that's not what happens, in fact, it's that the teams try to respect the priorities well and to take a little bit of stories from each.
[00:54:11] It wasn't the question.
[00:54:12] I'm going to try.
[00:54:15] About the objectives, for us, for a given objective, is there an a posteriori evaluation with the objectives that are in place?
[00:54:24] No.
[00:54:26] Ah. So that was the short version. It's clear that in a context, but I don't think it's specific to less or anything, it's that in an agile context, it's true that what we're going to expect from the team members, in fact, is really adaptability, to be able to be present when there are new, when we discover new things and we have to adapt, so somewhere, setting objectives in advance, long in advance, on which people will be evaluated in a very rigid way by saying, you have to have done that, while in fact we know that the priorities of the backlog will change, it's contradictory. So a very rigid management by objectives, I think that it's difficult to mix with agility. That being said, we can insist more on expected behaviors, that kind of thing. Uh, that being said, we can insist more on desired behaviors, that kind of thing, on being able to improve on such and such a technology, for example, so having slightly more generic objectives and that are realistic, but necessarily, if I have someone in my team who is going to say, uh, this year I would like to improve a lot in administration and OpenSearch architecture.
[00:55:36] And it turns out that during the year, in fact, we have enormous projects on Postgrez, well, he's going to end up doing Postgrez and at the end of the year we'll say, well, congratulations, you've gained skills on this techno and it's great, in fact, that's it.
[00:55:49] And the, the question is.
[00:55:54] I would say, I would say to be quick, the question is, are there collective or individual objectives, and I would say to be quick, there are individual objectives but which we try to make of the nature that I described to you. And, uh, excuse me for the collective objectives? No.
[00:56:11] I would say yes.
[00:56:14] I would say yes, the main objectives are to play the game of agile Scrum teams. So what we find in the job descriptions of team members is that, in fact, the objectives that we will evaluate each year. That is to say, teamwork, collaboration, continuous improvement. There's already, in fact, everything you need in Scrum to make a job description. And so that's what we evaluate, then we cross-reference that with experience. That is to say, depending on the skill development of people, we expect more from them, that is, impactful actions at the R&D level. So investment in communities of practice, in tech days, uh, in conferences, things like that.
[00:56:55] So, I have two questions, the first is, do you use your own solution internally?
[00:57:00] So that's a great question. Yes, we use our own solutions internally. Uh, not all of them, yet. Uh, not all and I'm thinking.
[00:57:15] No, it's already good that you use it, that's already good news. And the short answer is yes. A much more complex question, how do you guarantee architectural consistency both on the business side and on the technical side?
[00:57:28] So on the business side, we have meetings between product owners, uh, which are quite frequent. So, for example, I have a specific meeting for the next sprint with the VPR&D and the product owners of the Order to Cash cycle, because there's still a lot of interaction in Order to Cash between customer service and Invoice to Cash. And I also go to the other meeting on the purchasing side, because purchasing is the counterpart of, well, purchases are the counterpart of order processing with suppliers. Uh, we have PO meetings every week, uh, on the functional side. And on the tech side, I'll let you answer.
[00:58:11] I can try quickly. On the tech side, well, among other things, there are communities of practice, what we showed you in the organizational chart is that there's really this common technological base, really the internal framework that makes the different teams rely above all on common building blocks. And, uh, the other thing I can say too is how we guarantee consistency, well, sometimes there are divergences, and sometimes even there are teams that diverge and there are some that find better ways of doing things. And so I think that also goes with agility, it's to accept that sometimes we explore several paths and then we find some better, some not, and that's what allows us to move forward. So there you go, we don't have 100% consistency and that's perhaps not necessarily the objective. And I think we're at the end of the time, is that right?
[00:58:50] No, no, no.
[00:58:51] Let's go.
[00:58:51] Okay, I have the microphone, I'll take advantage of it.
[00:58:54] I had a question about team autonomy, you took the example of recruitment delegated to teams, I would like to know the other side of that coin, how do you decide to remove someone from the team, does the team decide that or not?
[00:59:13] Uh.
[00:59:15] So.
[00:59:15] Oh, wow. I said it was hot and it was hot. Uh, so, wait. Yes, so, in particular, so, there's the recruitment process, there's also the onboarding process during the trial period, that too is actually framed within the team, we have meetings in the middle of the trial period where, in fact, the team will give feedback to the newcomer and, in particular, we're going to say, are there things that are potentially at risk for you to stay or not, and what do we hope, what do we expect to change that would make it so that if it changes, well, it's okay and we'll high-five each other at the end of your trial period, and if that's not the case, well, at least we'll have been transparent about the fact that it's not working, and that comes up from the team.
[01:00:01] And, uh, for the more complicated cases, uh, if you have a magic recipe for that, I'd love to hear it, but, uh, I, uh, I would say that for this one, it's still quite a bit the Scrum Masters and the managers who take on their role of, once there's a certain number of feedbacks from the field, from people in the teams who say, there's really a problem, and often, well, that's where it comes from, well, at some point you have to take the plunge, and besides, in France, these are very long and complicated processes, and, uh, and that's what I would say there. And, uh, I suggest we do one last question because we're not staying on that. One last quick one, this stuff please.
[01:00:40] Thank you for this inspiring presentation. Uh, it looks so simple when you describe it like that. Uh, I have two questions. The first is, how, what are the first steps to go towards a LESS organization? And, uh, second question, what is the role of managers?
[01:01:04] We finish simple. Do you want me to go there? Do you want me to? So. The first step to doing LESS is to know how to do Scrum. And it's even valid for other frameworks that would be based on Scrum, imagine there are others. Voilà. And I often think we skip this first step. Uh, there you go. And I think that still, if we have a Scrum that works pretty well, that is to say that really we deliver regularly and that, well, this challenge has passed and there's really team autonomy and so on, finally, starting to do it with several teams, I'm not saying it's simple, but I think it's done organically.
[01:01:45] Yeah. Yes.
[01:01:49] The second part was about managers? So our LESS trainer told us, if you have managers, here's what you can do. Because it's not a role in LESS, but French law obliges that there is a manager who takes care of, who does at least one career interview once a year. So that's part of the duties of the manager. After, what to do, well, the product owner, he has his backlog, so the what part is managed by the backlog, the how part is more about self-organization, and so the role of the manager, it's reduced to little.
[01:02:24] The coaching, career management, and then sometimes offboarding. Of the team, it can be going to another team.
[01:02:37] But precisely, it's very little.
[01:02:42] Thank you very much.

Transcript (Translated)