Luca Minudel - Should we retire Accountability & Commitment and find a better alternative?

[00:00:05] My name is Luca Minudel, and today I will talk about accountability and commitment. I will try to dissect them and analyze them.
[00:00:18] Would you like to work for a team or have a team that work for you that is not committed to what they are doing, or they do not feel accountable for the decision they make and the work they do. I guess that none of you will like to be in that situation. But there is more about how accountability as a tool is used in our workplace, or even in the Scrum guide. And so, that is what I will explore today. This is the third version of this presentation and is evolved through conversation that I had with attendees of the previous session and online conversations. So I encourage you to get in touch with me after this presentation and share what you agree or what you disagree about. This session is based on what I learned in my past experience, is based on interview that I had with many practitioner and how accountability and commitment worked or not worked for them. I also researched what other thought leaders say about that. For example, Kent Beck, Allen Holub, Tobias Meyer, and I researched some relevant theory.
[00:01:45] So, I can tell you that I'm not going to share with you a silver bullet about accountability and commitment. I will not share with you a recipe about how to deal with that.
[00:02:00] But I will share an idea that is supported by theory and the experience of a lot of successful practitioner. This session will have a lot of thinking and information, so it's a lot for your brain.
[00:02:18] It doesn't come but it comes from the heart, even if it is very technical and conceptual. Because there are a lot of people that suffered the consequences of accountability and commitment used in the wrong setting and that became very painful for them. So even if there is a lot of concept here, there is some heart behind to stop doing bad to other people.
[00:02:49] The idea will not necessarily be easy to understand and in many organization it may be they may be hard to implement the idea that I will share with you because some of those organization are stuck with a different way of working and different way of doing things that may not get along with what I will share with you today. But for those in such organization, the thought that I'm sharing with you today, the idea is like planting a seed of an idea that may grow in the future. So, as I said, I'm Luca Minudel. My home town is in the north of Italy, near Venice and Treviso. I come from Conegliano that is at the center of the Prosecco area. So, don't kill me. I know Champagne here, but there is also Prosecco. I'm a lean, agility and complexity thinking practitioner and I have a technical background. This is where I come from. And I have over 20 years of experience in professional software delivery, most spent with lean Agile and complexity thinking. My career took me from software development into technical coaching and later I start to mentor and advise manager, senior leader, executives from the technical product and business side of the organization. So I'm pretty active on social media and on my blog, I will share with you the link during the presentation because I like to have a lot of conversation with different practitioner and that is how I learn from practice and from exchanging ideas with other people and understand what work in their context and what not. Here you see some of my latest publication. The orange one is a catalog of practices inspired by human complexity and complexity science. The latest one, the blue one is introduction to complexity thinking in very simple terms and easy to understand for everyone. So let's go back to the crux of the matter.
[00:04:59] Can we make and keep promises in presence of uncertainties, unknown, and unforeseeable change? Can we do that?
[00:05:10] Can we commit to a fixed deadline, budget and scope? Can be accountable for when we broke that promise or not? Or do we mean something completely different with accountability and commitment? Now, let me do a very quick survey. By the raise of the hand. So raise your hand if you're currently having some conversation at work about accountability and commitment, what it means, how to implement it or how to make it better. How many of you?
[00:05:45] Well, as a majority. If you are here for personal curiosity, simply on the topic or something else, raise your hand.
[00:05:59] Okay, thank you.
[00:06:01] For those that are discussing accountability and commitment at work or adopting it. Raise your hand if you are having those conversation with people that started to work recently or that come from a startup background. If you're having those conversation with a startup background, well, a minority. If instead you are having those conversation at work about accountability and commitment with the people that are working for a long time, coming from a traditional background or with a background in traditional company and enterprise environment, raise your hand. Okay, a lot of you. The first thing to be aware is that those two different group of people may have a very different meaning and understanding of what accountability and commitment actually is. What I learned is that the meaning that people attach to accountability and commitment is deeply connected to their past experience, how they experienced accountability and commitment in their job, in the project that they are doing or they they did before, how the teams translated those teams into practice and how people related into that. And that has a big implication.
[00:07:22] Even the Scrum guide use some of those terms and in a different way that someone else may intend them. But point is that people will understand those terminology based on their past experience. And there is no point to write on the wall a different definition and say this is how we all intend accountability and commitment. And there is no point because you cannot change their past experience. So this is not how we are going to deal with this topic today and I would suggest you don't do that either at work. It simply is not going to work. Another thing that I want to tell you is that because this is how accountability and commitment has been around for the longest time. The most common understanding of accountability and commitment are related to Taylorism and Fordism, to a predictive approach, and so commitment is connected to the iron triangle. And accountability who will pay is connected to who will pay for the failure to deliver what was promised. So for a lot of people will mean that, regardless of what we intend.
[00:08:37] So that was my first learning.
[00:08:43] That is why I took a different route. I try to get inside from promised theory from Mark Burges. Promise theory is an algebra in the real sense a mathematical language that you can use for cooperation and collaboration. It apply to distributed digital service on internet, as well as to people, how people collaborate and coordinate. Is a tool for understanding collaboration and cooperation at a different level and has this property. It can generate certainty on top of uncertain foundation. So seems it's exactly what we need at least for the problem that I mentioned before.
[00:09:32] In our life we use promises every day more often than we think.
[00:09:37] In our life as well in our work. Let's see some example. Now, I'm coming from London, so let's start when we queue at the bus stop, there is some promise about how we are expected to behave. When we stop at the traffic light, when we answer the phone, make an appointment or vote. And those are driven by social convention, etiquette, habits, social contracts. But we make promises also at work, in a business setting.
[00:10:08] For example, this happen when we do shopping.
[00:10:14] We go out for lunch, we buy something online, maybe it's a service or a custom made product. And that is driven by laws, regulation, contracts, and the relationship with customer and suppliers. Now, let's look deeper at the anatomy of a promise to better understand how it works.
[00:10:39] What are the building block? And this is a very high level simplified introduction of promise theory that is good enough for for today. A supplier can promise they can deliver something. A customer can say, I promise this is really what I want and need.
[00:10:57] And all these promises are voluntarily offered and they can be voluntarily accepted in that case, they are also agreed. It's important to say and this is a very important point that a promise is a declaration of intent, not an absolute guarantee.
[00:11:19] No one can make an absolute guarantee on a promise. Think about that, can you really promise always 100%?
[00:11:34] There are many reason you cannot promise an outcome that will come into being for personal reasons. Many times your own promise is connected to a chain of promises from others and if they don't keep their promises to you, you cannot keep your promises to someone else. Sometimes you may have a change of heart or circumstances and sometimes the need or your capability may be drifting. So what responsibility do we have?
[00:12:05] The supplier is responsible to do the best they can to deliver. The customer on the other side is responsible to have a contingency plan since there is no assurance that the promise will be delivered. A contingency plan can be a backup plan or using multiple suppliers. There you see a graphical representation of a promise that is offered and one that is accepted. In real life a promise is made up of a chain of more complex promises with other people helping us, but again for the sake of today that's good enough. What else?
[00:12:48] And this is an important point where we deal when we deal with uncertainty, novelty or innovation. There can be multiple interpretation of what is offered or what is needed and whether a promise has been kept or not.
[00:13:06] And how do we deal with that? There are two common approaches: the first one is to use a third party as arbiter of true. Could be an independent party, another thing is going to standardize and commoditize good. As we do when we shop online, we can choose from a menu, we know exactly what we get, we can configure what we are getting, choose the size of a shoes or a shirt and so on, and that will be efficient, fast, low cost and low energy. Instead with the lawyer or an independent party that will, yes, provide a sense of certainty, but it will take a lot of time, energy and it is fragile. The second option instead is mutual calibration between the customer and the supplier. It's a very sexable approach, achieved through multiple interaction.
[00:14:07] And this multiple interaction, the effort of this multiple interaction is pay back by building a long-term trust relationship. between the customer and the supplier, that is based on a common language and understanding of what is needed and what is offered on the ability to collaborate effectively and to deliver.
[00:14:29] So the example of using a third party to compare the specification with what has been delivered is a last resort. Given that it's very expensive, so we leave that option there. From worldly mapping we know that every product or service has a tendency to move from its generation to being gradually commoditized and standardized. Indeed, in order to reduce the the effort to understand what we want to make it cheaper to produce it, so we're going to mass production, volume and economy of scale. That is described by the movement in worldly mapping. On the other side, we have multiple interaction. where through iteration, something is produced, generate some feedback. What has been produced is validated by the customer and the supplier and their common understanding and looking this tangible thing, they can build or not trust.
[00:15:37] So, let's see how this two option standardization over mutual calibration work well. Because they work well in very different settings.
[00:15:48] So with standardized and commoditized good, how things work? And here I have some practical example. Let's say that oh, I like the flow on T-shirt and I want to buy it, it's lovely. Wow, I find it on Amazon. How lucky am I? I choose my size and I buy one. And everything that will happen since the moment I placed the order and pay the money to the moment that I'm here wearing that super cool shirt. is covered either by a warranty or the cost of every problem that can happen is backed in into the business model, in the volume and into the margin. We will always be happy, no one will lose money, regardless of what it goes. Same thing if I buy a spare part for my car. So let's make it clear.
[00:16:40] Standard service or good, I can choose it for a menu and configure it. I know from past events what problem may happen, their probability. I back this problem into my margin and the business model and in the end, here is the magic, absolute guarantee or almost. So this is where accountability and commitment works well.
[00:17:13] And that's my second learning.
[00:17:18] This is the type of work that in order to produce those good can be standard, repetitive, on in complexity terms, we call that complicated type of work. But what about the complex work, the one that we do when we are working on something that is state of the art, innovative, one off? Can really commitment and accountability still work? What happened when you are facing increased uncertainty unknown? What happened when the past experience and risks don't tell us nothing about what will happen today or tomorrow in our project, in our product development? When we are using a new technology, when we are dealing with a new customer, when you are working on a new domain or developing a really innovative product. And then margin and volume cannot solve the problem, there are not enough margin for the client to pay more or for the business to earn less.
[00:18:31] Many organization and companies that became successful selling commoditized and standardized product and they succeeded with accountability and commitment, they have developed some kind of implicit reliance on foresight, predictability and control.
[00:18:53] And so when something go wrong, the estimates goes wrong and they say, oh, we need to get better to estimate. We will do some more estimation of front. When the requirement in the end, we understand they were not clear because we learned a lot of things along the way. They say, oh, we need to get better to to get the requirement right at the beginning. And when the requirement keep changing because our understanding of what the client need or wants keep changing, they say we need to implement change management and maybe they may try even to delay change until all the changes pile up and managing them it become even more difficult.
[00:19:39] But when we try this, when many of the succession successful practitioner tried this and even myself, it did not work. It did not work to try to get better at those things, it didn't solve the problem. get the requirement right at the beginning. And when the requirement keep changing, because our understanding of what the client need or wants keep changing, they say we need to implement change management and maybe they may try even to delay change until all the changes pile up and managing them it become even more difficult.
[00:19:37] But when we try this, when many of the success successful practitioner try this and even myself, it did not work. It did not work to try to get better at those things. It didn't solve the problem.
[00:19:57] Imagine that you are a broker in the stock market. Can you promise to your customer that for the next year the stock price will always rise? Can you do that?
[00:20:10] No, right? So how can you promise your customer a deadline, a fixed price, a scope when you are dealing with the state of the art of very innovative project or innovative technology? How can you do that? Can you commit to unknown that could not be avoided? What do you do when past experience don't tell you about the future? There can be a sudden crisis, a black swan event. Who is accountable and how finding who is accountable solve the problem? Imagine that you committed for the next month or 10 item to be delivered next month, next week, next iteration, next sprint, whatever. And one of your assumption fail, or one of your experiment fail, and you deliver three out of 10 things. And in that situation you cannot find a way out. There are no margins. The customer cannot pay more, your company cannot serve the cost, and you can kick your team as much as you want, but they are already working as hard as they can. What do you do in that situation?
[00:21:15] Is commitment and blame, sorry, is accountability and blame helping you? No, you're cornered, there is no way out of there. You are already in big trouble.
[00:21:26] So we need something different.
[00:21:30] With this type of work, we need something different. Now, again, Flo conference t-shirt is super cool, but I'm attending a wedding. I'm Italian, so I'm going to a fashion designer to get a very cool dress and they will made a custom design never tried before. So no tailoring exist yet for that design and the material has never been used before. Imagine how cool my dress will be.
[00:21:58] That's a completely different type of work. I don't even know if it is possible to do what I want, if it fit well on me, if it will be delivered on time for the wedding, and if it will fit my budget. So, a lot of uncertainty. And think for a second how many of your product or project are like that, how much you tell yourself that there is certainty where there is not. So, my third learning is, look, there are all kind of work where accountability and commitment really doesn't work. We need to find something else. And here we are.
[00:22:43] I want to go back to the scenario of mutual calibration and I would like to share with you a way that many people I talk with did that type of mutual calibration between the customer and the supplier. So between the team and your client. How that can work in practice? And it need the three elements. First, to find an alternative to blame, something else, because that we saw don't work. Two, to manage risk in a way that is fit for the complexity of innovative product. The predictive approach doesn't work, we saw that before. And then find a way of working that is good for the type of product and uncertainty that you are dealing with. And this means, and I will get into the detail, using something different, I call that dependability and trustworthiness net. shift from a predictive approach to risk to an empirical approach to risk management and use an empirical way of working together with the team and customer sharing responsibilities. How crazy is that? When I talk with my fashion designer, what I say, bring some responsibility, I cannot just say stupid things. Seems natural and obvious, but then in a work environment or in a business environment, that sound so strange.
[00:24:11] So let's drill down into this. Let's move away from commitment, for example, from estimates or timeline to the outcome. Okay, we can take that out, but we need something else in their place.
[00:24:31] What could that be?
[00:24:34] Well, for sure, I would like team members that show up at work on time and they are competent and they do their work at the best. And they can also strive to make up for any shortcoming that may have if something bad happened. And then, I want that the people work and collaborate with the genuine intent to help us succeed in the product. I want for them to follow the highest standard and to run experiment that are required for the actual outcome. So I don't know if you ever heard about a resume driven software development, where I will try to use the coolest technology so I can put them in my resume. That is very different from using the technology that is best suited for the goal at hand, and this goes for all the professional in the team. So why again I'm using different terminology instead of redefining accountability and commitment? I think that at this point you already know the answer, it simply wouldn't work. So let's move on and use two new terms. So we can have a discussion about that, agree on the meaning and agree if we really want to implement that.
[00:25:49] Yeah, that is really nice to say and a very nice to sell. Problem is, how do they work when things go wrong? Because that's the real test. This is where accountability and commitment stop working with this type of work. So I can tell you what I tried in my experience. This is what I try when I was working in a Ferrari Formula 1, a quite high paced and high stressed environment. So, as a team, we created a checklist of collaboration and technical practices, a minimum set of collaboration and technical practices that need to be adopted and followed always in every situation, in every circumstances.
[00:26:30] So it is really a minimal set, is not all the great practices that we know or those that work in many different situation. Is the smallest set that everyone has to do always in order to be really dependable and trustworthy. That goes also for the customer. My experience here come from thought work. So when we were partnering with our customers, we made very clear in the contract what expectation we had with the customers, how they should collaborate with us and what were the rule of the game when they changed their idea on the scope, when they changed priority. Let me give you an example. If you say I want something and we work one week to do that, that time and money is spent. You cannot come later and say I changed my idea. Yes, we can do something else, but that time and money is gone. But on the other side, whatever is still in the queue, you can change idea or you can even shorter your queue.
[00:27:36] We constantly look at every complaint or feedback and we use those checklist to make sure that we were doing the right thing. For example, retrospective, demo or ad hoc meeting, for example, Monday after the race, all the management people from the track meet together and had a follow up meeting on all the issue happening on the track. But also measure incident and this is where things can get difficult. When there are a major incident and we realize that there is a breach, someone did not follow something that was on the list. The team member or the customer, they could get fired. Feels really bad, doesn't it? You may think this is not a nice environment. And now, this is the funny things on how things look on slide or on paper and how things look on real life. It was actually the opposite. There was this strange effect where the checklist for the team was actually protecting the team. When there was some pressure and some managers, stakeholder was coming to the team and tried to convince them to cut corner, they had the least and say we cannot go beyond this. This will be malpractice. This will be not doing the minimum that we need to do in order to be professional in our sector. So the team was super happy and in a sense the manager or people that were try to push things were also happy because the result was better following those practices.
[00:29:22] Not only that, but some team members feel it safer to experiment because there was a clear boundary around what they could do. So it they felt more lighthearted in taking risk, experiment and innovate, thanks for that risk. Even with the customer, while at the beginning some customer knew to this approach, it was difficult to convince them to get them involved to to be part of the conversation, once the customer understood the rule of the game, they started to use the rule of the game in order to change priority, change scope, and better what they learned, change idea and take the best advantage of the rule of the game. So in the end, with most of the customer, it worked really well.
[00:30:13] Second point of the three that I was telling you, moving from managing risk through predictability and going to managing risk through empiricism.
[00:30:23] So with complex work, I already said we cannot forecast risk and probability and there can be situation when you don't have any element to forecast. Think it's like throwing a dice and say what is the probability of getting six, with the only problem that the number of face of the dice are changing constantly in real time.
[00:30:46] You cannot even calculate the probability and sometimes the work we do is like that, because things around product keep on changing. Other time, the probability of risk is a uniform probability, with a lot of different risk with very low probability, but an extremely high impact. And we cannot spend money on hundreds risk with high impact. So we need to do something different. We need to embed our approach to risk, empirical approach into our way of working. And we need to add also something more, the ability to adapt and the resilience in our team. Now, let's look on the way of working.
[00:31:33] So the first point is to take a big promise, a very huge one, and break it down in a lot of small bets, experiment and smaller promises.
[00:31:47] and investing, working, implementing those small promises and making investment decision in small increments.
[00:31:58] When we work on this small promises sequentially, we start to gather data. So the information that we do not have from past experience, like we sold 100 t-shirt, 1,000, 1 million, so we have data on that. We start to gather data using these small promises, promise after promise.
[00:32:22] And the information created start to make up from uh from start to make up for the lost ability to predict. So we are going from predicting to real time projecting what we think will come based on real time information with the latest data.
[00:32:44] Now, the second element is the customer collaboration.
[00:32:48] Every bet, every promise is co-created with the conversation with the customer. With the customer is decided what promise, how the promise is shaped, what we do next, what will be our next experiment, where do we invest our time and attention? I look at the dress, I try my my dress and I say I really don't like the shoulder, if we don't fix the shoulder, the whole dress is wrong. Let's start there. So it's a shared responsibility between the customer and the provide the supplier, a shared responsibility. And this uh shared responsibility is on a voluntary basis. What it means? It means that the team can say, okay, I hear you and I don't agree with you or I don't feel I'm capable or of delivering what you want. Or the customer can say, I'm not willing or capable to pay for the experiment that you want to do. Sounds crazy, but this is important information. When you are navigating uncertainty, if the tailor tell you, look, if I go there, I will completely ruin the budget or I will take things in a direction that cannot work for the rest of the dress. Or if the customer say, look, for me the shoulder is really important. I know you want to work on this, I really don't care, I need to fix that. So that allowed to emerge important information that otherwise will be lost and in uncertainty, we cannot do that.
[00:34:32] More in general, co-creation is synchronous, is in real time and is on a tangible shared artifact, something that we can touch. It is not on abstract plan and future promises, but it is on deliverable, partially refined and finished deliverable. But this bring the customer and the supplier together and facilitate common understanding in uncertainty. Without that, the most likely thing is a divergent and the two will live in two different bubble until the end when we get a terrible surprise that we are not delivering what was expected. And this only bring disappointment unless we are very, very lucky. But being lucky has nothing to do with being a professional.
[00:35:23] So, this is an interesting point. It is doing the work that reveal what we need to do in order to succeed.
[00:35:42] That give you a measure of how much your plan tell you on your possibility to succeed. It's only when you start the journey that you really understand what is the next step.
[00:35:54] Okay, let's look on the third element of way of working. We can co-create an experiment, a bet or a promise, pick that.
[00:36:03] We can let the team and customer to say, yes, I agree with that, I volunteer in working on that. We do the work and then here is the last important big, the feedback loop. We deliver something tangible, we look at that, we share it in a transparent way and we can see if we are homing in toward the desired outcome or not.
[00:36:28] And this constant checkpoint is the fundamental element that allow us to build trust. As a client of the fashion designer, initially I may be scared, things are not going in the right direction, then I see something that is going in the right direction. I understand, the tailor understand me, he got what I want, he is working well and he is trying well to achieve what we need. And the tailor start to think, oh, this customer is not changing idea continuously, has a clear idea on what he or she want and we are working well together to achieve that. So this build the trust that is necessary in a situation of uncertainty when we don't know if it is even possible to deliver what we want in time and with the money that we have available. This is fundamental, so the feedback loops are fundamental to build trust.
[00:37:41] Okay, I'm not here to sell something, so I will also tell the truth. Whatever I described so far, the mechanic of it is extremely difficult to implement. Because there are some requirement for these things to be implemented in a team and in an organization.
[00:38:01] There is an element of customer centricity that need to come first before the stakeholder centricity. The moment that you share responsibility with your customer is not just a smaller detail. And does your team, your company, their culture go along with this?
[00:38:23] You need teamwork, but how does that work with individual performances? How many HR are working at the level granularity of team? Most of them are still working at individual level.
[00:38:37] So, easier to say teamwork, harder to do it for real when the game gets tough. And what about cross-functional collaboration when all our organization are organized by function in the border, there are people that represent distinct function, not always people that represent different line of business or product. So, how can people collaborate? And this require changes in term of policy, governance and structure. So it is not easy at all.
[00:39:10] But I rather tell you this right than sold you a lie or uh are still working at individual level. So is it to say teamwork, harder to do it for real when the game gets tough. And what about cross-functional collaboration when all our organization are organized by function in the board there are people that represent distinct functions, not always people that represent different line of business or product. So, how can people collaborate? And this requires changes in terms of policy, governance and structure. So it is not easy at all, but I rather tell you this try to than sold you a lie or
[00:39:19] in some situation you can still get some challenge like if you work in research and development, university, maybe you have external annual grants. Or you may have internal client. Those are as example of problem, but they can be handled. We can discuss them in the conversation if that's something that interests you. What surprised me, so
[00:39:47] I spend a lot of time working in Agile, but in order to deal with this topic that raised a lot of disagreement and a lot of opinion among many practitioners. I took a completely different path. I threw Agile away, no magical thinking, no dogma, and I start to look into experience and theory. I looked what it worked in the past for me, for example, in ThoughtWorks or in Ferrari and what worked for other practitioner. And what I came back to and that's what I described to you since now was already in some of the book and the things that I learned from when I started to do Agile. The voluntary element in the accept responsibility, the social element of the of the promise in the user story, the planning game and to engage the customer in sharing responsibility. The agile retrospective that is not like most teams thinks today is a fun moment for the team and let's have fun. Okay, I love fun. It's good to have fun at work. It is really good. Let's not forget that it is the key ingredient to recognize the empirical nature of the work to expect and adapt. So if we have fun, but we don't deal with the empirical element, we don't expect and we do not adapt in a retrospective, we are wasting time. Or customer collaboration, what did it really mean from that manifesto, if not other than sharing responsibility on the contract, on money, on other things. Not in trees, colorful post it and let's love each other, peace, love and harmony, but on hard money and difficult decision. So it was a surprise for me to get back to all of this and see that it was already there from the beginning. I just did not understand how deep those elements were in making thing work. with innovative, complex type of work. So to recap before going into Q&A or conversation or on one side we have the situation where accountability and commitment works, the Amazon example, the spare card example, goods are commoditized, standardized and I have a type of complicated work or red work. On the other side, I have what we call complex work in complexity science terminology, and I have that state of the art innovative type of product, project, technology, domain. When I buy a bespoke dress, when I develop part of a Formula One car, or where in my life I do all the things that come with uncertainty. And so you are the element that I described it so far. the dependability and trustworthiness, empiricism in risk management, partnering with the customer, cross-functional collaboration and real-time co-creation. invitation and voluntary approach to the promises, feedback loop, trust with the freedom to opt out. And so this is the major take away.
[00:43:13] that I described it so far.
[00:43:16] So, you see that I used some complexity thinking behind that, indeed promise theory, uh deal with uncertainty and try to build certainty on top of uncertain foundation. So, here you can find some idea, something that I use to better understand this topic. And on this you find a way to collectively assess if a piece of work project is a type of complicated work over complex work. So you know what to do and how to deal with that based on the nature of the product. Those are some links reference that I used. You can take a picture, you can get in touch with me if you want them. And now I will open up to question, conversation and also disagreement. I'm here to learn, I'm not here to sell. This is how the Agile community work. Yes, I'm here speaking, but I'm here to speak with you and learn and understand what I got wrong, or if it works, may works also for you. So if anyone has a question, please go ahead.
[00:44:46] Any question?
[00:44:58] Oh, thank you Luka for sharing your thoughts.
[00:45:02] Um, to to me it it really comes like common sense, really. And and I I there is no critic in in that statement. And I'm wondering why you spend so much time clarifying, documenting, justifying what is obviously common sense. And how powerful it is when you're trying to convince people that it's not common people that do not believe it's common sense.
[00:45:30] Yeah, that is very good question. The please can you leave the microphone? I'm happy to that is a very good question. I I can tell about my experience with Agile since 2010 after it become popular and mainstream from common sense, we shift into magical thinking.
[00:45:56] And um when I discussed this topic with people, I heard a lot of different opinion and it was hard to for me to come to a conclusion. So I wanted also not to trust some of the things that I was doing because I did it because I learned to work with Agile, lean, complexity thinking and stuff. I want to start from scratch and start to understand what was behind it. Is there a solid foundation? Am I going in the right direction? Are there other alternatives? So I started with an open mind and asking question. And you ask there are two reason why you can ask this. One it click with you and say it's common sense. I already know it. Not only, I already did it. I know that by heart. So I don't need you to tell me again. And I'm really happy if for you about that. I would like everyone is in that place. The second point is instead is I have an idea but I cannot explain it. And so I want to bring people to question every idea, to go back, to challenge. We are talking is 20 years we are talking about Agile. And Agile is about questioning what we do continuously, learning from experiment, thinking and criticizing. We are used to speaker that come here and share the true and attendees that is me when I sit there, taking the recipe and going to your team and say we need to do that. How crazy is that? No, Agile is this conversation. I think you are right. I think you are wrong because of this. I tried that in my context and it works here it doesn't work there. I switch that. So that is why you have to destroy the house, build it from scratch and inviting different opinion. This is Agile. Lean and modern way of working. Everything, sorry, go ahead.
[00:47:59] No, I I will react there. I I saw that you you quoted Dave Gray's bubble of evidence and uh I'm wondering whether that kind of of conference is kind of a bubble of evidence where we uh believe the same thing. We share the same thing but we are not talking to the people who are going to buy our services. At the end of the day because most of the time when I come to sell my services and as an Agile coach or whatever, uh I will meet uh buyers who will ask me to commit to deliver things I truly have no clue whether I can do it or not, but if I don't commit, I won't get the deal. So I commit or I don't commit and I don't get the deal. So basically that's where we stand. And it takes maybe an hour of conversation to bring some kind of awareness about the topics you're talking about. So I I think we all I I assume that in that kind of conference we all have a kind of common understanding and that's why we are doing what we're doing. Uh trying to push Agile or to educate or to teach or whatever we try to do in organization. But at the end of the day, it's still the person who is going to buy your services who will either, it's the customer who will either agree with you or not agree and either you will decide to work with him or not.
[00:49:21] Let me tell you that if you find this common sense, you are in a very lucky position and I'm telling something that may displease some, but most of us in our community don't have a clue about this. They have it as a magical thinking. I I mean, you find what is commitment or accountability in the in the latest Scrum Guide. I I don't remember which of the two, just to give you an example. So first, we need to put our house in order for those who need them. The second point is also very good, and I can tell you my experience. Some customer want accept that type of collaboration, they try everything, they fail and then they say, I try everything. I failed. Now I'm hopping to a new idea. And for us, as a professional, is since it's a partnership, think about that. I call it a partnership. We need to find a partner we can succeed with. A race driver, a Formula One driver need to find a team with a good car, a football player need to find a team that can win the championship. So that partnership is also about choosing clients that have a chance to succeed. And that's, yeah.
[00:50:39] you made two great points. So thank you for giving me the opportunity. Any other questions? Any question that you feel the need to ask? Or I think I'm keeping you from lunch, so Thank you. Thank you everyone.

Transcript