Samuel Retiere, Bruno Boucard et Philippe Serignac
Transcript (Translated)
in one day. So, we will first present the context that concerns us.
Samuel will quickly emphasize the model we use to support the teams, meaning how we support them, what levers we can use with them. And then, the transformation itself, how we do it, and we will spend a little more time on that. So, our situation: for several years now, we have been succeeding in transformations. We started with lean fundamentals that allowed people to better embrace respect for people and continuous improvement. Once we had that, agile phenomena appeared. Promoters within our teams pushed these events, transforming them into projects, and it spread in a positive way so that today, we have a lot of people who have done agile and wanted to go further, and now we have moved into a more global mode of delivering value to our clients—because we don’t forget them—through the content of the books.
I’ll hand over to Samuel for the model.
So here, a small pyramid—it’s the maturity model. Basically, where are we? We have the investment from Société Générale to move a structure like ours. We can’t just allow ourselves to say, okay, maybe we’ll go that way. We need a model to say, here’s what we’re going to do, here’s where we’re going. So here, there’s a great pyramid. Well, the first level, Business Value, is basically, if we go back to the previous slide, it’s the agility part. For us, it’s agility, First Star, Agile Basics—we’re able to collaborate with our client. We called it Business Value because it’s a bit nicer than Agile First Star. Second level, stable value—Philippe mentioned it a bit—we don’t want to be cowboys. So before being fast, we want to be stable. So here, we’ll work a lot on the stability of knowledge, software stability, proof stability. After that, the next level, which we called best value—so the rhythm—initially it was fast value, but what we say is that there’s no need to deliver quickly if we don’t need to. So we’ll deliver at the necessary pace for our client. After that, the next level, level 4, is case by case—level 3, I can do it on one application; level 4, I do it on a chain of applications that applies to a process. When we create a new product at our place, there are about 15 applications to impact, so basically, we want to reach level 4. And after that, the last one—because we prefer 5-level scales—is the agile enterprise. Well, don’t try to ask me what it is afterward—I don’t really know, but it’s the dream level.
So here, all three of us—what we’ve just done is that we’ve done transformations at the beginning of the year to move applications to level 3. So basically, we’re able to deliver quickly. We don’t deliver every day, but we could almost, if we wanted, apply it to deliver rather twice a week. So here’s the level we’re at now, and to move to level 4, what do we need to do? We just need to transform many applications, and then we’ll get there naturally. Level 5 isn’t for right now—when we finish this transformation, it will surely be a new goal.
So what are we working on? Why are there three of us on stage? So here, I’ll go over the expected impacts from Carl Scotland—we’re lucky he’s at the conference. Value—so here, it’s about putting the right things in the pipeline. So that’s mainly what I work on—we can also call it 12-hour writing. Basically, I put things into my system that serve a purpose. As I often say, 2 times 0 still equals 0. If I produce twice as fast, or things that serve no purpose, it’s still 0. The other axis we work on—I call it Flow, always in respect to Arles-Cotland—so here, it’s about doing things right. Basically, it’s happened to us that we worked on transformations—on the human side, it was great, everything was going well, but technically, it didn’t follow at all. To test, we had to take a production dump, copy it, run it for 3 days, and wait to see what happens. So here, we don’t have a flow at all. So working only on the human organizational part doesn’t make sense. We also need to work on the technical part.
After that, the last axis—value is about putting the right things in the pipeline, flow is about doing things well, and potential—so that’s human potential—it’s improvement, which is deeply embedded in Kanban. So here, we work on these three axes, and when we intervene in transformations now, we intervene as a trio because we each work a bit in our own domain.
And the feedback we have is that this is really what made the difference. Right now, we really intervene on everything, and we manage to make things move. Because just moving the technical part has limits. Just moving the organizational part has limits. And if there’s no improvement, we also have limits. So here, we’ve really seen in the transformations we’ve done that intervening as a trio is really the differentiating factor right now.
After this presentation, we won’t present what we’ve done in the past because if I present that, it’s already something that could have been done. So we’ve learned—we’re currently retransforming teams, we’ve adapted our transformation pattern, and what we’re going to present now is what we’re doing currently. We’re taking a team that’s at level 0, which has asked us to bring them to level 3—here’s the theme we’ll work on. So here’s what we’re presenting—the current pattern, which in 6 months probably won’t be the pattern we use. It’s what we’re doing now, and it gives you possibilities for improvement.
So, that’s the beginning for me. Business Dev Collaboration—we’ll say it’s quite close to the agile manifesto. I want to collaborate with my business, and I don’t want to contractualize. So what is that? It’s training the business, teaching them what agility is. I call it Agile Basics a bit. So that’s collaboration—business, development, and contractualization. The second max I work on—before, it was more at level 2 when we introduced slicing. Because at level 1, we focused on saying, okay, what I want is for the dev team to be focused on delivering value for my client. So I want to see, in everything the dev team does, business things, business needs—I don’t want to see business tasks. So here, it was a bit like—I don’t want to see a hamburger with a technical breakdown; I want to see a breakdown in slices based on what brings value. So from the moment we had value—so to speak, value—well, it wasn’t really value; it was more about behavior, business functionality, knowing what it was for, whether it was well-oriented in the business process—there wasn’t any. So, Slicing the Business Lead—how do I do it? We do Cathar exercises, we give them caravans, we ask them to break down projects based on 1) what brings value, and 2) then, the behavioral part—I’m talking about the app. And what knowledge do I want to have? So here, we’ll talk about MVP, Minimum Valuable Product. So now, we insist a lot on the value part and a lot on slicing and a business process renter. And why do we do this? If we don’t do this, once we want to...
We’ll talk about Bruno later—we won’t be able to do it. So now, we spend much more time than before on the slicing part, and for us, it’s the key to everything. If it’s well broken down and they’re smaller, the flow is better. So this is something we didn’t see as important before, but now we emphasize it.
So the first thing we can do is try not to work in batch mode. Not waterfall—batches mean potential delays. What we want—we’ve said it many times in this conference—is to be in a flow mode. So business processes that take too long, things that are too big in the backlog—we try to eliminate all that so that development is much more fluid.
An essential element—and one that touches me personally—is teaching developers emergent design. That is, when we arrive in a team, very often, people don’t have this knowledge of creating code in emergent design mode, and it’s something that... Is essential in our eyes because it allows them to have tests first and then write their code at the same time. To achieve this, we give them exercises, code katas we call Greenfield. They do them for several months. Generally, it lasts three months. From there, they are...
In parallel, we teach them to refactor their code, but in terms of design and responsibilities. That is, often, the code doesn’t have a good breakdown or a good distribution of responsibilities. We’ll find a class with too many responsibilities and another class with not enough. So we try to teach developers to distribute responsibilities well so that classes generally have a single responsibility and, ultimately, are easier to maintain and have fewer consequences when new developments are made.
So, once we’ve done that, it’s good, but we mustn’t forget the people in the story. And we know that unfortunately, many transformations fail—and when I say many, statistically it’s around 70%—they fail mainly because of the human factor, precisely. Either the managers who aren’t in the right behavior or who haven’t understood certain things, or even the people themselves, the staff. So what we do is focus on this human aspect so that everything else works. So at the very beginning, we’ll focus on personal safety. So why did we put a whip? It's because we want managers and even anyone to be able to give feedback, but real feedback, not just reprimanding. So if someone has something to say, if there's someone else regarding any event, they should feel comfortable sharing information that will help improve the structure. And once the manager themselves adopts this posture, they will even outright ask for feedback. So we see managers asking for feedback from their N-1 and asking to receive feedback from their N-1 or even... up to certain managerial layers, N plus 2 and N plus 3. Once this feedback is in place and becomes somewhat natural for people, we’ve heard a lot about it from Octo, for example, psychological safety also allows collecting problems. People are more comfortable reporting problems, and problems in the pipeline are the source of continuous improvement. So people are comfortable. reporting problems, and we will help them, through workshops, to address them. So workshops, what we call problem-solving sessions, but there are many types of workshops like this, where we help them facilitate, we give them practices to improve how they handle slightly more complex problems. And the other classic point is the retrospective. So those who aren’t agile aren’t used to it, but those who are agile are, so they will use retrospectives to capture these problems and find improvements.
Finally, the other important case at the people level is that we talked about business earlier. Sometimes, in our organization, they are far removed from developers, far from support, all those people are distant. So ultimately, they don’t know each other that well. And so, our goal is to bring them together. And when we sense there are tensions between certain people or certain professions, we bring them closer and use a game like the Given Tech Matrix, where each person will express their expectations of others, they will also express what they believe their own job is, and sometimes there are little discoveries, people who truly discover the other’s profession, they didn’t imagine it like that, and together they will build a team, a future team, that will allow them to understand each other well and function well. And we don’t have to have the same organization on the right and left. So once we have all that, we’ve done the flow, we’ve done the technical part, we’ve done the human part, we materialize this with a little star, a big star, And this star, we deliver it, we return to a form of first star, we hand it back to the teams, and it shows them they now have the basics and can move on to the next step, level 2.
Level 2, on the value part. At level 1, initially, we focus a bit, as I said, on the *what*. Basically, does the development team understand what the expected behavior of the application is? The next question is, do they understand what the user will do with it once it’s in production? Basically, the *why* versus the *what*. So here, I really insist on what it will be used for. Typically, when business teams provide solutions, ask them—well, provide needs. It’s okay, they provide a solution, but what will it be used for? So really say, okay, you have the right to challenge the business team if you don’t understand what it will be used for, what it will do, do it. So here, it’s a lot about mindset. I’ll take some. After that, an interesting thing, we’ll talk about the product part. Try to break away from requiring a project manager who focuses on green indicators, on time, on budget, and all that—I’m not interested in the whole team. What interests me is whether we’re delivering value for my client. Try to think product. I deliver a product for someone. So here, I use two katas. In exercises based on the first one from a book called *Dealing with Daring*, which talks about marketing, innovation strategy, what possible innovations there are. And then, I also talk a bit about *The Lean Startup* and *The Innovator’s Dilemma*. And what’s quite nice here is that we engage in the debate of what makes a good indicator. But I don’t approach it from... the managerial performance side, I approach it from the innovation side. So you’ll understand a bit why I’m talking about it. But basically, here, I’m talking about the innovation part, why you do things, and saying, okay, think about what you’re doing, try to determine in advance why you’re doing things. Last point, on the value part, why I like it at level 2, why I don’t like it at level 1? To reach level 2, that’s where I get into no estimates, everything that goes with it. Basically, it’s saying that once we’ve broken things down finely, when the functional breakdown is good, when I get to the bottom, I end up with—I take a team we’ve coached—they only have user stories that, in the end, take between 2 and 4 days. Then I ask myself, what’s the point of estimating? And what’s the point of bothering with forecasting, taking weights to say I have this user story that’s weight S, weight M, weight L? In the end, once the breakdown is well done, I just arrive at this notion of pure throughput, saying okay, I’m capable of doing 10 requests per, I don’t know, per week, per two weeks. But basically, once the slicing is done well beforehand, the forecasting part becomes super simple, and then we can start doing some stats in the Kanban style. I just want to clarify something because when we repeated it at the French Cog where we talked, Our focus is fully on time to market. Being able to deliver quickly. And it’s not necessarily about what I’m going to deliver in 6 months, what I’m going to deliver in 3 months. So here, we insist a bit less on that, which is why it’s at level 2. What interests us is that I want to deliver as quickly as possible, I want my product in production to evolve as quickly as possible. There’s a profession that says, and I like what they say, it’s... new features in production equal new needs. There’s no point in projecting 3 months, 6 months ahead, because of the feedback I’ll get from production, I’ll have new requests. So don’t bother telling me everything you’re going to do, tell me instead what your capacity is, what your throughput is. That’s why it comes at level 2.
Super simple. And here, we can start doing some stats in the Kanban style. I’m just clarifying one thing because when we repeat it at the French Club, we discussed it. Our focus is fully on time to market. Being able to deliver quickly. And it’s not necessarily about what I will deliver in 6 months or what I will deliver in 3 months. So, for us, we insist a little less on that, which is why it’s at level 2. What interests us is that I want to deliver to production as quickly as possible, I want my product in production to evolve as quickly as possible. There’s a profession that says, and I like what it says, new functionality in production equals a new need. There’s no point in projecting 3 or 6 months ahead because based on the feedback I’ll get from production, I’ll have new requests. So don’t bother telling me everything you’re going to do; instead, tell me what your capacity is, what your throughput is. That’s why it’s at level 2.
Then, at level 2, we focus on reconciling multiple stakeholders. That’s where the concept of DevOps comes into play. We won’t necessarily implement DevOps tooling. However, we will try to establish a relationship between the people who handle infrastructure, those who manage the flow, and those who handle the technical development side. The goal, obviously, is to better understand how to deliver efficient backlogs with less coupling, to better understand the infrastructure on which we deploy the application, so as to better control the impacts every time we act.
Another essential element is the BDD culture. We introduce people to BDD so that all new requests are made with tickets, developers and QAs if they are present, in order to produce scenarios that incorporate the thinking of these three people. That’s essential. Obviously, with legacy systems, we won’t necessarily go as far as automation, but if it’s greenfield, we will go all the way to automation. To do this, we have a full day of training to introduce biases and developers to BDD. If there are QAs, they also participate. And then they have katas over several months to become efficient at BDD.
We talked about refactoring in the first star; this is more hardcore refactoring, meaning it corresponds to somewhat older software where testing is really not present, and the coupling rate between entities is very high. This type of software often causes developers to give up. They say no, I can’t put tests on this kind of code. That’s precisely why we explain to them, with a series of techniques, how to add tests to untestable code despite everything. This is the first step before regaining control with TDD on that code. Here too, there’s a day of training and several weeks of practice so that developers are comfortable with difficult refactoring on legacy code.
Now, regarding the potential part, we have some basics that are quite important on a human level for people. They are ready to accept problems. Here, we’re talking about performance reviews now with managers and teams. Performance in the sense of how we performed. Not the bad term 'performance' in French, which somewhat means 'walking or failing,' no. We’re really focusing on how we succeeded, what didn’t go well, etc. Beyond that, today in organizations like ours, we have many indicators to know where we stand. But these are indicators that managers often don’t like to see in the red. Or they don’t like it at all. And so, this generally encourages people to hide things and try to report green metrics because they’re a bit afraid. When we reach this level with teams that are starting to be benevolent, reporting a red metric, on the contrary, is a good thing because it allows them to correct course. So we conduct workshops with teams, individuals, and managers to try to define the best indicators for them, which obviously contribute to the entity’s objectives and the organization, but which will allow them to correct course as quickly as possible.
Then, obviously, since the goal is to stabilize everything we’ve learned before, we encourage people to share their knowledge. One of the methods we use for sharing among developers, tickets, etc., is pair working. So someone who arrives... doesn’t necessarily have all their access, doesn’t necessarily have everything they need to work, but that’s okay, we’ll have them work with someone else. So working in pairs will help onboard the person. But beyond that, even someone who has been around for a long time, working with someone else will give them a fresh perspective and help them focus more easily on what’s essential. Also, regarding documentation, instead of writing large blocks of text, they will focus on the essentials and create living documentation. Which will be constantly challenged on their current usefulness. Thanks to this, they manage to work better on their stability.
And finally, we’ll talk about cross-pollination, because so far we’ve talked a lot about developers, tickets, etc. But we also work at the managerial level. And managers' practices often come from the field. They aren’t necessarily natural-born managers at first. They become managers because of their skills. And yet, they want to know how to manage well. They have concrete cases, problems, just like developers. So we bring them together in what we call co-development workshops. It’s a somewhat pompous term maybe, but in fact, they come together to address an issue, a small problem they have, and the others, their peers, will help them work on it. And so everyone leaves with options they may or may not use. And this allows for cross-pollination in the sense that, in a large organization, you don’t know everyone, but everyone often has the same problems. And the fact of meeting people you know less well, but who are at the same hierarchical level and have the same problems, allows for faster learning. At the same time, in our organization, we organize fairs. These fairs typically allow people to come and present what they do, and thus others can come and learn, and it typically allows someone who wasn’t agile to say, 'Hey, this interests me, and I’d like to go there.'
Once we’ve done all that, these people are eligible, and we give them the second-star diploma.
Level 3, so just to say, the applications at this level—currently, I think the unofficial number is 5. So it’s starting to get a bit more intense, a bit more complicated. So everyone recognized the Black Swan, and those who truly recognized it aren’t here because they’re in Joshua Arnold’s room doing the cost of the day at Maersk. So basically, what is it? It’s about trying to work on an initiative called Agile Portfolio to break down all projects, no longer having a project portfolio but a product portfolio, with batches of a maximum of 3 or 4 months. For info, this failed, let’s just say that, it was an initiative that came from top management. Now we’re more into initiatives that come from the bottom, using cost of delay from the ground up, trying to work a bit like a start-up, a calvary, all that stuff, but it’s really about stopping big projects, working on budget envelopes, maximizing value, and trying to no longer do projects. Basically, we start with the product, we start with the budget envelope, and then we figure it out, we maximize value. We still try to bring it up to the business level, to the strategy level. Why are you making a decision, why are we doing this? And trying to ensure that on the business side, there are better discussions. So, we have a lot of discussions on the business side. Currently, I find myself coaching the business side to help them work and try to do the right things. After that, in Dax One, we manage to do things, but it’s still complicated, I won’t lie. The bottom-up part, however, works really well. Face feedback group. What is it? Maybe you’ve heard of chic-beat automation. Now, what we do is when the business expresses a need, they must express the why, and now they must also provide what business indicator will allow them to validate whether what they requested is good or not. Basically, I want an indicator, typically, if we do this, what will happen for you, for your business. And so what do we do next? With a monitoring tool, we implement the probe inside the application. And once we’re in production, we go to the business and say, 'Okay, you thought you’d gain, I don’t know, 15% more connections.' You’re at 10, you’re at 5, you’re at 20. So we’re telling them, 'Okay, what’s the indicator?' And what will we calculate behind that, which is starting to emerge and somewhat welcomes the business? It’s the percentage of business requests that hit the target. Okay, you asked me for this, and you expected this. Okay, so what percentage of the time do you really hit the target? That is, do you express needs that serve a purpose? The goal is for the product to evolve faster. So, this is really the part that works best. This allows us to validate that the business requests have reached the target. So, this also allows the business to improve its requests. So, this is a part that works very well. A monitoring tool that needs to be set up behind it, a small V3 mode, something like that.
So, at level 3, it's the moment when we will focus on accelerating end-to-end, meaning we will do phrase code, which can be,
so we will initiate within the teams this customization part that will allow having scripts to automate as quickly as possible, like a one-click button, and that's the case. So, this is really something that allows us to effectively achieve continuous delivery at the project level.
The infrastructure at this stage, I will talk about it, but the two topics are linked. Meaning that here, it was the deployment. We can also do it with a tool called...
I lost the name. Deploy. But we could also do it with another tool, obviously.
The goal is to have scripted automation and not human intervention.
The infrastructure as code part is really something we are starting now.
There has been an initiative today in terms of strategy, and we can say that a few projects are benefiting from fully automated code.
The last point is something under study, which is not operational yet. it is to offer teams the ability to organize their projects in DDD mode,
This seems completely eligible to us for people who already have a good organization, whose code is relatively well tested, with a rather good design. At that point, we consider giving them some assets from the D. framework.
So, on the human side, we end up with very few people, as Samuel said and as Bruno also said. We are really in the emergence phase today, trying things out. And there are two themes we are trying today: decentralized decision-making and host leadership. And here, we are working at the highest possible managerial levels. Why? Because today, the decisions made in the company or in organizations are sometimes a bit absurd, and some realize it. So, we do a workshop. It's very simple. In fact, we show a video on *Turn the Ship Around*. So, it's a book. There is a fun little 15-minute video that explains this book. And from there, we get people, managers at all levels, to discuss their needs in terms of decision-making. Do they think the decisions made at their level are the right ones? And the managers also provide feedback on this. A discussion starts, and we try to get them moving to see what could change in their organization, what might be missing. And so, we often see discussions about communication emerge because this decision, to be made, needs information and communication. And so, this makes all these managers reflect on their way of functioning in terms of communication within their organization. in their own organization and with their peers in other organizations. In the end, very few people have made progress on this topic, but we feel there is potential. Because every time we talk about it, there is someone who is willing to initiate this in their board, with their neighbor, etc. And at the same time, host leadership, so here it's the same way we expect a scrum master to clear the way for their development team and ultimately allow value to be delivered as quickly as possible to their client. Here, we ask the manager to have this same posture toward all their staff. So, this can be quite broad. And we have seen some managers finally change the way they organize their meetings to try to be a bit more participatory and say that it's not my event, but ultimately it's an event for the staff. And so, change their approaches and no longer just give a long speech that lasts an hour and a half, preaching the good word, but also come and contribute. So today, this is very rare, like the other two themes, we are really in the emergence phase, but we are hopeful, and we still have a few who have succeeded and have earned a little third star. And we do not despair of having many more within the next six months.
Just before taking questions, for your information, the slides are on Slideshare, with the details. Here, we haven't included the details behind each item, but in the slides I put on Slideshare, there are details. Well, I checked my Mac, and I didn't see any questions on Twitter.