Benoit Meunier, Mathieu Gandin
Transcript (Translated)
And we will present you with a feedback on the experience of transformation, the merging of agile teams in a significant continuous delivery context.
And at the end of this talk, here is roughly what you will leave with. A feedback on an organizational change in a continuous delivery context. The lessons learned from this change and our mutual feelings, Benoît as Product Owner and me as Technical Leader of the team on which the organizational change took place.
So before we start, we will give you a bit of context.
It's important because it's the foundation of what we are moving towards with these organizational changes that have been implemented.
So lesfurets.com, this site might seem a bit corporate, we'll go quickly, it's a comparison site for insurance. We have 5 insurance products: car, motorcycle, health, home, and borrower, for which we generate about 3 million quotes each year. And each comparison funnel varies between 40 and 200 questions to fill out. So there is a lot of material, elements that we modify on an ongoing basis. Precisely to be able to vary our business and have it work as well as possible. To make it work as well as possible.
We are organized, our delivery, we are organized around 7 business experts, 20-25 developers. With three future teams. One for all that is traffic acquisition, one to convert all this traffic into leads for us, It is on this team that we will give you feedback. And one more focused on infrastructure, so data management and DevOps tooling management. We all work as developers on a single codebase that is about 500,000 lines of code. And we have continuous delivery, we put the lesfurets site into production every day, except on Fridays. And so, as a result, we have from 1 to sometimes 3 releases per day. And all of this is in feature branching. So all developers are cloning branches and we end up with 20-30 branches in parallel every day under development.
I'll finish. All this did not happen overnight, Rome wasn't built in a day.
We started with an initial agile base in 2012 which was a monthly Scrum with a release of the increment at the end of the month. Then in 2013, we switched to a weekly Scrum with a release once a week. And finally, Benoît and I, who arrived between 2014 and 2016, were lucky enough to experience daily deliveries in a pull-flow Kanban which brings us to about 210-220 releases per year. And we are considering ways to streamline and simplify these things even further for the coming years.
That's roughly the framework set, and we will explain in more detail what happened.
What really interests us today is to give you a field feedback. I think that at a conference like the one happening here, There is often a lot of theory. In this case, you won't get much of that with us. What we are offering is rather the application, what we did, what we saw, what we were able to apply, theories that we studied and that we also received here.
And that is the starting point. That's what happened at Les Furets. We started with three teams. So, there are other teams at Les Furets, but we started with these three teams. You have a legend, I don't know if the colors are very visible, but you have in orange the business analysts, one per team. In blue, developers. So we are working with small agile teams. We simplified here, but it's rarely more than that. And you have in green, though it's not very visible, but it's in the middle part, the technical leader, specifically Mathieu, who was on one of the teams, while I was the business analyst for that team. Three teams. All functioning with a culture, which is a company culture of Kanban. We all know the theory of Kanban, more or less mastered, but overall quite mature on the subject, adopted, understood. Each team shares this culture but has adopted its own Kanban. Over the course of its own... own retrospectives and experiences, so methods a bit specific to each team. And then each team has a particular theme, deals with a specific subject, the management of our partners, so the insurers, mutual insurers, the way we communicate with them, how we transmit information to them, the entire tunnel part. Which are the forms. The forms, for us, are insurance comparison forms. They are often a bit long and there is a lot of business logic behind them. And then, a third theme is online subscription. I won't go into more detail than that. What is happening at this point in terms of team atmosphere? Everyone is living their own life, everyone is happy. We have three teams that are running, and apparently, there is no need to change. Except that a request comes, and this is the starting point of what we will present to you today, which is that our management tells us that these three teams deal with different facets of the same subject, which is conversion, conversion in the e-commerce sense, even if we are not really an e-commerce site. So we will merge these teams and it will be much better.
So we did it.
We created one team, but we continued to operate with the three different implementations of Kanban.
So, we had one team, for example, the team that was in charge of the funnels, what did we have? We had a board on Jira and a physical board on which we did our... stand-up.
We do a bit of remote work at Les Furets, so those who were remote were more like, I'm working on this feature on Slack, and if there are any problems, you can contact me on Slack. We had our own type of retrospective afterward. Another team, for example, the one more focused on partners, does everything on the board in Jira. The stand-ups are in person, and those who are remote join with a webcam and participate virtually, or remotely, in the stand-up. And in addition, since the partner part requires interaction with partners, all the insurers we integrate on our site, it requires interaction with salespeople and project managers at the insurers we integrate, it was useful to have the salespeople present at the stand-ups so they could synchronize properly.
The online subscription team also had its own way of operating. And so, when we started to mix all this, it didn't work at all. So, very quickly, it was not great.
And initially, there was a big surprise: why do this? After all, it was working well before. Why this forced organizational change? And so, resistance to change, ultimately, everyone thought, in resistance to change, since it was working, well before, we might as well continue in the same way as before. So each team's specificities ultimately remained in their specialization. So I, who was on the side of the teams more focused on funnels and therefore with front-end specificities, we said, we won't touch those ugly back-end codes, they're not nice to look at.
On the other side, those who were doing back-end, 'Oh no, the front-end is complicated, I don't want to go there, and the code is messy inside.' And then, ultimately, there was still the perception of our management who wanted this team merger to handle all the conversion. What's happening? It's not moving fast enough.
So we progressed, we played the game.
So we moved to the next step. The next step was to stop the hypocrisy a bit and say that we were one team, when in fact we were still three teams grouped under one name, but in reality, not much had changed. So we let the frustration, let's say, continue to build a bit from the management and from the team due to misunderstandings until it was no longer really sustainable. And so the trigger was to say, okay, let's stop this and merge our rituals. We started to say, we need a single stand-up. So we need a single board, so we had to make choices as well. Do we keep a physical board, a Jira board to allow those who are remote to consult it? These were more down-to-earth questions, very logistical in the daily management of the team. In any case, we managed to do that and found ourselves doing stand-ups. So I imagine that in the room, there are people among you who do agile stand-ups. Generally, it's pleasant when you're in a small group, when it's quick, when it's a bit disciplined, but when you start to be 12, sometimes 14, it gets a bit complicated. So we had stand-ups that weren't very effective. The team's feeling, not great. A huge backlog, tons of tickets, unclear priorities, because there are too many tickets, so we no longer know which ones to work on. In the end, by default, we revert to these basic behaviors, namely that I will take... The topic that was my favorite subject before. So we merged our rituals, but we continue to function much the same way. We have a team that is too large at this stage, it’s noticeable, and we have priorities that are difficult to arbitrate on a daily basis. What is the next ticket I’m going to take? And alongside this, we have an illusion at the management level that says, 'Ah, finally, they’ve managed to merge.' Now that we have a large team, things will go much faster. Except that in reality, we don’t have more people than before. They’re just grouped in the same place. And so, there’s this kind of misunderstanding where we are still wading through the mud, and management is growing increasingly impatient, having the impression that just because we are... All standing in front of a board in the morning, it works. That’s not the case.
So, we continued to reflect on how to improve, and ultimately, we arrived at this way of working, which is the current mode of operation.
So, one of the first elements that was quite transformative for the team was the awareness of the different roles and responsibilities within the team. So, one of the first things was that Benoît positioned himself as the product owner for the entire conversion team, whereas he was previously the product owner for one of the sub-teams. And it may seem trivial like that, but it wasn’t necessarily very clear initially. And clarifying it allowed for much smoother operations, particularly in choosing priorities. Since we are now three teams merged into one, but still with three strong major themes, we haven’t managed to say, 'I’ll stop one temporarily to boost another.' So we continue to move forward on all three themes simultaneously. So, integrating new partners, modifying front-end experiences to make the funnels much simpler to use, and optimizing the final steps of online subscription in our funnels.
And so, as developers, we thought it would be good to be able to work on any of the subjects. We started to move away from... specialization, in a way. But we realized we couldn’t impose this on everyone, because there are developers who wanted to say, 'No, no, no, I want to stay on my favorite subject, because, especially in partner integration, we have a developer who has been here for 10 years, knows it inside out, and it’s his choice, he doesn’t want to change.' So, fine, we’re not going to put a gun to your head, you stay on your favorite subject, and you’ll become the expert, the go-to person for partners. So, in a way, we’ll give you much more responsibility. And you’ll work in a pair with a business analyst who works specifically on partner integration. And the two of you will help the team to... Smooth out the entire flow of requests that come to us. And it’s up to you to find... And the other developers are there to help you, in fact, with these issues. We did the same with all the issues related to the funnel.
And the issues related to online subscription. So, each time, we have a developer and leader pair, a tech lead on the theme, with a business analyst. And the other developers, myself included for example, are part of a pool where we rearrange ourselves according to the demands of each of the three sub-domains.
And so we launched this, and as a result, things are going much better. We’ve returned to a state where the team is... generally happy.
And generally happy, why? Because it ultimately makes more sense. On a daily basis, since we were in a fairly complicated phase, we still managed to reflect on how to improve and find meaning in all of this. So the team improved, found meaning, and discovered an organization better suited to managing all these issues. And so, we started telling our management, 'It’s good, we’ve stabilized the team, don’t touch it anymore.' And so, now, management’s perception is that it’s working, so we won’t touch it anymore.
So, here’s a fairly factual account of what happened over a year with us, at Les Furets. We’ll go into a bit more detail about what happened within the team.
First, how did it go for the team? We were afraid of change. But at the same time, almost everyone thought, 'Okay, this change is scary, but we still have things to gain if we do it.' So even if there was initially some resistance to going through with it, we thought, 'If we play along, we’ll learn things.' We’ll discover new subjects, we’ll learn them. And besides, if it happens again... At any rate, that’s one of the things I really liked about all of this. This whole situation is that if it happens again, I have some chips, I have some things, I have ideas to do it differently next time. It's within the team.
So first, as a starting point, how did it go for the team? We were afraid of change. But at the same time, almost everyone thought, 'Okay, this change is scary, but we still have things to gain if we do it.' So even if at first there was some resistance to moving forward,
we told ourselves that if we played along, we would learn things. We would discover new topics, learn them, and in addition, if it ever happens again, at least that's one of the things I really liked about all this, is that if it ever happens again, I have some chips, I have things, I have ideas for... Doing it differently next time. And one of the first lessons to remember is that, since this is fundamentally an organizational change that is pushed and forced by our managers,
there will be resistance to change. And so, regarding changes—I’ve put back a slide I already presented—there are rings in Agile conferences that I borrowed from a book by Gerald Weinberg written 30 years ago, so there’s nothing new. But it’s important to remember that when you initiate a change, you don’t go directly from an old status quo to a new status quo. First, you go through a very chaotic phase where you try... many things that work and don’t work until you find a transformative idea before launching a progressive learning phase that will lead us to the new state of change. So, assuming this will happen almost every time, whether it’s the way you change how you organize your socks or major organizational changes you can make in your large company, be very aware of the problem you want to solve. If you are well aware of... You want to change to solve a problem, and if the managers and team members are well aware of it, then this step, which can in any case—and it’s normal—be a bit painful, will go more smoothly.
And so, we still gained benefits from it.
We gained benefits, and in reality, these are even the benefits that, I think, management had envisioned when expressing this request to merge the teams. That is, we have an overall topic, which is this transition to a full web service, addressed by a single team that masters all aspects of this issue, and so the topic is much better managed with a common goal. So that’s really much better. And also, increased visibility on sequencing, the roadmap, and both at a... medium or long-term level, and on a very daily basis of how we will sequence the... And why are we doing this rather than something else? We really gained from that. And also, a form of resilience to failure, which was also an issue with the small teams we had before. When you’re a team with one business analyst and three people, if one breaks a leg or goes on leave, the team quickly grinds to a halt. Today, the way this large team operates with this pool of developers who will dynamically allocate themselves to different topics and thus immerse themselves in these topics, in the end, we are much more resilient to failure, we function much better, and we can smooth our workload much more effectively. With this knowledge sharing.
What worked well during this team merger, and for me, this is one of the most important points, is that we quickly realized that it was useless to force solutions. It was better to let things happen, let problems mature,
and welcome them in a certain way. And that’s where the key lies, and it’s probably the fundamental thing—at least personally, I know Mathieu shares this view—that we didn’t invent, Agile retrospectives are something extremely difficult to do, even if the principle is simple. Maintaining them and making them effective is difficult, and I think we succeeded in doing that. That is, we derived from the retrospectives and the commitment we managed to get from the team in these retrospectives the ability... to gather problems and address them with solutions, and thus to progressively implement—not solutions parachuted in or identified by one person or another, but team solutions for problems identified by the team, and thus to place ourselves in a real dynamic of continuous improvement. And that’s good for morale, good for the team’s functioning, and also good for its morale. And it’s really very pleasant, on a daily basis, to feel that every day things are better than yesterday. So once again, it’s... Almost an obvious point, though when you think about it, retrospectives aren’t necessarily that obvious. We’ll zoom in on that a bit later.
Yes, sorry, I forgot one point. That was partly the subject of the previous talk. Mathieu and I voluntarily, but also quite naturally, adopted a servant-leader position, meaning that
we don’t hold any truth; we simply put ourselves at the service of the team to support, encourage initiatives, and energize things when needed, but in any case, it’s not us who brought solutions to the problems. On the contrary, we really positioned ourselves as... managers, support in a truly supportive role for the team. Exactly, the retrospective is a snapshot taken at the end of one of our retrospectives.
It won’t teach you much, except that they’re nothing extraordinary. It’s sad; you might have come here to see fantastic things, but our retrospectives aren’t like that. On the contrary, they focus on what’s essential. We have a large team.
We do a retrospective every two weeks, lasting one hour. One hour with 12 people—again, we’re between 12 and 14 depending on the time. One hour with 14 people makes it complicated to play games or vary the retrospectives, as is often the custom, especially in Scrum. What we did was preserve this ritual, originally from Scrum but applied to Kanban, and kept it in its simplest form. What should we continue doing? What should we start doing? What should we stop doing? And what are the ideas that emerge? We start by... Classically reviewing the actions from the previous retrospective, because otherwise, there’s no point in taking actions if we don’t ensure they’re done, and then the real retrospective begins. In what way? In 10 seconds, 30 seconds, we take the team’s temperature, a show of hands vote: 5 means I’m very happy, 1 means I’m on the verge of resigning, and then we go around the table and ask people the question. When I say 'we,' in fact, it’s the facilitator, and the facilitator rotates—it’s never the same person. It’s neither Mathieu nor me; it’s someone from the team on a voluntary basis. They will ask the question, 'Today, you gave a 3, why did you give a 3?' What went well? What went badly? And we each get two minutes of uninterrupted speaking time. No one responds to anyone to allow time to express themselves during this speaking time. And the facilitator takes notes—this is what you saw on the previous slide—jotting down the key points of what the person says during those two minutes. The round table ends, and we still have time left, and it never fails—every time we do this retrospective, nebulous clusters of recurring topics appear. We’ll have three or four people who crystallize around the same topic. And so, we’ll naturally—this word is important—have two or three main problems surface. And so, we’ll choose, within the remaining time of the retrospective, to address these two or three topics. As a group, in a free debate, with no particular framework. We’re also working with a team that is quite... The people know each other well; the team is quite mature. So it’s both disciplined and benevolent. So that goes very well. And so, we’ll look for solutions. We’ll mainly try to identify the problem. And then, once we’ve covered it or we’re running out of time—because sometimes time is short—we’ll take actions in the sense...
For those who’ve read the book *Getting Things Done*, these are really actionable actions. That is, what is the smallest, least committing, least costly thing that will put the team on the path to solving this problem? And it can be as simple as sending an email, as has already happened: we notice such a problem, we don’t have the capacity to solve it ourselves, so we’ll send a team email signed by the team, addressed to our management. We, the conversion team, have noticed this problem. We see that it causes such and such operational issues; we propose such and such solutions, signed the conversion team. And then we take actions, and the result is what I mentioned earlier, which is that
every day, things are better than the day before.
And the outcome is what I was saying earlier, which is that
it's almost like psychology, if only for verbalizing and having the time and space to vent these frustrations, express them, or conversely celebrate the things that went well, Everyone comes out feeling lighter with the sense that we have a hand in our destiny, at least in part, or at any rate, we can place responsibilities where they belong.
I couldn't have said it better. One important thing, we tried to return to the very core, which is...
They are indeed, as Benoît said, not very exciting, but they are at the very heart of what we believe to be continuous improvement. So, reflecting together, exchanging ideas, reflecting together, and improving. There were also things that didn't work out. Normal. One of the first things was to apply solutions without really thinking about the problems. This is what happened, especially at the start of the team.
I know that with, for example, one of the PMOs who works at Les Furets, we tried to formalize workshops at the beginning to define a team goal.
I was half-convinced, and in the end, it didn't work well because it mainly served to put people in a room and make them realize they would be working together. But in the end, the goal that came out of it was somewhat useless. What will truly build a team goal and give meaning to the team is doing it incrementally on a daily basis with everyone. And it's all the exchanges we had, from retrospectives, where there was truly a... A common sense, a sense for the whole team that was built.
One thing that isn't working very well is that the team has ultimately become very large. We're no longer in a pizza team. We had three pizza teams at the beginning; now we have one large team. So this requires much more internal coordination within the team.
When someone is absent, you have to try to take over their work, or when they are leaving and you need to hand over, it requires some coordination, as well as coordination with other teams. The result is that we merged. We have three teams, and therefore potentially, we have many more feature requesters coming in. So this requires, outside of... At the team's boundaries, organizing in terms of coordination. So it takes much more time than if we had a small team of 3-4 people on a particular topic. One of the points that is quite technical, but we have the particularity at Les Furets of having a much more complex front-end than back-end. And so, as I was on the front-end, if you want the technical details, I'll go over them later in the questions. But then, I made the effort to go to the back-end afterward, thinking, this will be interesting, I'll learn some things.
And I messed up maybe two or three times at the beginning on certain topics, but that's normal in a learning phase. But afterward, it went generally well. However, bringing people who had been working on the back-end for several years back to front-end topics, which is quite complex,
we didn't succeed. This is an example related to our context, but be aware that when you mix teams, there can be technical topics that are much more complex than others, and from the moment you want to despecialize all these topics, it's complicated. And since we are on a delivery that is quite tight, as I presented at the beginning, we are in continuous delivery, we deliver every day, and we have three strong business issues that still generate revenue. This is the core of the business of the site lesfurets.com. It's complicated to organize learning time that is also fluid, especially to embrace all the technical complexities we may have. So we didn't succeed well in that. And the tension between delivery and knowledge-sharing training has at times weighed on our team. And while we had indicators, pressure that asked us to row a bit with our hands in a boat, Benoît and I were there saying, be careful, there are things that may be less urgent but just as important, like having an oar and moving forward.
A few examples, notably... A very simple technical example is that we have certain elements in our codebase that are very manual. And we thought about it, not completely, but in any case, some of them were done to make it as automatic as possible.
For example, when you search for a car on the site lesfurets.com, before, it was a manual task to update the cars. So we automated it because we were tired of having a ticket come in every week. Another example, much more organizational, was when one of the salespeople arrived with 10, 15, 20 new partners. Suddenly, I need them in a month, since you're capable of integrating an insurer in a month. You're about 10 people, it's done, it's settled. Plus, I've already sold all this to my clients. What? So this situation, which is a complex one, made us realize that we were missing a clearer process for prioritizing the partners that come to us. And so, since we were used to handling about 1 to 2 per month in a fairly comfortable way, it pushed us to question ourselves and find a more suitable prioritization mode with phases where many new partners will arrive with us. So we have a much clearer prioritization system. So this came from a retrospective where we started to say quite openly, it's not working, it's no longer working, we need to express it. From memory, this was done with an initial awareness email to all management, workshops, many discussions, until Benoît and Damien, the business analyst, who work on these topics, found a much clearer and more explicit prioritization system for everyone. at two per month in a fairly comfortable way, it pushed us to question ourselves and find a more suitable prioritization mode with phases where many new partners will arrive with us. So we have a much clearer prioritization system. So it came from a retrospective where we started to say quite openly that things weren't going well, they weren't going well anymore, and we needed to express it. From what I recall, it started with an awareness email to all management, workshops, many discussions, until Benoît and Damien, the business analyst who works on these topics, found a much clearer prioritization system. And explicit for everyone.
What could have been done differently? It's a somewhat delicate subject. This list comes from interviews that Mathieu had with the team members. It's hard to say whether if we had done things this way or that, it would have been better. In reality, we don't know. Now, what we're telling ourselves... is that things probably happened a bit too quickly, and we likely would have benefited from observing a bit more, back when we were three separate teams, how each of them functioned and why over time they had ended up with this or that way of working. Generally, it's supported by reasons; it doesn't happen entirely by chance. And so that analysis time simply didn't exist. And I think that held us back, at least it didn't help us.
From a managerial perspective, communication was actually carried out mainly by Mathieu and me. Without us fully understanding the depth of what they expected from this merger. And so, we think that clearer and more precise communication about the why and how, about the genesis of this merger, would probably have helped. And the last two points are that we think either we should have limited the team size, since we... are really on the edge of what's manageable, or else reorganize more dynamically around smaller projects. But again, it's hard to evaluate.
On the other hand, what we're telling ourselves is that we might be taking a step toward something that has been whispered in the hallways at LesFurets for a long time. It's the will of some. We haven't achieved it yet, but ultimately, what we did with this merger of three teams is already a first step, it's saying that we're abolishing teams, we're abolishing feature teams, we consider that all engineers and all business analysts work for the same company and are part of the same pool of people working on web service evolution topics. And ultimately, the approach we found here of having both functional and technical referents on each clearly identified topic. And then, all the rest that constitutes a kind of reserve of people who will work on this or that topic, we ask ourselves whether this isn't the next step, ultimately, to also remove the other teams at LesFurets, at the traffic acquisition level or at the data level, and then expand what we started at the conversion team level to the entire company. We talk about it, we haven't started doing it, but we talk about it.
a perhaps more personal feeling now about how we saw things and how we position ourselves now as technical leader and Product Owner respectively for me. Today, I have two roles. I am still a business analyst on the tunnel management and comparison part as such. So that's one thing. But here, it's really my Product Owner perspective, that is, on the entire conversion team for this case.
My priorities clearly go toward enabling the team to move forward. So it's maintaining the roadmap both in the medium and short term, determining, helping with short-term prioritization. That also means making on-the-fly decisions on daily issues, small blockages, if you work on services that are... Whatever it is, in fact, you must know what I'm talking about, small daily decisions, small obstacles on the path of this or that feature or this or that conceptualization, there are always some. So that's primarily what I will focus on. And on the other hand,
Just because I have a functional role doesn't mean I should be isolated. About fifteen years ago, I did development myself, so I also have a certain permeability to technical issues. But I also make it my duty to listen to
the technical issues raised by the engineering team, to value them and bring them up, so they also become an integral part of the product vision. I don't really believe in having a product roadmap on one side and a technical roadmap on the other. The best way we've found to operate today is also to manage to mix the two and align certain features with blocks of technical debt or tooling that need to be advanced elsewhere. I take this very much to heart. And on the other hand, just because you're an engineer or developer and mainly write code doesn't mean you're insensitive to the product. So there are also many ideas in the minds of engineers that we discuss in retrospectives, informally during coffee breaks or more formally in team meetings. That I take and also use to feed the roadmap. The last point, and not the least, we are in a context where, somewhere, I think it's a company that has gotten used to this level of agility, to being able to move fast. Somewhere, agility at times gives the impression that it has become synonymous with a bit of anything goes. Meaning that since we can do everything very quickly, we can change our minds all the time. And so it creates a lot of noise. So Mathieu, like me, tries to filter some of that noise to ensure the team works in the most serene way possible.
There you go, indeed. As my feeling, as a technical leader, indeed, the idea is that I will find myself with tasks, let's say, technical tasks and management, leadership tasks. I will focus more on leadership in relation to the previous point. And the idea is also indeed... to have a certain level of protection, not complete, but at least protected from noise that would be linked to very radical decision changes, to let engineers work in the most focused way possible. I've been with the company for two years, so there are people on my team who have much more experience with the existing code.
And I even have people younger than me who are surely more technically brilliant than I am. So I won't try to position myself as a technical expert systematically. And I will rather be there to listen to them and offer help. And sometimes, by asking them a few questions, it can help unblock things technically, even if I haven't provided expertise. And when that happens, I'm quite happy. Through this, I am a technical leader, so I am no less a developer.
And I systematically balance these tasks with pure development tasks where I need to be focused. So I live this daily. This back-and-forth movement isn't necessarily easy to manage, but I am someone quite experienced, so you have to go toward it, it's interesting. And I even consider that if a technical leader doesn't take the time to write code, they should reconsider their approach. And for that, I set aside time.
So my schedule is blocked in places. People can't, as much as possible, schedule meetings or things that will interrupt me when I'm focused on development tasks. So, as I said, I try to position myself more as a senior developer, roughly at the same level as the other developers. In fact, therefore, I didn't position myself on a business expertise pole among the team's referents, but more in the pool, with the goal of going a bit everywhere in the code. And so, it's very complicated to take on a technical subject, to tackle major technical refactoring subjects where everything would need to be broken down. I've done a few, with varying degrees of success. And I can't tackle more than one at a time. Because otherwise, I wouldn't be able to finish them. In a way, the tech lead isn't the worst developer, but a developer with experience, and there's no need to put pressure on yourself to reach an expertise level.
I tried, but it wasn't a good idea. And ultimately, letting others on the team, whether they are more or less experienced, take on tasks is good because, one, it relieves me, and two, it will give them more... empowerment, to use a bit of agile conference jargon. A little wrap-up.
So, these are the three points we advise you to keep in mind.
Clearly identify and communicate the problems you want to solve. It's important. If you want to launch a major organizational change, for us it was merging teams, but if you want to do something else, break up a large team or introduce stronger aspects into your organization, what problem do you want to fix?
Think carefully about this and communicate well with all your teams, if you're a manager, to the more delivery-focused team and vice versa. Retrospectives are essential. They were popularized with Scrum, but they existed long before Scrum or Extreme Programming. Kanban blew minds, blew up part of the planning, but we believe it's good to keep a bi-weekly retrospective rhythm, even if you're in a pulled Kanban flow with continuous delivery that allows you to deliver to production every day. And keep plenty of time for learning. And always make time for learning. That is to say, you will continue to deliver, we will ask you to keep delivering as before, but to completely change your organization. So perhaps you can negotiate what more we could have done ourselves. We will deliver a little less, even a little less than when we... Than before, and keep more time for learning, whether from business experts, because there are topics to learn, than the developers.