Interview: Implementing Agile enterprise with Lande Castberg and Kristoffer Ryeng

Lauri (00:00):

Thank you for taking the time, Kristoffer and Lande, and welcome to DevOps Sauna Podcast.

Kristoffer (00:05):

Thank you.

Lande (00:06):

Thanks. Thanks, Lapa

Lauri (00:07):

We are going to talk about the interesting topic today, which is implementing Agile enterprise. Kristoffer had added a note - a huge change in enterprise architecture. I'm pretty sure we are going to relate to that. I must say that although I am not, myself a practitioner in this, I have tried to practically acquaint myself with the literature around the Agile enterprise or Agile practice - whether it's an Agile enterprise or not -Agile practice and try to apply that in marketing. If I step in and participate in the conversation, then it's useful to remember that my own subject matter is in marketing, and I'm just desperately trying to take the most out of the skills and the practices that I see around me at Eficode.

Lande (00:58):

Absolutely.

Lauri (00:59):

We are going to have a few questions, six seven questions, around this topic, and then it's going to be a heated conversation in those questions. Why don't we just go right into the first one? Why would an enterprise, why would a company, on the whole, want to be agile?

Lande (01:21):

I love this kind of question because for me, it speaks to the whole meaning of the word agile, and what agile in of itself. I don't think, and at least I hope, there's not many organizations that just have a goal to be gile. Being agile in and of itself doesn't actually mean anything, but I'm assuming that there is a specific business goal that they want to attain, in which working in a more agile manner and using those principles will enable to them attain that goal. For me, I'm very keen on ... It's not about an organization wanting to be agile, it's about the methods they want to use to achieve a business goal. What do you think, Kristoffer?

Kristoffer (02:09):

Absolutely. It's in the nature of many companies and individuals as well, to search for stability. They want to be in a stable situation where nothing changes. Within the last decades, stability has become more or less an illusion. Change is coming faster and faster, and it's coming continuously. Now we could say that change is the only stable thing in the world.

Lande (02:48):

Absolutely.

Kristoffer (02:49):

For me, agility is more or less being able to respond to changes. It could be changes in the market or competition or technology or within recruitment or whatever, but agile is a mindset that helps a company or an individual to be able to respond to a change, which would be a counter-change. This response could either exploit an opportunity coming or it could be to mitigate a threat.

Kristoffer (03:31):

I think all companies should embrace this mindset because it makes them able to continuously improve the way of how they're actually working, make them learn continuously, and sort of a place where everything gets better day for day. It's a nice place to work, and that should be a goal for most companies.

Lande (04:06):

Absolutely. You said something there. You kept on using the word change. For me, in a way, you don't necessarily ... It's not just about change, though, is it? If we look into DevOps, we very much talk about development and operations, as an example. It's really more about ... Regardless of whether it's a change an organization wants to do or a more efficient way of working and operating and reaching a business goal, agile is quite relevant.

Kristoffer (04:47):

Absolutely. For me, change is a big word. It has different meanings. I like to substitute often with improvement, because we like to have most changes being improvements. But of course, all external changes won't be improvements necessarily. We could have threats or changes in the market, changes that we are not able to control, but I like to think of even development of how we work or of improvements, they are changes. They are minor changes. Some are externally motivated and some are internally motivated. We are actually wanting to change because we have developed such a culture.

Kristoffer (05:50):

I like to think of agile as a mindset that is embracing that willingness of improvement and wanting to actually learn and taste those changes that we are putting on internally. That will train us to be able to respond to external changes when necessary.

Lande (06:27):

Yep. Absolutely. There's another point as well, in terms of why an enterprise wants to be agile, which is something I've seen at a recent customer site, but I think it's also something potentially is not at the forefront of your mind. Actually, it's recruitment, right? It's recruitment and sustaining people within an organization, in terms of having to keep up with new ways of working, expectations of the kind of profiles that you want to be able to have as part of your organization, and fulfilling that employee need to work in a much more ... How do you say this? A newer environment, a more innovative environment. I think that's also something as well to bear in mind. Not just the business aspect, but also a people perspective. Making your organization more relevant today.

Lauri (07:25):

Tow observations, if I may, just to throw in. You talked about change, and that reminds that there's a lot of talk about this thing that some people call agile transformation, which can be getting more attention than it would need on the long run. But maybe it's because they are coming from a different world or they are going to a different world. And to do that transition, you need to do a transformation. But then there's also this place to be. Once you are in the agile, you apply agile of way of working, then it's no longer a transformation. It's a new place to be. That's observation. Are you coming from old to new, versus are you already in the new, and are you trying to stay there in the best possible way?

Lauri (08:18):

The other comment was ...Half a year ago I was going back and trying to do a little bit agile ... Using agile tools that are available to pull the health of the team. There are all these satisfaction surveys that you can do for employees, but then I found one ... Something that I liked quite a bit, and then I dug in deeper, and it seemed to have come from Spotify. It was part of Spotify's way of doing agile, which was ... It was simply a survey you run your teams to get the health check of the team. It was absolutely nothing in that survey that would have indicated that this is enterprise agile, but knowing it's coming from there could indicate that it has been born off the basis of practicing agile.

Lande (09:16):

I think, Lapa, you've touched upon something that ... Or makes the hackles on the back of my neck stand up a little bit, which is the things that get the label of agile just for the sake of it. What you've described now in terms of this survey that's done, what makes it agile? You're doing the survey to understand the well-being of people and how they feel within an organization.

Lauri (09:46):

Exactly.

Lande (09:46):

I see absolutely no reason why that needs to have an agile label on it. This is something that all organizations should do anyway. And then the other point that you made right at the beginning when you were talking about the agile transformation, and I think what you were alluding to is that we have a current state, and the point that you are transforming to a future state. And the transformation in itself, the agile transformation is the part. It's the bit in between. Even that, no doubt both of you have read the same articles and seen the same clickbait-y titles that I've seen as well. Why are your agile transformations failing? Et cetera. I think it's back to what the first question is. If you're doing agile for the sake of agile, then it will fail. But if there's a specific business goal that you want to achieve, and this way of working will help you reach that goal, then great. But if you're just changing, we're going to implement the Spotify model. Why? There is no rhyme or reason behind it, as opposed to ... Apparently, we're supposed to start working like this now. Then the principles actually have less meaning. You're just actually going through the ceremonies, and going through the steps.

Kristoffer (11:15):

I agree. I see agile transformation as a never-ending process. As I said in the beginning, companies search for stability. They come from a stable world, a traditional world, where stability was actually a thing. I don't think there is such thing as a stable, agile world. You might be better prepared for it, but you will always be in movement when you're going for this mission of being agile. You will never come to a destination because it's no destination. It's a vision far beyond the horizon. You will never actually get there, but you can get closer and closer and closer every day. Companies that are successfully being agile are the companies that are successfully accepting that there is no finite goal in the end. There is no destination. They are actually just going on the road, and the journey itself is the meaning and you have to accept that this is life, sort of.

Lande (12:51):

Yeah. That's the continuous improvement part. It's not a destination. Your initial destination is potentially giving you the ability to be able to continuously improve and adapt, but I would hope that you're not continuously transforming. I don't want to say that because continuously transforming and evolving ... Actually, I prefer that. It's good to see that you should be continuously evolving, but not transforming because transforming is a much larger process. It's a bit softer to be continuously evolving. That's really what you're saying, Kristoffer, right?

Kristoffer (13:36):

Yeah. I also like to see that transformation is the sum of all the small improvements. It's not one process. You are new and not implementing a transformation process, at the least not converting from traditional to agile. But there are all these small increments, talking in agile terms, that are summing to become the entire transformation in the end.

Lauri (14:11):

In the headline that says, "Implementing agile enterprise," huge change in enterprise architecture, there's this enigma, or there's at least a mystery that I believe that you want to unpack, which is alluding that it changes an enterprise architecture, which we haven't discussed yet.

Kristoffer (14:31):

Yeah.

Lauri (14:32):

Why is that? Why implementing agile enterprise is a change in enterprise architecture?

Kristoffer (14:40):

First, I think we should discuss the subject of architecture. What is actually architecture, and what is architectural descriptions or the connotation? Architecture is the actually perceived components of anything. If it's building, it's the actual building, how it looks, the acoustics, what environment it's put in, the materials, how it feels, how the people within are engaging and so on. That makes the architectural impression that you and I could feel.

Kristoffer (15:35):

The same thing applies to an enterprise. There are properties within the enterprise, and the enterprise architecture is the sum of all the people in the enterprise. The knowledge and competencies they are actually using. How they're actually working. It's not the process diagrams. It's how they're actually working. It's their mindset, how you build up the organizational culture, what tools and technologies they're actually using. And we could also say it's the building and facilities and surroundings they're actually working within. These things build up the enterprise architecture.

Kristoffer (16:24):

And if you're going to change any of these components, it's the change of the enterprise architecture. Even though you might not have an enterprise architect actually plan or build these changes. If you go to a more agile or DevOps world, we are actually changing every one of these components. We try to not necessarily change the people, but we are changing their knowledge, how they work, their mindset, how they collaborate together, and also the tools and technology they are using. It doesn't change whether you extend this to other parts of the business to become more agile.

Kristoffer (17:24):

I believe quite a lot of the listeners here know Martin Fowler. He also compares or has a description of why architecture matters. He explains that a good system design or system architecture allows scalability and large growth in functionality. If you are actually being able to scale, you need a good architecture to begin with. And bad architecture leads to an upper limit where it will be impossible to implement more functionality because you will have too many dependencies. There will be too many interconnections, and a small change to a small part will lead to difficulties in other parts of the system.

Kristoffer (18:22):

I believe that if we interchange the word functionality, in his Ted Talk, with successful changes, you could say the exact same thing to enterprise architecture. If you are actually wanting to have successful ... Being able to successfully change within an enterprise, you need a good enterprise architecture in the bottom. Of course, some companies, I believe, have this naturally, and they have a plan for it, but they are still having a good enterprise architecture in the bottom. Other companies have not, even though they had the enterprise architects, and they have been planning this for perhaps decades. But they have the same problems with actually adapting and actually being able to change. I believe this understanding of enterprise architecture being ... That implementing agile enterprise is a huge change in the enterprise architecture, and understanding how that works. It's really important.

Lande (19:45):

Kristoffer, just a question here for me, though. Typically, when you see organizations embarking on the transformation, for example, as it's termed, you start to see specific roles now called Head of Transformation or Head of Transition or Transformation, or something that's led by the CIO. From what you've just described now, it sounds to me you feel that the bottom line of actually what you're doing in this transformation is enterprise architecture because enterprise architecture encompasses a lot of how you work, the way you work, the systems you use, et cetera. Why is it ... At least certainly I see it. I see that there is for sure an involvement of the enterprise architecture, but it's a part of, as opposed to leading the transformation. Why do you think that is? Is it something you recognize even? It's something that I see, but I don't know if it's something that you've seen.

Kristoffer (20:52):

I'm not sure, actually. I believe many enterprises are trying to be more agile and have tried to change their enterprise architecture to become more agile. And I believe one of the major issues for many enterprises has been, actually, the financial part. They have started their initiatives within the technology sections. They might have some development projects that have been quite successful. And they had a successful software development project or even department. But when extending, they meet some issues and they are not able to implement it in other parts. One of the major issues is that the budgeting processes are not aligned to how we are actually doing things in agile. I believe that is an issue that many will recognize. And there are solutions for that as well. I don't know if that answered your question.

Lande (22:24):

You do answer my question somewhat. My experience is when I have been a part of a transformation when I look at how the transformation itself was instigated, and then how enterprise architecture was then holding to that context, it differs from the very good explanation you've given here about how the role of enterprise architecture within agile. And I have to say that I completely agree with you because I think you can't actually transition, truly, to a more agile way of working without actually looking at the systems and your infrastructure. But I'm looking at it very much from a technology perspective and saying, it's all very well changing how you work. But you also have to change the systems that you have. They also need to be compatible to enable you to be able to work in that way. Sometimes I see that's quite often secondary to the "We're going to become more agile, and we have a transformation project that's going to take 18 months." I'm like, that's just the icing on the cake, the 18 months. It's going to take you another four or five years to actually change your infrastructure for you to truly get that.

Lande (23:47):

But I guess it doesn't look nice on the balance sheet or on the project chart, to say this is a five-year project, because everyone's going to be like, "That's going to take too long."

Kristoffer (24:01):

Or you're actually having a never-ending project because agile transformation is definitely unsuitable for a project organization. It won't work. You can't have set ... "Okay, at this time in five years, 10 years, 20 years," you won't be able to reach it because it's a continuous process.

Lande (24:28):

Absolutely. That's very good.

Lauri (24:31):

Everybody agrees that three things are imperative. It's the people, it's the processes, and it's the technology. It's the oldest issue you can find on any change. But then what I'm hearing is that it's more than the discussion, what do you call that? Here we are calling it enterprise architecture and we say that it comprises of these things. But just to stir the soup a little bit, I go back 15 years and I think how was enterprise architecture defined where I came from, and I'm thinking from the five domains. It was basically the process, the information, the technology, the security, and the application architectures. That didn't include people, surprisingly enough. That was a very rigid definition of enterprise architecture, but it didn't include people. Basically, your description starts with people. Maybe there are as many definitions on what should be included than there are the terms.

Kristoffer (25:31):

Of course, there are different definitions and there are different frameworks for this. I'm trained in TOGAF and then I don't practice TOGAF strictly, but if TOGAF is the major architectural framework for this, most frameworks are more or less common sense put in system.

Kristoffer (25:57):

If TOGAF has this component called actors, those who are actually performing the process and processes, or providing services and so on. It's a part and I believe it's important to understand how the enterprise is perceived by others is strictly depending on the people as well. Because you could have all your processes, and of course all the tools and whatever you would like, but it would be nothing without the people.

Lande (26:45):

Yes. I have the beginning of a blog post in mind that I've started creating an outline. The title is "Yet Another Blog Post About Why Your Transformations Are Going Wrong." My next line ... This is what I started with. My next line is, "It's because transformations are all about people, people, people." That's what it is. I'm 100% with you. It's kind of like ... I think sometimes we get lost. We get lost in the tooling and the processes. Even when we talk about agile, we get lost in the principle. Although we say it is about people and being more agile, working with an agile mindset is about people, when you actually do the transformation, you fundamentally lose sight of the fact that you are changing people's perspectives. You are changing how they work. You are testing their knowledge and their experience. For a majority of people in the middle age and whatever, this is a scary thing. You kind of wonder, it's a change. For most people, it's a work-life change. You're removing roles. Yeah, I couldn't agree with you more about ... It's all about people.

Kristoffer (28:11):

I believe that many don't understand that changing the mindset is also a huge change of people, because then you're not only changing how they're actually being perceived or how they work or so, but we are actually changing how people think.

Lande (28:33):

Yes.

Kristoffer (28:33):

And that's the really important thing. And I believe, actually, most agile tools and frameworks and even with scrum or other methods, they are focusing on changing the mindset, and it's stated in all literature, and the trainers and the scrum courses and whatever, they are focusing on, we are changing the mindset. But I don't think everyone actually understands what that means.

Lande (29:18):

It's not something you go on a course for, is it?

Kristoffer (29:20):

No, it's not. And I believe this is the same thing with any transformation. You have all these small nudges building up to a transformation, and what we are actually transforming is the mindset. And the really important thing is that you can't do this in one big leap. You have to take all these small nudges all the time.

Lauri (29:49):

I am hearing that there is tons of agreement between what it is and what it isn't, but inevitably, people and organizations still come across the choice, and the choices between the frameworks. Somehow it's impossible to talk about enterprise agile or agile transformation without talking about frameworks. What are your opinions about frameworks? Once we have got them on the table, then maybe the leading question is: despite, or because of them, how do you then bring them in to do it, and where to start?

Lande (30:24):

If I may go first, frameworks are dangerous, actually. I'll say it. There. I've said it. Right?Because I think it gives you a false sense of security. I think we've just finished talking about how it's all about people, and then when you have a framework, whether it be safe or less or whatever, bottom line, you actually have processes and procedures in how to work. People can be forgiven from mistaking that this is it. If we implement this framework, ergo we're agile. That's the danger that I think. It depends on the organization. It depends on what you're trying to achieve. I think you always have to have those at the forefront of your mind. I think any framework, you have to use it in the way that makes sense for your organization. You need to adapt these frameworks or these ways of working to what suits and how you work.

Lande (31:45):

Of course, in doing that, a lot of frameworks will have a call principle that makes it flow, that it makes hand together. You have to be careful not to break the backbone of the framework, because then otherwise it turns into a mess. What I mean by that is let's say you decide to take something like safe, and you say, "We're going to take the PI planning card, but then we're going to ignore the portfolio part. And then we're going to take ..." That doesn't work. You really need to do a lot of research into how the frameworks are designed to work.

Lande (32:23):

And then I think coupled with a good understanding of your organization or objectives, then I think you get to a point where you understand better what will work for you. Otherwise, you're in danger of just following a recipe, a recipe to cook something that you never thought you were making.

Kristoffer (32:44):

I completely agree. And I believe that these frameworks, they might be a good starting point, and I believe some organizations will never be able to start their transformation journey without because they have these safe command and control structures. They're built in a way that suits using frameworks very well, and they won't be able to get into a more agile direction without. But then again, it's only a starting point. It's the necessary first step on the journey. Later on, they should be used for inspirations, views, and how others have actually made this work. But then again, you have to get into your own organization and know how your organization works and find out what suits your organization best. There is no one size fits all. Definitely not. And the important thing is that you have this vision of where are you actually going, why are you wanting to go there, what are you actually trying to achieve, like you said, Lande.

Lande (34:31):

Yeah.

Kristoffer (34:32):

I believe most, or even all transformation journeys go much far beyond the frameworks themselves. But they might be a good starting point. If you want to go with the transformation journey, you have to assess your culture. There are lots of frameworks. Some will suit some organizations, some won't.

Kristoffer (35:08):

I don't think that only because you know safe or know less or you know the Spotify model or whatever, that you should try to implement that in every organization because it won't work.

Lande (35:22):

Exactly.

Kristoffer (35:23):

You have to know your organization and match the most suiting framework to your organizations, and let that become your starting point.

Lande (35:35):

Absolutely.

Kristoffer (35:36):

And starting to develop it further on, to actually become agile.

Lande (35:45):

I absolutely agree, and I like that. It's a good starting point because it is scary when you're a large organization, embarking on a change. That, for me, is the danger. It can lull you into a false sense of security. If you just follow these steps, you will become agile. And sometimes it's okay when you start. As you said several times, it's a good starting point to help you align where you want to go. But being a less practicing organization or a Spotify organization, or a safe organization is not the goal. Do you see what I mean? It helps you on the journey, but it is not your end state. At some point, you need to move beyond these. At some point, you've learned about your organization. You've learned about the patterns of how you work. This now becomes part of your mindset and your DNA, so you evolve beyond a strict framework to the new normal of how your organization works. But yes, frameworks can help you along that journey, but it shouldn't be that if we implement everything in X, we'll be agile. That, I think, is the false sense of security that they can potentially give you.

Kristoffer (37:18):

I agree.

Lauri (37:20):

I think from marketing organization, one of the reactions that show that we are on the right track, of course, in a far, far smaller magnitude, is that when the team itself begins to suggest what to do next. Instead of the practice being led, it is facilitated together. It can be that an individual, a random person in the team can suggest that how about we made a template for this. And how about we try to follow that template for the way we work, and everybody did that. Like, concretely speaking, if we had a template of a task in Jira with sub-tasks laid out, and then every time we do this, we always do it the same way. That's a measure, for me, that something is right when the people being to involve, not only the execution of something, but also the definition of how the thing should be. That involvement then becomes some sort of a milestone. What are your thoughts on that?

Kristoffer (38:33):

I completely agree. And I believe that's a measure of actually ... That you have been able to change their mindset, which is the really important thing that we discussed early on. I think the important thing of the agile transformation journey is this improvement culture, that everyone is allowed and stimulated to actually suggest improvements. There could be really small things, like switching the order of two buttons in a UI, or like you said, implementing templates. It doesn't necessarily involve major development or a big change, but the consequences or the effect of those changes could potentially be large.

Lande (39:40):

Absolutely. I think what you mentioned, Lapa, is more that ... This is the patterns. Once you adopt it, these are the patterns you start to see within your organization, which leads you to understanding what works best, and so, therefore, you're able to adapt. You're able to adapt the initial framework that you implemented vanilla to suit you more. Then you start the evolvement, the evolution of a process. But I think the other thing, as well, is just to be ... To be quite concrete here, back to the point where I said one of my bugbears is we stick agile in front of everything. Of course organizations today are innovating, punctum, right? Regardless, they are making changes. They're making decisions. They are doing things without having to use the word or using the label of agile. But I guess it's important to emphasize that we want this to happen at all levels of the organization, which is where the mindsets come in. When we talk about things like autonomy and making decisions at the lowest level, it's really about ensuring that innovation or creation is not the remit of one department in the organization, called the innovation department, for example. It is the job of everyone in the organization, and they are empowered to make the improvements in the best way possible in order for them to achieve their job, and not necessarily constantly having to seek permission to improve.

Lande (41:23):

I think it's important to at least highlight what are the benefits when we talk about agile. It's not just for the sake of it. Because, you know, as human beings, we are ... How do you say this? Motivated to constantly do better, but we want everybody to want to do better.

Lauri (41:42):

Should you say that you are in the right place where there's no-

Lande (41:46):

Yeah.

Lauri (41:46):

Longer a need for an executive sponsor, which is probably one of the important words between 2000 and 2010 in the IT projects. I don't know how frequent that is nowadays, but then it was really a thing to have an executive strategy.

Lande (42:02):

I don't know. Someone still has to sign the checks, right? Hahah It depends on what we now want to define.

Kristoffer (42:17):

A really important aspect here is that you could have the most agile enterprise in the world, but it still has to operate within this world, which isn't necessarily that agile. We have legal regulations and financial regulations, and other companies, they will collaborate with. They are not necessarily that agile, and that leads to ... You will always have interfaces between where you can be agile and where you actually need these traditional ... Where you have these interfaces and where it meets something that is traditional and you can't deal with it. You have to accept it and make your processes meet the external processes. It could be from banks. It could be from governments. It could be from-

Lande (43:35):

Yes, context, isn't it? We still have to work. Yeah. 

Kristoffer (43:40):

Because even as a CEO, you can't control how you're going to operate with the governments, with the external actors, as banks and other companies that are outside your control.

Lauri (44:05):

Shall we try to address the two other questions we still have remaining? One is an important question about control, and then I think we still have one more remaining. But anything else to say about involvement, or shall we just take a deeper dive on the control part?

Lande (44:22):

I would say let's go into control part.

Lauri (44:25):

Yes. Let's take control of the control. I alluded to the executive sponsor before, which is that the leadership and control, sort of traditionally, go hand in hand. As I said before, in a smaller scale, the team comes up with the ideas, and team takes lead of the development of their way of working. It can feel like you are letting go of control, so how does that work in the agile enterprise?

Kristoffer (45:05):

It's always this balance between control and agility. It's difficult. Many agile evangelists, they're talking about do you actually have control, or are we having an illusion of control. But I believe that most leaders have to build up trust to their employees. Trust is an important keyword here. And making, or understanding that their employees, they are working for the best possible results. I know it's difficult to let go of control, and it's difficult to change the mindset, again, of the leaders for this part, but some sort of change management ... You have lots of different frameworks for that as well. But change management. All these frameworks have something in common. It's about understanding of why we change. It's about understanding where we are going with the change. And it's being able to actually change, and then have reinforcement.

Kristoffer (46:49):

I believe this change management practice has to be applied to leaders as well, for their mindset to change. And the important thing is understanding. They have to understand why we're actually doing this and why this will lead to better results for the team afterwards. When they really do understand why, it's easier to gain their desire to actually do this as well.

Lande (47:35):

For me, it is similar to what you just mentioned, Kristoffer. I would actually want to get to the bottom of what is the need. Why do we want control? For me, I go relegate to this just managers or leaders having control, because I think this is true at all levels within the organization, whether your remit is your team, or whether it's your one person and you have control or full responsibility of a bunch of systems and you want to maintain it. Looking at the control in the wider context and not just one group of individuals within an organization. You'd always want to get to the bottom of why is that need there. I think that's what we want to address, right?

Lande (48:33):

I think quite often it's about transparency. There's a number of key things. It's about understanding what's going on and have full transparency as to what's going on. And then the second thing is about having a level of blamelessness, a blameless culture. If you're able to miraculously achieve both things simultaneously, I think that's ... And I like the phrase the illusion of control. I think that need for that illusion of control that you think you have will dissipate, because everything you need is transparent. It's available. You can get the information. You know where to get the information. And we don't point fingers when we don't have the right version of the information, or we got it last, or didn't get it first, or whatever. I think when we talk about control, we have to start to look at the organizational culture, actually.

Lande (49:36):

This is sort of "I'm going to throw in the Western different organizational types in here". And the point is, you want to move toward a more generative culture. In order to be able to do that, there are so many things. And one of them is getting to the bottom of why we have this need and what we can do to remove it. It's difficult to tell someone, "You have to let go of control." And I'm like, okay, fine, but then what are going to replace it with? And then the next natural question should be "what is it you want to know, Lande?" Then I can tell you. And then we'll move forward. But just telling somebody to let go of control, it's can't compute, says the control freak here, by the way.

Lande (50:33):

It's not just managers. It's all levels. We're human beings. We're very territorial, aren't we? But you have to give us something else to stop us being territorial. We have to replace it with something else.

Kristoffer (50:48):

Yeah, and I believe that transparency and trust are fundamental keywords here.

Lande (50:56):

Exactly.

Kristoffer (50:59):

If you, as a leader, can trust your employees, and the opposite way as well, that you know that your employees trust you as a leader, this need of control won't be necessary anymore. It's this link between your employees and you as a leader or you as an employee and your leader to actually ... You need to have this level of trust. And with trust, blamelessness comes as well because you know that your employees aren't ... They won't destroy the business. They won't damage it on purpose.

Lande (52:00):

Exactly.

Kristoffer (52:01):

If they have worked for you and you trust your employees, they won't do that.

Lande (52:09):

At least not on purpose. Exactly.

Kristoffer (52:14):

Yeah.

Lauri (52:14):

When I was thinking about this control, or that there's an underlying assumption that control is bad, but it would be as useful that process is bad. Just the question of what form does it take and where do you apply that into the extent. And of course, in the same way that process can be detrimental, control can also be detrimental. But they can also be useful.

Lande (52:40):

It all boils down to people, doesn't it? And how we apply it.

Lauri (52:40):

Absolutely.

Lande (52:42):

Which is kind of the discussion we were talking about earlier. People, people, people.

Lauri (52:46):

Yeah. We have gone through a long discussion. We started by the basic premise on why should an enterprise want to be agile. We discussed about the enterprise architecture. Then, we gave enough attention to the frameworks, and that's enough of it. Discussed about where to start, how to involve, and now lastly, what's our approach to control. This has been a hugely interesting conversation. Maybe we can wrap this conversation up by talking about the good practices instead of best practices.

Lande (53:21):

Or even common practices.

Lauri (53:24):

Common practices. Even better. Yeah. Let's finish there, but give floor back to you, to Kristoffer and Lande, just to talk about the common practices, good practices, how to summarize all of this conversation.

Kristoffer (53:41):

I think that the important thing is actually to start small. Know what you're actually wanting to achieve and why you want to achieve it. If you want to become more agile, you can't take it in a giant leap. You have to implement it in an agile way, increment by increment, bit by bit. You have to know and accept that you will fail. You will ... That everything you do won't be successful every time. But in the macro perspective you will get closer and closer as time goes by. And that's the important thing. You have to really understand how your organization is put together. This is where enterprise architecture could be ... Or describing the enterprise architecture could come to help. Then you have to share this big elephant in pieces, and it has to be small pieces because it's not ... You have to take in the right direction, or in the right order. That's important.

Kristoffer (55:27):

But understanding the why and everyone involved has to understand why we change. It's a fundamental part. And they have to understand that this includes changing the mindset and changing the evolved people themselves. It's not about drawing some fancy process diagrams, or changing some IT tools, or changing the org chart. This is all about changing how people think.

Lande (56:12):

Good. I think you touched upon a lot of the things that I would've said as well, Kristoffer. I think the maybe two or three key things that I would highlight, in terms of what is good practice when embarking on such a thing. Always remember why you're doing this. That has got to be at the forefront of your mind. There is a business reason for doing this. You're not changing people for the sake of doing this. So, that at each point of your journey, is this getting me closer to my business objective. Which means that you kind of have to have a baseline of where you've started, so that you can know ... You can basically plot your journey of improvement. I think it's really important to constantly be aware of where you're going and redirect yourself to make sure that you're moving towards that goal. It doesn't mean that the goal doesn't change, but if the goal changes, then you adapt. For me, that's very good practice.

Lande (57:24):

The other thing that I would also say is ... A transformation or a change is not something that's done to you as an organization. You're the one that's doing it. You have to do it. You have to engage. You can get experts to come in and advise you and help you to understand good practices, help you to gain from other industries within your area that have done this, coach you, but you're the one who has to do it. Nobody can come in and change your mindset. That has to come from within. I think those are the two good practice things. The management, the leadership. Everyone needs to be engaged in this. And you all have to be going in the same direction. As you said, Kristoffer, you have to understand why you're going in this direction. You will lose some people along the way, and that's okay. Not everybody wants to change, and I think that's okay too.

Lande (58:37):

I think for me, those are really the main things when you're talking about a transformation. It's a long journey. It's a marathon. You need to have the stamina for it. It's not going to be easy.

Kristoffer (58:50):

Truly I agree. I believe that you have to have a vision of where you are going, which is sort of the goal, and that's the place that everyone wants to go. Then you should have a strategy to be the map, how to achieve the vision. You have the world that the company operates within that is the actual road. Then you have this organizational culture with all the people within. It's the vehicle we are actually driving. And then you have the enterprise architecture with the people, the competences, the processes, the mindset and everything, that is the capability of actually driving this vehicle to what's the goal.

Kristoffer (59:58):

If everyone wants to have a best ... Or if you're going towards the goal, everyone has to help because you can't ... You won't have this small children in the backseat that are messing up and shouting and yelling at each other, because that won't get you to what's the goal. If alignment is an important thing there, that you have to see and understand the goal in more or less the same way throughout the entire organization.

Lande (01:00:52):

Yep.

Kristoffer (01:00:53):

I'm Kristoffer Ryeng and I'm working as an enterprise architect. I'm embracing agile. I'm an experienced tech leader, architect, and have been teaching as well. And I have a strong automation and agile DevOps mindset. I have a strong interest of enterprise agile, business agility. There are lots of words to describing this, but I'm strongly interested in the outcome of what we are actually trying to achieve. That's the major part.

Lande (01:01:34):

My name is Lande Castberg. I work for Eficode. I'm responsible for our operations in Norway. In addition to that, I am responsible for our transformation program business in Eficode. Some experience from the other side of trying to agile or digital transformations in organizations. Well-loved topic. So yeah, that's me.

Lande Castberg
Country Manager, Eficode Norway
LinkedIn: https://www.linkedin.com/in/lande-castberg

Kristoffer Ryeng
Enterprise Agile enthusiast /Enterprise Architect
Twitter: @kristofferryeng
LinkedIn: https://www.linkedin.com/in/kristofferryeng/