About this podcast episode

Agile change is not something you can deploy in your organization. Setting goals, building relationships, and collaborating are critical to agile transformations.

In today’s podcast, Michal Idzikowski shares how you can successfully introduce agile change into your organization.

Michal and Bill share stories and examples that will help you learn:

✅ What is an agile organization

✅ What effective agile organizational change looks like

✅ Competencies versus roles

✅ Reducing complexity

✅ Mistakes to avoid

✅ Using a Scrum Studio for greenfield agile adoption

✅ Working with agile supporters and detractors

Transcript

(transcripts are auto-generated, so please excuse the brevity)

Michal Idzikowski: Please, don’t think about agile change, don’t think about agile that’s something that can be deployed in your organization.

Bill Raymond: Hi and welcome to the podcast. Today, I’m joined by Michal Idzikowski, agile coach at Huge Games and leader of the SCRUM Master team. Hi Michal. How are you today?

Michal Idzikowski: Hi, Bill. I’m very fine. I’m very excited for the moments to come for our conversation, and I hope that you are fine too.

Effective but not glamorous, agile change

Bill Raymond: I am excited for it. We’re going to be talking about effective, but not glamorous, agile change, and I think that’s actually a really good title. Sometimes, we take a look at how we’re going to change our organization and we see something like a framework that looks really good or terminology that sounds exciting, but really, what we’re doing is we’re going through a change to help improve our organization. And it can sometimes be a little bit more mundane than the fancy websites and videos that you might watch, so I’m excited about this conversation as well.

About Michal

Bill Raymond: Can you share a little bit about yourself?

Michal Idzikowski: Yes, sure. So I have supported the adoption of agile and SCRUM for 7 years now. For those years I’ve been working on the individual level, on a team level, and on organizational level.

In the meantime, I just found out one very important thing for me, a game changer for me. I found my personal mission, which is to make people grow, and it had a massive impact on the direction of my self-development and how I approach the next agile transformations. And it allowed me to be here with you and share my experience from the last years.

Bill Raymond: Great. Thank you. And I guess, I know that you work at Huge Games, so I’d love to know what they do and what you do there. However, I also know that you are not speaking on behalf of Huge Games, right? You’re just only sharing your experience.

Michal Idzikowski: Yes, exactly. So I’m just like sharing broader experience and not definitely connected with Huge. Some examples will be from Huge, but I will not say about that directly.

So what I’m doing at Huge Games is in the role of a agile coach, I’m working with two departments and working with all levels of organization, trying to find the best ways to increase the effectiveness of the departments. And as a leader of SCRUM Masters team, I’m building the team itself and working with aligning the SCRUM masters, working with them to develop them as professionals. So those are my main duties currently in Huge Games.

What do you mean by an agile organisation?

Bill Raymond: Thank you. And I guess it would be interesting to understand from your perspective, I always love to ask this question because everyone always has a slightly different perspective on things, because I don’t think agile means one thing necessarily. And at a high level we can say it is helping you improve performance or release something better, faster. But we have all these different opinions and definitions, so I’d love to hear from you what you mean by an agile organisation.

Michal Idzikowski: So in the first place, it is an organization which is focused on outcome, not the output. Meaning that we are focusing on delivering value continuously, iteration by iteration. Afterwards, it enables us to have a conversation with the stakeholders, after each iteration getting their feedback, and adapting our further steps. In addition to that, an agile organization has empowered product owners, and by empowerment I mean that they are decisive at the areas of the product.

Michal Idzikowski: So they don’t have to ask plenty of people around, okay, can I do this? Can I do that? They are just collaborating again with the stakeholders, organizing the backlog and making decisions.

Michal Idzikowski: Afterwards, we are measuring everything. So an agile organization measures everything, and is basing the decisions on the metrics, not on wishful thinkings or some assumptions and so on.

Bill Raymond: And you’re specifically talking about the value that you’re delivering?

The value or just it can be also the monetary or non-monetary value. So we can directly impact how much the company earns right after the releasing of the new increment, a new functionality. Or we can have a non-monetary value, which means that the work of our last sprint allowed us to spread our marketshare. It’s not directly generating, let’s say income, but it makes our market bigger.

What does effective agile change look like?

Bill Raymond: Right. Those are great examples. Now, we are going to be talking about agile change, and we’re going to get more into this as we converse. But at a high level, what does effective agile change look like to you?

Michal Idzikowski: Yeah, so in the first place, like I said, switching the mindset into being busy to delivering actual value, and this is the biggest change. In addition, the effectiveness impacts the technical constraints.

Michal Idzikowski: So I, from my experience, I have witnessed many times when the teams were working in a sprint, I don’t know, but usual those are two week long sprints, it’s because it’s just in the middle, right? So it’s not one week, too short, one month, too long. Okay, so let’s make it to the middle. But the technical abilities of the organization were not able to cover the, so let’s say, regular releases. So we had two week long sprint, but we were able to do a release once per month, which wasn’t supporting, let’s say the broad agility.

Michal Idzikowski: So after the effective agile change takes place, we have removed the technical constraints, meaning that the teams are able to release any time they need, not any time they can. Additional think about effectiveness is that the transparency is kept.

Michal Idzikowski: Now we should have one product, we have one backlog, one explicit backlog when everyone can reach out and look what is the future of the product he’s interested in. So we don’t have distributed backlogs.

I can provide you an example. When I found out that we had an product backlog in one tool, and it came out that technical backlog was in another tool. And those backlogs were not connected. So the product owner was taking care of the business part of developing product, and the development manager was taking part of the technical part of the product. So that was that, that made me, okay guys, let’s do it, let’s have one backlog because you know, it’s still one product and those two things are impacting this product. So maybe let’s make it transparent in a way that, okay, that we know where to balance the work which is needed to be done from the product side.

Michal Idzikowski: And don’t forget about the technical side. Additional, think about the effective that people actually follow the new structure.

Michal Idzikowski: And the new structure is not let’s say, collapsing after the first, let’s say, failure. Because failure happens. So you know, the change actually sticks.

Commitment-Based Management

Michal Idzikowski: And another example, when we were working on the agile change, so introducing SCRUM, all of the elements of the framework. So you know, we had people who were just like waiting for any failure, just to introduce another thing. I don’t know if you heard about the Commitment-Based Management.

Bill Raymond: No, please go ahead.

Michal Idzikowski: . Okay, so after the couple small failures, there was a decision that we need to use an additional SCRUM, we need to use a commitment-based management. In very short words, it’s a kind of a approach that builds endless chains of customers and performers. And the organization was decided, okay, who is the performer? Who is the customer?

Michal Idzikowski: And we had to create those chains, okay, that the product owner is a performer for let’s say, product management. And then team leader is a performer for a product owner, and the whole team is performer for a team leader.

And those were the chains. But it cost a lot of money, and sticked for I think, half a year. But fortunately, this whole initiative died because it was not working, but because as far as I remember, it’s like a way of working from the 80s or something like this. So I do not recommend that.

Bill Raymond: I hear you. There’s so many different ways that you can kind of lay out these charts that say, you know, here’s the person that’s accountable, here’s the person that is responsible. What is accountable and responsible? What’s the difference between those? I don’t know.

Bill Raymond: But then the other thing is then there’s other terms such as being the delivery person. Those are easier, but I think when you start just trying to like, these letters to each person that says, you’re accountable for this, you’re responsible for that, what you’re getting at here is that the team is focused on working with the customer to deliver more value. And you’re trying to take away some of those layers of, who does what, when?

Michal Idzikowski: Yeah, exactly. By the end, this causes the organization to create a massive sharati matrix.

Michal Idzikowski: And the negative side of it afterwards, is that people, if they want to, they can stick directly to this matrix and not going outside those responsibilities or accountabilities which are in there, and it doesn’t push us forward.

Competencies, not roles

Michal Idzikowski: What brings another idea about the effective organization, and it’s from my perspective, it’s also very important that effective organizations and after, in the agile transformations are just like focused more on the competencies, not the roles.

Michal Idzikowski: So for example, if we have product owners who have, let’s say, some problem about communication, sometimes they’re cannibalizing their ideas or their metrics and so on.

Michal Idzikowski: So, the effective organization will just, okay, get those guys, okay, talk with them, let’s work it out. Maybe that we are missing some kind of competencies and the organization will deliver those competencies.

Michal Idzikowski: The organization, which is for example, like more working in a usual way, okay, so we have a problem with program management, right? No? Okay, so we will hire program manager. So then, x problem, x person appears like the pattern and it’s multiplicating some kind of responsibilities. And then after a half a year, we are finding ourselves in a organization which has 20 roles responsible for actually value delivery. And we are struggling just to align all those guys instead of focusing on actual delivery.

Reducing the complexity

What I’m hearing from you is that we really need to think about how much layers of management that we need in there in order to suport agile teams doing their work directly with the customer. And if we start adding too many layers of management structure, then we can slow everything down.

Michal Idzikowski: Yeah, exactly. We are just like increasing the complexity of environment instead of simplifying it.

What we need to do to start shifting to agile?

I like that, “ reducing the complexity”.

Effective but not glamorous

Bill Raymond: So that kind of gets us into this concept of effective but not glamorous agile. Let’s talk a little bit about what we need to do to start shifting to agile.

Bill Raymond: Let’s just go ahead and make the assumption that either we’re starting our journey on agile or we’re thinking about it. What are some places that you would start to start thinking about how you’re going to introduce agility into your organisation?

What you shouldn’t do

I would start with a little bit different thing. I would start with a thing which you should not do to introduce agility into your organization.

Michal Idzikowski: You already mentioned it at the very beginning, that there are some frameworks, some methods which look okay. It’s looking very good, I want it. So please, don’t think about agile change, don’t think about agile that’s something that can be deployed in your organization. I think that should be the most important thing from our conversation. It’s not something that you take, and so you have, let’s say, an organization which is ineffective and you want to change it and you take some model, for example, you deploy it and now, ta-da, you’re agile.

The case of Spotify model

Michal Idzikowski: Nope, sorry, it doesn’t work like that. It’s like the case of the infamous Spotify, called by some people, model. It has never been a model. It has been a way of working, which was empirically reached by the Spotify, and they have created it for themselves. But the market just showed, okay, it works beautiful,I want just guilds, I want chapter leads, I want chapters, I want tribes, because it’s beautiful and they say, and that it works like a charm. But surprisingly, it was not working like a charm when you take this, let’s say, ways of working and try to deploy it in a bank. That’s the first thing. Do not think about the agile as something which is, let’s say, the set of structures which will suddenly make you effective. Instead step one, take a closer look at your organization, reflect the whole system of your organization. See what are the relations between people, between the backlogs, the products, and other let’s say, competencies, which we have.

Michal Idzikowski: You can, for example, usethe casual loop diagrams to reflect your system. Afterwards, think of a goal you want to reach, okay? In this moment, the agility should not be the goal because the agility is just a way to achieve something else. So what is the goal you want to achieve? Where do you want to take the organization?

Michal Idzikowski: Okay. Should it be more adaptive to the market, or maybe you just want to reduce the lead time, or maybe there are other things you just want to introduce and then focus on that goal.

Michal Idzikowski: When we know that goal, own it and by own it, I mean that the C-level, C-Suite should own the goal. It is not something that, okay, the agile change, I can support it, but you know, just don’t make me appear on those meetings and so on.

Michal Idzikowski: No, sorry. If we are thinking seriously about the agile transformation and effective agile transformation, the C-Suite has to own the goal of the transformation. What is the end goal, and over-communicate it. This is the direction we want to go.

Michal Idzikowski: Afterwards, we have these goals, it’s just like, again going back to the diagram, which is reflecting our organization and check where are the connections. How big this change is going to be? How big the impact on the whole organization is going to be just to fulfill this goal?

I’m wondering, you said that the C-suite needs to be bought in on this. Is this something that you should do organizationally, or is this something that you might do by department?

Bill Raymond: For example, I know that agility is, if not adopted almost everywhere in IT and software development, it’s getting there very quickly. But I suppose you could have some goals that you’d set up that help move forward in any department in your organization. Yeah, you can start a department, but you want to reach, let’s say, the organizational agility with only one department. So again,depending on your goals, you can start introducing the change in two ways. Basing on the goal, basing on the interviews, observations you’re making it in the organization. You can be lucky or unlucky.

Michal Idzikowski: In case of being lucky, you have found yourself in an organization which is full of people willing to change. You have people who know what agility is, and they’re just, like waiting for a signal to start the change. In this case, you just, you can find that the department and start with one department top down, changing the way it works, and then finding the connection points with other departments.

Michal Idzikowski: And then,going, spreading their change, you know, let’s say step by step by step, you know, just like to introduce, you know, this change evolutionary.

Michal Idzikowski: And by the end, you are just finishing with the agile transformation, which is exactly as you need it, leaving the parts of the organization, which just don’t need to be changed because the way they work, it makes them effectiveness and it’s not, you know, it’s not a problem for the whole value delivery.

Michal Idzikowski: Or the option two, you can be unlucky and you can find yourself in an organization which is very much sticking to the old ways of working. You have multiple PMOs. You have a steering committee, which is in the middle of any conversation taking place with the customers, all the stakeholders. So in that case, you need to approach it in a little bit different way.

Michal Idzikowski: You can approach it using something which we call, a SCRUM Studio. So you are starting a new organization within the organization. And you’re just like pulling into the new organization the new people you hire, or maybe you were able to find the people who were willing to change, but they were not able to do it because of the rigid organizational structures. So you are just pulling all of those people and you’re just like, for example, making a CEO or a CTO, a direct manager of this SCRUM studio. And this is the small SCRUM studio’s focused on value delivery in a new way, which is independent of the old structures. And then continuously by working, you’re just like expanding and taking new parts of the product and pulling it into this SCRUM studio. And then it’s like replacing the old structure by the end.

SCRUM Studio

Bill Raymond: Can you trail down into what you mean by SCRUM studio a little bit more? This might be a term that folks on this podcast may not have heard before. I don’t think we’ve actually used that term. But we have of course, used SCRUM quite a bit, so we are recording this in the Fall / Winter months of 2022 2023, and wehave an entire series of SCRUM that you can look up on the podcast. If you’re listening to this, you’ll see a number of series, what we call Seasons of SCRUM. And so if you want to learn more about that, you can listen to some of those other podcasts. We have some amazing people that are talking about that.

Bill Raymond: But I think it would be great if you could just kind of define what you mean by SCRUM Studios so we’re all on the same page.

Michal Idzikowski: Yeah, so a SCRUM Studio is, as I said, a totally different organization within the organization. It’s being built basic on the new ways of working.

Michal Idzikowski: So if we want to use SCRUM, so that’s why it’s a SCRUM studio, we are building SCRUM teams, as it is stated in the framework, without the tweaks which are already happening or had happened in the old part of organization. So we are creating a pure SCRUM structure, focused on a product, focused on the value delivery, and which has, let’s say, a clean sheet in regards of the management, in regards of the HR, in regards of any other thing. So we are just like pulling new people into that and we are just like creating this fully independent part of organization.

Michal Idzikowski: So let’s say there can be no negative impact of the old structures on the SCRUM studio.

Bill Raymond: So we’re basically saying, go out and be free. Do the thing that you think is best to do your work, and we’re only going to hold you accountable to things that you just must do in the organization. Maybe it’s around legal, abilities to deliver something, you know, in certain countries or what have you.

Bill Raymond: Butyou’re not saying, you must use these systems, you must use these processes. What they’re saying is, start from a clean slate. Is that what you’re saying?

Michal Idzikowski: Yeah, the greenfield.

Bill Raymond: The greenfield. That’s a great word. So that’s a very good idea. And you’re not saying that this is some group that’s up on high reporting into the C-suite. What you’re just saying is, this is how you can start practicing it using people that are willing and able to practice it. Is that what you’re saying?

Michal Idzikowski: Yeah. It’s about finding the right people, people who are willing to work, not being pushed to do it,

More education needed

I can give you an example from one of the organizations, because that was a moment when the CEO was replaced and the new CEO said, okay, I believe in agile. I want to do everything agile way.

Michal Idzikowski: So we as the SCRUM masters, we were just like, yes, this is what we are waiting for. And he just changed the slide and we saw that agility means that we are doing the full scope in a budget within time. Oh my god. So we just saw the iron triangle of the project management connected as, or described as agility And that’s why when you want to introduce agile in some environments, you have to spend a lot of time for explaining and teaching.

Bill Raymond: Yeah, it makes sense I’m a project manager by trade, right? I got a PMI certification, I got a number of different awards around that, and I’ve talked about project management, implemented project management everywhere. So I do not want anyone listening to this podcast to think that project management isn’t important and does not have its place at the workplace. Absolutely does.

But when we are talking about agility specifically, we are not talking about a scoped piece of work that will be done in a time period that will be completed and finished.

Bill Raymond: The idea is that we are taking a journey and we’re marching along, trying to meet some objectives along the way, and we’re just trying to deliver those more quickly. And as we’re meeting those objectives, we might find out that, Hey, you know what? Our product has more use in another category of business, so we can switch gears very quickly.

Bill Raymond: And we’re not tied to some sort of a scope statement that was built six months ago. We’re talking about being able to constantly change and pivot and continue to deliver value, and I think that’s one of the biggest differences here. And yeah, you’re still fighting for budget sometimes, but what you’re doing is fighting for the budget because you have a assumption that the value you will bring will be equal to or better than the budget that you brought into the effort.

Bill Raymond: And I think that’s a very big difference there. And we’re also trying to remove process as much as possible. So I can for sure see why we still need project for project management for some efforts, because having that Gantt chart, that’s that tool that shows you everything that needs to be done by whom and by when. Those types of projects will always exist, I believe.

Bill Raymond: However, what we’re talking about is more about continuous improvement of a product until that product is no longer with us because we want to replace it or what have you.

Bill Raymond: And I love this process that you talked about at the beginning when I asked you how to do effective change. One of the things that you brought up right away was this, looking at the existing processes and how things integrate. You used the example of there being multiple backlogs, sort of, if you will, a business backlog and a technical backlog. And if these things are all separated and someone’s gate keeping these, then you really don’t understand the objective that you’re trying to achieve if you’re on the team.

Bill Raymond: And one of the things that really was interesting for me, was that when I started working on these agile change projects, when we start thinking we have to think about, you know, what are the roles? You know, do we need to change that? But we always started that way with the process.

Bill Raymond: And we spent a lot of time mapping out all the processes that we have, with the intent. And unfortunately, a lot of people spend a lot of time on this, to get everything charted out and mapped out. Sometimes there are bigdiagramsof what we do, and then we start chopping away at them. You know, see, can we cut this step out? What happens if we cut this step out? What happens if we combine all these things into one ceremony, and all that stuff, right? All these meetings.

Bill Raymond: And you start to see that sometimes, you have a lot of process and system flows that are almost getting in the way of doing the work, but you’re just so used to doing them, it’s just normal for you. So to map it out and then take a pair of scissors to start cutting away at it, at first it feels like, oh, you’re destroying my work. But actually it’s a good process to go through and it helps you get into that mindset of, okay, what else can we do to improve how we deliver?

That’s a pure power of visualization. So then you see that, that’s all of the processes. You are thinking about it, but sometimes you are not able to find a connection inside your head, but suddenly putting it on the whiteboard, now you see it clearly.

Let’s choose an organization and company and let’s choose something we’re all familiar with, which is the IT organization, right? Because I think there’s a lot of change going on in IT right now.

I see software development, agility sort of starting to show up in larger organizations in IT But it’s still kind of, if you will,in pockets in many places. I think IT was going through a big transformation to the cloud. And then of course, we had the pandemic hit and we had a lot of changes that needed to be made on the fly.

Bill Raymond: And now we’re getting to a point where IT organizations are starting to really think about this more holistically. What does agility mean to us? So if we are just, let’s say for example, a CIO, what are some of the things that you might do to start adopting agile? Because you have customers, you know, these people that are going to start working in this sort of agile mode of working, still have to work with customers that may not be agile. So how might a CIO think about that in terms of implementing agility?

In the first place, it’s about informing people what is our goal. Why we are doing this? Because of course, if we are working with the customers, it will impact them somehow. But it’s about sharing, okay? This is something which allows us better fulfill your needs. So over communicating the goal, saying, okay, everything’s going to be fine, don’t worry. It’s just like new ways of working, but you’ll be happy about it. Checking the customers are also happy.

Supporters and Detractors

Bill Raymond: There’s going to be people that say, Yes, bring this on, we are looking to move more quickly. But then there are others that might be detractors. And they may not be detractors simply because they don’t like the term ‘agile.’ They might have more process in place for very good reason, and that could slow down the perception, or at least be perceived as being slowed down the team that are doing the work. So how do you balance those supporters and detractors when you’re implementing a new concept here, like agility?

Michal Idzikowski: Yeah. Again, it’s about the goal, about why we are doing this and transparently communicating that, okay, is our progress in, let’s say,introducing change. And constantly informing people, okay, are they going to be a part of this change right now or maybe later, or maybe never?Because it’s fine what they are doing, like you said about the project management. Let’s say, one department can be focused on purely delivering projects. They certainly they do not need to be changed and their ways of working, they don’t need to be changed. Because there is another, let’s say, false belief that when we want to stick to the projects, but when we introduce agile practices, the team suddenly will start working faster. Which is not true because then additional, let’s say, events or the things that the agile teams are doing, they would just take their time.

So we can leave some parts of the organization working still classical project management way. Okay? Peaceful. So now we are just like, okay, now we just do not have detractors from that department.

Michal Idzikowski: So they are just like phew, okay, now we are safe, so we can, we can do focus on our work. And in supporters, and yet we need to deliver them as much information as much support as we can.

Michal Idzikowski: So we have to, the CIO has to be, let’s say, has to have the open door policy. Okay. If something is going on, I’m the one who owns actually, the goal of the full transformation. So if you have any problems, please reach out to me. Say it out loud. So you know, it’s again, starting the full collaboration.

Bill Raymond: Yeah, that’s really important. And I think what you’re getting down to there is that,and I think we’ve mentioned this in the podcast a few times, when we talk about agile, sometimes we talk about enabling teams to deliver more value more quickly, but there is such a thing as a C-Suite that is a team as well.

Bill Raymond: And that CIO is hopefully putting those goals together, not only to help improve the team, but also improve upon how the IT organization works as a whole.

Michal Idzikowski: Yes, definitely. Hopefully.

Bill Raymond: And that CIO has team members, and they include any number of their customers as well.

Michal Idzikowski: Yep.

Key learnings

Bill Raymond: So as we’re wrapping up, I’d love to hear some of your thoughts on some key learnings that you can share. So if someone wants to start on this journey, what are some of the things that are super important to get right if you want to start implementing agility in your organization?

Michal Idzikowski: So the most important thing is to start with building trust with people. They have to know that you are there as an agile coach, SCRUM master, or any other person who is a change agent.

Michal Idzikowski: They have to know that they can trust you, that you don’t have a hidden agenda, that you are here just to build up your career on eliminating theirs, but you are just here, just to increase the effectiveness on the organization.

Michal Idzikowski: Find out what is stopping them for example, for being more effective, and then openly have a conversation and build up relations, let’s say from the bottom. And it’s just like creating the soil for the change, which is coming from the top. The people will be prepared for the change and they will know that it is not to eliminate them, but for example, to make their life a bit easier.

Michal Idzikowski: So for example, I was working with one team, which was responsible for building a release process. So there were some people who were just like a bit closed for a change. Because okay, if we automate everything then what will we do in this organization? There will be no work for us.

Michal Idzikowski: And that was also a work with their manager, just, okay, so what’s your idea for that team afterwards they will automate everything. And the manager joined the team on one of the meetings and he shared that list of interesting things they can do, instead of manually clicking and pushing through the release process.

Michal Idzikowski: And that was also a game changer because they know, okay, our job is safe.

Bill Raymond: That’s actually a really good one right there, I have to say, because you know, very often when we start to become responsible for that one important thing that happens on a regular basis, you end up becoming the go-to person for that. And you get worried sometimes, if they’re going to automate a system and they don’t need you for that, does that mean they don’t need you? And very often, that thing that you’re doing every single month or week or whatever it is, or day, and that you’re super important for, probably isn’t adding a whole lot of value and should be automated, right? Because that gives you the freedom, the ability to start doing some more strategic work.

Bill Raymond: At some point, it might feel strategic that you’re doing those things, but maybethe strategy is in doing new things instead of sticking with doing things the old way.

Michal Idzikowski: Yeah, again, going back to the topic of the competencies, we want to build up competencies of our people, right?

Michal Idzikowski: And just like doing some repetitive tasks, manual tasks like standing next to an assembly line. I don’t know if standing next to an assembly line is a creative work, I’m not sure about that.

I was just thinking about this project we were implementing a financial system for a very large organization. And one of the things that we’re concerned about was all this automation of the invoicing and purchase orders and things like that, people were worried that anyone in the organization can create these, and I’m the one that creates them, so therefore, I’m going to be out of a job. If everyone else can kind of create their own purchase orders, then what do I do? And the answer was, well, now we want you to start focusing on the rules around those purchase orders to make sure that people aren’t overspending, and start thinking about how you do contract negotiations.

Bill Raymond: And you know, what we ended up with, was a team that felt more empowered to help drive company’s financial objectives. And they feel more empowered now. And I think that’s a big part of this, is that if you can trust that the objective here is to improve how you do work, the objective isn’t trying to remove you, then you can start thinking about all the things that you do every day and the things that maybe are very not cost effective. That’s actually putting agile into work right there. You’re thinking about how to remove roadblocks so that you can deliver faster.

Michal Idzikowski: Yeah. And then additional thing would be just to spread the news, okay, there will be a job security in our company through the change, but necessarily the role security.

Bill Raymond: Yeah, that’s I think a really good point right there, the role security. Because yes, if you do this right, then there’s probably a good chance that you’re going to have a different organizational structure at the end, and your title might change. And also you might have a different competency that’s required of you. So it is a little bit scary, but I appreciate what you’re saying is, if you start with trust and you start by thinking about how you’re going to embrace this, then you’re going to be more successful at the end.

Bill Raymond: So I guess, are there any like really hot button issues, anything that you suggest that you should look out for while you’re going through this agile change?

The whole thing would be just check the structure, how many directions of movement you have. Because I have another example, when I was working as a SCRUM master and I just wanted to remove an impediment which was on their way to work more effectively,I needed to prepare a presentation which presented the problem and the solution which comes from the team.

Michal Idzikowski: And I had to go through the whole structure of the department, like step by step, manager and then director and then head of and so on. But the problem was that I was stopped at one certain level and I was informed that I cannot go any higher. Because, no, the SCRUM masters are not allowed to go that high.

Michal Idzikowski: So you have to send me the presentation and I, as a director, I said, no, I have to go evenhigher. So that would be the thing. Check the environment you are working with and if you identify any blockers, start working with the blockers. Why I cannot go any higher?What is stopping us?

Michal Idzikowski: Or, you know, just useI like those sentences very much, they are from Geoff Watts, SCRUM_ Mastery_, “the good SCRUM master asks for permission, a great SCRUM master asks for forgiveness”.

That’s a good one, I like that. And actually, I think that’s a good way to wrap up our conversation.

Bill Raymond: Michal Idzikowski, I really appreciate your time today, is there some way people can reach out to you if they want to further this conversation?

Michal Idzikowski: Yes. I’m just like sincerely, if I think anyone who would like to reach out to me please use LinkedIn.

We will of course provide that LinkedIn link on the podcast app that you’re listening to right now or on the agileinaction.com website.

Bill Raymond: And also, we’ll include the Medium article and including your Medium profile, which is where we found you, so that you could read the article that you wrote, which is_ Effective, Not Glamorous Agile Change, How to Use People’s Relationships and Overcome Resistance._

Bill Raymond: Thank you so much for your time today.

Michal Idzikowski: Thank you very much for having me.