A Better Way to Transform Your Business

[00:00:01.290] - Pawel Felinski

Hi. Welcome to Agile Encounters. My name is Pawel Felinski and today I'm going to talk about a better way to transform your business. What we're going to cover, what you're going to learn during this webinar, is first of all, what is a transformation? What kind of organisation transformation do we deal with?

‍

[00:00:19.830] - Pawel Felinski

There are a lot of buzzwords over here and I'd like to tell a few words about it. Secondly, what are the types of change? And by change I mean organisational change over here. And finally, what are the two tracks of transformation and which one is typically forgotten? Why is it so important and what to do with that?

‍

[00:00:40.000] - Pawel Felinski

If you're interested, stay with me for the next couple of minutes. Let's start with the word transformation. Personally, I really enjoy academic discussions. I mean, it lot of good energy, lot of great conversations. However, every niche academic discussion I've been to is so not practical.

‍

[00:01:04.320] - Pawel Felinski

So if you have your Agile Code, Scrum, Master, Agile Consultant, whoever nearby, try to start the discussion. Should we say an Agile transformation? Or rather, Agile adoption. Or maybe it's transition. I'm going to tell you why is it important and what the difference is over here.

‍

[00:01:25.050] - Pawel Felinski

So many practitioners say that we shouldn't name Agile Transformation v Transformation. The reason for that is that we are not transforming organisation from a simple state A to State B. Actually, with Agile, what we want to achieve is to enable the organisation to redesign itself as it's needed in the future. So there's no end of the transformation. That's what they say.

‍

[00:01:54.230] - Pawel Felinski

Very often you will hear that it's way better to say adoption, scrum adoption, Kanban adoption, Agile adoption. So taking all these frameworks and adopting them within the circumstances of your organisation, your team or your product, sometimes you will hear a transition as a word that we just move from one step to another step. But this is never ending. Ending journey. Why don't like it?

‍

[00:02:20.420] - Pawel Felinski

Why don't like this kind of conversation? It's absolutely correct, but not helpful. I saw a lot of consultants spending a lot of time discussing this topic with their employees or employers or with customers, and it doesn't bring anything to the field, in my opinion. In fact, what I find the most important problem among managers, consultants and everybody who deals with Agile transformations or any other organisational transformations, is ignoring the reality. And the reality is your customers transform their business.

‍

[00:03:00.160] - Pawel Felinski

That's the language they use and I don't see any reason why not to use it. In fact, in many cases, no matter if your customer or your employer is a big corporation or small company, transformation is typically a project, a longer product versus current state. And we want to be in State B, and why shouldn't we support our customers in achieving it? Of course, State B desired state is to become such an organisation that is able to redefine itself if needed, later in the future, but we will achieve it when we transform ourselves from where we are right now to the next level. Therefore, in the interest of this presentation, I will not debate whether it's adoption, transition or any other word.

‍

[00:03:50.640] - Pawel Felinski

I will simply use the transformation because that's the standard I hear among my customers. Now, whenever we talk about transformation, we technically talk about a change, organisational change. Years ago I attended a lecture by Esther Derby at one of conferences, Agile conferences in the USA and I was really, really happy to hear her talking about different types of change, organisational change, and how language that we use as consultants, as change agents, no matter external, internal to the company, how much it matters. And what I pick up from it is what you can see on the picture over here. There are couple of types of change, organisational change.

‍

[00:04:40.810] - Pawel Felinski

One type is simply a simple change. On the picture you see some boxes because it is as if you were moving boxes from one site to another site. What is important about this kind of change, a simple change, is that you exactly know it's very transparent. What is the starting point, where are you at the beginning? The boxes are here and you know exactly what you want to achieve.

‍

[00:05:05.500] - Pawel Felinski

You want the boxes to be here and you know what's the path, it's very simple. Now we have you a few examples of such changes in organisations. Imagine moving your employees, moving your team from one floor to another. We are in open space on floor number two and there is a better space for us on floor number three. Some employees, some team members who used to see it in front of a window.

‍

[00:05:34.480] - Pawel Felinski

Now on another floor they will have their desk closer to toilet with no nice landscape. It is a change and actually it does impact their performance, their mood at least. So although simple change is not what we will discuss over here, they exist and there are many examples of that in our organisation. Such a change could be managed is not so not so difficult. That is a simple change.

‍

[00:06:00.900] - Pawel Felinski

A very interesting type of change is a change that has the name a dynamic one. Imagine you are its wintertime, you went to Aria with mountains and you want to ski. You are at the peak of a Mountain and you more or less know your destination. You want to go down there. There are many paths you can take in order to reach the destination.

‍

[00:06:24.050] - Pawel Felinski

You can do what I typically do. So straight line down there very fast or you can maybe take a longer walk, turning left and right as you wish. There are many paths. However, what is very similar to the previous type of change, you know exactly what your starting point is and you know exactly where you want to be at the end. Such changes also happen in the organisations before I comment on it all, there's one more type of change.

‍

[00:06:53.370] - Pawel Felinski

This one is not so common. We call it a complex change. Imagine you are in front of a forest, so you know where you are. That's exactly what you would say in a simpler, dynamic change. But the forest is very high, way taller than you are, and you know more or less your destination.

‍

[00:07:15.230] - Pawel Felinski

You go that direction over there. You don't know exactly where you will end, where you will end up. And only as you go through the forest, you realise what your path would be. It's also not transparent. You can't see it from the top of the mountain.

‍

[00:07:29.770] - Pawel Felinski

It might be that as you go, you find out there's a lake in the middle of the path and you need to turn around. It will take you more time and more steps to take to come back to your path behind the lake. Maybe there will be something dangerous. Maybe we find out that actually you would like to turn a little bit more left. So you have a vision, you have a general destination, not so clear picture of the end state and the path.

‍

[00:07:55.710] - Pawel Felinski

You discover it as you go. Now, digital transformation of organisations, Agile transformation in particular, is in the majority of cases an example of a complex transformation, where we have a destination, more or less, we want to be there and as we go, we learn. And learn is a keyword for us. Over here, it's too simplistic if we treat it as a simple a path to B kind of transformation because there's too many nuances, too many process, too many people, too many topics that are affected. Organisational change typically is a complex change.

‍

[00:08:38.140] - Pawel Felinski

If we talk about transformation, Agile transformation. Now, let's take a look at transformation and what typically you would expect over here. Well, first of all, transformation very often for my customers is a reorganisation. They are using these words, maybe not as equivalents, not really, but transformation at some point of time into your organisation. What does mean exactly?

‍

[00:09:06.660] - Pawel Felinski

Because that's obviously true. Well, first of all, it could be top down, bottom up or inside out. Top down basically means that executive Leadership team assess, we want to go digital, Agile, whatever, and the rest of the organisation needs to implement that flow. I see some positive aspects of top down transformations. One of that is we have sponsorship, we have clear, hopefully vision, clear direction, and everybody is aligned around that.

‍

[00:09:39.510] - Pawel Felinski

Bottom up organisation. Bottom up transformation, slightly different topic, in my opinion, way more difficult. It's where development teams, delivery teams find out, oh, Kanban works, it's cool, or Scrum is very good for us. They start doing something, they see profits, their managers see profits and goes bottom up and the organisation is affected, not necessarily the entire company in these cases. Inside out transformation for me is the best way of doing it, is where internally, typically around the middle management layer in the Krak of our organisation, but internally we see the benefits, we see the need, we have enough competences to start promoting it top down, inside out, in all the other parts.

‍

[00:10:26.470] - Pawel Felinski

But I wouldn't like to go into that topic today and I'd like to focus on key elements that you would see during such organisation. First of all, hopefully transformation starts with definition of value streams and I'm talking about Agile transformation, also digital transformation, because it impacts processes of your company identification of value streams. Who are the customers, what are our products, what are the services and what are the customer segments? And so on and so on is very important because very often what we had in the past in our organisation is the result of years of compromises of work, basically speaking. And if you want to go Agile, it's a very nice moment to think of your value streams, to map them, simplify them, decide on priorities as well.

‍

[00:11:24.890] - Pawel Felinski

Agile transformation means also we are doing some with roles, some roles existing in the company will change. What are we going to do with project managers, for instance? Should they stay, should we redefine the role? Should they do something else? Become scrum masters?

‍

[00:11:41.910] - Pawel Felinski

Hard to say. Some roles appear, for instance the Scrum master who I mentioned a moment ago. In traditional non Agile company we don't have such a role or even position. So redefining roles or defining new ones would be one of the bigger milestones of such organisation. Hopefully somewhere at the end of that journey, not earlier structures, organisational structures are touched.

‍

[00:12:09.860] - Pawel Felinski

Ideally, in my opinion, the structures of the teams should follow value streams. I have value streams, identified products within value streams and teams supporting the products. If you start with changing structures of the teams and only then we're going to think what do we produce, what kind of services we offer, we might be in a very bad place, I saw it a few times in my life, but this is half of the story. And I know companies managing their Agile transformation for a couple of years, three, four, five even. Yes, long, long programme for them and they are focusing mainly on that lack of the transformation.

‍

[00:12:54.770] - Pawel Felinski

What I like to propose present over here is something to some of you may be obvious, to some of you may be something new. It's a second track of transformation that is always there but not always managed, at least not effectively. And that is, in my opinion, way more important because reorganisation and what you're going to do over here, the defining value streams, changing calls and structures that will give you obvious results and very often this is enough. However, if we think about the transformation, Agile transformation as a complex change, there is no obvious end state that we would know upfront. It's very tempting to say when you transform into a organisation.

‍

[00:13:41.210] - Pawel Felinski

This is exactly how your structures would look like. That would be dynamic change or simply a simple change. This is too simplistic view. As we go, we learn and where's the learning when we reorganise or where we only reorganise. So another track of transformation that is always there, but not always we know about it is what we call capability building.

‍

[00:14:05.470] - Pawel Felinski

If we want to build, reorganise, transform our organisation, we need to invest not only new roles, new structures, but also proper capabilities that are needed in the new organisational design after the transformation. Capability building. Well, when I think of it, definitely competences. We need new skills, we need new knowledge. If we are starting using the Camden method and nobody heard about it, let's learn, let's learn what the Campbell method is.

‍

[00:14:35.460] - Pawel Felinski

But it's not only competence, it's also new culture, system of beliefs and values in the company that would support the Agile, Agile organisation and what we want to achieve. Of course, capabilities. Also the tools we use, some tools would be replaced by new ones, some tools won't be used anymore. There will be different approach to using the tools, no matter if we talk about physical ones or digital tools. The thing is that capability building and investing in that area, in my opinion, is one of the major success factors for any transformation.

‍

[00:15:15.530] - Pawel Felinski

Why is it so? For two reasons. First of all, investing in capability is simply investing in a big enabler of reorganisation. If reorganisation is changing or redefining existing roles, we need to build competences in order to help people move from there so far role to a new role. If neurals appear like Agile roles, very often we need to either hire these people as a sort of capability building or grow the roles as a part of our transformation.

‍

[00:15:53.670] - Pawel Felinski

But that's one aspect, that's one aspect only. The capability building answers to the reorganisation needs. But there's one more thing. Very often you would see that transformation understood as reorganisation only is called a great success. It's a matter of two, three, maybe four years, and it's a great success.

‍

[00:16:15.800] - Pawel Felinski

But the success is called based on the obvious results only we change structures. You can see it definitely. Everybody felt it's a big exercise, no matter how big your company is. We have new products, maybe we have new roles, definitely. But this is not the end of the story.

‍

[00:16:36.380] - Pawel Felinski

Very often, a few moments after the success is announced, we realised, company realised we are not Agile. The very big promise of the Agile movement, fast responding to change, higher value offered to our customers, it's not yet there. Why is it so? Because capability building was not mentioned at all during the organisation. So capability building is an enabler also for a long lasting, long lasting transformation.

‍

[00:17:09.380] - Pawel Felinski

We will see the effects of transformation not only when we call it success, but also years later if we build the capabilities in in our organisation. If our, you know, if our people really understand what the new reality is about, they will be able to use it when the transformation is over, when external support coaches or consultants leave your company. And that's something very important. Now, when I say capability building enables long lasting results, what exactly? I mean, what capability building is.

‍

[00:17:49.290] - Pawel Felinski

Very often you would see, okay, one of the enablers are classes. Courses accurate, non accurate. With certification, without certification, maybe instructor led ones online, in the classroom, whatever. Courses are very important. I do agree.

‍

[00:18:07.690] - Pawel Felinski

But the very beginning of your team's journey or your organisation journey, we need to have a common language, that first result that we care about in the new reality. New common language is very important. Secondly, we need some basic understanding of new tools, new methods, new approaches. But courses as such have a really low rate of success. If we just train our people and tell them, you know, your stuff go away.

‍

[00:18:41.140] - Pawel Felinski

What is very often essential is some extra support. I'm going to call it mentoring, maybe coaching, maybe action learning, but simply taking the knowledge that you got during courses and bringing it to the next level, first of all, secondly, implementing, rolling it out in the context of your team, of your product. So if in a class you learned about the Kanban system, cool. Now you need some help, I believe, to roll it out in your team for your process, for your product or service that you manage. Mentoring and coaching have different phases.

‍

[00:19:18.670] - Pawel Felinski

It might be one on one mentoring very typical. If we work with leaders, leaders of the transformation, it'd be one too many. One too many mentoring and coaching. So simply having an Agile coach, flow manager or scrum master supporting your team. But in my opinion, what is even more effective is what I call the on the job training.

‍

[00:19:41.950] - Pawel Felinski

Instead of discussing cases that would be in the classroom or discussing your cases that's mentoring and coaching, we would actually work together. And on the job training, maybe you may use different tools. It can take anything from a few weeks, a few days to many, many months is where you work as you should work in your new role. And somebody who already understands that role works together with you, shows you how to work. All the shadowing or belonging on your relying on your peers would belong to the on the job area as well.

‍

[00:20:26.200] - Pawel Felinski

It's making practical, making what you learned during the two above appearance and what we find at Meirik very effective. Even more effective. What we thought originally, and it was surprise for us, is when you're neural, you're already good enough. Not an expert, but good enough. What helps you grow significantly is to teach others.

‍

[00:20:50.620] - Pawel Felinski

So very often as a part of on the job training, what we ask our trainees to do is to teach others. They become mentors and it's very important internal mentors, not external ones. So people who will stay in your company way longer than external support for the change. When you take a look at the list over here, it looks pretty cool, but one thing is missing and I'm going to put it over here. The proportions.

‍

[00:21:21.050] - Pawel Felinski

I see many, many companies investing in courses, only trying to make it as cheap as possible. So perhaps not instructor led courses, but some online courses, something that you can replay multiple times. That's great, but it shouldn't be the majority of your capability building, actually the minority. What is way more important is mentoring and coaching. What is even more important is on the job training.

‍

[00:21:47.140] - Pawel Felinski

And I would invest a lot of attention, a lot of time and money perhaps into that field of my pyramid over here. Teaching covers very effective, but you can do it nonstop. Therefore, for me, it's a slightly smaller bit, perhaps equivalent in size, to mentoring, coaching and action learning on the chart. Now, where to start, how to do it. I think I would go top down over here.

‍

[00:22:18.930] - Pawel Felinski

We need a common language, some knowledge. Knowledge and basic skills. We need to enable our people to use the knowledge that's mentoring and coaching and action learning. Then on the job training, definitely closer support of a mentor and then less and less support on the job trainer. Finally, when you are able to teach hours, we think you are really good.

‍

[00:22:46.470] - Pawel Felinski

To sum up, we transform organisations to achieve goals. That's very important. We are not transforming just to be transformed via goals over there. Transformation is a complex change. It's very important.

‍

[00:23:02.570] - Pawel Felinski

We use a language that makes it simple, like we are driving change, as if you can drive it very fast from .1 to point B. It's not like that. It's very complex and you never know where you end up. And that's why building capabilities is very important. It enables long lasting results.

‍

[00:23:22.950] - Pawel Felinski

Without that, the moment your external support for transformation leaves your company, you will be back to the point where you start. And that's not what we want to achieve. If you want to know more, don't hesitate to reach out to us. For today, that's all. See you next time. Bye.

‍