Adopting Agile Mindset

Adopting Agile Mindset

‍

[00:00:03.770] - Speaker 1

All right, mid-past six, at least here in the UK. I think we are ready to go. Welcome now officially to our webinar. The second time Tony and I are doing it, but the first live Agile Encounters, part two. The topic for today is adopting an Agile mind it. Before we move on with the topic, a few technical notes versus a chat window available for all of you. You can write anything to us, you can write anything to each other. Please use it as you wish. If you have a question, however, there is a special mode Q&A mode that we will switch on a little bit later. And the questions that you will put over there will also appear in the presentation on the screen. So please use this one. We'll be looking at it closer to the end of the presentation. I think that's it from a technical perspective, what did we prepare for you? So, first of all, Tony and I, we know each other for some time, and we've been working together, supporting few customers on their agile journeys. And our point of view on webinars and meetups like that is that the best is to meet and have a conversation and we thought, okay, let's do it and let's invite others to listen to us.

‍

[00:01:30.910] - Speaker 1

Maybe we'll find these topics interesting especially, but we have a limited but still way to interact. Both Tony and I are Agile coaches management consultants, but in the field of Agile product delivery and we have several what I call I shouldn't, but I do Warfield stories. So relax. Examples real cases that we know resonate with people. They resonate with people with certain training sessions for our consulting engagements topic for today, adopting Agile Mindset disclaimer at the very beginning is not to tell you how to manage, how to encourage your customer, how to make or force your organisation to adopt Agile mindset. It's not also how to coach the organisation to do that because it's so context specific, product specific, culture specific, people specific. So instead of giving you set of detailed agenda, how to go one by one helping customers go to networks Agile, we will share a few stories of ours, but we gathered into several points over here and we think you will find them, some of them at least inspiring stories are over here. We will start with the topic of mindset. First of all, if we talk about adopting Agile mindset, what mindset is first of all?

‍

[00:03:01.870] - Speaker 1

Then we'd like to share with you a few examples of leading by example, moving to quite important topic of building trust and communities and change agents in Agile transformation and measuring success. That would be the final, final one. Q and A at the end. Before we move on to the first topic. Tony, anything from your side?

‍

[00:03:26.530] - Speaker 2

No. Just looking forward to the conversation with you this evening, Pavel, and sharing a little bit of what we've covered and what we've experienced, see if anyone gets any from it.

‍

Agile is Culture

‍

[00:03:36.870] - Speaker 1

All right, that's cool. So let's move to the first part. It's not a story really, but we would like to share a few words about mindset. My experience is that very often I would say 50% of my customers have no clue that Agile is way more than just Practises or methods. First question I ask during my training session about basics of Agile guys, what Agile is. The answer is Agile is a project management methodology which is so wrong. So half of customers have no clue. This is something about mindset, about culture, about attitude. Another half of customers, my experience again, they are really aware of that but have no clue what to do about it. Okay, so Agile is culture. Fine. Now what? That's the topic. And we thought while taking you into this journey around a few stories of ours when we helped customers adopt Agile mindset, it would be good if we start with explanation what mindset is at all. Tony, your thoughts.

‍

[00:04:44.650] - Speaker 2

So I mean my thoughts on this and you know from past experience that I'm very coaching in my style. So one of the things I think of when I think about mindset is the way in which you see the world. So you have your own set of lenses, your biases, your philtres. And for me that can sometimes prevent you from seeing things that could help you, could improve things for you, or you may just actively be discounting them because they don't fit in with the way that you make sense of the world today. So for me, the mindset is about almost the way you see the world, the set of lenses, you see it through the glasses you're wearing.

‍

[00:05:23.350] - Speaker 1

Is it something that is helpful or not necessarily helpful during gadget transformations?

‍

[00:05:31.370] - Speaker 2

Using this expression, mindset specifically is probably something I avoid because it can become quite polarising. Either someone will be open to the idea of exploring it or it will turn them off straight away. So I tend not to use the expression, I tend just to try and find opportunities for them to see things they're familiar with in a different way. That's what I'm looking for. I don't know about you, what's your experience?

‍

[00:05:59.890] - Speaker 1

My experience, I think it's quite similar. It's not that I intentionally avoid talking about mindset, but I know that starting discussions about business agility from the culture perspective, mindset perspective is not as a misleading but counterproductive because people will say yeah, we agree, fine, but nothing will change. It's something that comes the change comes over time. I typically start with Practises introduction of Practises that fit their current culture. Whatever the current the bottom line state zero day zero state is offering them a few of Practises that perhaps will not change dramatically in a revolutionary way, their current ways of working, but they will give them a baby step towards agility is the first step I encourage them to take. And then as we go, step by step, we're opening more to the new mindset. It's my first couple of cents. Another one is that very soon it's a matter of months rather than years. Companies that I work with start either challenging the entire concept of going to Agile way of works or without challenging, they're asking how we can measure it. And it's so tricky. The conversation about measuring Agility, I wonder what your thoughts are because before I.

‍

[00:07:23.040] - Speaker 2

Reveal mine yeah, I mean, measuring is a real place of pitfalls, really. If you try and measure something like as we're talking about mindset, it's almost unquantifiable. I've not come across any way of doing it myself. I'd be interested if anyone on the call has experienced anything around that space. I tend if people are insistent upon measures, I tend to focus on how do they describe success? So what is success for them? Rather than talking about Agile and using that as the mechanism of well, can we measure it? And if we can't measure it, what indicates to you you're moving towards success? Because they're probably better guides that this way of working is bringing you or taking you where you'd like to go.

‍

[00:08:10.990] - Speaker 1

I personally see that a lot of companies try to measure Practises, Agile Practises, and it's a waste and have no sense. How many retrospectives do we have in a sprint? Or if is daily scrum every day? Or how many people attend sprint review? What's the trend of that? It's easy to measure. Absolutely. It's useless completely. I don't see any value of that. So I actually bring up the topic of Agile mindset or culture in general. When I see these kinds of attempts asking people, guys, if Agile is culture and everybody agrees it is at that stage, I tell them, well, how would you measure culture? Are there any ways and any proper research methods in the field of culture? And of course there are, but there are very expensive and time consuming. It's observation, interviews, ethnography, for instance, something that you would you wouldn't do. And that leads us directly to the to the conversation that the best way to measure Agile is to measure how good or bad we as organisation are in achieving business goals. Because Agile is just a tool, it's a way helping us achieve the goals. If we are better in achieving the goals, that means the entire idea for taking the path towards agility was not so bad.

‍

[00:09:33.370] - Speaker 1

That's about mindset. I'm checking if there are any questions from the audience. Let me turn on the Q and A. It's up and running right now. If there are any questions, please write them down in the window and we'll be happy to give the answer. We're going to give you literally 15 seconds for that.

‍

[00:09:57.470] - Speaker 2

So while we're waiting to see if there are any questions, when have you found have you had any experience of mindset being an important starting point when you've worked with clients?

‍

[00:10:11.810] - Speaker 1

Tough question. I'd say yes, but in a bit negative way. So I'm really keen to find out what the day zero mindset of my customer is, especially if it's very far away from Agile mindset, because that gives me a hint. It would be very hard to challenge few things. We need to start slower or we need to plan the journey in a little different way. And I think that's something that I see quite often. Maybe it's the thing who my customers are. Typically, these are companies that really struggle and we're far away from Agile mindset. If I had a customer that is already Agile by design and they just want to learn more, it would be so easier. But this is not my profile. Not yet, I'd say. So it's quite tricky. Quite tricky indeed. But I pay attention to it from day zero to find out where potential risks could be.

‍

[00:11:24.330] - Speaker 2

So we have a question Jack's asking. Is there a way to help measure how Agile somewhere is? If you're asking to measure health cheque type of thing.

‍

[00:11:37.390] - Speaker 1

Johnny would like to take it.

‍

[00:11:39.340] - Speaker 2

I thought you might ask me that, so I suppose I've come across some means of doing it. There are surveys and things out there. Personally, I found the ones that are labelled Agile tend to be a little prescriptive, like Pavel described. They may be asking you to identify visible things. I found better ways of doing it are looking at things like the Leadership 360 type surveys. They tend to be more informative to me around which way round the organisation is orientated. And what I mean by that is which way that the hierarchy or the pyramid of the organisation operates. Those tend for me to tell more about where the mind of the organisation is today than maybe a direct Agile questionnaire or Agile survey, if I was.

‍

[00:12:34.320] - Speaker 1

Going to put it that way.

‍

[00:12:35.970] - Speaker 2

How about you, pebble?

‍

[00:12:37.610] - Speaker 1

I remember one way that I really liked way of helping organisations measure agility. It was designed within Scrum torque, as far as I remember. Yes. Ago. It's not in use anymore. It was before Scrum dork found out. Evidence based management framework. A few years before that. It was a sort of survey plus a set of questions for real interviews. But as an Agile coach, Scrum coach these days, you would help your organisation. So it was a process. The entire Agility was defined based on five different domains. It was a series of questions, but you are not assessing yourself as a coach, but you're engaging the organisation, the managers included, into the journey. The questions were not directly about the practises, but about the outcomes, about what was important. I think that's my guess only. Frankly, I never asked that. This project was not continued because it was time consuming. It took a few days to have the full assessment and therefore very expensive. And to make sense, you need to repeat it quite often. There's one more question, so before we move on, let's try to answer this one question. If Agile mindset can be measured, how we would know whether we have Agile mindset or whether we are on the right track to adopt it.

‍

[00:14:11.160] - Speaker 1

Also, why should we care about adopting Agile mindset at all? Over to you, Tony.

‍

[00:14:20.050] - Speaker 2

I'm just really ruminating on that last part of the question. So why should we care about it? I honestly don't believe you should care about it. There's other things far more important, and getting that mindset is probably a by-product of getting to there some things that you want to achieve, maybe not within your gift, until you have that kind of mindset. But getting the mindset itself is not in itself the goal. So I would say, yeah, as we've discussed, it's really difficult to actually measure this kind of stuff. So I'd go for things that can be measured, that count, that are important, and use those to be a guide to whether you're sort of embracing those kind of Agile ways of working Agile mindset.

‍

[00:15:08.450] - Speaker 1

I tend to agree, first of all, and in case of such broad questions, I very often come back to debut. So 2001 v Manifesto for Agile Software Development. Agile, as it was defined, it was a set of values and principles, something that you can't literally do, something that describes your attitude approach to software production these days, mindset in general, and perhaps that's why we care about. I do agree with you that if we talk about a particular organisation on their Agile journey already, Agile organisation, it doesn't really matter. What does matter is for business goals, the outcomes. Agile is just a tool and as such, I wouldn't care about it. But if Agile is treated seriously, Agile is not just practises and methods, it's the inter-complete system, including values and principles. So if we miss that part, we actually miss half of the toolkit. I'd say so. And that's why it's perhaps important to me, it's secondary always, but not the mindset. Agile, no matter which approach you would take, it's secondary. What is primary business objectives of the company and the reason why somebody thought it might be wise to solve our organisational problems with Agile or with Lin, because it seems they should help us.

‍

[00:16:36.590] - Speaker 1

All right, that was just an intro topic, the mindset. Let me come back to our deck over here. Let's move on. Tony and I would like to invite you to the first broader topic that is named leading by Example. Shall I start, Tony?

‍

[00:16:55.850] - Speaker 2

Go ahead, Paul.

‍

[00:16:56.890] - Speaker 1

Yeah, first time I met Tony was when we supported together quite a big organisation, international organisation that did it right. In my opinion, they did it right. Perhaps because of initial mindset. Indeed, that was installed over there. There were a lot of indicators of data visual, big, visible, visible charts, maybe because of the way how executives and sponsor of Agile Transformation behaved, and there was a lot to buy in from them. But leading by example in general was a topic that was so bold, there few Warfield stories to discuss. First thing, it's great if we introduce Agile into organisation in an Agile way. So not yet another waterfall project with various phases and milestones, but something that is emergent. That is emergent. It's a living transformation with perhaps pretty stable vision, but goals set frequently and revised also frequently. First thing that I remember for the company I joined after they started transformation was there was a particular space in the office pre pandemic times that I called Agile Incubator. All scrum pilot teams these days, and just scrum teams and pilot teams were sitting together, literally one floor, one wing of the company. And whoever visited that area, other workers, sometimes visitors from headquarters, for instance, they knew it's something different.

‍

[00:18:38.790] - Speaker 1

You would see it when you look at it, look at victims. They were swarming, they had boards, they had their meetings. That's the first thing I remember. Tony, what was your impression because you joined a few months later?

‍

[00:18:52.970] - Speaker 2

Yeah, I joined a bit later on. I was quite surprised when I arrived at the amount of visual management that was taking place across this organisation. It was everywhere and everyone seemed to be having a go to varying degrees. But the thing that struck out to me was that Incubator area, how much had been tailored towards the teams? I've come across something similar with an American organisation where they had this idea of dojos and they bring teams in to get them working together and performing well. So, yeah, that was my takeaway. I was going to share a little story, if it's all right, about one of the specific areas, a division inside there that dealt with reliability. So if you imagine this is a firm that engineers, and if you think about engineering, not from a software point of view, but stuff that moves the physical things, engineering. And when I joined them, one of the things I noticed was that of the 100% things they started, they were only actually making 20% of those things come to life, actually be acted upon, and their real value was reliability. So I have a bit of a past working in infrastructure, it infrastructure in data centres.

‍

[00:20:08.350] - Speaker 2

It reminded me of those kind of times. However, the way you approach things there is totally different to this group. And they had a physical constraint, a physical limit that they were trying to beat, and it couldn't be beaten. It was limited to 20% of what they produced. So I think, coming back to the topic of leading by example, what I noticed with that group was a couple of things. When we started working with them first, they were open to the idea of using Agile ways of working to introduce Agile. So the leaders were willing to actually go through the whole process of introducing this way of working in an iterative and incremental kind of way. So they were starting to experience what the teams would experience, which I thought was a really good sent a good signal out. And what I found was as they started to grapple with this challenge of we can't do all the things we'd like to, something that emerged was there were the two groups. There was groups of specialists and groups of generalists. Now everyone was a specialist. But when there were problems occurring that needed many different disciplines together, they would crash everyone together.

‍

[00:21:19.610] - Speaker 2

And they use this term that Pavel mentioned earlier, war rooms. They would have a war room, they'd bring everyone together, it would solve a problem, create utter chaos back in their specialist teams because they were having to let go of even more work whilst they did this. And then they would disband this room. They would go back and deal with all the backlog of all this stuff that had built up over time. But what I found was by getting into this idea of introducing Agile, using Agile, the people who had the opportunity to influence the teams, the leaders of those areas, they were much more receptive to. We do need to help you focus. We do need to reduce the amount of work we send out to do. So they almost taught themselves some of the great things that they need to do or empower the team to do. I don't know about you. What was your takeaway from our time with that client?

‍

[00:22:16.330] - Speaker 1

Speaking of the war rooms, I think this is a fabulous example of using the existing culture, existing before Agile One in order to help people transform war rooms. So task forces, but also physical room, literally a room where the task force could work for a couple of days or weeks was something that was there forever for Incident management. And we just extended that concept to be a permanent war room. Maybe not a room a little bit bigger, hall actually, but we did the same. So we had boards with the most important information. We had a separate condom board for blockers and impediments. Again, we met every day, literally like in the war room, but also like in Agile methods such as Scrum to plan the day and communicate. I think starting from the concept that we were familiar with and using it in more Agile way was one of the key success factors over there. Especially that typical war room during incident management was a place that a lot of executives visited also because incident is something important that perhaps we should take a look at. So we were also visiting our Agile war room.

‍

[00:23:39.830] - Speaker 1

In that case, they were exposed to what we were doing over there and also engaged in solving impediments in unblocking what was blocked. That's what I remember mainly from these times. Unfortunately we don't have any pictures and das for PDAs from showing them, but it was big and we will have the one more chance to talk about it closer to the end of our presentation today. One more thing, if I may tell something that I recall also as key success factor and we already spoke about it a little support of executives, I hear it very often. Of course we do support Agile ways of work. However, to hear it heal the declaration versus to see executive team really using Agile also for their own, there are two different stories. One that we can share is that Executive Leadership Team reached out to us at the very beginning of the transformation after a few several months actually, that they would like to use Agile ways of work as well. First of all, to improve, they work as a team executive but still leadership team and secondly, to lead by example. And what was introduced with our help order was Common Board to help them manage portfolio of strategic initiatives and it was not in a room but in a corridor so that everybody could see it and really supported all the efforts of ours in transformation at this stage.

‍

[00:25:23.270] - Speaker 2

Pablo, as you say that you just reminded me tying this back to mindsets. There was one individual in that area we worked with and when we started working with them, the idea of having any slack time, any free time to themselves was unthinkable. That was actually seen as potentially it was a failing. When we started, as we've gone through this journey with them, they wore the fact they had capacity to think and the capacity to actually make sense of what was going on as a badge of pride. So they would actually quite openly say in their group of their periods I've got free time on my hands and that's a good thing because I can actually really focus on what's getting away of this or what does the team need from me next. It was amazing watching that individual in particular go through that kind of journey of I'm not sure about this stuff to actually I do see some kind of benefit for me and then I can help others as a matter of that. So that wearing slack time or available capacity as a badge of pride was a real takeaway for me of a shift in mindset.

‍

[00:26:30.830] - Speaker 1

I think many of people here listening to us will be interested in how we how did we achieve that and I think that's a great segue to the next story, next set of our stories. Let me bring you over here just to summarise what we're talking here about regarding leading by example. First of all, something obvious but very important, especially if you are down there trying to help your customer apply Agile while introducing Agile, as simple as that. Help leaders experience the journey the teams are going through. That works on both ends. First of all, teams see that it's not just for us. Leadership do care as well, so they lead by example, literally. Secondly, leaders literally experience the journey of the teams and see what they struggle or what they potentially could struggle with. Finally, we need to accept that not all approaches work in every context. Perhaps that's why we're not giving you a step by step recipe, how to achieve that, but showing few stories. But we remember because they were bold and it worked. Let's move on. Let's move on. Next topic we have for you is set of stories around building trust.

‍

[00:27:51.670] - Speaker 1

You are way better than I am as an Eastern European in building trust with customers. Let's start with you. I know you would like to share a few stories about a few individuals that were pretty similar on one side, on the other pretty different. Over to you.

‍

[00:28:11.630] - Speaker 2

Yeah, just to really pay back the compliment you just gave me. I don't know if I'm any better at building trust. I think it's all down to the relationship you develop with individuals and for some of us, certain individuals we can work better with than others. And I think when you're working in this space, you have to acknowledge sometimes I'm probably not the right person to be working with this group or this individual. I think in the example I'm going to give now, I nearly came to that conclusion. I'm thinking of it was an HR team, so it was actually in the field of people, really. And it was an individual I started working with who from day one, hearing what we were about to embark upon was completely unconvinced on how on earth you can run an area and not assign all the work to everyone. They thought that was an unthinkable proposition. So getting back to mindset again, this idea that everyone would self-organise around the work, they would pull the work in, they would decide and assign themselves, it's just never going to work. And what I learned was that there was a huge amount of importance placed on the idea of status and that was okay.

‍

[00:29:23.220] - Speaker 2

So I acknowledge that that's okay. There's nothing wrong with some people needing and having a need for status, that's fine. But what we discovered as we went along was they couldn't see beyond this idea of assigning work. So the way I approached this, and as we said before, I'm not saying this works in every instance, was I almost set a wager with them. So I effectively said, well, we know what it's like now when we assign the work. How about we run a little experiment and we see what it's like when we don't assign the work and then we measure the difference and they got them into the thinking about again, what do they measure of success? So it's like not, I'm not going to talk to you about self-organisation, I'm to going talk to you about this, that or the other. We just want to know well what's your outcome like today? What does it feel like today when you're assigning things and we frustrated with let's be honest and then let's run a little period of time where you're not assigning things effectively, you're letting go a little bit and see how that goes.

‍

[00:30:25.480] - Speaker 2

We ran the exercise and lo and behold people took that kind of extra additional responsibility, personal responsibility on well they started pulling the work, they took ownership, it all sort of grew from there and this person went from a detractor to a huge advocate. So much so that they were willing to start to post on their internal social media of their organisation about their story, about their journey. And it was a case of what, to me felt like at the outset, I wasn't going to be able to get trust with this individual. And I might have to reach out to another coach and say, can you work with this person? Not me. Turned into a well actually I've got the evidence myself, I've proved it to myself, I've seen it and now I'm bought in. So I'm not saying this is going to be easy with everyone. That's why I really stress. You got to establish, have you got enough trust with them for them to even go with you on the experiment? And then if you can go through the experiment and it does turn out because be prepared, it might not work out, then you get that extra layer of we know to trust each other.

‍

[00:31:35.500] - Speaker 2

How about yourself Pavel? Because you mentioned that I've built trust but I have seen you build trust and I'm not convinced I'm alone in that.

‍

[00:31:45.320] - Speaker 1

We need to talk about it once, perhaps we can start right now. So in theory, really not in Practise, building trust is very easy way is a thing to do. I need to remember two rules really. The first one is don't make the person, the individual wrong. As simple as that because they don't like to be made wrong. Especially if you are right that they did something wrong. It's the first thing. Secondly, in order to build trust in theory just keep your promises. If you promise you will do something, you have to do it and that's it. It's very simple. And I see a lot of people also coaches failing in that area still it's theory. The practise is I always try to find these people that at the very beginning they resist a lot. I named it Constructive Resistance and one of the individuals that you were talking about was a person who before working with you attended my training session. I spent with the person two days and that's it, I wasn't involved anymore. But out of 20 people in the classroom, big classroom, that person was. Really tough guy for me as a trainer, asking a lot of questions, trying to maybe not jeopardise what I was doing, but trying to learn how does it work in Practise?

‍

[00:33:18.740] - Speaker 1

Is it really so? That's it. And I like it. I like these kind of people because my experience is the more constructive resistance I see, the better promoter of Agile mindset the person will be when it click, when it click, it's a matter of months, few months before it clicks. But in that case, these people become great advocates of what we are doing. There's no one fit all scheme over here. I think what is important in our job is to find out what the person is really looking for. One of the individuals was really paying attention to people being busy. You did work with the person as well. So in imagination of that individual, my people have to be busy. If they have slack times, that's not good and they will not work. And that's why the person was against Agile. Because Agile comes with self-organised teams, autonomy of teams, and if you introduce the Kanban method, also the concept of slack time. We are not starting something if we are totally blocked, we are focusing on blocking or we are doing nothing really, because in midterm that will increase the throughput. But the person was also very data driven and when we showed charts, this is how it was before, how it can be.

‍

[00:34:47.710] - Speaker 1

I think it clicked and trust was built.

‍

[00:34:53.550] - Speaker 2

Yeah, I would agree. I remember it really well that they were in a context of reducing the size of their organisation as well. So the whole question about keeping people busy, it was a guarantee everyone was going to be busy, there were less people, there was still the same amount of work to be done. So they had to think of a new way of doing things. And as you say, it was that journey that individual went on to discover that there is an alternative way to do this. I just needed to see the proof. And I think often, like the first story we were talking about, it's about allowing someone to find the proof for themselves. Sometimes you need to help them construct the experiment. But it's their experiment. Let them own it. Don't make it yours.

‍

[00:35:40.190] - Speaker 1

That reminds me another story, same company. Actually, not sure if you remember this one, Tony. Three independent coaches these days entered the department of 120. I'd say developers, more or less. Ten teams, single disciplined teams, so the concept of functionality didn't exist. A lot of dependencies among all the teams. Obviously each team supported same set of customers. The big spaghetti if you draw a picture. By the way, we did draw the picture and was pretty bold message to the leadership. And the first thing I proposed was guys, let's do scrum. And we need to create without maybe changing structures. We need to create cross functional teams. And it was a huge resistance. No, we will not do it full stop. I think the smartest decision we made these days was we will not push. We will not push. We changed our approach deep leaving cross functional teams and Scrum would be the perfect fit. Over here, we started with Kanban, but the Kanban method, we start with single discipline teams. After a journey of about 910 months, guess what happened? The organisation proposed to change the structures to cross functional ones and the teams were reorganised.

‍

[00:37:02.850] - Speaker 1

They were continued the journey using the Campbell method mainly, and at the end of the day, they achieved what we proposed on day zero. But it was their idea and they were ready for that. And I think that's also a good lesson that even if you feel you are right, even if you are right, technically speaking, don't push. If you see a lot of resistance, try to wait or address the same from a different approach. All right. Comes over time. I think we need to move on.

‍

[00:37:36.160] - Speaker 2

Definitely.

‍

[00:37:37.170] - Speaker 1

Just to summarise what we were talking about over here, a few highlights that we just caught before that meeting. In order to build trust, challenge those unconvinced to run an experiment. Typically, it works no matter if you're working with senior management, middle management or with teams. We're not changing it forever. Let's run an experiment. People that are even in not so constructive resistance, they will want to run an experiment to prove you Agile Coach you're wrong, which is fine as well. Secondly, make the results visible and help people to interpret the data empower all their ship. We will come back to the topic in a moment. Lesson one. Next set of our stories about communities and change agents. Change agents, communities. I think all of you, everybody is familiar with the concept of community of Practise. In brief, it's not a formal structure in organisation, but a community created bottom up. Not by a mandate of the management. And a place where those who want volunteers interested, those people who already got by in or they're on the edge, they want to do something together. If this is community of Practise, of Scrum masters, these are simply Scrum masters.

‍

[00:39:03.730] - Speaker 1

Not all of them, but just these who want to share their experience, learn together. And that's pretty obvious if you are an agile coach or a Scrum master. Indeed. However, we found out during our journey that there are a few ways how you can build it in a differently not so obvious ways. Shall we tell a few words about it?

‍

[00:39:27.570] - Speaker 2

Yeah, I think so. And I was also going to mention Pavlo asked you a question in the audience there. The question and answers is still open, so if you do have any questions, please pose them through and we'll try and pick them up either through the conversation or at the end. But yeah, in terms of this is a team based story, really. And what it took me back to was my coach mentor gave me this expression, which I never liked, if I'm being honest. He talked about, you've got to establish a team of schemas. And I didn't like the term schemas, but I get what he meant by it. Now, it was almost that group of people who are curious, they've got an appetite to learn more. And the reason I bring this up is we found this group within this large area that Pavel talked about, where we mapped out just how big a challenge they had in their hands. And these individuals, they were really stood out during the training. So they were really sort of asking those really deep, almost surgical questions about how it all worked, really curious. And then when we got into working, they came across as they would always help everyone else out in the team.

‍

[00:40:42.400] - Speaker 2

So my suggestion was, well, I'm just going to put this call in, we're going to call it the design group. It's not going to have any formal attendance, there's no hierarchy or you don't have to be a certain level in the organisation to attend. Anyone can attend. And what happened was we had a little bit of a changing audience, but gradually this group started to establish the sort of almost what I call the ground rules that enabled the flow of work between these specialised teams. Because I didn't know the answer to it, nor the specialised teams knew the answer for the other team. They needed some way of agreeing and it was almost like the handshakes that had to happen between these teams and this design group was so powerful that they could put a change through the whole way of working. Within a day, they could literally speak to all their teams, something that, if you are coaching, and it was several teams at once, would be unthinkable because you just couldn't get through there and it would feel a little bit like the coach was doing to the teams. This flipped it the other way around.

‍

[00:41:43.830] - Speaker 2

You were creating the environment for the improvement to come out. Everyone involved felt empowered because they were coming up with the improvement. So they were invested, they felt that it was theirs. They then took it upon themselves to talk to their colleagues, their other team members, really help them understand. And as I said, it would normally happen in a 24 hours period and then you'd see all of their workflows change to enable this kind of change in interaction happening. And I think what I've learned from that is if you can start to build that community, however small, however fledgling, to start with, it really will pay off later on. It won't pay off straight away, it never does, but it's later on it really starts to grow arms and legs. And the word of warning here is you start to feel a little bit redundant as a coach because they're doing it all for themselves. But they have all the context. They can explain the change. If anyone in leadership then questions it. There's a group of them, so they feel a little bit more empowered and they don't feel so vulnerable when they're putting these changes forwards because they feel they've got the power of a group, there a community behind them.

‍

[00:42:57.500] - Speaker 2

I don't know if that was what you're thinking about or whether you had something else in mind.

‍

[00:43:00.490] - Speaker 1

Powell I was thinking about this case, but from a slightly different perspective. First of all, the biggest lesson for me is it works because we observe it partner. Not with one customer, not with two, with few ones. So that's something about this one. Secondly, huge lesson is that it is so good if Agile is run by your customer, not by you. And such a group, such an internal community really helps. It's not a coach who suggested something, no matter internal or external, by the way, it's us who did that. If I go into details of the story of this case, but you are talking about Sony, I think we can reveal that. It was pretty simple at the beginning and none of us thought of a community. We run a series of Kanban training sessions for a bunch of teams, ten or so in one big department. Each team started to work with a coach preparing their Kanban systems. And one of the first steps you do with your team is a static workshop. Static is a practise from Kanban world. Static stands for Systems Thinking Approach to introducing a Kanban. Pretty focused meeting or series of meetings with your team, helping them discover why they want to create canvas system, how they want to do it, how they want to manage it.

‍

[00:44:33.300] - Speaker 1

And I would put a full stop over here, but it was not one team, as I mentioned, to several teams in one department. And very, very soon they find out there are many dependencies and it's good if we communicate. And they struggled because each team designed their board in a different way, which is good. We don't want to set up one standard, but they thought if we talk, we will at least see what we need on the interface among the teams. And that's where we created the group. It wasn't a committee, it was a task force. I'd say a bunch of people who already got Kanban, so they knew what they were talking about with our assistance as coaches, trying to find out some solutions to the current and local pain points that they had. And that evolved after weeks, not so many weeks, I'd say two months stops into actual community because all the design of the interfaces among the teams, it was already done weeks ago, but they still thought it's great to meet, to share experience, and they work as a community that was awesome. My second story from similar area would be something about pilot teams.

‍

[00:45:47.950] - Speaker 1

One of good I'm good ideas to start an Agile transformation. If you're focusing on your organisation, anything above 50 people, I'd say is to start with pilot teams. So nominate one, two, maybe five teams projects, even old fashioned traditional projects where you would like to test what Practises, which Practises and methods from Agile work which doesn't. And if pilot teams are managed well, so they have full support of an Agile coach, proper training at the very beginning, we know exactly what we want to achieve with them. Not from project perspective, but Agile transformation perspective. These people involved into pilot teams will be great change agents later when pilot teams are dismissed and they come back to their original teams. And that's exactly what happened to us a couple of times as a coach, if I enter department of, let's say 100 people, I'm alone, maybe there are two coaches, but still 100 against two. If I have one, maybe two change agents who already see what good looks like, who already were trained with us, they would be great advocates. And again, their voice, voice of one change agent, internal one would be way more vulnerable if you compare it to an external coach.

‍

[00:47:15.360] - Speaker 1

And when you invest a lot into these first successes success stories, because it simply pays off, it makes transformation better, faster and our life as coaches way easier, don't you think?

‍

[00:47:31.180] - Speaker 2

I do. And I'm just looking there's a question from Sarvesh which kind of links into what we're discussing now because you're talking about pilot teams and if you wanted to tackle that now it's about teams that are reluctant really to make that shift.

‍

[00:47:48.630] - Speaker 1

I tried to put it on the board. I'm not sure if I can. I can't. So we have to reach the loud.

‍

[00:47:55.290] - Speaker 2

That's okay. So how to work with a team that is new to Agile and team members are reluctant for the shift and feel they're too busy to use campaign boards, have scrum Agile events. So what would your sort of approach be? Pavel.

‍

[00:48:10.570] - Speaker 1

I think in the same spirit that we started, Agile is not for sake of Agile, but Agile is tool or set of tools to solve problems. I would start with problems literally in static technique that we use in the Kanban method. We name it sources of dissatisfaction, which is pretty sophisticated way of saying what are your problems or problems of our customers? And I would focus on solving them because first of all, that's helpful, this is what we want to do. Secondly, that's very tangible and sometimes quite often very emotionally related to the team, to the people that are not perhaps yet convinced. If we gave them something that gave them relief from the day to day problems, they will like it, they will be happy and they would be interested in going forward. So I wouldn't explain them one more time and yet one more time. Why is it important to have spring retrospective? I would focus on their pain points, aim them and solve them using Agile techniques, no matter which. How would you?

‍

[00:49:21.400] - Speaker 2

I would completely concur with that. So I would also take the pain points approach. The addition I would add in is if you can find a pain point that both the team experience and those who request things from them also experience, you've hit gold because effectively, by overcoming that, you make the team's life better and you make the requester's life better. So they're both going to effectively be motivated to support the change. So I'd say if you can find pain points that hit one or multiple parties, you've got far more support. You might end up with the opposite problem. The reluctance shifts and suddenly there's an appetite to do more and more and more. So my word of warning is this can quickly turn from we don't want to do this stuff, we don't want to adopt this Agile mindset to we've seen it work, we want to do lots of this now and we want several teams to do this at once. So it's always getting wild. Yeah. In my personal experience, it's operating within my own level of competence, so I'm always cautious not to extend or promise more than I can do.

‍

[00:50:34.970] - Speaker 2

But pain points, as Pavel said, has been my weigh in as well of entering systems and organisations.

‍

[00:50:41.950] - Speaker 1

Right, thank you very much, Tony. Let's move on. I have a couple here trying to summarise what we did talk about right now. Change agents and communities identify early advocates very often, especially nowadays. You will see people who did work using Agile ways of work, for instance, for previous employer. So even if the organisation have no clue what Agile is, there are few people who already know it from previous life. Start with them, maybe build ownership through community as we discuss and encourage early pilots change agents to share their story with other parts of the organisation. One warning for me, maybe over here, because I remember it from one of companies I did support ten years ago or so. They did something that, in theory was great idea in Practise was rubbish. They invested a lot in one team, I wouldn't name it pilot Team, just one team. Test driven development, technical excellence, Agiles of work. Extreme programming these days was perfect team. And when the organisation management found out that that looks great, they wanted to scale it up and what they did was very, very bad. So they dismissed the team. They dismissed Team A completely, sent each single team member to join one of our teams.

‍

[00:52:11.860] - Speaker 1

In that case, a team of ten was dismissed and ten other teams got one team member. Because the idea was that if a member of the great team now dismissed enters new team, he or she will promote these ways of work and his new home team would be a factor. It doesn't work like that, unfortunately. I prefer different way of scaling, but perhaps there's a different story. Shall we move on to me?

‍

[00:52:41.250] - Speaker 2

I think so, yeah. I think one more area you want to touch on.

‍

[00:52:46.630] - Speaker 1

Last area that we prepared today, something about measuring success. We gently touched this topic at the beginning, talking about the mindset and tell me what else do we have?

‍

[00:52:58.810] - Speaker 2

So I had an example again from an interaction with an HR department. So they were very hot on measures and data, that was their world. And what I found working with them was they wanted to know what is the perfect thing to measure, to give us the perfect answer and that everyone else in their professional industry was doing. And my answer to them was, that doesn't exist, there's no such thing and I'm not convinced anyone's ever going to get an answer, there's going to be the perfect measures for you, but I don't think another organisation is using them and I don't think their measures will be useful for you. But what we did instead, we flipped it and we started to look at, well, what's the kind of impact they want to make on the organisation? So when they change this way of working, how do they want to be? And I sort of started to use a technique some of the people on the call may have heard of called impact mapping, started to illustrate out what are they trying to achieve through that? But it became very evident early on that they were struggling with getting clear on what was the goal or goals they were after.

‍

[00:54:09.420] - Speaker 2

So I took that technique I was using and combined it with something called hypothesis driven change, which is just really about making your beliefs explicit. And by getting this large group of leaders to make their beliefs visible through hypothesis driven change, it became evident very fast. They all shared very different beliefs, so their difference in beliefs was going to then philtre down into the teams and cause absolute kind of confusion. So they were really, really engaged to get clear on what is the belief that they can all rally around, and that became their goal. And why I'm telling you this in the context of measures was it then allowed them to get very specific around measuring movement towards their belief. So their belief was something in the distance. We believe the following will happen and we'll know that because we'll be able to measure this result in this way or we have to observe the following. And by doing that, they got their answers, they got their measures in their context, and they were able to chart their course and ensure that everything that they were doing, everything that teams was doing was always contributing towards these beliefs and testing them, knowing that some of them may not validate, they may not turn out the way they wanted.

‍

[00:55:23.300] - Speaker 2

But it was a really interesting journey for me of a team that were very into measures but probably looking for answers to be given to them or spoon fed. Whereas this way they came up with their own measures. And they were then able to see, well, some of these things we're going to have to start thinking about, because we never really thought about measuring things in that way before. But we can do it. So that was really what it made me think of when we were talking about measures. How about you pebble?

‍

[00:55:51.330] - Speaker 1

I'm really interested in the topic of that section measuring success. Not measuring agility or business agility, measuring the goals but measuring success. If we are talking about adopting Agile mindset if you take any organisation change management process like any phases of change management you will see one of first key success factors is to share to communicate successes if you have no success created, because that's very important to have early indicators. But it can be done. It can be done. Could be done in our organisation. The approach we took so far is of course to measure what is important, to be measured from day one just to see how introduction of Agile waste of work helps or not achieve our goal but also focus on the successes pilot teams. I think what has to be done at the end of when we conclude each of the pilot teams during Agile transformation is a proper case study. Smaller or bigger, but something that you can immediately share with the rest of the organisation as a proof. What worked, but also what didn't work is very important in the topic of metrics. There are always crowds whenever we have a module or full training session about what we measure what are the metrics in the Agile world because people think they will receive the set of answers from us.

‍

[00:57:30.400] - Speaker 1

If you go Agile need to measure this, this and this. No, you won't get it because it's context specific product project and organisation specific. But what I would insist on, at least at the beginning of your Agile journey with your organisation, is find out few one, two, maximum three things that you would measure and these are related to value either number of users that you want to attract or cost saving, for instance, or whatever else you produce, but something that is easy to be measured and very bold and linked to any of your initiatives. That's quite important. And finally these stories are very important because during first couple of weeks maybe of your engagement with new customer they will ask you questions okay, however companies are doing it, what are the successes from our industries? But very often they will ask you for examples for real cases from the organisation you're coaching. So if you have these cases, if you have first successes and by success I mean any kind of learning, even if it was a failure. Business wife, we learned, okay, Scrum will not work in that company. They prefer Kanban. And that's why and we wrote a one slide, one pager, one pager on that.

‍

[00:58:54.780] - Speaker 1

And that really helps, I remember, but these were good pre pandemic times. After few first training sessions on Scrum and basics of Agile, we introduced what we called field trips. So it was one day or two days long class in one room at some point of time. Day two, I remember it was pretty, pretty late in the afternoon, free, maybe 04:00, we took the entire training group for a walk to our I mentioned at the beginning to the section where all Agile teams sat, and we showed them during the training, we were talking about the product backlog. Here we go. That's how Team A is doing it, that's how Team B is doing, and that's what Team C invented. Actually. We're using Kanban board for having and managing the product backlog. And it was real, using their language, their specific context, very powerful. And I think it did the majority of job promoting Agile in the organisation and eventually helping us succeed. Anything else that you can recall, Tony?

‍

[01:00:03.470] - Speaker 2

I was just about to say we're reaching the end of our time box, so I didn't want to interrupt you. And what I've done is I've addressed a question raised by Jeff around MPs in the chat window or the Q and A window. So if anyone else is interested in Net Promoter Score, there's another approach in there that I've offered that helps with the question of my MPs is going down, what do I do? Because some measures, they'll tell you that things aren't right, but they won't tell you what to do next. And that's one thing to watch for with measuring success, is having a measure that is actionable as well.

‍

[01:00:38.350] - Speaker 1

All right, speaking of time, the time box expired. Indeed, but I think we shouldn't have any problem. Tony is staying here a little bit more if there are any questions. So if there are any questions, please go to Q and A mode and write them down. Tune and I will be happy to give you the answer. If we can answer the questions while you are typing, I hope we have a tiny surprise for you. Tony already mentioned impact mapping. Impact mapping is a technique not as popular as I thought, but used in Azure product management, helping us link business goals with user outcomes, customer outcomes and eventually items of the product backlog. But from time to time, Tony or I, we like to use these techniques in a bit different contexts. And for instance, Tony, you brought up the impact mapping technique used actually for creation of the plan, for the inter-transformation of that department hypothesis driven plan. We thought it might be a good idea if we had an over Agile encounter devoted actually to that topic. So already right now we'd like to invite you for the third Agile Encounter impact mapping in Practise.

‍

[01:02:05.200] - Speaker 1

Again, Tony and me, less discussion, less conversation, more perhaps practical examples. A disclaimer. We will not give you the full training on impact mapping itself. That would be perhaps the entire day. But for those who are familiar with the technique, you will find out how else we are using it in context of Agile transformation. For those who never use it, perhaps we will have a sort of primer at being to help you look at it. If you are interested in joining, don't hesitate to register. You can scan the QR code that is available over here, as well as click on a link that you should see. Right now, on top of this webinar window, I'm taking a look at the Q and A section. I can't see any new questions.

‍

[01:02:58.490] - Speaker 2

It's just a question around whether this recording is going to be shared.

‍

[01:03:04.930] - Speaker 1

Yes, it will be shared. Please take a look at us on LinkedIn, also on Agile Encounters YouTube channel. It will be published next to the previous one. If you can't find it, don't hesitate to write to us, any of us. We will give you the link. I can't promise it will be available instantly. I can assure you it won't, but quite soon. Yes, all right. I can't see any other questions, so I think we are good. Tony, thank you for the conversation. To all of you, thank you for joining us, listening to us. I hope it was valuable. The first Agile Encounter was just Tony and me talking today. A little bit more interactive and it's alive. Next time perhaps we'll take another step and make it even more involving, given both Tony and I are professional trainers and we like interaction with public. But that's on March the 8th. Thank you very much. Take care.

‍

[01:04:05.450] - Speaker 2

Thanks Pavel, speak to you soon.

‍