Samuel Retiere
Transcript (Translated)
First of all, let me introduce myself, Samuel Rottier. Here, it's not written afterward, I'm just saying it in the intro. I am an Agile coach, a former manager. You'll see later why that matters.
What I'm going to talk to you about is the investment banking side of Société Générale. Just to talk a bit about the size, we are roughly—I don’t remember exactly how many—but in Paris, we are between 3,000 and 5,000 on the IT side. So, Kanban for Managers, why am I talking about this?
Here, I don’t think anyone saw me at Scrum Day. Overall, what’s happening on the Société Générale side, we often talk about scaling Agile, especially on the investment banking side. So, we really did mass deployment. So, in mass deployment, afterward, there’s really a deployment game. And to succeed in doing that, what do we often talk about? We talk about the Agile manager. So, the Agile manager... I really like it when I go to Agile conferences, we talk about it a lot. It’s the one who helps their teams, who is always there for them, servant leadership, and things like that.
I’ll just allow myself to say this. So, servant leadership, in practice, I haven’t seen many servant leaders or Agile managers who arrived like that. So, what do we say? We can say that in practice, we still often have to do work to succeed in having managers with a slightly more Agile mindset. So, to achieve this, what we do, and what I mainly believe in, is succeeding in making managers think Agile by truly practicing Agile. So, we did the same thing a bit with the business side, having the business work on Agile projects without IT, so that they know how it works on their side. So, on the manager side, it’s about having them practice Agility without necessarily having teams developing software underneath. So, the goal is a bit to do that.
I’ll do the presentation in three parts. Explain how Kanban for Managers came about. So, here I’m saying a bit how it came about. In fact, we discovered it by chance. It wasn’t something that was thought out. Once we saw this appear, several of them appeared with us. We really... created, let’s say, implemented a maturity model. And so, that’s how I’ll roughly explain to you what Kanban for Managers is for us. Not just saying, okay, Kanban for Managers is this, but where we place it in managerial practices. And afterward, I’ll roughly tell you how things are going next for us.
Okay, this is a small slide, it’s really nice. To roughly tell you about Société Générale’s investment banking, I need to give a bit of history. So, two years ago, our revered boss, our CIO, roughly told us that in two years, 40% of projects would be Agile. So, that was two years ago, that was the target. Roughly two years ago, we can’t say we had nothing, we had a few Agile teams, not that many. But roughly, he gave a very clear objective, and we had to move toward that. So, a few months later, the Agile center was created. When the Agile center was created, at first, we only did Scrum. It was really Scrum only. So, we see it here.
Afterward, we deployed Scrum at first. That’s where we see it deployed quite a bit. Afterward, what are the gray bars? Necessarily, in investment banking, we are still quite driven by performance indicators and things like that. So, roughly, what happens in February-March for us is the annual objectives. I know, it’s a bit strange that it’s in February-March, but it’s in February-March. So, there are many projects and teams that self-declare as Agile. So, that’s the entire gray bar. Afterward, we realized that Scrum was good, but in some teams, we had quite a few issues, and it didn’t go well. So, it was Michael Saota’s book on culture that made us change our way of seeing things a bit. Saying, let’s stop taking Scrum and deploying it as is. They have a perhaps slightly more iterative and incremental approach. And that’s where we started using Kanban in addition to Scrum. So, that was, let’s say, last summer.
So, we continued to deploy. So, you see, from that point on, Scrum, ultimately, tapered off. We’ve almost only done Kanban lately. So, we really deployed Kanban in addition. And afterward, an important event was this summer, one of the coaches who is with us, named Jerry Derbier, to name him, who started to have a crystal clear approach. So, there’s another approach—I don’t know if everyone knows it, I’m not sure—so I’ll roughly explain, it’s saying that practices aren’t important, what matters is the expected result, the properties of an Agile team. So, he did it on one team, it’s not so much interesting that he did it on an Agile team, especially that it changed our way of seeing tools and frameworks. Roughly, we started to say that what matters is the result. We want the properties of an Agile team. We want customer feedback on working software. We want the team to be self-organized, things like that. And afterward, we started to let the teams be free. You do Scrum, you do Kanban, roughly you do what you want, it’s not a big deal for us. So, we stopped having a Scrum-Kanban difference, because in addition, we had Scrum-Ban, which for me doesn’t mean much, and we started to say we have Agile teams, which have Agile properties, afterward you take the practices you want, knowing that we, as Agile coaches, are still there to advise them, but you are free. you are free.
Afterward, there’s still a small thing, which is that we had to do 40% in two years, then we found ourselves doing 40% much earlier than planned. Now, we’ve even exceeded 50%. And there, our CIO asked a bit, but actually, what is Agility for us? Are we really sure that the teams are truly Agile? So, roughly, he asked us—here I put ‘Keep calm because I am the law’—it’s us, the Agile center, to go see what’s happening, let’s say, on the ground, and see a bit what the maturity level of the Agile teams is for us. So, we went to see in relation to properties. You should know that at the coaching level, we had seen that roughly 10% of the teams, all the rest, either left coaching, they did it directly, or they are self-trained, things like that. And so, we really had to go see what was happening. So, by the way, in going to see what was happening, we see that the curve is descending, because we saw behaviors that we consider more Agile. For example, I take the example of a project where they froze the roadmap for the entire year. So, they locked the scope so much that for all the iterations of the year, we know the scope. So, necessarily, that had many perverse effects. The team is no longer empowered, they are no longer committed to iterations, so we know in advance what their iterations are. So, for example, how did they manage to meet the deadlines? They compromised on quality. They compromised on quality or else they worked overtime. So, roughly, we moved into a mode where we go see, knowing that we try not to be the police, but rather to say okay, it’s really too obvious that they are off track. They are disqualified. And there, we realized one thing, which is what I would call the deep nature of Société Générale’s investment banking in terms of management, so the layer above, it’s still rather saying by default we do waterfall. All the teams below, so roughly
40% of the teams below work in Agile, but the way the managers above think is not really Agile. They tend to ultimately put a framework that makes the teams revert to waterfall. So, with the turnover we have, let’s say, the fact that people have to move every three years, either internally or contractors. So, roughly... Every year where we lose 30% of the teams. So, this turnover caused some teams to be Agile at one point and then fall back. So one of our major challenges is still on the strategic-management part above the teams, which really causes them to naturally tend to fall back into old habits. Typically, they often set roadmaps, known staffing for the entire year, things like that. So afterward, there were three small events that allowed us to move forward on this part, Agile for management. The first amendment was in September of last year. We have at our place what we call Agile Fairs. Every three months, we hold sessions, usually with about ten booths where we present new features. These are 15-minute booths that repeat, we do awareness. So it's really about presenting the new features. So on that occasion, in September, I had presented Kanban, we were starting to work with Kanban.
And then, not long after, I received an email from one of the managers saying, 'We need your help.' So it was exactly that email that did it for me. And so after that, I went to try to help them. And actually, what did I see appear? I saw managers appear. So at the level of what we call a responsibility center, it's basically managers who have about 150 people under them. I saw a board appear that still looked very much like a Kanban. So they started on their own, and they were the first to do it. So that's on the dev team side. Then, in February of this year, we realized that we were, so 40%, I think we were even at 42%, let's say, agile. What we consider agile on the dev side, but on the ops side, so everything related to production, support, integration. All those activities, they were 2% agile. So basically, there was a big gap between business up to dev, we're agile, but as soon as we want to go from dev to prod, it's a bit of a struggle. So we reported this to their top manager, the person responsible for all those people, who manages about 1,200 people under him. So when he realized the gap between what had been done on the dev side and what had been done elsewhere, knowing that he also has this goal of trying to be a bit agile, he said, 'Ok, we, the management board, will start applying it to ourselves.' So there, they asked me to help them set up, let's say at the base, visual management to move toward Kanban. And after two months, they asked me, 'By the way, what is our level of agility?'
So a level of agility for a management board, I was a bit embarrassed. So that's when I thought, 'Oh no,' I need a maturity model a bit because they wanted to know how far they could go, at what level they were. Basically, they wanted me to give them a possible progression. So that's when I started to create the maturity model. And then, in April, we started the DevOps initiative quite a bit, so trying to be agile, let's say, end-to-end across the chain.
Not just stopping at the end of dev, but being agile, let's say, and being able to deliver to prod fairly easily. So there is an agile initiative on the Ops side. So I went there to see what we could do with the Ops teams. And then, at one point, I met with the Ops, and they told me, 'Go see the Dev team.' So I went to see the Dev team to see how they worked because I didn't know them that well. And then, what did I discover? That they had a daily meeting with all the managers in front of a board. So I went there to see what it looked like. And I realized that there was still some exchange, but it didn't look like the previous Kanban board I had seen the summer before. So basically, that's more complicated. It was me who thought, seeing that, the maturity model is a bit more complicated than I thought. And so that's what made me further evolve the maturity model. Which I will present just after. Well, a manager, here I took the definition from Wikipedia.
It's just to say, well, it's someone who does a lot of things, who tries to coordinate people. But the question I ask behind is, is there really only one type of management?
Is there only one type of manager? In some companies, yes.
In a company the size of Investment Banking, Société Générale, it's not quite true. So for me, there are still more operational managers.
So those are the ones we worked a lot with on the agile part. So for me, these are the ones who are really... It's the manager just above the people who are at the very bottom.
So he's really a bit like the firefighter, he's in the thick of it, he's in the mine, it's him who makes things move forward. Then, we have the top manager, who is still a few levels above. It's him who defines the vision, where we want to go. So it's usually them who make the plans. Oh, in 5 years we'll be there? It's always the plans that amuse me a lot. Yes? Layers?
Not that many. Between our CIO and the people at the bottom, there are about 5 layers. For a company of our size, it's not that many after all. They really decided not to have too many layers. What?
In width, we are in Paris, we must be around 3,000, something like that.
Between 3,000 and 5,000, I don't know the exact figures. For the record, there was the number of teams before. We don't know the number of teams we have here. It's a level we don't have. At the organizational level, we have what we call the Responsibility Center. We know there are about 150 people below, but we have absolutely no idea how they are organized. There is no organizational chart that shows the number of teams here. So the agile teams, it's because I went to see all the boards and everything, then afterward, I reconstructed the file, but initially, we didn't have it. We know the number of people we have, but we don't know how they are organized. In fact, it is calculated based on the budget consumed in euros.
Moreover, it's in euros. On the budget consumed in euros for the projects. The indicator was initially created like that. It is based on projects, not on teams. Then, the middle management, it's all the intermediate layers. And overall, where I said we have quite a few difficulties, it's really on this layer, which is truly a layer where they are supposed to have the strategic direction coming from above, then they are supposed to pass it to the tactical level. In practice, what we see is that we really have, depending on the middle managers, for example, on the agile part, we have places where it's very agile, other places where it's much less so. It's a bit depending on what they feel like doing. And what often happens is that these middle management people have a lot of demands, a lot of strategies, but they have so many that it ultimately exceeds what they can do, and everyone chooses a bit what they feel like doing. And it's often on this layer that we see a bit, ok, I have a new objective, below you will move, but me, on the other hand, I continue to work as before. And that's often what happens. And so we see again, ok, I have agile teams, but you make me a roadmap, then you tell me where I am in three years. So that's something we see relatively often. Well then, what does the middle manager do?
Basically, he has the directives coming from above, he supervises the managers below, so that goes down on one side, then it comes back up the other. What comes back up? Generally, at our place, it's KPIs and reporting. So that's it. Okay, how are you? And then, I have... I added a little drawing with AAA. We have at our place what we often call 'watermelon indicators' on projects. Meaning they are all green. If we look at the project indicators, it's simple, they are all green. Why watermelon? Because if you look a little inside, there are still quite a few that are red. But by default, they are all green. For me, the indicators we currently have are not very useful.
Well, in the end, I presented a model, which is really the control model we have, it goes down, it comes back up. So for me, this is what I call 'I work for my boss.' And then I made some little diagrams like this for you. So basically, the OBA is for me where things happen. If you want to know what's happening in an organization like this, You'd better go to the coffee area, because generally, that's where you learn things. It's in the hallways, but it's very siloed. And it's really about individual objectives. If you look at what's inside, you'll find reporting and control. When I was a middle manager at one point, I was amazed. I had zero objectives regarding my team. None. I had, I don't remember, 23. They were all upward. I had to do communications, things like that. I had to report. I wasn't supposed to exceed my budget. I had zero objectives on how I managed as a manager with respect to my team. I didn't have any. I only had objectives about moving up in the organization.
About what? For me, that's what I call 'I work for my boss.' And after that, I made you some little diagrams like this. So basically, OBA is, for me, where things happen. If you want to know what's happening in an organization like this, you'd better go to the coffee area, because that's usually where you learn things. It's in the hallways, but it's very siloed. And it's really about individual objectives; if you look at what's inside, you'll find reporting and control. When I was a middle manager at one point, I was amazed. I had zero objectives regarding my team. None. I had, I don't remember, 23. They were all upward. I had to do communications, things like that. I had to report. I wasn't supposed to exceed my budget. But I had zero objectives on how I managed as a manager with respect to my team. I didn't have any. I only had objectives about moving up in the organization.
About what?
Yeah, no, it wasn't even up for debate. I had even proposed adding some, but they told me no, it's not very important. So in the end, I didn't have any.
Okay, can we do things differently? What are the problems? Yeah, we can still do things differently; we've still managed to change things in some places. So the problem is the lack of a common culture, and then at the level of knowledge sharing in general, if you ask someone what their neighbor does, what the middle manager next door does, they can't even answer. That really struck me when I arrived in investment banking; I was at a table in an open space and asked what the people next to me did—they were 3 meters away—they didn't know. That was still quite surprising. So basically, one model is 'one project, one team,' so what they did with Waterfall projects was still trying to create project teams. Instead of having everything sliced up, with a project spread across many teams, you create a project team. So it's a model more like this. Do you have a question?
Sorry, it's just about the 3 meters and the somewhat distant teams. Did you feel that it was intentional or that there was a lack, that people would have liked to know what the people across from them were doing, or did they not care at all?
No, they didn't care; it's not a problem. I don't really see the point, actually.
It's really a bit of everyone in their own silo, but it's not that they didn't like them; it's just that they didn't really see the point in talking to their neighbors. Okay, after this, I'll talk a bit about tools. For me, the Kaman for managers, I'll present it a bit. For me, it's a tool. So basically, the visual management part. So, visual management, you know visual management for, let's say, often for... Teams at the bottom, but we really implemented visual management for managers, so that managers discuss among themselves. So, managers of managers discussing among themselves. One of the dev teams I saw, actually, did this. They had set up a board to discuss all the projects within their team. So, these are managers overall. There are 60 people below them. Every day at 6 PM, they have a daily meeting to know what's happening at the level of... Actually, it's an application that's below. So, basically, what is it? It's transparent; it's problems, it trickles down. It's at least about knowing what's happening. So, often this is one of the things that isn't as easy as it seems. What's the point of management face-to-face for us? So, to give the status of the process, direct the manager to where they need to help, and then indicate the actions to take, the corrective actions that are underway, and especially show what is normal and what is not normal. And often, that's one of the things that's really hard. Because at the manager level, if we take managers of managers, For example, if you consolidate all the projects to put them at the epic level, They have a really nice thing, they have a good tracking board, but they have no action. So it's useless to them. And on top of that, if you look at the board, you never know what's working well and what's not working well. So this idea of starting from the teams and then trying to consolidate the information to make something useful for them, that's something we abandoned because ultimately, in terms of action, it's completely useless to them. They don't see where they need to move and where they don't need to move. So, just for info, the board I put in the photo comes from a Lean Management transformation that took place before. I mention it a bit because it's one of the constraints we have. It's day of the week, person by person. So, we had to start from that. So the idea, I want to see what each person is doing and be sure that everyone is busy at 100%, that's kind of where we start from. It affected, I don't remember, I think, 70% of the scope. So in the mindset, we have that to take into account.
Okay, what I'm saying is, when it gets to this level, what's not bad is that they share. At least if you ask a manager what the manager next to them does, they can say because there's everything on a board, and everyone talks about it and sees what others are doing. So basically, I call this 'I know what my colleagues do.'
In the model, so I talked about Obeya, so there are teams that have things like this, with what we need to do, where we are, what we've experimented with, what we've decided to spread externally. So what do we see coming? We still see that individual objectives are changing; we see KPIs appearing that are less at the team or budget level, things like that, but more at the project level, making sure the project succeeds a bit, and we really often see knowledge-sharing objectives appearing. Okay, that one is always a bit tricky, the knowledge-per-head objective, because what does a successful objective mean, what does an unsuccessful objective mean, it's not always very clear. So the analogy I make is one project, one team. At the model level, we see that there's a manager in the center who talks with the others, but we see that I've put dotted lines that start to talk on the side. Whereas the old model is really, I don't talk to the side because ultimately it's not very useful.
So, the teams that switch to this at the management level, I find that it's already a good start. At least they start talking to each other, they start sharing. After that, can we go further? Yeah. Why? Overall, what do we see with, for example, the dev team 860? It's the managers who arrive and take a post-it, then they put it right in the middle of the board. Actually, there's this. And in terms of anticipation and prioritization, there's nothing. It's really about discovering what others are doing. There's absolutely no management of what we need to do globally. And there's no mutual assistance either. It's really each person arrives; there's no assignment. We discover. And it often remains a project-organized view. They tend to do this at the line level. There are no longer people; there are projects. And it still remains, for me, siloed views. Okay, it's already not bad; they're starting to share. But we often realize that one is overwhelmed, the other is fine. And really, the things just show up right in the middle. This means that some initiatives move forward while others do not. And it's not necessarily the most important initiative for managers that moves forward.
So, there you have it.
After some time, I arrived at the main topic. But for me, it was necessary to show how we got there. Because I don't think you can go directly from stage 1 to stage 3. And then, I'll talk about a stage 4 again. In my opinion, it's a bit more gradual than that. So, what is Kanban for managers? That's when they started to think, okay, maybe we should actually manage what we put into it. So, we began to see product backlogs appear on the left. That's what really changed things. So, it's really about what we, the management team, want to do, what our goal is. So, we really start to see the team's objectives emerge. However, I talk about objectives and initiatives, not projects. Because projects, in the end, aren't that important. What's important is what the managers themselves will have to do. About 75% of their activity isn't project-related.
There's a new HR plan, things like that. And that's really about starting to distribute globally everything the team has to do. Trying to limit multitasking. So, I put a small number on a progress bar. And really distribute it across everyone. And then, Matrix. So, the CFD, I haven't seen anyone actually use it yet. The Control Chart, however, they really use it. At the level of... I think I'll talk about it just a bit later. At the workflow level, I put 'In Progress.' Some have put more complicated things. You should know that what they have isn't a development process. So, the process is generally much more basic because it's very heterogeneous.
So, what do we really have here? We really have managers who are made responsible for the team's objectives. We really have more of a systems thinking approach—no more things moving forward at different speeds without really knowing why. And really, we start to develop a team spirit. Really, the managers are among themselves; it's a team. It's not each manager in their own corner, trying to take the place of the manager next to them by being better on their side. That's also what we're looking for.
Okay, here I'm trying to zoom in a bit to explain why I call this Kanban and not Visible Management. Uh, We really have a notion of backlog, demand management, prioritization. So, for me, that's clearly the big difference between the previous stage and this one—it's the fact that we prioritize. It's about having backlogs coming in from the side, a board, and not things arriving haphazardly.
So, what do I say next? Full 'Done' column. That's quite funny because, in the end, with classic Kanban on the dev side, the 'Done' column empties itself. As soon as something goes into production, the 'Done' column empties. But with managers, they don't have releases. And there, I've seen many boards where you arrive, and the 'Done' column is completely full. So, often, what this indicates is that, first, there's no cadence. So, there's no cadence. Often, we see that there's difficulty in having an input cadence, but also an output cadence. And that's also an indication that there isn't much continuous improvement on their part. Because often, when do we empty the 'Done' column? We empty it when we do continuous improvement, when we look at what's happened since last time. When the column is full, there's a good chance that the continuous improvement sessions are...
Cost of delay, so the soft service, generally, we don't see it much. We see three. Expedite, so everything that's urgent. So, often we see almost always a top line to manage emergencies. And then they fumbled around a bit, but almost all of them come to the same conclusion: they have actions to do themselves—that is, me as a manager, I have something to do because it's asked of me—then I have follow-up actions, so following up on others who are below. And in the end, we realize that deadlines and requests aren't at all the same frequency. So often, in the boards, there are three swim lanes. Expedite for emergencies, standard, and then follow, so it's them following the teams below.
Yes, that's clear. At the beginning, everything is urgent.
What's really funny is that, especially with the first one, which for me is actually one of the most mature, So they implemented urgency and then gave themselves some deadlines, saying a kind of small SLA they set among themselves. Okay, an emergency shouldn't stay more than two days, and a standard shouldn't stay more than five days. They're a team that really, every two weeks, does continuous improvement to see what happened. They realized there were things in the emergency lane that had been there—I don't know, one had put two weeks, I think, something like that.
Is this thing really an emergency? And so, they started doing what we call the chickenpox. Every day, they put a dot on each post-it. They realized there were things lingering in the emergency lane that weren't. So as soon as there were too many dots, in the end, they would say whether it was an emergency or not, and they started to move them down. It was putting the dots that helped them a lot with this. They also used the technique of putting different colored dots depending on the column. And they could see in which column they were spending time. I think I put it just after theirs.
Work in progress.
So, focusing on the flow rather than the...
occupation of people, it worked really well on the dev side, because that's something we did on the dev and ops sides, really the devs got it into their heads that you shouldn't have too many things to be efficient,
so that went over rather well, but on the production side, for them it's a bit more like the more I start, the more I finish, so there's really a notion of stopping accumulation that's very hard, and there, we're clearly struggling a bit to make them understand that multitasking still has perverse effects. So, we're trying. It works very well on the dev side, it works less well on the ops side. Continuous Improvement is a bit the same. It works very well on the dev side, it doesn't work well on the ops side. On the ops side, they don't have the culture of saying, 'Okay, I try to improve every month, every 2-3 weeks.' And in no team have I been able to have availability to train them a bit, explain the concepts, show them, or I don't know, do games.
Not at the manager level, though.
No.
Just for info, on the Ops side, when I first arrived, the only indicators they had were in, out, and stock. And never the response time. I still teased them a bit about it, saying it's funny you're Ops but you have no idea what your response time is. And so for them, it was more their indicators for the teams below, it's only about stock. In, out, and stock. Not on response time.
Yes, almost all of them, they're field managers here.
Yes, it's clear, they have the Ops culture.
It's on the Ops side, however, that it has deployed the most, Canman for Manager, on our side.
So afterward, however, for the five that I somewhat followed and helped, I never managed to get an hour to train them, to explain a few concepts. We were only able to improve each time by going with them, attending their meetings, trying to make them evolve gradually. So it's evolving slowly, I find, partly because they don't give themselves the means to go faster. So the workflows, as I said, are basic. I've seen that it's almost only the ops who do that. They have a progress from 0 to 100%. And basically, they made a fairly wide column and they move the action inside it. Well, it's a bit basic, but... It worked for them. As for me on this, I tell them it's a bit their process, do what you want. Same thing yesterday, each person assigns themselves their own board, it's responsible.
I let them do that. Then what was quite funny, it also happened on the OPS side, it's the DON. What to do with the DON? At one point they said okay, about the DON, what we still need to know is what successes there are to be able to market them and what achievements there are. So they started to split the DON column between success and achievement. Well, that, for me, is a bit of the manager culture, it's what we're going to be able to market. So that served them to try to see globally at the level of their team what they were going to be able to market upwards. Yes, it's their culture. But there you go, it's quite funny.
However, what we saw, and what really pleased me, is that we started to break the swimlane vision, it's the people. And some made swimlanes, not so much based on classes of service, but based on the objectives of their team.
It's not even their team, it's on the OPS side. They have global objectives for the whole year, service quality, things like that. And in fact, their column is that. And that allows them to see, in relation to the objectives they were given for the whole year, whether they are progressing on all the themes.
And the measurement part, cycle time, that really speaks to the ops. So it's them who pulled that. Even if initially, they weren't using it. However, when I asked them why they weren't using it, it seemed a bit silly to me. It really spoke to them. For information, why they weren't dealing with it, it's because in the previous few years, we had a lot of production problems. So they told me a bit, our priority was major incidents. And let's say the flow was less of a priority.
Well, success, luck, failure, but on this, I also tried to add something for them, so Lean Startup, to tell them by the way, your initiatives, every time you want them to finish, but it's normal that some of them stop. So also try to talk about initiatives and say that it's normal for initiatives to stop. So there, I also started to try to, let's say... Instill some small subliminal messages. You can change too. For now, it's starting to come. The fact of talking about initiatives, we're starting to be able to discuss it. Because before, it wasn't even possible.
I call this level 3, 'We think together.' So basically, we think together. But I moved too fast.
The model is a bit like that. The table I put here, it's hard to see. But this one, for example, they made it a bit more detailed than just 'To do in progress zone.' They had, for example, 'Analysis,' 'Implementation,' and 'Review,' I think, something like that. And basically, why did they do that? Because during the analysis, they often had a post-it. And it was a time when they do the analysis and they split the post-its into several pieces. You can't see it well here, but... If you look at the slides I put online, you can see it better. They have clear limits per column. And they have the expedite at the top, that's what they follow in the middle, and what's at the bottom is what they follow.
Some use avatars, but not everyone does, to know who is working on what. So, individual objectives, in the end, we don't really find individual objectives. We find more team objectives in the goals. What we say is that we raise the objectives by one level. Instead of giving objectives per person, we really only give the team's objectives. And this still also drives continuous improvement. You are able to say in the objectives, you must improve. So that's quite nice, and we really see that people are starting to work with others. For the first one, for information, when I went to see them, I attended a daily meeting, there were five of them. I only knew two people in the team. And at the end of the meeting, I didn't even know who the boss was. And I found out afterward which of the five was the manager above everyone. There was one, and four others below. And it was only afterward that they told me, by the way, he's the manager. The way it was led and how it worked, I didn't even realize who the manager was. That's why I make an analogy with agile teams. It's really, we've seen self-organized, empowered teams appear, they are committed to the team's objectives.
Well, I won't spend much time on this slide, just to say that we are quite influenced, it's an ad, by everything related to tribal leadership. Try to make people collaborate together, stop competing, try to be efficient. It's really, we're all about that, on Canman for Manager, we are very influenced by tribal leadership. Try to create triads, make people meet.
It's one of the books that really inspired us for this. Well, can we do better? Yes, for me we can still, because just because you work with someone else doesn't mean you're really working together. They realized in the first team that at one point one of theirs had a lot of problems, it was mostly with his teams below, The others knew he had a problem, and in the end, nothing happened. Because it was kind of his team, and there was no initiative on that part. And afterward, it still made them think, saying, OK, we work with others, we assign everything we have to do globally, but are we really working together? So there, they realized it wasn't quite true. So, pair work. Basically, they started to say, OK, we could do like pair programming, and we'll try to work together. Basically, they started to say, OK, on certain initiatives, we'll really work in pairs. It's not one person who will take the initiative, do it, report, and then we have this sign globally, it's really, we'll work together. So there, we've seen appear, so there's only one for me that is really at this level, among the manager teams. There is one team that is really starting to do pair work between managers. What they often do is on an initiative, they really start working in pairs. And not, he would have left if one of them took it. And especially in this area, where they go the furthest, they have also started to create, in this area, communities, guilds. Everyone who knows Spotify knows this diagram. So basically, we try, but for now, it's super hard. It's super hard. Why? Partly, we have discussions about this. It's that the culture of giving isn't ingrained in us. Because when you're in communities, you give to others. Do we have a direct return? Not really.
So we launched communities. Communities that work, that are managed. For now, that's a bit... A failure. I think that as long as we don't change the fact that we need to be able to give to others, that at the level of people's objectives, we are much more team-oriented, I think we won't get out of it right away. So for us, we know we have this in the toolbox, communities, to try to develop people further. But for now, it's not really taking off. Not to say, it's not taking off at all.
Well, I call this 'you work together.'
And so in the model, the Obeya for me is really the double chair. Well, there aren't chairs like that, I haven't found any on the market.
Afterward, regarding objectives, I admit that more and more, I am against SMART objectives. Do you know what SMART is?
So specific, the last time I didn't even remember all the letters, specific, measurable, time-bound, and achievable. The more I go, the more I am against SMART objectives, because in the end, we tend to have an objective that is SMART, very precise, and what will people do? We will try to get the indicator. We will see the behavior we measure. And more and more, I find that it influences behaviors so much, the objective, that I am in favor of stopping setting SMART objectives. And afterward, we will move to real team objectives and 360-degree feedback. When we evaluate the manager, we do a 360-degree feedback. This, for now, is just starting to show up, but we're still not quite there yet. After that, well, we have that in mind. Why did I create a model? It's also a bit to give them something. They were asking where we could go, what we could do. It's to try to present this to them, to say, well, you can go this far. Often, I call this, opening the chakras. So, showing what's possible, and then it's up to them to see.
Okay, so what's next?
Alright, I'll have time to take three questions. Wow, that's really nice! This is our current model, it's still another model. Why did we create this model? 40% agile in two years, for us, we call that the first star. Basically, the bare minimum for agility. Here, I call this the '12th sing right.' Basically, what do we put behind it? We include being able to deliver the feature, being able to collaborate with the client, and being able to empower people. So, that's level 1. For us, we've reached this point.
Why did we do this, by the way, for info? It's because, basically, the managers at the top, whom I mentioned earlier, realized they had their 40%, so basically, agility, they said, 'Okay, that's done!' " So, basically, the pressure completely stopped. The goal was achieved, no problem. So, this is the next goal. And so, our new goal for in two years is this: continue to deliver value.
Knowing that it was still a bit of a marketing slogan. And afterward, we had to define what we put behind it. So, what we put behind it is: do the thing right, client collaboration, deliver features, people empowerment, do the right thing, which is the next level. We put it afterward, but well, it depends on the companies, you do what you want. Do the right thing, what do we put? Value, I say value, not just features, and then stability. So, stability means there are quite a few dev practices on code, automation of functional tests, things like that. And we also include stability in knowledge, knowledge sharing, all those things, being able to properly manage turnover.
And... So, that's our level 2. It won't be easy because, in terms of value, on the business side, we still have some difficulty. That's why I was at the super workshop with Don Reinertsen these past few days. After, do it fast. So, do it fast. And basically, here, it's about speeding up. So, all the DevOps practices, I collaborate with Ops. And there will be a cloud code phase. A lot of Dev practices at this level. And we also start to scale. Because the next level, continue to deliver value, is really about scaling. That is, by being able to truly deliver value, deliver value across the chain. So, we're also tackling everything related to Agile Portfolio, which we're already starting at Do It Fast. What do we put behind it? It's about being able to do the right project, even though more and more, I think a project doesn't make sense, and we should look at minimums. Marketable release. Within a project, look at which parts make sense and not at the overall project level because it might be that only 50% of the project is used to create 90% of the value, and the rest we shouldn't do. So, we're starting to address this, and we eventually want to do dynamic staffing. That will be much more complicated, meaning there will no longer be three-year projects. All projects will be sliced into small blocks of three or four months. And every three or four months, we'll ask the question again: is there still enough value, is it interesting, should I move to another? For now, what we're doing a bit is slicing all projects into three months; we won't give the entire budget at once. We'll often revisit the priorities, but reallocating staff dynamically from one project to another, that's level 4. So, that's what we need to do over two years. So, it's a big project. For now, in my opinion, 90% of the teams are at level 1. There are a few teams at level 2, and some even at level 3. There are one or two lagging behind. But basically, that's it. And on this, in my opinion, we won't succeed if the managers, let's say, don't change their perspective on some things. Way of seeing some things. So, that's what we'll propose to help reach level 4. Now, we're no longer at the stage where we've discovered a practice, a tool, a way to manage. Now, we'll try to propose it in certain cases when we think it's interesting. I don't talk much about my level 5 for now; we don't even know what it is.
We included it because we needed a level 5. But if you ask me what's behind it, currently, there's almost nothing. There's just the title. So, that's the future for us. In two years, we want to be, not all teams, but a good portion of the teams at level 4. Just for info, everything related to accounting, things like that, having all the necessary infrastructure to deliver features to production one by one, we find that it doesn't make sense, it doesn't bring value. So, we'll move toward that only for the applications where it makes sense, those that are very close to the front end, and those that are well-organized to be able to do it. We don't want to deliver in... It's really about continuing to deliver value, not just continuing to deliver. We put a lot of importance on this to say, okay, it's not just about going to production and delivering anything; it's about value. So, that's it.
So, there you have it.