On the other hand, this fracture is less generational than almost temporal. because I’m from an era where uh some of us may have experienced it as well, uh we did everything in waterfall, in the V-cycle, very rigorous, very rigid too and uh with a whole host of advantages that we gradually ended up forgetting a bit. Afterwards, we had the great agile period where everything had to be done in agile, we put imperative and scrum a bit everywhere. And progressively all of this evolved uh also into full flow with the analytical battery for performance allocation with its fluidity uh and its very scientific side.

And now we’re asking ourselves, after all this, where is it going with a few frameworks starting to show up. But we rather wanted to ask ourselves, do we really need to continue enriching our frameworks like this? do we really need to rely on this?

because the real world is not a white paper. what we see in the reality on the ground of our organizations is not what is written in the methodology books. We can take the best agile manifestos, the most beautiful PM books, we absolutely do not have in these tools, in these books, what actually and concretely happens on the ground in our organizations. The observation is that we are subject to an environment that is totally different from one organization to another, whether it’s strategic constraints, regulatory issues, technological problems, organizational biases, and so all of this ultimately contributes to the different nature of work to what is often written “by the book” in all methodology books.

And so, effectively when we apply frameworks for everything, all the time, and by principle or by religion, so to speak. well, we’ve often said that there’s more or less absurdity in what we observe. like this team we saw deploying in Scrum the audio piles in the 10 large meeting rooms of a large group. or these two teams that deployed a whole Kanban system, very clean and all, by the book, for them to deploy a Salesforce.

uh of Supply Chain and who, uh after a year, uh with many audits and retrospectives, we observe that there is a factual contribution to the trouble they went through to do the camp.

So the problem is not the methods, it’s the interpretation of the nature of the work that we make of them before applying them. I’ll take an anecdote, like what Briux just did to illustrate the point: I recently worked within a large group in the defense sector on an audit of a program to redesign its entire quality management information system.

an information system serving approximately 100,000 users worldwide, some thirty thousand partners and suppliers, uh which was launched for redevelopment uh since January 2024.

which was scheduled for delivery in June 2024. I arrived in June 2025, so a year later, to make it a an audit, particularly in the form of a diagnostic, and uh to lay the foundations for sectoring a way out of a crisis in which everyone is fully involved. We were on an ISO refactoring linked to a technological obsolescence of the previous platform. with a planning constraint and an initial budget constraint. However, the supplier who had decided to go for this project submitted the idea to the client, who also accepted it himself, to go agile. It seemed completely normal to them, and in the results of our audit, it demonstrated that it was surely one of the essential elements of the crisis they had experienced since uh a year ago. So for a laugh, we’re finally getting out, so we took over this project uh in hand uh both on dev and on piloting, and we got out of it and we put back a whole other rigging, a governance uh in V-cycle for once uh around the project.

And so, this is the first element of the three big things we wanted to share with you today, which is uh this famous topic of the nature of work. Have we taken a step aside with Sébastien and our colleagues to try to find something that is simple and at the same time useful for them to inspire us to guide these choices that are made very quickly today, as we just shared with you? and we ended up with a three-factor something that seemed sufficient to us, all three of them, to qualify the types of work that will be able to help us orient ourselves. The first factor we want to share with you today, is uncertainty. comparatively uh the initiative, the opportunity, the project, the program on which we are asked to intervene uh does it inherently carry uh a certain level of certainty about what needs to be done or are we on something totally unknown, totally vague. and we consider that this is one of the elements that will uh consist in defining the level of nature of work we are in.

The second factor is instability, uh because it’s not at all the same thing uh to move forward in the fog as to move forward on familiar ground. When what’s true today uh well is false tomorrow, then you don’t approach it at all the same way, whatever certainty you have to manage. you need to maximize what you have now as much as possible but constantly remain ready to do something completely different and continually decide what that nature should be. So stability is the second factor uh that we chose, that we estimated to be a characteristic of our work nature. And uh already with these two, we find ourselves on something quite familiar, I imagine for a large part of you, which is uh the Cynefin framework. We’ve slightly expanded it, since it has the same vertical axis of uncertainty on how we’re going to go about it. But the horizontal axis, but the vertical axis is uh the weakness of consensus, for people agree, and the higher we are on the matrix, and we considered that the weakness of consensus on the need, ultimately it is one of the forms of instability uh that will structure the nature of work, that will characterize the nature of work. And so, we already find ourselves able to have some key types of work on this matrix. The matrix is more method-oriented, we really chose to orient them towards the. So uh we already have three familiar ones but uh the simple cases where we have known tasks, we have results that are rather predictive, uh predictable. Uh we have roughly reproducible results and autonomous ecosystems. The complicated part is where we’re going to start talking a bit about necessary coordination, multi-perimeter and uh about key expertise emerging. And in complexity, we’re dealing with multi-team, heavy dependencies, numerous demands, uh needs that can change very quickly all the time. And here we are in complexity. And when we go up in the matrix on the level of instability, this time we will find types of work that approach a certain level of certainty more related to critical maintenance contexts, multi-tasking, significant reactivity. of rare skills, where we will be more on a reactive work nature, uh by moving away a little, by moving away a little in terms of uncertainty, we will this time be on a rather exploratory work nature. This is also what we find a lot right now around artificial intelligence, sometimes everything is scary, but we talked about it a lot during these two days. Uh but also in contexts of important R&D, uh of market exploration. and finally the extremity of the matrix, a high level of instability, a high level of uncertainty, that’s where we are dealing with types of work we don’t want to find ourselves in, chaotic types of work with immediate risks. total instability, a dearth of information. Here, let’s be honest, we won’t have any tools or magic recipes to offer you, but in any case, it exists and uh we hope you don’t find yourselves there. it’s just that you have to chase your way out by all means, there are a few things that work in these chaotic situations, but uh it deserves to be in this. However, there’s a third factor uh that seemed decisive to us to get a fair idea of the nature of work with work, which is the constraints.

So it’s a factor that’s rather extrinsic, so it seems crazy to make it a characteristic, but uh fundamentally uh it ends up structuring uh really uh in a decisive way than nature. with equal instability and uncertainty, you add constraints, you add external constraints to this nature and you will have to approach it perhaps completely differently, uh often completely differently. And so, it’s on this triptych that we land to uh arrive at characterizing the nature of work and we’ll come back to it later. Because the second pillar of this approach is to consider that your entire toolbox is much more important than just what you think you know. So it’s a factor that’s more extrinsic, so it seems crazy to make it a characteristic. But fundamentally, it ends up structuring the nature in a truly determining way because to instability and a little bit, you add, you add external factors to this nature and you will have to approach it perhaps completely differently, often completely differently. And so it’s on this triptych that we land, for them, to arrive at characterizing the nature of the work, and we’ll come back to that later. because the second pillar of this approach is to consider that your entire toolbox is much more important than just what you think you know. Today, we have a toolbox that is often much richer than the elements on which we often limit ourselves, such as flow, agile, the project traditionally in the organizations we work with, it’s a key point on which we end up stopping. Whereas we tried in an exhaustive way and we may have completely elements, but in any case, to give a palette of tools that is a little broader. In the first part of the tools, we will find all the predictive tools, Scrum, Gantt, which will allow us to provide planning. risk management, governance and all the elements that will allow us to secure a project start, empirical agility with everything that will revolve around Scrum, XP programming or Scrum of Scrums when we start to have a little more team to coordinate. And then everything that will touch on exploratory discovery elements, the product approach, lean startup, design thinking. Where there, we will really be in the need to discover, to appropriate new business and technological contexts. that’s a first part of the palette. The other palette, we’re going to be in the flow today, which brings us all together today with key tools and these are the operating keys, lean, Kanban, cumulative flow diagrams, and all the metric native, like, and the music of life. We’re going to see the hybrid that is starting to earn its stripes as such, the word hybrid in all the clients and in all the organizations we interact with. Now it has become a rather dedicated theme for the assembly of large agile beasts at scale that can advance on large perimeters like that, it does things like that. Assembled with uh project phasing uh and program roadmapping, large-scale lotting uh lotting and incrementalism at several scales, the feature user stories and uh and the and the big program plans.

And finally, uh there was a family that particularly addresses, let’s say, critical chains, where we use constraint theory, critical chain project management. which consists of working and being able to manage critical points in a process, resources so much that the whole system must revolve around it and, by providing tools such as buffer management and things like that.

But our aim was not so much to highlight a plethora of possibilities, but rather to enter into, to initiate reflection, the fact that each of these families of tools is not characterized by their tool, by their definition and their functioning. We want to characterize them by their contribution and to make sure to rather use them like a palette. The palette is a painter who would choose to choose the right contributions from which he could benefit to carry out his project or his initiative.

We will find everything that emerges in predictive, all the elements that allow us in terms of contribution to manage coordination, risk management, an important element on which we often make in rather agile management, dependency management, critical milestone security, so many contributions that will allow, thanks to these predictive elements to secure the output of a program in due course. We will also have everything that will touch on empirical agility, elements around value management, continuous feedback, adaptability, incremental piloting. Here, we have important contributions that we will be able to combine. That’s also important with other elements of this palette. And finally, contributions that are linked more this time to exploratory, to discovery. And finally, contributions that are more related this time to exploratory work, to discovery, which ranges from uncertainty reduction, experimentation, hypothesis management, and also the ability to pivot. the flow, well, it will bring us, it will make us able to regulate variable flows, to visualize a whole bunch of things that are precious, sometimes not, sometimes very much in the way our system works. It will also allow us to manage paces that we have to endure. but that the flow allows us to better manage and time. On the hybrid side, we’ll be able to share and bring to life overall visions, to pilot multi-multi-teams, to put into practice the collective and engaging strategic arbitration. and to bring together instructional phrases that are fundamentally sequential with large-scale manufacturing ecosystems for agile at scale, which allow these instructions to be digested incrementally. And finally, uh when we think about constraint theory, it’s because we need to be able to manage critical resources, resources that alone uh must be protected uh for their crucial contribution and to protect global teams that are very fragile uh to the performance of these critical elements.

You don’t need new methods, you need a diagnosis. We are presenting to you this afternoon with Brier the fruit of a reflective work. We are once again not in something of Rocket Science, it is also to be able to collect feedback. a tool that we have humbly modeled with the three factors that we shared with you and that we will try to describe to you in this sequence. Because in fact, the diagnosis would simply be to ask ourselves these three valuable questions even before, and before asking ourselves how we are going to proceed with the question about what we have. What will we work on together with the question: to what extent is the problem or the solution known? So we’re talking about to what extent the environment, the problem of solutions, they’re going to move, they’re capable of moving, and to what extent external constraints will hinder, slow down, discuss what we’re going to, what we’re going to try to implement, whatever form it takes. So we end up with a kind of three-panel rosette where each will play its role in the inspiration we will try to have to make the best choices before jumping on one or the other by condition or by. And so the first parameter of this matrix, of this diagnostic tool, rather, sorry, will be uncertainty. We return to the three factors. with a gradient system that we wanted to be simple, with three grades, the first being weak, the second medium, the third strong, and on each of these gradients, we will have a certain level of uncertainty that we will evaluate, which will contribute to clearly defining the nature of the work we face and thus allow us to better choose and orient the tools we have to solve this nature of work. The criterion, therefore, is uncertainty. Therefore, the uncertainty criterion, if we take the lowest, weakest gradient, we are on controlled work, we are on clear needs, on a stable perimeter, results that are reproducible over time, there, the tools that will illuminate our path are rather predictive tools or possibly agile ones. Next, on the medium gradient, we have a partially clear need, hypotheses that are still important. We have a moving technique and then potentially multiple tools to coordinate, and there the tools that will illuminate our path are rather flow tools or hybrid ones. And finally, with high uncertainty, we’ll be dealing with fuzzy problems, important, numerous hypotheses, critical learning to mobilize, potentially non-existent solutions that will also need to be determined, and there the tools that will guide us are more discovery and exploratory tools. As for instability, we use roughly the same reasoning, low instability, we’re at the very bottom of the matrix and we’re on stable needs, we don’t expect any surprises. The dependence is already controlled and we can, we know they won’t change over time. Controlled risks and there, we can effectively confirm a choice, an orientation towards a predictive approach. which works very well in these cases uh if we look a bit at incrementality. At the medium level, we will be on perimeters that will move, on which we allow ourselves to, we know we need, we already know we need to adapt over time on the on the on the rotation, or where priorities will potentially change from one period to another and where we have to expect frequent unforeseen events. So we’re going to work together. And so there, the also with a little more attention on the feedback loop and on the good finishing of each increment, we will be able to respond, the predictive, the predictive can also apply

the flow.

The flow is more indicated there because precisely, we must adapt as events arise. And when we’re very strong, well, in instability there, you really have to exhaust it in the elements that are there to do discovery and at the same time, the fact of taking one step at a time and working enormously on the next step, almost more than on what we just did. And there, we will rather focus on exploratory approaches, the tools that bring us exploratory and critical chain management.

And so the last parameter is constraints, that famous extrinsic parameter. Where there, on the weakest gradient, well, there are constraints on a product that is rather autonomous, small maintenance, R&D that we can still carry out locally, APIs that are decoupled. Here we are on tools rather around predictive, agile, possibly flow. on everything that will be in a medium constraint, here we will have some dependencies, potentially we will have perhaps a digital associated with a Legacy that will need to be maneuvered, simple paths, we will have suppliers who are present but who still bring a certain level of flexibility, especially contractual, a regulation that can still be quite light to manage. Here the tools that will enlighten us to successfully carry out this initiative are rather those of the hybrid, and then finally on strong constraints. there you have it, with rigid contracts, we know, with suppliers who sometimes prevent proper maneuvering, mandatory committees, very important regulation, bottlenecks especially concerning the availability of experts or imposed milestones. Here, predictive and critical chain are surely the best solutions for these problems. So at the end of this short reasoning, we find ourselves with a methodological profile, a profile of contribution of methodological needs. and that’s what we wanted to achieve, we didn’t want to arrive at a ready-made solution at a given level, the right method. But that will allow us to have a clearer panel on our methodological needs to assemble. a bit like a palette, a palette of colors that we were talking about earlier with the metaphor of the palette. So like a composition. uh a composition in which you will go and pick your ingredients, your seasonings, your that will make the difference in terms of your characteristic of the nature of the work.

And so, to follow up, we tried to crash test the thing. Exactly. So we crash-tested it with two cases that Briux and I illustrate, which are real-life cases, lived experiences. the first case on the redesign of an insurance core business for those to whom it may speak the least in the insurance sector traditionally the core business IS is often a large monolith for the insurance premiums, a monolith developed in ancient technologies for those who have invested and precisely have committed to redesign projects. often they started on redesigns based on packaged software. so in this kind of context, typically if we do the exercise of applying the diagnostic tool we just presented to you, on a a level of uncertainty, well, we’re going to be on technologies that are relatively well framed since often, as we do, we do a redesign rather in a project context, which has often been deployed and redeployed many times for different clients. we’re going to have results that are very reproducible since we’ve already done it many times. We have clearly established business needs. We start from something that exists, we enter a new system, even products that we know where we want to go. In terms of instability, we have however, numerous dependencies, are sectors of trades that are interfaced and interconnected with enormous information systems internal but external to the company with partners and suppliers. we have uh a perimeter that remains relatively stable despite everything and therefore a relatively medium level of instability. And finally, regarding constraints, there, on the other hand, we are dealing with very strong constraints. The insurance sector, like the banking sector, are often sectors in which we face a regulator who regularly audits the information system, the attacks that occur, the financial reporting, and therefore it is necessary to be able to ensure this ability to adhere to this regulation. we often have a Legacy that will have to be managed in a double run with the new information system that we are installing with uh well, transition periods during which we will have both information systems cohabiting, migrations to carry out, data synchronizations, still quite significant constraints. and then often we are still in contexts with rare because as time goes by and the business experts in particular and the technical experts are gone, natural turnover, retirement, departure from the company means that we have to deal with skills that will have to be mobilized quickly. and there, the assembly level that we structured, using our diagnostic tool. It’s rather an assembly with a big predictive to be able to secure important regulatory milestones in the context of the redesign project, the fact of holding the deadline or the reason for a certain number of official reports, the code of accounts to the official regulator that are linked to the sector. Agility rather for non-critical perimeters. In this kind of project, we will often have to develop several tools in parallel with this information system for the framework of a redesign which allows us to enrich the functional scope of the software, and these tools can potentially be developed more in agility. it’s that we have to deal with expertise that we’re going to have to mobilize in Agile. And there, the level of assembly that we have structured, by using our diagnostic tool, is an assembly with a predictive framework to be able to notably secure important regulatory milestones within the project context. The fact of keeping abreast of the deadlines, the supply of a certain number of official reports, of course, that everyone, the official regulator who is related to the sector. Agility in the interim, rather for the perimeters that are non-critical, we are going to, in this type of project, often develop several tools in parallel with this information system. for the framework of a redesign that will allow us to enrich the functional perimeter of the software, and these tools can potentially be developed rather with agility. of hybrid for coordination and dependencies. That’s what we see most at the moment among our clients where we are on this type of redesign, rather in an approach, just to surface, just to present. And then, of critical chain, notably for managing the capacity of experts who are relatively reduced, and for whom we will have to, somehow, be able to compose within the framework of a given. So there you go, a case that we tried to make as concrete as possible through this diagnostic tool, and which allows us to illustrate how, thanks to a few elements of reflection, we can imagine embarking on a full-scale project without being dogmatic, with a “by the book” approach, or, that is, for once, more adapted and better adjusted according to the specificities of the context in terms of constraints, stability, and certainties. Or, that is, for once, more adapted and better adjusted according to the specificities of the context in terms of constraints, stability, and certainties. And we wanted to share this second example with you. which is a bit retro, sorry. which is a bit retro-conceived, it was a a modernization of a Git platform. transport. and modernization it was purely and simply to implement payment so, with mobility. and said like that, it seems simple, but in fact, when we exercise, in fact, we are very, very high on uncertainty because these technologies were completely new, and once that, uh, there, it works for the new. You know that, it took a very, very long time, to, deliver. Notably because, well, the technologies were new for the sector of biotics and, and of transport, as cited, that, there was a lot of devices to bring into the dance on this techno. that the legacy was extremely complex, we realize the complexity of the biotic. in France, between the RATP and the SNCF and all that is shared, that it’s very old, that it’s layer upon layer of users on top of others, and that for certain places, the expertise itself was lost. So we are quite high on uncertainty. We are rather low on stability because we knew exactly what we wanted to do and we just wanted it to be possible. we weren’t exploring, asking how, what people want, and what would make them happy. We wanted to do that and that alone. and the technology was stable. The partners of the big, big manufacturers of devices were there and we just had to make it work, and nothing else. However, we were, we weren’t laughing in terms of constraints because precisely these dear partners, sold proprietary systems, which don’t let us do what we want, anywhere, and it’s even in the deployment processes, because of their rhythm, to which we have to conform. And there was the legal framework, because imagine the general terms and conditions of sale of biotics from the previous year, one on top of the other over several tens of years, of associated rights, for all that. So it was, it was a framework that had to be truly, at least re-explored. but in any case, to be faithful, and the whole thing with a level of interoperability radically inevitable, because it had to continue to work elsewhere, it had to work elsewhere. And so we are on a 1-4 case, and the 4-uncertainty case brings us rather, rather towards uh, hybrid, uh. an exploratory one, because it was necessary to advance little by little, the case of the constraints who send us rather towards the predictive because it was necessary to implement large phases of re-appropriation of the legal framework and of re-writing, of re-qualification of how it works, who pays what, all over the place. And and of profitability at 1, well, that’s for all the perimeters that were clear in terms of tech and in terms of, in terms of framework. functional, and so we’re going to do, we’re going to act empirically, and besides, it’s that agility that was first put in place. And after that, we added exploratory, and after that, we added predictive. I’m going to do it retroactively because frankly, the theory of the tools of critical chain would have been very useful at the time. Because, there were rare expertises both on the legacy side and on the new technical stack side of the partners, who, created a lot of problems for us in terms of fluidity of work, and, probably if we had thought about it, at that time, it would have cost us more with these resources, these resources that were arguing a little bit by themselves.

So, we were happy that it worked. with all lucidity, with all humility, we looked if it worked in real life. both of the current, and and of the retro experience, and it has effectively, enlightened us, so we wanted to share it with you.

Because, Because, well, that’s where we wanted to go, that we have diagnostic tools, we have simple tools, without spending a ton on analyses and and and designs, well, we can, with all humility and with uh, a lot of nerve. determine if indeed the flow, will save us or will hurt us. If the predictive will slow us down or will save us. If something else is needed. You open, you open your chakras for something that is a big Giardot bridge, uh. Or a very archaic phasing and mean stuff, well, with a relatively simple diagnosis, it allows you to get to what you want to do.

And so, today, assembly and customization are no longer given. It’s a condition we wanted to share with you to conclude this session.

uh, it becomes the matter of fact. So, I will share with you a feedback we had uh last week on the part of the team that was in Amsterdam. who himself, already several years ago in conferences, shared the fact that applying the framework blindly, in defining, brings an ultra measure of questions about whether it’s good to do it on a given perimeter, whether there are criteria that allow us to go there, comes to introduce as a new principle in the development of the framework. the fact that customization, specialization to the specific environment in which we want to deploy it has become a necessity. so, it’s not a matter of saying it’s good, it’s just an observation that we need to add, it’s that even the big players of the frameworks as we have known them for a few years, are in the process of pushing for personalization and specialization. Adjusting the nature of the work, that’s what we tried, here during this conference, to do with you through this diagnostic tool, is to compose your toolbox, because, once again, your toolbox is only as large as the flow allows. This toolbox is not so much full of tools as full of capabilities, including precisely the objective of playing with it. Don’t just pose a functionality, it’s the discernment that will allow you to pick, not tool by tool. It’s the discernment that will allow you to pick, not tool by tool, but what you have, what you are capable of doing with this toolbox, to manage constraints, to manage, an instability, to manage, the fact that you have to discover as you go what you are going to do, to manage big things. that we have to deal with, that are in Agile, phases of instruction that we write faster. sometimes you just have to put phases in and do them correctly. so, it’s the nature of the work that must, in our opinion, guide your choice, both in the picking of your toolbox, and in which part of the tool you will assemble with which other part of the tool. both in the picking of your toolbox, and in which part of the tool you will assemble with which other part of the tool. be decomposers. That’s what must be fun now, in 2026, we are no longer, working with frameworks, we have to make assemblies, partitions, compositions, a bit like an an orchestra conductor, who will, who will put objects, who will put instruments. you know, the others, and or else, like a painter who will add, who will make his composition before putting it on his canvas.

My name is Benoît Molion, I am partner at Sopra Steria Next, and I am in charge of the Agile and Product tribe. I intervene with my clients with my team to accompany them in their transformation, the implementation of operational models, the deployment of agile practices, of agile at scale, of product management tools.

And I am Benoît Le Marrec, senior coach Orga, within this very nice, very sympathetic team. And so, as we shared with you in the introduction, Benoît, just now, here, I think we haven’t told you anything radically new or disruptive. The objective was above all, and it was the discussions upstream with the organization of the flowcon that led us to this sequence of, of presentation, rather to open the debate, to exchange with you on how in your organization today these tools, these methods, these approaches are deployed. Are they done in a dogmatic way? Do you yourself, enter into a logic of personalization and adaptation? What are the elements that you find perhaps in mirror of the presentation that we have just made of our diagnostic tool? that’s where we wanted to take you for this sequence, to finish, on the last, last part of this presentation. And we also wanted to restore a bit of the glory of the predictive, frankly, because we observe in the field that we need to give it back a bit of rigor and theory, and of facing, and so it arrives, and it’s much broader than what we were tackling before. So we were happy to share it with you.

Do you want questions?

Reactions rather.

Reactions, feedback, there you go. We are open to discussion, we also came for that.

It’s for all of us.

Uh, I actually have a question, about your grid, to know what’s behind the flow, because if we say it’s just a band. for me, this value is a value and inside there are three parameters, notably. that you make the distinction. I have the impression that we don’t have the same distinction as the one you’re going to continue after this presentation.

I’m going to take it. So, we decided this family as being the one that will try to include everything that is agile, as opposed to everything that is perhaps in the radical cutting, in the mental cutting. in the rather radical mental cutting, whatever we do, we do it one after the other. we wanted to put in this family everything that allows us to, to, uh. to see all things as a continuous flow, of work and of value, but not everyone gets to value and not everyone needs to be radically in value. We put this, this is how we adjusted it.

It’s the concept that we have in this.

Thank you for this sharing, quite quite striking and, and very useful. I admit, I’m at Orange and, uh, different organizations that are in train, and, we have all the time, in projects, in projects, in projects. Anyway, a bit of everything.

Exactly.

There is feedback. There is feedback. There is feedback. There is feedback. And, and when there is feedback, we can say, well, actually, it worked almost, but, uh. ultimately, in the end, we do a lot of backtracking, because it was too, you will have to, retrain the people. And, and, ultimately, what we kept is the agile spirit. And, and, ultimately, what we kept is the agile spirit. The spirit, it’s also that. So I just wanted to share that, and, in terms of questions after my sharing, I have.

Uh, it’s actually interesting on the value, how do you make the different expertise coexist, even within the same project, in terms of predictive, agile, and and product. how do you actually, how do you apply these different perimeters and how, how do we also act on these different perimeters?

There is not necessarily a magic recipe, in what we have seen when, we see this at home, we come more and more to a to a operate model, it’s a bit the word that has been in vogue for a while. now we talk about product operating model, finally all the terms of operational model type are often very, very often in introduction of the and we find a common thread which is the one that has been fixed in the definition of the operational model and then we stick to it, we stick to it whatever the place where we will implement it. Today, I, in the organizations I accompany, I have one, in fact, at a large French insurer, who, defined an operational model, even if it’s an operational model that we accompanied in the definition of the operational model, but with a conscious choice that was that the deployment of the operational model had a, already, it was conscientized that there is an investment in the transformation and that it was perhaps not relevant to invest everywhere. Today, I, in the organizations I accompany, I have one, in fact, at a large French insurer, who, defined an operational model, even if it’s an operational model that we accompanied in the definition of the operational model, but with a conscious choice that was that the deployment of the operational model had a, already, it was conscientized that there is an investment in the transformation and that it was perhaps not relevant to invest everywhere. already, it was conscientized that there is an investment in the transformation and that it was perhaps not relevant to invest everywhere. And that, moreover, he had also made a conscious choice not to want to transform everything, saying, me, at the end, in the next three years, I want there to be at least, perhaps, at least 30% of all the perimeters that will pass in product mode, which was the starting point. For the rest, he fully assumed to continue to work either in V, or in certain cases on basic agility, I want to say, on Scrum, or on certain large programs that continue to run and run well today, on Safe, to keep Safe. For the rest, he fully assumed to continue to work either in V, or in certain cases on basic agility, I want to say, on Scrum, or on certain large programs that continue to run and run well today, on Safe, to keep Safe, and to continue to make coexist, another complexity, which is more in the implementation of the tools you shared, but it’s more in the governance, that’s where the problem lies. And there it’s how I manage my project governance, today, agile. the three tools we shared, on the grid, there too, there’s no magic recipe. It still requires a lot of work, of co-construction with the teams that, will be, PMO, what will be, what will be a product owner, what will be a project manager, to arrive at defining a governance model that actually fits the strong constraints, which means we will continue to do predictive, but also gives the flexibility and agility that we need when we are on a lot of agility. but also gives the flexibility and agility that we need when we are on a lot of agility. and I would add that, all the places where, where we’ve managed to attach, we’ve managed to assemble, effectively, what we often say Agile by Agile, uh. it’s very often in places where we’ve managed to materialize and I would say accept the decorrelation between the rhythm necessary to know what to do and the rhythm necessary to do it. because as much as the agile as the big book postulate easily that, necessarily, we can necessarily put everything at the same speed. we decide what we’re going to do, we do it, and we continue. And most often, in the, in the, in any case, in the big groups, in the somewhat complex groups that we encounter, we realize that, very often it’s much more complicated. In any case, it’s sufficiently different that you can be sure. We realize that, very often it’s much more complicated. In any case, it’s sufficiently different that you can be sure of, even if it’s a small piece, just cutting it takes a lot of time in the collective conscience. And to decide what this small piece is, it also often takes a lot more time than, than the rhythm we’re going to do the work. So, it’s often a kind of realization that ends up putting aside the Scrum teams with a somewhat predictive phasing, which will allow us to frame the environment around a team and to prepare things and to make them happen. So it’s often a kind of realization that ends up putting aside the Scrum teams with a somewhat predictive phasing, which will allow us to frame the environment around a team and to prepare things and to make them happen, to put in place the fact that these two rhythms are going to be aligned without being linear necessarily.

Hello. thank you very much for this presentation. It was very interesting and very stimulating for the decision-makers, for the objectives of the decision-makers, for the stakeholders, for the partners. so, from my side, I have a question about this. Is it only for the whole transformation that you go with your teams and you accompany partners? Or is it also on just a small project at the beginning and then we realize that there are things to do on transformation? And sorry. Ah, that’s not bad either.

Exactly. Well, because it’s very often cultures that are to be restarted, with a new or a messy but arranged mess, and, so it, it demands almost more mastery in the cultural deployment and in the connection between people, than an expertise in methodology, uh. Or we integrate this methodological expertise into the systemic aspects of humans and and of transitions and transitions of transformation. But yes, yes, it’s it’s about making simply something that that in fact, so to speak, obliges people to be recognized for their contribution of know-how. It’s about making simply something that that in fact, so to speak, obliges people to be recognized for their contribution of know-how, in the same objective. We found that it was already something that brought a bit of clarity on the fact of putting people from several professions, and several expertises around the table, and it usually requires another expertise to make people agree.

Do you have any more questions? thank you very much for this first.

Uh, I wanted to know, in the teams, who takes the role of doing the diagnosis and, and therefore of painting the solution. Is it in the team or is it through the team?

Uh, the imagination is often imagined first with, that’s why it’s also, I brought the examples, the retro rather in the in the in a big boss, a big boss who accepted the proposition of a big supplier to say we’re going to do this in Agile with them. So it’s often there that it plays out because once it’s out of the room, it’s not, it’s not, they’ve already in the first place, it’s often in these big pre-structural decisions. But not necessarily everywhere. It’s a bit strange, but I’m completely aligned, that is to say that today the constant that we have, it remains that the choice is made very early at a strategic moment for a company. either in the startup of a big program, or there we will have decided on a methodology very upstream, sometimes even it’s the supplier who, as in the case I just mentioned with the client in defense, who brings this to the table as something indisputably essential for the success of the project. and we see the impact it can generate. either in the programs, or to transform organizations in the sense, once again, of a client who decides to define an operational model, who does it alone, or most often with support, uh. or most often with support, and there, for once, it’s also our role to be able to bring this kind of tool, to have an angle of analysis of the deployment that is not dogmatic, once again, but that is a bit tooled, and to try to have something that we do in a somewhat mechanical way. and there, for once, it’s also our role to be able to bring this kind of tool, to have an angle of analysis of the deployment that is not dogmatic, once again, but that is a bit tooled, and to try to have something that we do in a somewhat mechanical way. However, precisely the fact of bringing a minimum of tooling, the objective is also, as I’m telling you, to say, that, we’re going to say, the consultants, the coaches or the accompanying organizational, after this decision, can perhaps reflect a little more, and a little more than the feeling, there, you will have decided that from above, there, there, there, it’s not going to work. so the idea is also to, to, to support a little bit to nourish this kind of, of protocol, at key moments in the deployment, being capable of challenging, decisions that would not have been challenged just with a small feeling, of a coach here who would say no, guys, we’re not going to do agile here because it’s not conducive. that’s also an idea to to to foster a bit, the capacities to to question, to question decisions that would have been taken a bit quickly from the start. Thank you very much, gentlemen. Thank you very much. Thank you very much. that’s also an idea to to to foster a bit, the capacities to to question, to question decisions that would have been taken a bit quickly from the start. Thank you very much, gentlemen. Thank you very much. Thank you very much. Thank you very much.