Month: December 2021

Gunther Verheyen

“Scrum is more about behavior than it is about process. The process aspect of scrum is only the mere beginning.” – Gunther Verheyen

TRANSCRIPT:

Speaker: Miljan Bajic 00:32

Who’s Gunter Verheyen?

Speaker: Gunter Verheyen 00:38

Gunter Verheyen is a Belgian guy. I live in Belgium in Antwerp. Beautiful city, by the way. Have you ever been there?

Speaker: Miljan Bajic 00:51

No.

Speaker: Gunter Verheyen 00:51

Have you been in Belgium? No? Okay, you should come over someday, once we can travel again.

Speaker: Miljan Bajic 00:56

Would love that.

Speaker: Gunter Verheyen 00:57

Nowadays, I call myself an independent Scrum caretaker. And I’ve added to that I call myself an independent Scrum caretaker on a journey of humanizing the workplace with Scrum. And for some strange reason, that seems to resonate with a lot of people. So, that gives me some hope and maybe also some inspiration about the future of agile and the future of Scrum. Because the way that it resonates with people, I tend to see that as sort of indication, yeah, we’re on to something and I might be on the right track or on the right path. So there’s this hope, that’s a good thing. Because I think, I don’t know, Scrum has been around for a while, as you know. 25 years exactly was celebrated by the end of last year, the end of 2020. And what I’ve noticed, and that’s why I started calling myself independence scrum caretaker [inaudible 01:59]. What I started noticing in those first 20, 25 years of Scrum, we have achieved a lot so let’s be really happy for that and even grateful to all the people around the world that are actually applies from doing it, employing it, trying it out, and doing great stuff with it. So, we have achieved a lot. And just to name a couple of firm so that cross functional thinking of the work of development. So, cross functional teams, moving from old school, fixed price projects to a more product-oriented way of thinking. We’re getting to the idea of a product owner also, to have achieved a lot. But I started calling myself an independent scrum caretaker, when I left scrum.org. I don’t know whether you know, Scrum.org. So, the organization of catering. So, I’d been working sort of exclusively; partnering exclusively with Ken and Scrum.org from 2013 until 2016. And when I left him, I wanted to be truly on my own two feet, not be tied into any type of structure and be out and do consulting as well because something that scrum.org doesn’t do. I had to think about a name, a title or whatever, a role or description or something. Because you know, LinkedIn wants us to do that. And I felt like rather than giving myself an established whatever title because I’m just a one person company. Just me. So, I started my own little company back in 2013. Exactly, to stop partnering with Ken. Because I had been in consulting the years before that. So when I left in 2016, I had to come up with a sort of title for me. Because it’s almost like to state stupidly, a mandatory field on forms and on LinkedIn as well. And I felt like why would I not call myself for what I believed that I am, what I like to do, maybe how I like to be seen. That something I feel that reflects who I am. And that’s enough sort of intuitively came up with the idea scrum caretaker. Because scrum caretaker for me reflects the idea of taking care. So, it already has the sort of people and human notion in it. But I called myself scrum caretaker because I do care for people and the human side of our work. But I also care a lot for Scrum that I’ve been doing that since 2003. So, that’s quite a long time. I’m so passionate about it. And it sort of turned out fine because it resonates with people, because I feel people have a need for this increased focus emphasis on the people aspect of scrum. And that’s why I say, I think we’re onto something here because in those first 20, 25 years of scrum, we have achieved a lot. But a lot of people still are sort of stuck. Can I say that? In looking at Scrum as these entities.

Speaker: Miljan Bajic 05:11

Process or?

Speaker: Gunter Verheyen 05:14

Process, products and so on. But what about people? So, what about adding people to the formula, the equation?

Speaker: Miljan Bajic 05:24

So, that’s, yeah.

Speaker: Gunter Verheyen 05:24

Products, process, yes, but also people. Product in a general term, that’s where Scrum comes from. Nowadays, it’s more about dealing with complex problems in general. But about that and what I call scrum’s DNA, you know is empiricism and self-organization. And I feel we have achieved a lot from projects to products, cross functional thinking, the product owner role, the business involvement, crossing bridges between IT and business and product management and so on, we have achieved a lot. But I miss the focus on that second aspect of scrum’s DNA, self-organization, which is the people aspect. So, empiricism is slowly getting through. That means a lot of organizations have, whether they like it or not abandoned the old way of thinking, the linear way of thinking large phases, the industrial approach, the waterfall approach. So, the empiricism is coming through and using empiricism to inspect and adapt, build great products, fine. But I feel still very difficult for management, leadership, organizations and unfortunately, even often teams and self to really grasp is the idea of self-organization. Being able to organize yourself for your work within boundaries against objectives and goals. Without anybody outside of your ecosystem, your team or your product or whatever.

Speaker: Miljan Bajic 06:54

Why do you think that is?

Speaker: Gunter Verheyen 06:56

What you should do and how you should organize. Because [cross-talking 06:58]

Speaker: Miljan Bajic 06:58

Why do you think that is, like, yeah? Like, and I completely agree, we’ve gone, you know, a long way. And you know, one of the things that resonated with me, with the latest thing that I did in Utah, with the co-signers of Agile Manifesto. There were six of them and they all reemphasize that focus on individuals’ interactions over processing tools and people, the people side they use. So, why do you think you know, 20, 25 years later, we’re still talking about it’s all about people, it’s all about interactions?

Speaker: Gunter Verheyen 07:35

Yeah. Because software development itself as one example, huge example of complex challenges, because it’s about complexity meaning, a lot of uncertainties and predictability and so, requires intelligent people to solve that, to bring their brains together and to tackle that. So in a way, the fact that people are organizations, let’s say are increasingly embracing empiricism is because although it’s really not easy but within the whole, it’s even the easy part of Scrum in that sense, it’s a lot sort of the process, what I like to call the gold part. It’s how to organize, it’s setting up a process.

Speaker: Miljan Bajic 08:21

So, it’s also the easy part, right?

Speaker: Gunter Verheyen 08:23

Yeah.

Speaker: Miljan Bajic 08:23

It’s the easiest part.

Speaker: Gunter Verheyen 08:25

Yeah, it’s the easier part compared to the people aspect, which is the, what I call the warmer parts, so not the cold, the warmer part because it’s more difficult to cross. And in that sense, it’s great that you bring up that first statement of the Agile Manifesto. Because it means that we are still working towards shifting the balance from processes and tools towards people, interactions, individuals as well. And as because a lot of organizations still are in the mindset of seeing Scrum too much as an old school process. I like to see Scrum as a process. But you know, 2001, the Agile Manifesto, when they said individuals and interactions over processes and tools, what they meant with processes by then was big phases, big things, waterfall as well as big size, large size, governors, meetings, hand over sign offs and so on. That’s what they meant with process. For me, Scrum is a very lightweight process. I call it a servant process rather than a commanding process. Because those large processes are commanding processes. They tell people what to do. They’ve got exhaustive, detailed instructions on who should be doing what, what should be happening at that point in time. Scrum doesn’t do that. Scrum actually, for me, Scrum is on the correct side of the equation, meaning it supports interactions and individuals. In essence, scrum does no more than try to invoke, sometimes even provoke people to interact, to collaborate. That’s what I said in a book I wrote about Scrum back in 2013 and there’s a third edition coming up; My Scrum, a pocket guide. Scrum is more about behavior than it is about process. The process aspect of Scrum is only the mere beginning. And imagine it’s already we always say, you know, that expressions simple, not easy. It’s already very not easy. The next step will be the people aspect, seeing the scrum process really on the side of interactions and individuals. Because with Scrum, we create a frame, we try to create a lightweight structure that gives people focus, give them some boundaries, within which to again, self-organize. But self-organization means we’re not going to tell you how to do that. We just give you literally a frame within which to do that.

Speaker: Miljan Bajic 10:59

Some compact of guardrails right or something like that?

Speaker: Gunter Verheyen 11:02

Yeah. And within those guardrails, within that frame, it’s all about the sort of, let’s say, what you get out of Scrum. The benefit, you will realize with Scrum will all depend on how well people gel, collaborate, interact. How they in a way use Scrum, to in short cycles called sprint, solve and tackle problems, do that together collectively. And that self-organization sort of the foundation, the empirical process with the events and as well, it’s just a start. Because let’s say, there’s a lot of like you would have in books, there’s a lot of whitespace. You have to fill that in. If you don’t do that, you’re adopting the process, but you’re not adopting the process as a framework within which people can tackle challenges.

Speaker: Miljan Bajic 11:55

And change the behavior, like you said, so like, how would somebody change the behavior? So, I agree, it’s all about changing the behavior and there are certain things that influence the behavior like mindset, right, like the systems that we work in. So, from your perspective, what are the best, what are some of the ways they’ve seen that not only focusing on the process, but also the behavior side?

Speaker: Gunter Verheyen 12:21

Well, it’s why also in my book, 2013, I wrote about the scrum values. And I think the scrum values can be really helpful, at least as sort of what I call a compass; sort of gives direction. It has a second purpose too, I’ll come back on that. Because what I like about the scrum values is that you can translate them in a way into behavior. But in that translation, because in the end the Scrum values aren’t just five words, it’s what you mean those words, what you mean with commitment and focus and openness and respect and courage. Because you can give lots of meanings and interpretations. And then you need already some courage to translate those words, in the context for which you want to apply for meaning complexity. And again, working with people and then you can translate them into tangible behaviors is that’s what I tried to do with a blog note I wrote about it and then put it in my book. And am I even creating workshops around on scrum values to help people think about the values because you can’t, in a way, you cannot teach values to people but values drive behavior. That’s why I say Scrum, actually, it’s more about behavior than about process. And then those values in a way they give us a sense of direction, a compass to help us navigate and collaborate with each other.[cross-talking 13:54]

Speaker: Miljan Bajic 13:54

Yeah, no, I completely agree. I’ve recently in some of my workshops started to, especially in the leadership once started to also tie in, you know, put between the value; Scrum values and the behavior, put the beliefs because we could have same values but we don’t differ a lot of times in values, everybody wants to get respected. Right? But what does respect mean to you and what do you believe about respect is a lot of times where people have disconnect and have different type of behaviors. And it’s been really interesting how we don’t spend a lot of time thinking about values and beliefs. But like you said, they’re the things that drive the behavior.

Speaker: Gunter Verheyen 14:44

It’s sort of an ethical side and by the way, I like how you call that beliefs. Because when I say values drive behavior, it’s very similar to saying that your beliefs will show in your behavior. So, what are your beliefs? And then what I think is important with Scrum is you can’t teach values, you can’t impose values. But you can try to reveal that. And like you said, you can try to reveal people’s beliefs by looking at their behavior and help them think about it and maybe grow into another different beliefs and another way of believing another set of fellows. Yeah, that’s great.

Speaker: Miljan Bajic15:28

Yeah. And the way that I tell people there is a litmus test. If somebody is pissing you off, there is a value that’s being, you know, violated. So, if it’s trust, you know, courage, whatever it is, if you’re getting pissed off, you know, some value is getting violated. If you’ve been happy about something, that means somebody is reinforcing the value that you have. So like, you can see, you know, and going back to the interactions, you can see if you’re living those values, right? Because we talked about, like, it’s about embracing and living those values, not just saying, I believe in, you know, in this or I value this, but actually, you know, do you live those?

Speaker: Gunter Verheyen 16:17

Can I build a little bit on that?

Speaker: Miljan Bajic 16:19

Yeah, please.

Speaker: Gunter Verheyen 16:19

Because the thing that you say, because you call it a litmus test, and that is exactly sort of what I just called the second purpose of this scrum values. So, values drive behavior. And the second thing is, so it’s sort of a composite in a way the scrum value to think about and the second not really purpose, but the second way to look at is that litmus test. So, what I say behavior expresses values, which means that in a way, what I call in a paper I wrote about it scrum values as your scrum adoption continuous and growth, and in a way becomes more sophisticated, that means that the people, the sort of the players, your Scrum players will focus less on the process, following the events, the meetings, the time boxes, and so on and they will start in graining and expressing different behaviors. And in that sense, in a way, what I say the way, the way that the scrum values are being enacted, is a sort of barometer of your adoption of Scrum and even the health of your team. Because in the way that you see in a team, less focus on process, more on interaction and behaviors. And in those interactions and behaviors driven by discovery and to see sort of commitment, increasing, engaging people people, re-energized and inspired by the work being open to each other, but in engaging in respectful disagreements. Not agreeing, but respectfully solving that in order to tackle complex problems that requires a lot of courage. You know, in essence, the way that values are being enacted is sort of a barometer of the state of your Scrum and the health of your teams.

Speaker: Miljan Bajic 18:10

And key to that, you mentioned courage and you mentioned, you know, trust is a key aspect of that, and to have the courage, you know, a lot of times to be vulnerable and to build that trust is huge. And it’s tough in organizations, I think, especially large organizations. And most of my work has been here in United States. But what have you seen like, what are some of the things that are misunderstood about Scrum or that people find the most challenging about Scrum? Besides embracing values and that whole behavior, like what else do you see that maybe at the organizational level?

Speaker: Gunter Verheyen 18:56

Yeah, a problem with a lot of you know this things called HL transformations? I see you’re smiling, that good. So, a lot of them are about Agile and fire scrum. And they are what I call way too explicit. In that sense, large organizations, how do they try to go through change by setting up a change project. And they’ve lots of stuff that people have to now follow. So, they enforce change upon people. So, it’s really explicit. It’s in a change project, it’s a separate thing with managers and project managers and so on. But I feel that’s not how you grow, you evolve your company. I believe a scrum transformation should be more implicit rather than explicit. Because in Scrum, we’ve got this beautiful thing called a retrospective. So, by the end of every sprint, you’ll get a beautiful opportunity with a team and all teams across the organization to reflect, improve, change things. So, in a way that should be the driver of change by every retrospective look into what can you do. But even then, what I believe is impossible, it is impossible for me to properly adopt Scrum, try to get, you maximize your benefits you get from Scrum, without rethinking the structures around Scrum. Meaning how do you deal with governance? How do you deal with this relationship with product managers, relationship with sales people, HR strategies or sales and sales processes? Well, you can’t. And that’s something a lot of management or leadership still likes to think I believe is that, you know what Scrum and agile is just for the teams. It’s just for delivery, it’s just for development. And that often, they establish Scrum teams within the existing departmental structure, silos and so on. And then you’ve got all those little micro teams, often they’re isolated.

Speaker: Miljan Bajic 21:01

Even within teams, right? Yeah, even within the teams, you have people that are not cross functional. So, you have the scrum in silos. And then you have inside the scrum teams, you have silos of people that are not willing to step outside of their comfort zone and do that.

Speaker: Gunter Verheyen 21:18

Rather than like in the past, what you had is sort of work being thrown over by individuals to each other. It’s by individuals within teams. But let’s say that we might go pass that already. But still on top of that, it’s sort of micro teams throwing work over the wall to each other. So, there’s no view to sort of end-to-end value creation and the total delays that all those teams have. So, what I miss with those organizations is, here we go again, the courage, to what I call rethink the structures around Scrum. Rethink, think in terms of what is a product, what is a service or more generic, what is the complex problem that we’re trying to solve? And then organize your Scrum to tackle that problem or deliver that product or that service optimally. And everybody sees the value but nobody has the courage or the insight, whatever, to sort of tear down all those departmental walls between those teams. Because those teams in different departments, you’re working for the same product or the same service. So, if you would organize your Scrum for your product, you will start with product, and then set up your Scrum teams to ultimately serve your product. And that would be regardless where those skills and expertise would come from, which department. You would organize your scrum teams across those departments. But then you can’t like, chop rotate then, hierarchy status [inaudible 22:49]

Speaker: Miljan Bajic 22:50

Yeah, exactly. Yeah. And you know, I would even go further and I would say like, you will start with the customers and users and see what products and services that they’re willing to pay for right? And then go down. But you’ve probably seen this too, where it doesn’t really take hold or the so called agile transformations, which by the way, I think most of them fail to do anything that they intend to. They fail until like, really, the board in large companies or the top people in the company fully understand the differences between agile and agility. And that it’s not just the implementing bunch of processes. That really they need to change the complete structure of the organization, to be that product based, service based, experience based whatever it is. And if you think about it, who can do that? Only few people and organizations. And where I’ve seen it work is where you have a support from the board and president or somebody like president to actually make those changes. Because I’ve been in a situation where I remember this guy, I was telling him like, just as far as previous experiences what happened and he’s like Miljan, you know, this means you know, I’m going to lose my authority in a sense in that, kind of those words like you know, I thought this was only for the teams and you’re saying now that you know, everything, you’re going to flip everything, or we going to flip everything upside down. And it’s like you said it’s not courage. People don’t have the courage and willingness to, you know, you describe yourself as a caretaker; Independent Scrum Take care, sorry, caretaker. But not many leaders see themselves as the organizational caretakers. And I think that’s one way to look at yourself is how are you taking care of the organization and the people in it. And then sometimes it’s doing that certainly without serving, you know, serving the people in the company, not serving your own needs. Any thoughts on that?

Speaker: Gunter Verheyen 25:11

Yeah, absolutely. It’s sort of what you say, it’s in a way about agility. Because what I like to say is Scrum cannot be the purpose of Scrum. You don’t do Scrum, because of Scrum, you do Scrum for some different purpose, for some different reasons. And, like you said, is to build better products and services, increase customer satisfaction, to get more, to deliver more value to your users, discover new services that might be valuable as well. But also, in a way to increase what you just call the agility of your organization. So, like when I worked with Ken back in 2013 to 2016, we try to stay away sometimes even move away from the term HR because it became a very confusing term because everybody asked, given the success of a HR and a manifesto, everybody was giving a different meaning also. So, we try to help people think in terms of what you just said; agility so, that totally connects to your baseline of your podcast, from agile to agility. So, we try to help people think about agility. And agility for me essentially is a state, a way of being but a state for your organization. And that’s not business agility, that’s not technical agility, it’s not IT agility, because we want to transcend all those sort of specialized focuses let’s say. So, it’s about agility. So, enterprise agility, organizational agility, the ability to act with agility, swiftly with speed, responsiveness, being able to change direction, being able to innovate, to be able to innovate maybe drive your competitors crazy with all the things that you do. So, and we say that, if you want to do Scrum, it’s to increase your agility, which probably expresses itself in your ability to go to market faster or increase your customer satisfaction, increase your financial benefits as well. But also make in a way your people happier, more engaged. So, it’s not just about value for the user, it’s value for the organization but also value for the people doing the work. And that’s why I like sort of a 360 degrees on things. But agility, scrum as a tool to increase your agility and your ability to respond and to deliver value. And then how to achieve that, because a lot of the existing organizations are very rigid organizations. For me, a rigid or rigidity is the antithesis of agility. So, rigid versus agile, where do you want to go? We have established large organizations. And then what I tried to bring to leadership and CXO teams often is because at some point in time, I started describing this thing called the illusion of agility. So, a lot of organizations grow through HR transformations and I fully agree with you, most of them, if not all, tested, end up what I described delivering an illusion of agility. That is not truly agility. You’ve gone to lots of things, you’re imposing a new process on people. You make sure that all your teams across the organization now all work on two-week sprints with the same start and end date. You make them apply the same practices, use the same tools, the same digital tools and some same electronic tools. They all have to use JIRA, TFS, whatever. And you’re building up what I call an illusion of agility. You are fooling yourself into believing that your agility is growing. But you have all those micro teams handing over work to each other, which means that the overall value stream is still very long, it’s full of delays, it’s full of waste, it’s full of rework and so on. And it’s not helping so at some point in time, I know most organizations go to something what I call, so they build up an illusion of agility and that is shown by what I call the deflation by reality or the illusion of agility.

Speaker: Miljan Bajic 29:32

Wake up call?

Speaker: Gunter Verheyen 29:34

Yeah, some morning, it’s a hard wake up call, very painful. They wake up finding out that customer satisfaction not improving, benefits not improving, market share not increasing, teams still leaving the company, top skill people still leaving the company, unable to hire great, new people that are full of brains and so they wake up, it’s deflation by reality. And they wake up, oh my God, this wasn’t truly HR. My sort of antidote to that because, you know, in scrum and HR, you know, it’s all about feedback loops. So gathering feedback and then acting upon that feedback. So, it’s not just about gathering feedback, it’s more about acting upon that feedback. In Scrum terms, I like to say that inspection without adaptation is pointless. None of the things in Scrum are about collecting data, reports, logs, whatever about the past. No, we start by looking at the past, observing and inspecting but the goal is always to adapt. So, everything in Scrum for me should be what I call forward looking. Every Scrum event and Sprints as a whole should get your eyes on the future. So, we start from the past, but the goal is to look at the future. Well, if our observation is an illusion of agility, that’s not enough. It’s good to make us laugh and we can whatever and brag about, you know. But what are we going to do to help people get across that and do better? And that’s what I ended up with saying illusion of agility avoid it. If you’re soon enough, or get over it, once it does shows. Reimagining your scrum. Because the message I bring to a lot of CXO teams is, let’s reimagine your scrum. And in that sense, let’s make it manageable again, let’s make it controllable again, by making it small again. Meaning my suggestion is, let’s look at all scrum initiative that you have going in the company, and let’s pick out one, a meaningful, a real one. Let’s look at it and let’s go back to the basics of scrum, the original intent of scrum. What is the product that Scrum initiative is about or several initiatives? So, let’s look at the product, let’s reorganize the scrum teams to ultimately serve the product or the service. Let’s have a real product owner, somebody with ownership over the product.

Speaker: Miljan Bajic 32:04

That’s a big one too, right? As far as like just business buying in and another one that I don’t see is like you have, unwilling to combine those product teams and combine business and IT and you really have product owners without you know, any say. But if maybe you then build on this inspecting on the past and you know actually doing something about it in the future, I spoke with Tobias Mayer last week and he said that we should be happy. Like you know, this 20 years, like these, if you look at the history of management, history of you know, kind of how these 20 years is not a lot and maybe these last 20, 25 years, 30 were about agile and maybe the next 20 years will be about agility. What are your thoughts on how does the future look based on where we are today and where we’re coming from? What are some trends?

Speaker: Gunter Verheyen 33:07

I had a test of several years ago that when you look at the future itself and for me what I said by then is the future of HR is in the small because it connects to that idea. Rather than trying to transform and transition all teams across the whole organization almost overnight or over the weekend towards something that is sort of an industrialized version of Scrum and agile. I like to make it small and then go take it step by step. So, initiative after the initiative, convert that into what I call a small product hub, that might be a round of service. So, have it sort of ecosystem within the organization around a product. Have all the skills, expertise within the hub to ultimately serve that product. And then gradually move from that old school pyramid structure to a network structure of prototypes where leadership and management is about connecting those hubs but not interfering with the self-organizing aspects of them. And then for me, we create HR organizations, because those become more flexible structures, rather than the pyramid rigid structure. Go from HR structures, meaning network systems [cross-talking 34:30] Ecosystems, yeah. They can grow, they can shrink, they can disappear, they can pop up without sort of destroying the whole of it. So, it increases flexibility. And that’s where I want to go with reimagining your scrum. Rethink your scrum, one initiative, let’s do that initiative, then take the next initiative. And by then, gradually transform, literally transform your pyramid into a network structure. So, away from the industrial, large folding, whatever thinking making it small. And you know what, when people, organizations go through that phases, yes, often of that illusion of agility, often two, three to four years, imagine how much work you could have done in four years time by making it small, growing something, expanding it, adding something to it, doing something more. But it seems to be organizations want to go too fast and therefore, they become very slow.

Speaker: Miljan Bajic 35:39

Well, also like, I think what I’ve seen, it goes back to what you said about HR and about, like, you know, a lot of times leaders come in, transformational leaders, right, that companies hire and they don’t have a lot of time. So, they know and they’re in a, you know, under a lot of pressure and they try to push without, you know, a lot of, in my opinion, a lot of experience, they bring in the consulting companies, big consulting companies, tell them what to do. But under that pressure, they just try to do whatever they can and they try to build on top of, you know, usually it’s not a first transformation. By now, it’s, you know, companies of, at least in IT companies have gone through several of those. And how, you know, from an HR perspective, what have you seen in some of the shifts in HR and how HR and finance too, how we budget, you know? Going from cost centers to funding products and services, what have you seen in that space?

Speaker: Gunter Verheyen 36:49

Well, again and you’ll confirm, indeed, the fact that it’s often way too explicit because you’ve got all this feeling and exerting pressure on people is not helpful. But what we’ve tried to do is help companies and organization leadership, at least managers move away from continuously judging people for that individual performance. And try to look at in terms of agility in a way ability to deliver value or to create value. For instance, [inaudible 37:23] rather than a cost center, which is the typical view on old school IT but we delivery part of it, turn it into a value center, many focus on value and then look for balances. How much value are we getting out of this versus how much money in away goes in. That means value, not just money being earned. But it might also be customer satisfaction, competition being blown away and so on. And in order to do that part of the end of that, that people aspect of Scrum self-organization, that requires a very different stance in a way from people from HR. Because it’s in a way people from HR, first of all, we have to get rid of the term HR; human resources because humans aren’t resources.

Speaker: Miljan Bajic 38:09

Alright, yeah. Somebody said… you know about that joke, sorry to interrupt. When developer was referred to as a resource and I think it was a manager and developer and one other person. And the developer turned around and said, if you call me a resource one more time, I’ll call you overhead to the manager.

Speaker: Gunter Verheyen 38:33

Great. That’s a good answer, yeah. Because people are people, people are not resources, right? Because resources, like sounds like people would be considered as robots, programmable, replaceable pieces of machinery. It’s not what we are. We are people, human beings. We’ve got emotions, we’ve got a private life and so on. And what we try to build on and that’s actually part of an agile transformation tool, certainly with scrum. You try to build on people’s natural ability to be agile, to adapt, to able to capitalize on new insights, new experiences and so. So that’s what we tried to build on. Now, how can you convert your HR human resources to something more respectful and more like a facilitating services towards helping people, really self-organize, develop themselves? So, over the past year, I spoke a lot about humanizing the workplace with defenses or with people it resonates. Before that I called it engagement is the key. Engagement of people across the world is extremely and I would almost say dangerously low. That means across the road, it turns out from surveys and research that only 50 and up to like 30% of people of the workforce say that they’re really engaged, meaning believing their company, coming to work in a spirited way with energy and so on buying into what the company is doing. Most of people go to work like sort of couldn’t care less attitude. More of I wanted to go home as quickly as possible again. So, there’s an enormous 15 to 30% only are really engaged. Look at the room for improvement. We can try to re-engage 70, up to 85% of the workforce. That is massive, that is huge. So, engagement is the key. So, how can we build on people’s ability to self-organize, people’s ability to be agile, adapt with Scrum and help them develop themselves, rather than telling them what to do? All again within a framework, within those boundaries.

Speaker: Miljan Bajic 40:48

Just to build on that, that the you know, telling them what to do. Like, I usually describe that I actually asked people in classes and workshops, how many of you actually wake up every week excited to work? And it’s roughly like that, you know, only 30% of people, right? But the other thing, the other two points that are interesting too, is if we are working on multiple projects and the whole cost of context switching is another thing. And then we, you know, I don’t know what it is today. But you probably know, you know, in the past how much we’ve spent on building stuff that’s not valuable. So, you have people that are disengaged, you have people that are context switching and building things that are not the most valuable things for the company. And somehow Scrum is going to fix all of that, right?

Speaker: Gunter Verheyen 41:37

Yeah, but it’s part of the idea of thinking in terms of what is value, what is valuable? And like only use features in a system that value will get them out because it will improve your life a lot, not engaged workforce that is not adding, that is not helping your ability to deliver value. So, something that you want to work on. We want to do that in HR, we want to build on self-organization, we want to check in with people regularly. But again, we got an event by the end of every speech that checking with people regularly, how do you feel about this stuff? And I hope that those things will also reveal the idea of multitasking or multi-projecting and so on. And it’s good to bring it up because that’s self-organization. Self-organization means for me more than just allowing people to organize themselves in sprints. In essence, being self-managing. So we’re not going to intervene as external, whatever, within your sprint. But there’s more to Scrum. And I’m glad you bring it up because I’ve seen it in a lot of organizations. Sometimes teams become really what I call highly collaborative, they really gel, they get to know each other, they are really flowing. In that sense, performance emerges from that because performance for me is not the goal, collaboration is the goal and performance is a side effect of that. And then a lot of them often plummet again. Why? Because they are being pulled out of the team or their product owner are being sent to another team or the main developer, whatever. And like yeah but there’s more to Scrum self-organization. Scrum self-organization means for me also that if people have the intelligence, the creativity, to organize their own work in short cycles, called sprints and openly, transparently show what they’ve done by the end of the sprint to learn from it, capture feedback as well, if people can do that, that for me also means that people can be accountable for their own team formation. That means external forces outside of the team are not only stopping to interfere in sprints but they should also stop to interfere in team composition.

Speaker: Miljan Bajic 43:48

So, do you think that’s why the latest Scrum guide went from self-organizing to self-managing teams? Because the way that I read it, you know, self-organizing teams decide the how, but self-managing teams decide what and how, do you think that’s the case or am I misunderstanding that?

Speaker: Gunter Verheyen 44:06

No, I have to say that I agree, that’s another thing. For me, self-management, meaning managing your own work on a daily basis in sprint, it’s only the start of self-organization. Self-organization, sort of the next step at least will be for me, what I call not just self-managing teams but also self-designing teams, meaning teams that know who should be on our team, who should not be on a team. So, for me, the self-managing already means the what and the how and the why. On top of that, I believe that we should go for what I call self-designing teams, so not just self-managing. Self-designing teams, people stopping to in a way tear teams apart all the time. Because you break up team dynamics, you break up personal relationships, you break up a system that you can’t really express in words. Which is, again, more much more than the process. So, from self-managing to also self-designing and also to avoid what you just described as context switching because that’s crucial. Because context switching, people, I don’t sometimes do PMO, the department head to senior, whatever saying that you should now go work on that team for the next couple of sprint and I need you over there. That is, at least not helpful. It’s not respectful again, for people. And it expresses a way of thinking in terms of utilization. And that again goes back to the idea that people are considered as resources. Because if you don’t consider people resources, you wouldn’t be trying to take a piece of machinery from one machine and put it into another one. You will just leave the team be for what it is, a combination of people that get to know each other. And you know what I’m thinking in terms of you ever have to feel that one person’s days and weeks of work because he has some sort of special skill. That’s again utilization in this whole view on what is actually should be a creative process. Yeah.

Speaker: Miljan Bajic 46:17

How much have we been conditioned, to actually be commanded and control because like, I go in large organizations and somebody that’s been there for 20 years or so doesn’t want any responsibility. Just give me, tell me what to do. And I see as a result of being conditioned in that culture and that system and it’s hard.

Speaker: Gunter Verheyen 46:43

I agree. It’s a result of a couple of decades of conditioning, also what I call oppression.

Speaker: Miljan Bajic 46:52

That’s a good word for it, yeah.

Speaker: Gunter Verheyen 46:54

Yeah, we have taken out all initiative, all ideas that people might bring up. And why did we do that? Because or how did we achieve that in a way because every time in the past, we said to people, you can bring in your own ideas, whenever we didn’t like it, we chop their heads off. And if we keep doing that, for a couple of decades, of course, people will show no more initiative, every now coming with scrum and beautiful ideas about self-organization and they don’t believe us anymore. And I totally get that. So, we have conditioned people. So it takes quite a while to remove that sort of layer of conditioning and show them that now, no, we really mean it. This is serious. And that’s sometimes what you need to do with management and leadership, ask them to be patient because you can’t suddenly over 1, 2, 3 Sprints of time, undo all of that conditioning of the past decades.

Speaker: Miljan Bajic 47:54

That goes back to the behaviors and only started with. Maybe, to conclude here, let’s talk for a little bit about the scrum master role. You know, it’s been 25 years since Scrum was defined. And still it seems today that the scrum master role seems to be so misunderstood by so many. Do you share that thought and why do you think that is, yeah?

Speaker: Gunter Verheyen 48:27

I’ve seen at least some ups and downs in those 17, 18 years of Scrum in the perception of that role. Although I think essentially, it’s still the same role. It looks like they’re struggling with it a little bit in the scrum guide to describe it as well. And it seems to be this tendency nowadays that it’s just a coach role, sitting back you’re not doing anything. Like, I don’t think so. I think Scrum master is also about doing something. The only thing you don’t do is command and control. But you’re not just sitting back, sometimes even by we do nothing, it includes some aspect of doing something because it means being connected, observing and ultimately, at least always in scrum, by the end of everything spent at a retrospective, try to inject, sometimes indirectly, sometimes in a very subtle way, try to inject some of your observations of what happened during the sprint into the team. But in a way that you want to get people to think about it for themselves, not tell them. So, it’s quite an active role. What I’ve seen over the past five, six years in some organizations where they didn’t have scrum masters anymore. Because in all of them were I don’t have all this over there but in country, I live in Belgium but I work a lot in the Netherlands, also organizations and they’re sort of a form of country, which is beautiful. But at some point in time, it all had to be like things like DevOps or something and so on. And suddenly the scrum master role was at least less prominent. And then it disappeared a little bit. It was sort of something you did if you had some time left. And again, sometimes things take time. So, it took a while for a lot of organizations to see why is this not happening anymore? Why is that not happening? Why is that problem not being handled? And then you’re going to ask, oh I think we have a role for that thing. Oh yeah, that’s right, Scrum master. Because but we don’t have a scrum master. So sometimes you try to [cross-talking 50:32]

Speaker: Miljan Bajic 50:32

How much is it like the perceived value of the Scrum Master? Because a lot of times when I talk to senior leaders and, you know, it’s like, why am I paying this person so much? Because all they think is they facility. And then on the other hand, there’s a lot of Scrum masters that see this as an opportunity just to switch from, you know, what I’m doing to the scrum master role without really embracing and understanding what that role is about. So, it’s kind of twofold. One is misunderstanding about the role and the other one is desire to get better at that role as a scrum master.

Speaker: Gunter Verheyen 51:11

The unfortunate thing is that even Scrum masters themselves misunderstand the role often. It’s like yeah but I’m the Scrum Master, I can’t do anything. Of course, you can do something like indirectly ask open questions, challenge people, there’s a lot of things you can do. Sometimes you want to teach a technique, bring in a technique and so. The question I often ask in classes, also in leadership is, how many professional sports teams do you know that are both successful, performing whatever you want to call it and do not have a team coach or a team trainer? No, of course not. Because a team sports with a group of people, there’s always a trainer. Let’s call him a trainer for the time being. And then the second question is, what does the trainer do while the game is being played? Well, there’s not much you can do, you watch, you’re on the sideline, you can try to shout and so on but the team probably doesn’t hear you, doesn’t hear your anyhow. But once again, you’ve start asking questions to the team, you think about strategies and tactics and so. That’s the role of a scrum master. Now, in a world of utilization, people are considered as resources. The value of the role of the Scrum Master is fairly difficult to get across. Because you can’t say in terms of utilization, you can’t say how much time you will be spending or what sort of work but you’re making the whole system more fluent. And the only difference is with the game in teams sports is that by the rugby, I believe you have, and that’s where we get the name scrum from. On a daily basis, there’s this little huddle, of the team coming together. So, even during the game taken already make some corrections. So, it’s even more dynamic. But you’re like the team trainer, you do more, you think about psychology, well-being of people, you talk with people individually, talk with them as a group, you take it to the retrospective. If needed throughout the game, if you want and a player comes down to the side line to ask, hey trainer, and you’re there to answer questions as well but you’re making the whole, sort of a well-oiled thing. But the difficulty is that a lot of organizations only see the value of a scrum master once there is no Scrum Master anymore. That’s difficult because it’s a very civil role. And that don’t get skipped from the scrum guard again, which is my view sort of unfortunate. I truly believe in that servant leadership. Now, that they changed in the scrum guide because it was often reduced to servancy only. No, you’re a leader by serving people, you have authority without power. Your authority is from your knowledge, insights into Scrum, into how the game is played, and your leadership is in how you help people develop themselves become better as individuals. And as a team, so you are serving the team but at the same time, you’re the leader. So, it’s not just all the services, it’s not just old school bossing people around, it’s a combination. And that’s a difficult thing.

Speaker: Miljan Bajic 54:26

What do you think about the part that they added that the scrum master is responsible for the team effectiveness? That’s something new that’s been added that’s pretty explicit now what Scrum Master is accountable for.

Speaker: Gunter Verheyen 54:43

Well, the funny thing is that in a way, it’s sort of it has always been because you’re in that sense accountable for the effective use of Scrum to help them become better as a team, deliver more value, be also be more engaged, more inspired as a team. And you’ve got a whole toolset available for that. The only thing you can’t do is command and control. So even in Scrum terms now, new Scrum guide, even if you’re accountable for the effectiveness of the team, how are you going to try to increase the effectiveness? By serving, leading by example, teaching, facilitating, coaching, sitting back, observing, asking nasty questions, challenging the status quo, whatever, help them think about things. Every possible technique except command and control. So, in a way that hasn’t changed. And I think it’s even a little bit way around. People might now take accountability almost too seriously and stop behaving as a boss because this scrum guide now says that.

Speaker: Miljan Bajic 55:50

Yeah. That’s very interesting.

Speaker: Gunter Verheyen 55:52

So, I hope we don’t shift the balance from servant leadership, from it used to be only service, you know, in leadership. I hope we don’t turn that around and people forget to also help and serve people. Yeah.

Speaker: Miljan Bajic 56:06

Yeah, that’s a really good point. I haven’t thought about it that way. And I use also the coaching analogy a lot. I describe the product owner as a GM, the scrum master as the coach and the developers as the team. And it’s you know, who gets fired when the team is not performing? Right? Usually it’s the coach that’s accountable. But what we’ve seen in sports too, is that command and control does come in when you’re under pressure. So, it’s interesting to see now that we, you know, have that highlighted as accountability. And like I said, is it going to shift where under pressure Scrum masters thought are acting certain way so?

Speaker: Gunter Verheyen 56:55

And as we know from sports, firing the team coaches and replacing with somebody else, only in a minority of cases really helps. So, people give the idea we’ve done something, we’ve fired somebody but in the end results often do not really improve. It’s not replacing the team coach itself is not but yeah.

Speaker: Miljan Bajic 57:16

Yeah. No, I love that analogy. And also, like I pointed out to LA Lakers, I played soccer all my life, but for some reason I follow basketball more than I follow soccer. But I talk about like, how LA Lakers in the 2000s had, like, you know, five or six Hall of Famers, really good players, Shaquille O’Neal, Kobe Bryant at that time, you know, Karl Malone, all of these superstars, Hall of Fame, careers, and they couldn’t win championships. So, it’s also not just putting budget superstars together, they have to understand how they’re working together. They have to have that chemistry and willingness to you know, so, you know. Coach by themselves can help but also team if they don’t want to help themselves, or don’t have a common goal, it’s the same thing almost.

Speaker: Gunter Verheyen 58:10

Yeah, they’re building on the same analogy. So, I like that a lot, it’s cool.

Niels Pflaeging

“A real consultant doesn’t say yes, I’m telling you this shit. A real consultant says no, you don’t. First you want to understand your problem. If you had understood your problem, you wouldn’t beg me for tool or whatever hype shit.” – Neils Pflaeging

TRANSCRIPT:

Miljan Bajic: 00:39

Niels, nice to see you. It’s been couple of years since we’ve seen each other. And I think I know who Neils is but how would you introduce yourself to my audience? Who’s Neils Pflaeging? If I pronounced your name correctly.

Neils Pflaeging: 00:59

Oh, boy. There’s so many titles that you give yourself over time, right? I would say I’m a consultant, I work on organizational development and help clients with that. I have done that for 17 years. I’ve written books. Quite a few, three.

Miljan Bajic: 01:20

Really good books by the way. Just honest opinion. I think that’s how I invited you to come to Boston and agile and yeah.

Neils Pflaeging: 01:34

Maybe it was this book that inspired you.

Miljan Bajic: 01:35

Yep. Yep, it was.

Neils Pflaeging: 01:37

So I write books. I also with this book, I started designing my own books. So I’m a book designer as well, I am a publisher. And, of course, I was speaking at agile main, that’s how we met. And we have this company sitting in our studio right 42 and we help organizations with transformation. And let’s say, from agile to agility, as it turns on behind you, right? [inaudible 02:03] I’ve been working for that with the beyond budgeting roundtable starting in 2003 till 2007 and then we renamed the whole thing into the beta Codex. And I found that the beta Codex network in 2008. And since then, it has been, I’ve been trying to create with others a movement around organizational transformation.

Miljan Bajic: 02:28

How did you come up with that concept of Beta?

Neils Pflaeging: 02:32

[inaudible 02:33] We picked it up. The beyond budgeting concept, the beyond budgeting model has the same pillars, let’s say. Very similar 12 principles as well. Beta Codex has 12 principles, beyond budgeting always had 12 principles. But the problem with beyond budgeting, the brand is that it suggests so many things that beyond budgeting would never was that we always felt troubled by the brand. So in the beyond budgeting movement, we split in 2007, 2008, we split in two wings, let’s say two movements. That was the time, the opportunity, I saw the opportunity to rebaptise the concept into something that would be more contemporary, less about the roots of where it came from, which was let’s look for alternatives to budgeting and financial steering and control and more towards what do we want to create. And the idea, well, my ex-wife, she had this idea of when she came back working from Google one day and she said; at Google, everything we do is in beta. It’s in perpetual beta. And we picked up the theme that every organization should be in perpetual beta and not static, not command control. So we turned that into the beta codecs. But the idea was already developed in the beyond budgeting days, 1998 to 2003.

Miljan Bajic: 04:07

So I mean, a lot has changed since 98, 2001. I was talking to Daniel Mezick last week and you know, then well, and I mentioned, you know, a lot has changed in the last 20 years, but also a lot has not changed. Like when you look at how organizations operate from an HR perspective on how they operate from a financial perspective, in budgeting, it hasn’t really changed that much. It’s just some of the practices like at the team level, what are your thoughts on that specific…?

Neils Pflaeging: 04:40

Yes, not much has changed and command and control practices have pervaded the last realms where it didn’t exist, for example, hospitals today, management are managed just in the same crazy way as business and in an evil toxic way as businesses. Public services have also become ever more tailorized and contaminated by management practices. So, not all is good. I mean, you are an agilest. I think the Agile movement is decaying as well, let’s say falling back. I read more and more about agile leaders and agile coaches are more pervasive than agile teams these days. So one wonders what is going on and then with the whole scaling movement, I think agile has lost its virginity, it’s spirit, I think. Everything is about, it’s pretty much I think, what I see, what I can see at least. I’m not judging or condemning here, what I see is more and more about command control than it is about liberating software developers from the stranglehold of command and control. So it worries me. But you’re right, other things have changed, like attire has changed so much, right? Business attire. I think vocabulary has changed quite a bit and not just for the better. Yeah, many things have changed.

Miljan Bajic: 06:14

Yeah, you mentioned leaders. I saw in one of your posts, you describe the concept of leaders as bullshit. Could you elaborate on that?

Neils Pflaeging: 06:26

It’s from the dark side. Leaders, the concept of leaders, not leadership, by the way. Leaders, basically we rebaptised bosses into leaders to make it sound, whatever, sexy.

Miljan Bajic: 06:42

Rebranded, yeah.

Neils Pflaeging: 06:42

But the deal about bosses, whenever you say leaders, you mean bosses, right, you mean it. And when you say everybody can become a leader, you mean rising up the hierarchy. So still the old, evil concepts. Which is why we haven’t… I think we would notice advancement in organizations, if we would stop using terms like leaders and bosses and refer to leadership as something that is happening in the space between people and not as something being done by people. And we haven’t reached that level at all. And this is an old claim so don’t get me wrong, I’m not claiming that this is a new, completely new insight. Mary Parker Follett, she complained about that 80, 90 years ago in writing, in crisp writing. All this leadership bullshit, and the bull shit of over fantasizing about leaders at the top has a long history. So which is why it’s hard to overcome it.

Miljan Bajic: 07:44

It is and like a lot of that you talk a lot about systems and a lot of that has to do with systems. And one of the things that you have at least I came up with, I haven’t actually seen it but as I was looking for questions to ask you, I came across the word, the system and not the people. And that resonated with me. Can you talk a little bit more about that and what does that mean to you?

Neils Pflaeging: 08:11

Yes, I think our organizations and also organizations, even organizational research and tools, and so it’s all about correcting people and also, let’s say we are walking a fine line there between blaming people and calling them heroes. It’s all about people, people, people, people, you know. We are over aggrandizing people instead of acknowledging that much of our behavior, yours, mine, as good as anybody else in organizations is about organizational context and systems. So we always behave within context, you know, Even I as a consultant, when I walk into a company, a client company, of course, I start behaving differently, because it’s just like walking through an opera or into a football stadium, we start immediately, start adapting our behaviors. Which is why whenever we observe behavior, in software development or in management or whatever it is on sales, we do not observe the person and the problem is not with being authentic or more purposeful or mindful. Although I think there’s a lot of bullshit narrative going on still in our field. And we should look more about how systems are designed and change the systems we work in. So work systems, the company systems, the way we pay, the way we manage people, or we shouldn’t, of course managed them much less, we should finally get rid of practices like budgeting, fixed targets, bonuses, performance appraisal, the travel policies and much, much more even sales departments and key accounting. I would say that and I have often said this. I think even the position defined, let’s say, definitions of positions like agile coaches is doing more harm than good.

Miljan Bajic: 10:08

I would agree.

Neils Pflaeging: 10:09

Because it creates the illusion that agile is being done by agile coaches, which is not and it is not supposed to be like that.

Miljan Bajic: 10:15

Exactly. And I think it’s like at least I see the same thing in the industry done, right? That there is that and it is more about here’s somebody is going to come and transform us. And companies are not really taking a hard look, even at systems. You know, I work a lot with organizations and most of the people that should know how to influence, how to create systems in organizations have no clue and somehow, over the years, they’ve moved up the ranks and nothing bad with that, it’s just natural, but what I find is that they really are not fit for the job. And they’re too busy, the system is also forcing them to be too busy to not even understand what they need to know.

Neils Pflaeging: 11:05

Yes, I would like to say that I see the problem less than people and managers, I see the problem more in we are really not taking care of organizational science. For example, culture. I mean, you are in the US, I’m in Germany here, culture, I think it’s a topic now worldwide and it was popularized by great people like Ed Shine and so on who I deeply respect. However, this confusion around what culture is that it is supposedly is something that dominates organization, culture doesn’t have that, it doesn’t dominate. However, organizational culture has the power to absorb you and make you blind for even the most fundamental organizational phenomena. After a while working in an organization for example, you become blind for how ridiculous certain decision making processes are, how ridiculous certain rules are…

Miljan Bajic: 12:00

Like annual reviews?

Neils Pflaeging: 12:03

Exactly. And you consider it normal after a while you know, exactly. So, that is a byproduct of organization is that organizations produce culture, which is what is perceived as normal. It is not something that dominates us. But it makes us think that oh, this is normal. In our organization, this is what we sometimes call it the status quo, which is ridiculous as well. But when we call it, it’s better to call it culture. The culture is what we perceive as normal. And so, in a way, culture is like the Borg from Star Trek. It absorbs us, it has the power of persuading us that things are normal. So it becomes harder to work the system because we considered all normal, for example, consider it normal, that there are agile coaches around after a while. We consider it normal that there are bonus systems, we consider it normal that they are fixed targets or that there is a travel policy, or that there are 17 layers of hierarchy. None of that is normal. Those are apparent byproducts of two command and control systems. And in order to break up the systems or transform them, we first have to become philosophers I think. Maybe this makes the philosophy of work the system clear. We have to learn to observe systems to change for some to flip them into another state. Get rid of [inaudible 13:23]. Doing organizational hygiene, you know, get rid of the travel policy, get rid of the performance appraisal, all those are flip means flipping the system and then something different becomes normal. A good example for how culture absorbs us is that today in Germany, gay marriage is considered totally normal. 20 years ago, it wasn’t because it wasn’t the law. So once we change the law and flipped the system, other things become normal. I mean few people in Germany would even consider going back to forbidding gay marriage, it’s normal. Culture has this effect. It’s beautiful. Sometimes we look back at history and think, what did we do? Just like that in organizations, some distances needed to see the problems as they are.

Miljan Bajic: 14:11

Yeah, so that’s really interesting, just made me think of like, how culture and mindset are your culture? Like, if you think about it, that the collective level, but mindset is also I mean, it’s almost like we lie to ourselves, right? Oh, we have certain beliefs and those beliefs, you know, could be true for us right now, but different. What is your take on the mindset? How would you look at it and how much to does mindset need to evolve or perspective that we’re looking through needs to evolve and change?

Neils Pflaeging: 14:44

I think mindsets do not even exist. You do not have a mindset; I don’t have a mindset and we certainly do not have a shared mindset. You have your concepts, your theories, your beliefs, and I have mine and you have your values, I have mine. The whole notion of mindsets I think it’s hugely overblown. I think that something like the principles of the Agile Manifesto or software development, that is something like a mindset, you know, the principles, I think 15 or so 16, all in all?

Miljan Bajic: 15:15

12 and there are four values. Yeah.

Neils Pflaeging: 15:18

Yeah, okay. Yeah. So that is like a mindset or the principles of the beta Codex, that I think we should call that kind of sets of principles of mindset. Because it’s something that we can swear an oath upon, you know,

Miljan Bajic: 15:31

It’s definitely Yeah. Yeah, definitely. I mean, yeah, I agree in to some extent, our values and beliefs and principles define, you know, how we behave. So it’s…

Neils Pflaeging: 15:47

Yeah. It’s very personal, your values are very personal. If I tell you, hey, we have to have shared values. That would be like, a fascist notion, you know? Not good. I want you to have your values, and I have mine and we can fight about it, of course, occasionally, when they stop, because of course, our values and principles are all about ambiguity and about can we still work together even if your values are slightly different than mine? Are we capable of dealing with diversity? That’s a big question. So yeah, all these things, all these fashionable words like mindfulness, mindset, purpose, culture, we have created a lot of, it’s a lot of storms about….

Miljan Bajic: 16:36

Marketing and branding. Yeah, maybe to some extent.

Neils Pflaeging: 16:39

Yeah. A lot of bullshit really. It’s a lot bullshit. In the agile sphere as an organizational development as in lean, or whatever you call it. A lot of bullshit going on. And everybody then tries to do certification course, five-layered certification course around it, right?

Miljan Bajic: 16:54

Blame the PMI for it, right. They, I don’t know, I think.

Neils Pflaeging: 16:58

Yes.

Miljan Bajic: 16:59

Everybody steals PMI’s ideas as far as in it. But you know, the people are, I can’t tell you how many people are coming to my classes, and most of them are just coming for certification. And, you know, I was talking to somebody else doing that. They said, that’s it. You know, if you think of history management, and you’ve talked about history, and, you know, 20 years, what has happened last 20 years is not a lot of time. So like all this crap that’s happening and things that we’re seeing is, you know, what possibly more of doing agile rather than being agile is just part of the course. Do you believe that or what are your thoughts on that? Like, just that a lot has happened in 20 years, as we said, you know, some of the things didn’t change. But if you look at 20 years is not a lot in the grand scheme of things.

Neils Pflaeging: 17:49

Yes. You interviewed Daniel Mezick recently….you know.

Miljan Bajic: 17:55

Yes, Bias Mayer, yeah and a couple others as I’m starting this, so yeah…

Neils Pflaeging: 17:58

That’s a good thing by the way. Thank for starting this. What Daniel and I have in common is that we share an interest in how to develop organizations and not just have agile practices or some Scrum practices in teams. What we really care about how to make organizations you know, transform substantially, like have this kind of systems change, you know, of which, of course, Scrum practices and patterns, and so on, are part.

Miljan Bajic: 18:31

Part of that, yeah.

Neils Pflaeging: 18:33

And quite frankly, too few agilist I think, have become honestly interested in organizational development or change or the psychology of change. And there’s a huge gap. So when we try to make Scrum happen, or agile practices happen, often we do it with coercion and force, brute force. Yeah, or we try to convince others, which is already a ridiculous notion, because you can never convince people of anything. So the really, of course, I very much believe in the overall proposition of the Agile movement, of the Agile Manifesto, if I’m going to call it like that or in Scrum, I believe that it has the say, the right, it’s the right direction. It’s of course, about creating practices that are much more robust in complexity and much more fit for software development. That is all. That is unquestioned, I think. However, the way, how to bring it about, how to Scrum about, how to bring an agile organization about. There’s a lot of crime going on and in my personal opinion, all those scale frameworks are the same. They do not lead us anywhere good. Of course [inaudible 19:51]. Which is why Dan and I are suggesting approaches that are more let’s say holistic or whole [inaudible 20:02]. Well, organic based on invitation, based on people’s liberty to design their own organizations to transform their own organizations instead of having armies of consultants. Yeah, that is why we believe these approaches are liberating and important.

Miljan Bajic: 20:20

So in order to liberate, another thing that I hear you talk about is this, you know, concept of leadership, power and structural change, what are those three words mean to you in the sense of changing the system? How do you…?

Neils Pflaeging: 20:38 are

Yeah, when, again, maybe we didn’t talk quite clearly about it, when you try to change an organization by changing the people, you will never get anywhere, because organizations are not about therapy and they not correction institutions, you know, like prisons. They shouldn’t be. So we should work the system, the context, the environment, like the way we pay people, like the way we promote people, the way we deal with the future, we shouldn’t do planning of course. The we deal with resources. Totally ignored by everybody I know in the Agile movement, nobody cares. Nobody gives a fuck about how resources are. And how our results are measured from a business perspective. There’s a total disinterest in the Agile movement about measuring from a business perspective, from a financial perspective. Sadly, which should be should be completed. In the beta Codecs network, we have a much more, much clearer understanding of that. However, the overall intent of Scrum was never to correct people but to change the system so that people as they are, can do much more in much less time and more economically and get the job done. So work the system, that’s really the future. We have a website, workthesystem.eu as well, which presents approaches like cell structure design, open space data for transformations. What was the question again?

Miljan Bajic: 22:10

That’s tough when we go back to leadership, power and structure, right. Yeah, so it’s like that power, the authority, letting go and like decentralizing right, it’s so tough for people.

Neils Pflaeging: 22:25

Yes, because we have bad theory about leadership, power and structure. Thank you for getting me back on track here. Leadership, power and structure. Whenever we talk about leadership, power and structure, we think about hierarchy, bosses, underlings, Scrum Master at the bottom, we think about those things. Now, that’s something that I can really only recommend all your listeners to check out. About 10 years ago, Sega Hammond and I, we created a concept called arc physics. And I think that is a part of the solution really. Orgphysics says, organizations are bound by natural laws, just like physical laws. We can opinionate about it, but they won’t change, you know, accepting or not accepting, liking or disliking those natural laws won’t change the reality. And the reality of organizations is they don’t have one structure, they don’t have two, they have three structures, three, leadership’s and three…. Let’s say three origins of organizational power. One of course, is hierarchical power, the power of position. I am your boss, I can fire you, I can hire you, I can fire you. And somebody in the organization signs the annual…how is it called? The audit report and so on. That’s formal power. It exists in an organization, this structure exists in every organization in the world. Formal power otherwise, it’s not even an organization. So formal structure in which hierarchy of formal power of position resides, that’s a reality. However, there’s a second structure in formal structure and that is the power of those who are liked.

Miljan Bajic: 24:10

Influence or I guess influence could be through the other, but I think more of the influence comes to that informal.

Neils Pflaeging: 24:18

Exactly that and then on social media, for example, we call influences influences because they have no follow up power. You know, they cannot call us to you know, do something and we cannot resist. No, we can resist, but they can influence us. So, from in social structure, informal structure resides is the power of influence, hierarchy is the power from that resides in formal structure, influence resides in informal structure. Every organization has tool. Now imagine work, you can get work done neither in formal structure or informal structure, you need value creation structure, as we call it. And that is the most interesting, the most unexplored part of orgphysics, because we have a good understanding of hierarchy and organizations and some of influence as well. But value creation, it means that an organization consists of teams that create value for each other, with each other, and ultimately for an external client or the external market. And this….

Miljan Bajic: 25:21

And that, yeah, that goes back to the system. I mean, I see the way that you describing the value structure is the system understanding the system. Yeah.

Neils Pflaeging: 25:28

At the shape of a value system or value creation structure has a center and the periphery and outside there’s a boundary of center periphery, the boundary binds the periphery so to say, it looks like a peach, and then outside is the market. And the periphery should be in charge, which in most organization isn’t. It isn’t the charge. The centers [inaudible 25:50] which is a terrible mistake in complex markets, you know, and this notion that ultimately, if we want to have better performance, there’s no way around improving value creation structure and of course, diminishing formal structure as much as possible. Formal power and formal structure and formal leadership and putting value creation structure first. There is a power that resides in valuation structure, which we might call reputation. Reputation power, the power of those who have mastery. You know, skill.

Miljan Bajic: 26:25

What about the other, so you mentioned leadership power structure, they all have three dimensions kind of to them. What about the other two? Could you talk a little bit about those?

Neils Pflaeging: 26:37

The leadership?

Miljan Bajic: 26:38

The power structure, the power, like what are the three types of power and leadership because the way that…

Neils Pflaeging: 26:44

I think the three types of power or hierarchy, influence and reputation. Three kinds of power in every organization. Hierarchy, influence reputation. Of course, we over accentuate hierarchy. Many of us ignore influence and most organizations have no clue of really what to do with reputation, you know, the power of those who have mastery. Sometimes we then talk over decisions should be made at the frontline or by those who know. We approximate, you know, we find ways of trying to understand value creation structures. But the real thing about value creation structure is you end up, every organization ends up having it in form of a cell structure design, cell structure network thing. So a network of cells or teams that create value with each other for each other, and between teams. Toyota has a very good understanding of this kind of structure, Southwest Airlines, as well as another American company or WLGore. Of course, here in Europe the great companies like Hammonds Bank and DM and so on. They’re great companies that have a great understanding of this but those are the exceptions. And all others. it’s trying to create more value or improve through formal structure, which is really good. Safe, of course, is a great example of a framework that tries to improve agility through fundamentally stacking agile teams, it cannot work.

Miljan Bajic: 28:18

I have been part of several safe, what I call now installations and it just doesn’t work like after, I’ve never seen it work more than two years, or people have to evolve in and change it. It looks nothing like safe if it evolves. Another thing that you said, caught my attention, which is changes, like adding milk to coffee. And your perspective on change is like a lot of things and your perspectives are different. And that resonated with me too when I saw kind of what you thought about that. Could you share with the audience like what you mean by change is like adding milk to coffee?

Neils Pflaeging: 29:10

Yes, that refers to what I said before that we have to become much more knowledgeable about the psychology, the dynamics of change in organizations and how it really happens, we have so much prejudice about it, which expresses itself in metaphors like change is a journey, or there’s so much resistance to change which we may deal in this or that way. Our prejudices about change are so big that we talk of things like status quo and kicking it off and programming it and blueprinting it and structuring it. The whole notion of change management is like real garbage. It’s like really waterfall applied to organizational development. It’s all bloated and busted theory and all the worst theory there is. And of course, all underlaid by a notion the prejudices against human nature, you know, that are negative. We have to motivate people to change that kind of shit. So..

Miljan Bajic: 30:05

Like there’s something wrong with people, like it’s almost like we need to fix them that type of belief. Yeah.

Neils Pflaeging: 30:14

Yes. Just like leadership itself, which often assumes that people are the problem, when we talk about change, usually we assume consciously or unconsciously that people are the problem, which they are usually not, sometimes Yes, because there are assholes in every organization, let’s face that. Assholes exists, I’m not counter arguing against that. And there are people who are sick as well, and so on. So there are many things that exist in organizations. But by and large, people are not the problem, the system is we have created the problem. So, this is how we came up with 10 years ago or so, we figured out that there is a whole, very, very small, there was a small amount of researchers and people who were saying, change, management doesn’t work. For this and that region, resistance to change doesn’t work and change cannot be planned. And we looked very deep into this and figured that normal change is more like a mental coffee. You change when you pour some milk into coffee, it never goes back. It’s forever changed. And it mixes, you don’t know how that will happen. It’s of course, this is just a metaphor, right? So…

Miljan Bajic: 31:27

Yeah, no, it’s simplified but yeah, but it’s kind of, it’s not, in a sense, it’s forced by the system that you create, which will be the I guess the constraints, they will create the cup, and then you know, it’s doing it by itself, even if you don’t steer it, you know, it’s going to mix. So, yeah.

Neils Pflaeging: 31:48

Exactly, which is an interesting, right. Even without stirring within the boundaries, that there are two liquids and they will mix, and you don’t know precisely how they going to mix, that is chaotic actually, to be precise, scientifically is said it’s…

Miljan Bajic: 32:01

From a complexity.

Neils Pflaeging: 32:05

And it can never be repeated just the same way because it’s okay. But you know the end result will be mixed coffee with milk mixed in a cup, you know. So you know, the end result, as so often in chaotic systems, you know, the end result, but the path. And changing organizations is very much like that, we can trigger the change, we can, as we say, flip the system and then observe the consequences and flip again. We can imitate or flip systems, we can, for example, if you take a horrible bank, like Bank of America or so, take out the bonus system, the whole organization will change, you don’t know exactly how, but it will change. If you take out the travel policy and substitute it by a principle, let’s as we deal consciously with all our resources, we protect all our resources, including money and people’s time, things will change. So organizational transformation does not require blueprints, projects, programs or consultants, it requires a consciousness that actual transformation will require 700, or maybe 7000 of those interventions are several 7000 times putting a little milk into the coffee, so to speak. Yeah, little flips. These changes flipping on actually, it happens in organizations all the time. Every organization…

Miljan Bajic: 33:34

This is really like understanding the complexity management and I’m still surprised like how many people are not, especially as I said earlier, like there should understand complexity management, don’t fully understand that because those are like fundamentals of complexity management, like this is not, you know, it’s the basics. So you would think somebody that’s responsible for organizational effectiveness, organizational systems, they would know the basics of the system that they actually part of.

Neils Pflaeging: 34:10

Yeah, then they don’t as most Americans know nothing about America, American culture, because they have never been abroad, they cannot compare. That’s Oscar Wilde, I think said that once. You can only know a culture of your country if you know two.

Miljan Bajic: 34:25

Exactly.

Neils Pflaeging: 34:26

Only if you know two. Just as you grew up in Croatia, and now you live in America, I think you have a fairly good idea about what America is. I lived in Argentina and Brazil, also the US a little bit and Germany and so on. I think I have a fairly good idea about what Brazil is like, many Brazilians don’t. And that’s not because I’m intelligent, it’s just that we are blinded, blindsided by our upbringings and our own history. Again, culture is assimilate strongly, you know. But okay, you said those things should be obvious and they should be, just those notions of change or transformation that we described about, they should be natural. They are not. I think there’s a lot of education lacking, we educate people in the wrong ways about the wrong things. For example, we have leadership development programs, which are just for some, and they just get some knowledge and then they come back to systems that are totally unchanged, and they don’t have a clue how to change it. Also, as Daniel Mezick and I would promote, organizational development, organizational transformation these days should be done by all the willing, so ideally, by everyone together, not by leaders at the top. Because that makes it faster and more, you know, ingrained embedded in the, let’s say in everybody’s mind. So…

Miljan Bajic: 35:52

Yeah, the more people that the [cross-talking 35:54].

Neils Pflaeging: 37:33

More leadership development. I think the solution is less agile coaches, less consultants, like myself, less of us, and less training, conventional training, and more, you know, action research as Kurt Lavine would call it. You know, more working the system together, all at the same time, in a process that, for example, begins in open space and ends in open space as Daniel Mezick and I programmed it.

Miljan Bajic: 36:22

Yeah, and I love that concept. And I think, you know, it’s very hard. It’s simple concept but it’s very hard for people to imagine, like, I think it goes back to that, blind let’s say and cultural like, if you haven’t seen it, if you’ve been part of the open space and part of that concept or just experience, it’s like one of those things, once you see it, you know it and you see, and Dan was actually telling me about one experience with a client where, you know, somebody just showed up to make sure that his boss sees him that he showed up to the open space concept. And then when they actually became part of that, and they saw that they can actually drive the agenda, that they have a say, it was like, I want to be part of this. This is if somebody is actually valuing what I have to say, and that’s liberating in some way. So that was a really good example of, you know, we resist it to where see what it is and then once we actually experienced it, we want more of it. So what do you think? Yeah…

Neils Pflaeging: 37:33

It’s a very nice example of also that you never know when people will have this insight that this is going to be different, we are working the system together, what it means to us, these insights you cannot command them, of course, they come when they come and that’s often-surprising moments and surprising interventions or interactions.

Miljan Bajic: 37:56

Do you have any stories like that? Like, what’s the craziest, most messed up thing maybe you heard a client have done or any stories that you share over the years that you think people would enjoy hearing?

Neils Pflaeging: 38:11

I can only, well, there are so many things, because I’ve done this for 17 years. And when we found out about Daniel Mezick’s approach, open space agility, that was only three years ago, in May. By the way, the magic moment happened in Portland, Maine, that we figured out Oh shit, we could instead of just to agility with this approach, we could transform entire organizations. That was the starting point of open space, the open space-beta approach. This is just a book, you don’t have to read it if you don’t like this. A lot of it online. But this notion of transforming organizations fast, that was a shock, came as a shock to me, because I had worked for 15 years by using other approaches like William Bridges was influential in my work, he wrote a book called Managing Transitions which is about the neutral zone that we must set through to learn the new. We use the John Cutter approach, leading change or change leadership. So we put a lot of change approaches together. But then when we found this approach, okay beginning with everyone, you know, just invite everyone to do an open space thing and do the change, do the transformation work together for 90 days and then close it, let’s say to time box transformation, that it flabbergast. And of course, we did this with a couple of companies already and even the sponsor, which is one person in every organization, client organization, organization undergoing the transformation, the way the sponsor evolves throughout these let’s say, last six months all in all of transformation, that such as open space beta chapter takes that has, it’s truly flabbergasting. It’s shocking.

Miljan Bajic: 40:14

You open up any possibility, right? It’s like people almost, you know, it’s nice to see leaders open it up. It’s almost like you know, anybody has a say, anybody’s like everybody’s equal. And it can be liberating. I mean, like, if you’re in a system that’s constantly saying, shut the fuck up and do your job and then all of a sudden, you know, you actually can have a say, in what happens is others can say; yeah, I believe in that and you know, I want to do that and I want to do that, versus you know, what I’m being told. That’s liberating.

Neils Pflaeging: 40:55

Yes, exactly. Those people inviting everyone to do this together, they learn the most, that’s what we found and they come out of this transformed because they…

Miljan Bajic: 41:12

The system is messing them up, too, right? So, you know, it’s liberating. I know, when I talk to people, they want to change the leadership, but it’s also the system is forcing them to accept ways. I remember one guy told me, you know, I was talking about exactly that, like, you know, just letting go. So the authority letting go and when you have incentives and bonuses died at the end of the year, with wrong, encouraging wrong type of behavior, they essentially came to me and said, Miljan, what do you want me to do? It’s between, you know, paying for my kids’ college, or doing the right thing in the company, what do you think I’m going to do?

Neils Pflaeging: 41:55

One through the other, both.

Miljan Bajic: 41:58

Well, a lot of times making decision and doing the right decision will not get you the bonus. And if 20% of my bonus, which is the policy within the system, then I’m going to make sure that I get the money, even though I disagree with, you know, how that might impact the organization long term or how it might impact the people in the organization because it’s first you know, my family over the organization. But the system, the policy itself is forcing the person to act that way or behaved that way.

Neils Pflaeging: 42:37

Every agilist in the world should read a great book about exactly this topic. It’s called Punished by Rewards by an American author, Alfie Cohn, I think he resides in New York, Alfie Kohn. Punished by rewards from the 1990s, I think. Excellent book about why, of course, all incentives or bonuses are toxic to not just to…they damage performance as well and they damaged human motivation. In that book, beautifully as you have children, I’ve grown kids, it also outlines why tests, of course, and judging people’s performance or behavior is totally destructive. Yeah. So those are the basics, I think every agilest should read those books. On Beta-Codexorg, we have a whole reading list, a list of I think, 70 books, and all very worthwhile from the trivial, from the beautifully trivial, like Austin Kleon’s Steal Like An Artist. Do you know that? Steal Like An Artist? Great book by American.

Miljan Bajic: 43:41

I’ll check it out, too and I’ll leave the link in the description below so people can easily access it.

Neils Pflaeging: 43:50

So we have all kinds of great books, including, of course, books by Daniel Mezick and myself, but starting with, you know, stuff about organization development systems theory and so on. So yeah…

Miljan Bajic: 44:02

By the way, yeah, I love the, like it and you spoke about it earlier, about design of the book. I love the simplicity of your books, both Dan’s and yours, especially the last. Well, the first one got me interested, really in, you know, how I kind of get in touch with you years ago, but the simplicity of it and the way that you’re raised and explain the concept, I think is it’s not an easy thing. People think it’s probably an easy, but I know that’s the probably the hardest part. How do you explain these complex concepts in a way that people can resonate? Is that your experience or maybe it comes easy to you? I’m not sure.

Neils Pflaeging: 44:48

Well, I take years and years to figure out ways of saying things easier in my books. And but ultimately, I think this goes back to an old Einstein quote.

Miljan Bajic: 45:05

It’s something along the lines, if you can understand it or explain it in simple words, you don’t understand the concept or something like that.

Neils Pflaeging: 45:15

Exactly. And sometimes when people talk about agile or complex systems, it sounds like Okay, do I have to have a PhD for this? And that just means that the so called expert doesn’t know shit about it, or what it means in practice. I think systems theory or complexity phenomenon, in one of our books, we like to talk about the difference between the complicated and the complex, the blue and the red, you know. Every 14-year-old or 15-year-old should learn about this and understand it and wrap their heads around it. It’s not you know, rocket science as they say. Those concepts I think everybody should know them and everybody can know them and they are not banal. Because in the way those things [inaudible 46:05] organizations and collaboration, they’re not banal. For example, the power of time boxing, I think that’s one of the most beautiful things in Scrum. Timeboxing is a beautiful concept but to understand it clearly why is that? Why the sprint? And so many people talk badly about Sprint’s, I don’t see it. I think timeboxing is a beautiful idea. Philosophically, especially, you know, the notion of time, is something that easily slips away in organizational day to day activities.

Miljan Bajic: 46:35

So Daniel and I talked about and just because I think talking to both of you, understanding both of you, we have a lot in common. And the reason I started this podcast is really, to bring attention to what I believe is, you know, agility or what comes after the so much focus and agile with a big A, and understanding these patterns and I spoke with Dan and I agreed with him and it’s the next phase of this is understanding patterns like you said and understanding these, like, why do you do time boxing? It’s not like, oh, the scrum says on page 10, you know, timeboxing so I’m going to do timeboxing. And I use the example of cooks and chefs. Like chefs know ingredients at the chemical level. They know, like, if I throw this thing with this, or if I have these ingredients, I know what I can make out of it. Right? And the cooks just blindly, most of the cooks and I actually wrote an article on this on a spectrum from cooks by the book to cooks, with the unique style, cooks with innovations, and then chefs. But in organizations, we have a lot of cooks that just follow recipes blindly. And this is like following a framework like Scrum, without understanding for instance, why do you have timeboxing? Why do you have a role of a product owner Scrum Master developers. And in my gut feeling, I think the next 20 years or the last 10 years, were all about big agile and these big scaling frameworks, the next 20 years will be about understanding the patterns, understanding the complexity, management and coming up with unique recipes. Because I’ve never seen organization just blindly apply any framework and be able to do it. It’s only they have to create their own recipes with their own cooks and chefs, rather than Hey, Miljan, come in as a perceived chef and tell us what to do. So what do you think? What do you think, what comes after agile? What is the, I know, it’s hard, obviously, to predict, but what do you think the next 20 years will be about? Or at least then.

Neils Pflaeging: 48:59

Yeah, I think there’s two big topics or two big issues in this. I think what you just described relates to the tools for toolhead problem. Which every consultant, I’m a consultant, I think you should be classified as a consultant as well. And of course, when our clients come up to us, they tell us what they want. Yeah, for example, I want [unsure 49:25] or I want scrum or I want safe or I want less. They tell us what they want or maybe they say I want Lego serious play, I don’t know, all kinds of shit you know. They want all kinds of shit. And what a consultant should always reply is, No, you don’t. A real consultants doesn’t say yes, I’m selling you the shit. A real consultant says No, you don’t. First you want to understand your problem, If you had understood your problem, you wouldn’t beg me for tool or whatever hype shit. So I think we must, this is one of the problems in our industry. But let’s go back to really advising our clients instead of just selling tools, you know, certification, certification product, product, Product, Software, software, license, license, days, days of agile cultures you know. It’s very easy of course to sell products, but it is evil, I think. We must help our clients understand their problems better, you know, we must be more of an organization of philosophers for them or you know, help them become their own philosophers in their own…

Miljan Bajic: 50:32

Exactly, the way that they’ll build on the analogy they use. It’s like, we need to help clients develop their own cooks and chefs, rather than relying consultants to give them recipes, because you work with probably big consulting companies, you work to, you know, they give you a playbook, they give you and they’re like, here you go, here’s your recipe, and good luck, even though your ingredients change, and you don’t know what the heck you’re doing, good luck, because we’ve taken your money, and we’re going to move on to the next.

Neils Pflaeging: 51:01

I like to, I recently published a piece about two axes diagrams, and how they tend to confuse people into believing stuff, you know. And of course, all these diagrams are part of the bullshit as well, the tools are, much of the software is applied and then cannot be used because of course, the problems lie elsewhere, not in software or in technology. So I think when one thing that should change, and I’m not sure how it will change, is we should move away from the tool craze, and enough selling tools, tool heads, to go back and actually help solving problems, and that usually means the tools are needed afterwards. Even tight your order from Toyota wanders, I think 40 years ago that never crystallized the thinking into tools, because the tools will be void of the thinking, you know. We shall never do what the Agile movement has been doing since the Agile Manifesto if I may call it that way. So we are all in the wrong packed with tools, overwhelming fascination for tools. Tools are very seductive of course and they’re like heroin for clients and for sellers, of course. However, we can never bring about the great organization transformation or the necessary organizational transformation with tools. So this is like preaching to you. But I mean, I know we are both on board. And we still can make a living, I believe, without selling tools. But the other more important thing for agilist, I think, is the Agile Manifesto. Of course, the real name is manifesto for Agile software development, but let me call it the Agile Manifesto. It was designed to solve an immediate problem in software development, it was never designed to transform organizations. So there are some things that are woefully absent from the Agile Manifesto or even from the scrum Guide, which is also about solving team problems. And I would advocate what comes after agile, of course, agility should come after agile. But to achieve organization wide agility, we need a more robust set of principles, or as we discussed earlier, we need a different mindset, you know, set of principles that reaches economic questions, question of coordination of resources, of how to deal with people’s pay and organization and all that. These principles exist and I know I’m very self-serving here, but the beta Codex is exactly what is needed. I believe that principles of Agile software development plus principles of the beta Codex can consult out of the mess for software companies. For production companies, of course, you need to spice it up a little with Lean principles, principles from Edwards Deming and so on. So the principles are there, they are in Agile, they are in lean, they’re in the beta Codex and I think we must put together finally, and recognize that we should be a united nation of you know, organizational transformers of people striving for agility, however, we might call it.

Miljan Bajic: 54:15

Yeah, and, you know, at least what I’m seeing is in the reason that I invited you to come and share your thoughts is because I think you’re one of those leaders that’s been saying this for years, and I’m seeing more and more people aligning to those principles. And I think it’s a momentum that’s gaining and that’s what I’m seeing is going to slowly start to kind of expose itself and it’s also helping that most of these transformations are unsuccessful. And so people are realizing…

Neils Pflaeging: 54:49

People get tired of the bullshit, right?

Miljan Bajic: 54:51

Yeah. So, it’s like, it’s a wakeup call and people can say you can no longer say let’s do this again, because you know, that hasn’t worked last three times we tried the agile transformation, yeah.

Neils Pflaeging: 55:02

Yes, you’re right. Personally, I would like to spare organizations decades of wasted, you know, transformation, reorganizations consulting projects and that kind of stuff. I would prefer seeing them doing the real stuff, open space, beta open space agility straightaway. That’s what I would like best. But it’s a question of course also of insight. And I think it’s very seductive to believe that consultants will save my problems, tools will save my problems, technology or software will save my problems, very seductive. It is very seductive to believe that by slicing and dicing the organization, I can just transform the slice and little dice or the little slice. Yet software development or production or HR, it’s very seductive. Slicing and dicing does not work. And it’s very hard, I think, it requires some tough reflection to understand that transforming an entire organization might well be more effective and much faster than trying to transform a slice.

Miljan Bajic: 56:14

Yeah. And it also like it, a lot of times they go into organizations, leaders come in, and they don’t have a lot of time. And it is like, in a sense, they’re under pressure to because the system or whatever, you know, in this instance, the board is saying, you have this much time to prove what you can do. And this is what you can do but if you start with those silos, you don’t even have time, you know, in a sense, like, you know, it’s like you’re doomed from the start.

Neils Pflaeging: 56:45

Lack of time is a byproduct or a collateral of an alpha or command control organization.

Miljan Bajic: 56:50

Exactly, exactly.

Neils Pflaeging: 56:51

Because of [inaudible 56:52] the organization to communicate from the top down to the bottom up and left and right, you need to slice your agenda into little slices that are void of thinking at the end, and so on. Which is, for example, why I educate my clients, when they get in touch with me, one of the first thing I educate them is that we don’t have to have a conversation if you have just 30 or 60 minutes. For a good conversation, it takes 90 minutes or more. It’s okay, if it takes more, but not less than 90 minutes. It’s something that a good consultant, and I hope if I’m at least becoming one, I think we have to teach this to our clients as well. No, don’t fuck with me with 20 minutes or 30 minutes. No, if we have a real, that’s not a conversation, it’s a throw up.

Miljan Bajic: 57:38

So, I think, what I’m hearing you say is like, we have to have integrity, like as consultants, as coaches like, Yeah. It’s like we have to call the bullshit, we have to be honest with ourselves because we know it, right? A lot of times I’m guilty of it too. You know, like, you know, you’re saying things that they want to hear and you’re adjusting to their system without actually you know, standing your ground and saying, this is kind of what it takes. Do you want to do it or not call me when you’re ready?

Neils Pflaeging: 58:15

Yes. I sometimes tell prospects things like this is what I know what works, I describe and discussed it, you know, if you want to do something fiddling around with it with tools and more consultants, you do it and we will probably be talking again in two years. Yeah, integrity, it’s something that must be…

Miljan Bajic: 58:43

Embraced, right? Or in some way to…

Neils Pflaeging: 58:46

It requires serious stance on what you do and taking yourself seriously. And I think you’re totally right. The agile industry overall, something that Daniel Mezick also criticizes, yeah, we have lost, we have industrialized, we have created an agile industrial complex. The same goes for the agile, the consulting industrial complex and other of these…As individuals, we always must ask ourselves, do I want the easy sell for and am I willing to do the bullshit? And then fool myself that oh Lego series play in the long run, it’s a good thing to transform, you know, it’s not, you know, if you do it at the wrong time, you know, for the cheap sales. And then, of course, there are methods that are far worse than that, and we yeah, we have to be we have to practice integrity.

Roman Pichler

Speaker: Roman Pichler 00:15

Thank you for your questions and thank you for the votes. It seems the top two ones are, what is the best way to define what is a product? And how can you teach the organization, what is a product. And then based on your experience, what are the main challenges product owners have when it comes to stakeholder collaboration and how to solve them? How about if we start with the very first question what a product is? To me, that seems pretty fundamental. I mean, I have to say, I’ve got a product and a product management bias. But even if you don’t work primarily with product people, like I do, if you apply a framework like Scrum, there’s a product backlog. There’s a product increments, and most recently, there’s even a product goal. And of course, there’s a product owner. So, there’s a lot of product. So, it’s worthwhile to reflect on what is a product? How can we define a product? So, let’s start there. And can I share my screen?

Speaker: Miljan Bajic 01:21

You should be able to.

Speaker: Roman Pichler 01:23

Cool, So, hopefully you can see a screen that isn’t too exciting yet. And now a slide that says, AMA, Agile Maine, now product, and I thought I’ll just use my iPad here to visualize some of the ideas that I may be mentioning. So, it’s a little bit more interesting and maybe it’s slightly easier to understand what I’m what I’m trying to communicate. So, what is a product, I like to think of a product as a…, so different people have different definitions of what a product is. But it seems to me that… [I’ll share mine.] So, for me a product is. We have a product here, a product is an asset. And in the context of digital products or software, that will be essentially a piece of code plus, possibly additional artifacts. So, we have an asset. And for these assets to qualify as a product, there has to be a group of beneficiaries. So, it has to be a group of users, or possibly customers. Users are the people who use the product and customers are the people who pay for the product in one way or another.

So, I’m using Microsoft Office PowerPoint here, I’m the user of the product and my business has licensed or subscribed to Microsoft Office. So, my business will be the customer, right? So I’ve got users and customers, and the product has to do a specific job for those individuals, it has to address a specific need, or it has to solve or address a problem or create a specific benefit, or in a another way to put this as it has to allow the users in this case the customers to achieve a specific goal. So there has to be a real reason for people to engage with the product to use the product and to pay for the product. So there has to be a need here. Then you could say that the value that the product creates towards those individuals, towards these users and customers. So, if I wanted to, say create a new Healthy Eating product, then I’d have to think about who would benefit from such a product. And I might decide, I’ll go for people like myself, middle aged men, who may not always have super healthy eating habits, should maybe start to consider changing their eating habits in order to avoid the risk of developing type two diabetes, and that could be the benefit. So, the benefit of using the product might be to reduce the risk of developing type two diabetes, again, it’s very important to be clear on who would use the product, particularly who would use the product and then why would people want to use it? What is the specific value that the product creates for those individuals? But that’s not enough, there has to be something else. For an asset to qualify as a product, it has to also create value towards the business.

And this is meant to be some form of building here. The business or the company, maybe I should have drawn a group of people because really, businesses and companies are a collection of people, of individuals, right? So here, we also need to ensure that the product creates a specific value towards the business. And that might be, for instance, to open up a new revenue stream or to achieve a certain amount or generate a certain amount of revenue within a certain timeframe. Well, you could think about other benefits, such as achieving a profit target, probably for more established older product, or reducing cost, increasing productivity, developing the brand, or helping market and selling other product. So that’ll then depend on what kind of product it is, is it a product that directly generates revenue, then you typically have things like revenue or monthly recurring revenue and profit as key, business goals. So that’s what I should write here… On the right-hand side business goals.

Speaker: Miljan Bajic 05:53

How much do you see… and this is just to build off on the value, what I see is, a lot of times I talked to product owners, and they don’t even know what value is, they don’t know how to define it, they don’t know how to explain it. A lot of times they say, return on investment. So, could you maybe just quickly elaborate on how to help product owners define value for a product? Because I see a lot of product owners and even companies struggling to explain that.

Speaker: Roman Pichler 06:21

Yeah, sure. So, the value should really answer the why question, why is it worthwhile for people to use the product or pay for the product in one way or another? What’s in it for those individuals? And why would your business, why would the company invest in the product? Is it to generate revenue? Is it to support another product or service? Or is it to maybe reduce cost as in the case of a traditional IT product or traditional IT app? And so, the formula that I like to suggest to define what a product is, is the product has to do a good job for the users and possibly the customers, and it has to generate some tangible business value. Now, if you’re interested in some form of the tool, to capture those key pieces of information, you can take a look at my… if I can only find it. Hopefully, it’s not going to take too long, at my product vision board. I don’t know if anybody of you has worked with it. I’ve written too many book posts, I think. Oh, come on. Yeah, this one will do. So, okay, that’s a sampled one. So here you go. So, you can use this little structure here, it’s just one way to capture the needs and the business goals. And, you have the vision at the top, which is the positive change that the production created a purpose of a product. And then you have the target group, those are the beneficiaries, the customers and users the needs, again, focusing on the main problem, or the main benefit, or the main job, the primary job that the production do for the users.

And then the product itself, and it’s a key feature that make it stand out, make it special in one way or another. And then the business goals. So that can be a helpful template, a helpful structure to clarify your thoughts and describe the product and describe the beneficiaries and the value it creates. And the trick here is the key point is really to be specific. And if I say, well, my healthy eating product should help people eat more healthily, which is like, well, I’ve just restated the vision. That’s not specific enough, it has to be so specific that I can test, that I can find out if that benefit is truly desirable or if that problem really is significant enough so that people do want to have it addressed. Similarly, with the business goals, they have to be specific as well.

It can be nice to try and make them measurable, but at least they have to be specific. And so, in addition to being able to validate my ideas, I’m also in a position to choose the right metrics or KPIs key performance indicators, and measure how much value my product creates. But again, for me, it really starts with saying, who are the beneficiaries, the users and customers? What Problem does my product solve for those individuals? Which benefit does it create? What is the value? What are the benefits that my product offers to the business? Yeah. It’s a worthwhile exercise, particularly as products change over the life products grow, if they’re successful. And then sometimes what happens is that they grow so big that it’s time to break them up.

Think of those of you who are OS Mac users, Apple users, Apple… fairly recently, I think that was 2019 Finally, unbundled the iTunes app that had grown so much over the years from essentially the ability to purchase digital music online and then download it onto an iPod to all sorts of things, managing videos and reading Apple books and administering your iPhone, and it’s just grew so big. And then finally Apple spun off three or divided it into three new products. I think TV, podcasts and music. So, in that case, you have a product that has changed, that has been split into three, and sometimes companies do unbundle knot… so I’ll leave it there.

Speaker: Miljan Bajic 10:39

Yeah, no, I think it’s great. And Roman, you and I talked about timeboxing these, and it’s been roughly about 10 minutes. So, do you want me just to remind you, or probably I don’t want to rush through these, but…

Speaker: Roman Pichler 10:50

Cool. So, I hope that was useful. Now, the next question, I think was about, oh! I’m looking at the wrong screen. The next question was about main challenges product owners have when it comes to stakeholder collaboration, and how can you solve them? So I think in an Agile context, we’d really like to encourage stakeholders, and by stakeholders… my understanding of stakeholders is that these will be people from within the business, so, for commercial revenue generating product, a stakeholder might be somebody from marketing, it might be a sales rep, it might be somebody from supports, possibly operations, or maybe finance depending on the type of product that we have. So obviously, in an Agile context, we’d like to encourage close collaboration.

Now, if that’s what we’d like to do, and then the question is, and I think for product owner, that is, okay. Yeah. We’d like to encourage close collaboration and the question is, how can we achieve this? And what can go wrong? And so, for me one of the key gradients in order to enable effective collaboration is to build trust. So, for me if I think of collaboration, I think about trust, if there is not sufficient trust, then it’s hard to collaborate, right? So if I don’t trust another person, if I don’t have faith in the other person, if I don’t believe that the other person watches out for me, or at least doesn’t want to cause me any harm or disadvantage, then it’s difficult to be open, it’s difficult to trust the other person, it’s difficult to speak my mind. And it’s difficult to… in a way, be willing to rely on the other person, open up to the individual. So, whenever you experience any collaboration issues, my first question would be, is there a trust issue? And if it is a trust issue… if there is some form of trust, that’s lacking? Then the follow up question will be, how can we build that trust, and so there a number of things you can do in order to build trust, [just looking for a nice color to use.] The first one is to get to know people. And I think that’s very worthwhile, particularly for product owners, who have just started to work with a group of stakeholders to get to know the individuals and make time for them. And we’re all influenced by our backgrounds, and by our personal situation, our family situation.

So, it’s interesting to learn about people find out about people because that sometimes explains a behavior that people that people show you. I remember being in a meeting a while back, and one of the attendees just was just going off on tangents all the time. And I thought it was extremely difficult meeting and I was getting increasingly impatient in a way, agitated and frustrated and didn’t quite know what to do. And only afterwards, I found out that the person was going through a particularly difficult stage in her divorce. And, that allowed me then to empathize with her and I felt a little bit guilty for having unkind thoughts about her being like, “oh, man, you know, just wish she shut up. Can we just get over things?”

Speaker: Miljan Bajic 14:50

It’s really about that empathy. We talk, especially in product ownership. I know you’ve talked about it. It’s empathizing and trying to look through other people’s eyes and see what’s going on versus just…

Speaker: Roman Pichler 15:02

Thank you. So, I think it’s easier to empathize with people, if we get to know people a little bit, it’s easier then to understand people, right. And in order to be able to empathize and get to know people, it’s good to listen, listen attentively and listen with an open mind. And even if a stakeholder makes a suggestion, or requests a feature piece of functionality, which we disagree with, then I think it’s still worthwhile listening attentively, or trying to listen attentively. And being open minded, at least initially not judging too quickly, because first of all, maybe the feature really is a good idea. And we’re just biased and think, oh, no, it can’t be. But after a little bit of consideration, we discover Yes, we should definitely take on board that feature and get it implemented as soon as we can. But even if that’s not the case, then by attentively listening to somebody, we show the person that we care, that we value the person’s perspective and contribution, and that builds trust. So those are…

Speaker: Miljan Bajic 16:15

What about your tools, for instance, I’ve used the gold roadmap and other things that you do, to help in that collaboration. A lot of this is soft skills, I found a lot of times using some…, other tools, like story mapping, but some of your tools that you’ve shared with the community, those are really good to communicate and collaborate with the stakeholders. So, I don’t know if you want to highlight some of those and how you have used those to help with collaboration with the stakeholders.

Speaker: Roman Pichler 16:46

Thank you, thanks for suggesting that. So, I’m jotting down joint decision making and planning. I think that’s another great way to very practically collaborate with stakeholders and users, and the number of tools you can apply. I mean, it starts with coming up with a shared product, vision and strategy, so you can use the product vision board, structure that I showed you earlier, if you’d like to. And I’m a big fan of translating a higher-level vision into a more tangible product roadmap. And I like to work with outcome based or goal-oriented product roadmaps that contain product goals.

I think we’ve got a question about product goals and I’m not sure how high up it is here in this fight, how many votes it attracted. But the idea with a protocol is… well, at least that’s my interpretation, it’s a specific measurable benefit or outcome that product should create. And I like to suggest sort of in the next three months or so, and so having a shared vision, having a shared strategy, and having a product roadmap that describes how the product is likely to develop and grow. [Let me just quickly see if I can find a sample product roadmap so I can visualize what I’m talking about. Scroll down a little bit again.] So here is a template, again, one of those little templates that I’ve created over the years, that you might want to consider using. And as you can see, the goal is here in the middle. And that’s the desired outcome that should be achieved. And so, a great way to collaborate with the stakeholders is to agree on specific measurable benefits, product goals, outcomes that your product should create over the next 12 months.

And that can then really help align people, it can help people work together, you don’t want to be in a situation where the stakeholders go off and everybody does her or his own thing. They do their own thing. And then, the marketing strategy in the marketing collateral doesn’t fit and the sales collateral, and the sales strategy doesn’t fit and so forth. And the training material that was created for the service guys doesn’t fit because everybody was doing their own thing, right? So, we need integration, we need an alignment, but at the same time, we want to enable people to work autonomously, as product owners, we don’t have the time. And often we don’t have the expertise to essentially tell people what to do or babysit people. We’ve got a job to do ourselves. So, for me working with those types of goals, strikes the balance and it achieves that alignment and at the same time, the necessary level of autonomy. Yeah. So, having the…

Speaker: Miljan Bajic 19:54

It’s also level I think, one of the things that I’ve seen in the feedback that I’ve gotten from stakeholders is that… especially with the roadmap, product roadmap is that it’s at the right level for the stakeholders, a lot of times, and it’s easy to communicate, and it’s easy for them to see as it evolves and changes. So…

Speaker: Roman Pichler 20:15

That’s great to hear, thank you for sharing. So, from the product backlog is just a little bit too detailed. And the rate of change can be too high for stakeholders to truly understanding and work with it. So that’s why I think it can be really helpful to complement it with a product roadmap. And I mean, if you want to work with product goals, and in the latest version of the Scrum Guide has introduced the concept of a product goals, then you can put your product goals on the product roadmap, and then just simply copy them into your backlog. So, I find that quite handy. So, workshops, joint decision making, planning, and I should maybe also say, review meetings. And that can be really powerful.

Speaker: Miljan Bajic 21:03

How about we move? It’s been another 10 minutes. And I think it’ll be good to maybe shift to the third, that one had seven votes, unique quotes. And the question is, would you recommend breaking out Agile teams into support and new development?

Speaker: Roman Pichler 21:22

Generally speaking, no. Unless these teams are virtual teams, in the following sense. And there is a…, [I think I’ve got an article about this somewhere. So, I’ll see if I can find it quickly, because it has a picture that I’d like to show. We’ll see. Actually, that’s probably under a different category.]

Speaker: Miljan Bajic 21:54

Maybe while you’re looking for that, in a lot of times what I’ve seen, it’s like creating a JV team, support team and new development, your varsity team, what we call it here. And there are some pros and are some challenges, but I agree with you, it’s much better if it’s jointed, so it looks like you have your stuff. So…

Speaker: Roman Pichler 22:19

That’s right. So, the drawback of working with as a separate in a way development team and support team is that… in my experience, it can create a two-class society in the sense that, nobody really wants to be on the support team and do the more difficult bug fixing, maintenance tasks. Everybody would like to be on the feature team, where you get to implement cool new functionality, and it’s exciting and interesting. And I’ve also experienced that the setup can lead people who develop new functionality to have a slightly sloppy approach when it comes software quality, because, they don’t have to fix the box, somebody else will sort out the issues. And that can then lead to software that isn’t as good as it could and should be. So the picture here suggests that, if you have a lot of technical debt, or you have a lot of bugs, you have a lot of maintenance work, then one way to deal with it, rather than having separate teams is that you still have one team or a number of teams who look after a product.

But then teams have volunteers and two or three people per sprint from each team volunteer, to do the maintenance work, to do to support work, to do the bug fixing work. And then in at the end of the sprint, new people volunteer. And so that way the majority of the people can focus on enhancing features or developing new features. And not disturbed by having to do support maintenance, bug fixing work. And so, you have dedicated people who can take this on, but you avoid the drawbacks that I mentioned earlier, the loss of kind of accountability for substandard software. And also, the being stuck on a team and doing work that I don’t really find particularly motivating and interesting. Yeah. So maybe something to consider.

Speaker: Miljan Bajic 24:37

Great! I’m thinking about jumping one ahead, and then we’ll come back to the other one. This one comes up a lot. What’s the difference in Agile between a product owner and a product manager? Should always be one person. This question comes a lot in my classes, too. And I think it would be good if we could hear your opinion then this.

Speaker: Roman Pichler 25:01

Yeah, sure. So, when I started working in a way properly with Agile practices, the people who I was working with were product managers. And then when I introduced Scrum for the first time, again, the people who would act as product owners were mainly product managers. So, for me, I’ve always looked at a product owner in Scrum, the Scrum Product Owner is essentially, the Agile product manager. And I find it interesting that when you look at the scrum history, before Ken Schreiber, who mainly coined the Scrum terms, choice to term product owner, he actually used the term Product Manager for the role. Now, some people may say, Well, come on, why did he then change his mind, but I think one of the reasons for calling the Product Manager, Product owner is that, particularly in an Agile context where there is so much collaboration, but we value collaboration, we talked about collaboration earlier, right. And we’d like to encourage collaboration, we’d like to involve the stakeholders and the development team members in the decision-making process. So, we’ve got all these collaborations going on, where you we have to make sure that if people can’t agree, if people can’t reach consensus within a realistic timeframe, there’s a person who can make a decision and move the process forward and progress the product.

Now that person in Scrum is called the Product Owner. So maybe one way to continue the discussion is to look at this little picture here. So, what you see is a simplified version of my cones planning onions. So, I’ve simply distinguished between vision, strategy and tactics vision as the purpose of our product strategy is how do we get there. That’s the general path that we’ve chosen tactics, then are the specific steps along the path, you can think of the user stories and epics or the good stuff in the product backlog. Now, in Scrum, that’s my perspective, a Scrum Product Owner has full stack ownership, and should own the product in its entirety. For me, the Scrum Product Owner is very much an Agile product manager. However, other Agile frameworks have a different perspective on this. So, if you look at Safe, there’s also a product owner, but in Safe the product owner, and that’s my understanding of the role is mainly a tactical role. So, a Safe product owner would work with one or more development teams and take responsibility, take charge of part of the product backlog, I think in Safe it’s called a team backlog.

So, it’s more a tactical person, more of an inward focused person or role, I should say. It has partial ownership of the product. And then there is a Safe product manager who owns the strategic part and make strategic decisions and is more outward facing and understand the market and the market trends and measure the product performance using KPIs and review the strategy and maybe work with a product roadmap, if that is appropriate. So essentially, what the scaling framework has done in order to facilitate scaling is, it has taken the Scrum Product Owner role and split it into two roles. Now, that’s one way how you can scale and, certain circumstances that can make a lot of sense, particularly when your product has reached a certain stability and the strategy isn’t too volatile. So typically, that’s the case in maturity and decline if you’re familiar with the product lifecycle model. But what it has done is, it has created even more confusion in the community and generally, in businesses what it means to be a product owner.

Speaker: Miljan Bajic 29:01

… authority level, for instance, what I see is… what you’ve shown here, Safe Product Manager, which again, I’m not a big fan of safe, but you also see an another is just named differently, like Chief Product Owner and then product proponent down below, but it really has to do with authority level, right?

Speaker: Roman Pichler 29:19

It has to do with the decision making. Maybe, some of you’ve seen this little diagram here that I created a while back. And so, the idea really is just to illustrate different types of ownership. So that’s why it’s called six types of owners or Scrum Product Owner owns the product. And then if a person looks after product capability and major features, say the ability to… you go to an online retailer’s website like Amazon, the ability to look for a product on the Amazon web page for me is a feature or component, somebody who looks after payment. The payment system, there will be a component owner. That’s at least the terms that I like to use. We have the Safe product owner who takes care of the tactical decisions for a given product. And then, we have two products here, they may use similar services.

So, we may want to take them out and encapsulate them, extract them into a platform. And then we have a platform owner in platform owners, like a Scrum Product Owner only looks after an internal technical product, right? Now we have a little portfolio and sometimes it makes sense then to have a product portfolio owner. And as we’ve just heard, all these owners, they have ownership, but to a different level. So, their level of decision-making authority in their responsibility and accountability will vary. So, product portfolio owners’ job is to maximize the value of a group of products. A good example of a product portfolio might be Microsoft Office, with PowerPoint, word and Excel is the traditional members, job of a Scrum Product owners to maximize the value of the product, job of a feature owner is to maximize the value of the feature, I think it’s just important to be clear on, if you have a product role, what is your responsibility? And what is your decision-making authority.

And I generally tend to recommend to my clients to either choose the term product owner or product manager, I find that it can create a lot of confusion and organization uses both uses both terms. I’ve worked with businesses where the product managers were desperate to become these hip, new, trendy Agile product owners, when I’ve worked with companies where the product owners, they couldn’t wait to become product managers and grow up and finally make important product decisions. And that was seen as a positive career move. So, it can create quite a lot of division. And in I think that’s not that’s not desirable. So, my suggestion, again, is use either product manager, product owner. And then maybe you have a feature manager or feature owner, for instance, if you want to follow my model here, when you can have senior and junior product people, senior and junior product owners or product managers. But again, I think that just limits the confusion, at least a certain extent.

Speaker: Miljan Bajic 32:19

And someone’s like, depends on your organizational governance design structure. So that’s going to influence a lot. How about, let’s move on, we have about maybe 20 minutes left, just a little shy of that if we move to the next question, which I also think is something that’s pretty common, and I hear often, how can I get my team to write stories instead of relying on me or another person as their scribe?

Speaker: Roman Pichler 32:50

That’s a great question. And so, for me, the trick is a to a certain extent, empower your team to take that ownership into… [you won’t believe it, there’s another picture that I have that I’d like to show you quickly. Quick is relative, you here we go.] So, I sometimes find that product owners and product people think they have to feed their development teams with detailed user stories or requirements, essentially, forever. And while sometimes that’s true, when you work with a new development team, a team where people don’t have much knowledge about the market, the domain, the users, the product competitors, that will benefit from detailed requirements.

And same thing is true when people haven’t worked with Agile practices. And people are more used to the traditional setting, where you use a well a traditional detailed requirements specification. So then people will ask for those detailed user stories, those detailed requirements, and initially that can make sense to create them. But if you do that, I’d suggest that you create them together. So, product backlog, refinement, product backlog work, should be a joint responsibility. So here on this diagram, it’s written between the product owner and the development team. And that you actively transfer knowledge from yourself as the product owner, you try to actively transfer knowledge into the development team, and try and educate people about the market, the domain, the users and customers and so forth. One way to do this is to take some of the people along when you carry out some form of user research. So, when you interview people when you observe people, when you talk to customers and users, be it current customers and users or prospective customers and users, another way to do this is to make sure that the development team members are present when a sprint review takes place.

So, they can directly hear, at least from selected users and customers, depending on the solution validation technique that you use, about how well the product works for them, and listen to the feedback. So, it’s about actively transferring that knowledge, which, in the short term may be more work. But in the long term, should enable the development team to become more self-sufficient, and take on the job of at least writing detail user stories. So not to just suggesting this, that as a product owner, as the person in charge of the product, you should not be involved in the product backlog work. But I don’t think that you necessarily have write every single, detailed user story and you don’t necessarily have to forever detail the user stories or create super detailed and specked out user stories. In fact, that was never the intention with user stories, the user, the intention with the user stories was that they would essentially capture the conversation or the essence of a conversation. So, it’s really about developing a shared understanding, it’s really about the communication piece.

Speaker: Miljan Bajic 36:14

A lot of people, if we just go back a little bit, a lot of people, you mentioned customers and users. And a lot of times people don’t fully know the difference between customers and users. And I have my own way of explaining. But I’d be interested to see how do you typically explain what’s the difference between a customer and a user?

Speaker: Roman Pichler 36:34

So, I think I touched upon it. Earlier, when we talked about what is a product user is somebody who uses the product, employs it’s. I was using Microsoft Office just a minute ago, Microsoft PowerPoint, I’m the user and then customer is the person who pays for the product in one way or another. So, the example I gave earlier is that my business has subscribed to Microsoft Office. So, my business will be the customer. And sometimes customers have different perspectives and needs and ideas from users and vice versa.

Speaker: Miljan Bajic 37:05

And sometimes one can become another, the example that I use if I’m buying a bike for my four-year-old son, who’s the customer, who’s the user? His son is the customer, I’m the user.

Speaker: Roman Pichler 37:21

Unless you decide to give it a go and you will see if it’s a..

Speaker: Miljan Bajic 37:24

Sorry, it’s the other way around, right? Yeah. So, my son is the user, I’m the customer but if I’m buying a bike for myself, I’m both customer and user and my wife is the stakeholder. So that’s another way you can look at how things… a user sometimes is both customer and user, and sometimes it’s different, so…

Speaker: Roman Pichler 37:51

So, try and really transfer that knowledge into the team and enable the team. And at the same time, I think you should also be able to expect that your team is willing to support you, and certainly support you in identifying and capturing user stories that should be a truly joined responsibility if and it should be truly, a form of teamwork. And if that’s not the case, then I would suggest that you talk about it in one of the upcoming retrospectives. And also, maybe secure the necessary support from your scrum master or Agile coach.

Speaker: Miljan Bajic 38:30

So, here’s an idea Roman, I’ve done this in the past, but we have 10 minutes. And a lot of times people have these questions. So, if we limit it to 30 seconds, quick Roman’s responses to these Would you be open maybe instead of diving deeper into one just going broader? And answering some of these? So just pick and choose some of these questions in 30 seconds or less, just maybe give us some answers. But I think given that there were a lot of votes, at least those individuals that wanted to and this is probably one of the few opportunities that they will get a chance to get your opinion on it. Just give them a quick answer. Maybe you can for some of these.

Speaker: Roman Pichler 39:12

So, we’ve got a question around, Publications and organization are defined as products. Hopefully, that’s been addressed by the discussion we had earlier around, what is a product? If not, then the test for if something is a product is? First of all, it has to serve a specific group of people. So, you have to say, what is the value of create? What is the problem it solves? So, the benefit it creates? And who are those individuals? And at the same time, you have to say, Okay, what is the value that my product largely on its own independently creates for my business? If you can answer those questions, then most likely you have a product or the asset or in this case, the app is a product. So that’s something you may want to do and always look from the outside in avoids the mistake of saying, we have the systems in place, therefore, each system has to be a product and think about trying to look at your system landscape from a user perspective and see how users interact with the various assets and look at the user journeys in order to identify products. And then, what does a good product goal look like? How is it different than then a strategic intent? So, a product goal, again, I briefly touched upon it earlier, I would consider a good effective product goal to be specific and measurable. And a goal that describes the benefit or outcome. So, if I wanted to create a healthy eating product, then a good product goal for the very first release the MVP might be to help people become more aware of their eating habits, and at the same time, acquire an initial user base. So, something that you might be able to achieve, say in the next three months, sometimes that timeframe is too long, and then you maybe shoot for six weeks or eight weeks, sometimes three months is maybe too aggressive. And you need more timeframe of four to six months, but somewhere within that, that sort of scale… that’s usually an effective product goal. What’s next? Do you have any tips on how to add effective acceptance criteria during sprint planning? Yes, I have don’t do it. So separate product backlog work from the sprint planning.

So, make sure that you refine and work on your product backlog before you move into the sprint planning meeting. Otherwise, your sprint planning meeting becomes very strenuous, it’s likely to be overloaded, and the quality of the backlog work you do might be sub optimal, so make sure you invest in a product backlog refinement when doing the engine behind the scenes that drives the product, how to do it in smaller releasable chunks. Now, I’m not quite sure what the engine here is. But, I suspect it might be something like a platform, like a software platform that encapsulates shared services or shared components. If that’s what it is, then I would suggest you best start by addressing the needs of a small number of products. And by forming a team, or in closely involving the teams that build the software, that sits on top of the platform or the engine to make sure that the engine or platform really does a good job for those teams, because the users of that engine or that platform will be the development team members. And otherwise, you can pretty much… assuming that the engine or platform is managed as a product, you can pretty much use all standard product management techniques to do that. And there’s an article I wrote I think about a year ago about software platforms maybe refer to that and check it out.

And we are doing Agile so wrong. How do we get to convincing management to go the route of continuous discovery and building features that are of value rather than saying yes to every feature that our customer wants? Sometimes that has to do by actually moving away from a building, tailored, custom, bespoke products to well, essentially, commercial products. I’ve certainly seen companies struggle with that. So, if you currently earn your money by running, essentially projects and doing bespoke custom work for individual clients, then you’d really have to change the way the business is set up and operates. Otherwise, it might be an empowerment issue, establishing effective, empowered, qualified, knowledgeable, professional product people, product owners. And the thing that you can do to help with this is that you first of all, build trust with the stakeholders, as discussed earlier. And secondly, that you increase your expertise, the more expertise you have, the more likely people are to trust you and listen to you. Do you know any good practices, how project managers could cooperate with product owners? Well, so if we’re talking about Scrum Product owners, and if you’ve set up Scrum in the right way, and you’ve filled the Scrum roles with the right people, you don’t need project managers. And you may you may have noticed that certainly in Scrum, the term project isn’t really used. It’s all about product. It’s all about organizing around products, and it’s all about then developing and progressing and enhancing products. So, project managers typically face a choice, they can become team members, they can become Scrum Masters or product owners, but in all those cases, their role will change significantly. So, it’s something to be aware of, I think. Alternatively, if you currently have project managers who perform program management, some of those individuals might make good product portfolio managers, as I briefly showed in one of the one of the pictures I shared with you, then we have should every feature requests go through design sprints? No. So a design sprint, as the name says, that’s at least my understanding, is really there to figure out what is the right user experience design approach for… either brand new product or product that is being significantly enhanced or changed. So, it can be very useful then to spend a week and well going through that, design, Sprint, but certainly not for every single feature.

So that’d be really again, for brand new product, or for a major change when you take your product to a new market or market segment, for instance. And then the final one I can see here is having trouble getting value… Having trouble getting value info from the business making it difficult to prioritize using COD, are any of the matrix approaches valuable, or are they anti patterns. So I think whenever you are the product owner, you have to really understand the value that your product should create for the business, I wouldn’t expect that any of the business stakeholders have to tell you, it’s really something that you need to know and you have to take responsibility of the products, ability to create value towards the users and towards the business. And then you have to think about, how you can ensure that you maximize that value and that the desired value is created. Again, as I briefly hinted at earlier, the model that I like to use is by starting out with a product strategy, and then test out that strategy, validate that strategy translated into a product roadmap, and then derive a product backlog from that product roadmap via a product goal, or one of the product goals. That’s on the product roadmap. If that is useful to you, it’s probably something that you need to look into in a little bit more detail if you’re interested in possibly experiment with…

Speaker: Miljan Bajic 47:16

Maybe one last question, Roman as we’re here. It’s the second one here, and I haven’t voted and I would vote for this one. I’m currently writing a book. Do you have any advice I should consider to get it done and published? I’m actually writing a book as well. So. I’m interested, as well in this question. So maybe you can just quickly for me, and this other person just answered that question. You’ve written three books for how many…So any advice for us inspiring writers?

Speaker: Roman Pichler 47:55

Well, I’d look at a book as a product, a product in its own right. So, be clear on who is the target audience? Who are the readers and be clear on why people would want to use the product and be clear on why you write that product? What is the benefit that you want to get out of that product? And depending on the benefit that you want to achieve by offering this product by writing this product, think about which route you want to go down, is it self-publication or working with an established publisher, if you’re a first time author, and you want to write a book to establish your name, or to grow your reputation, to grow your brand, it can be beneficial to work with an established publisher. Well, if that’s less the case, if you feel that won’t necessarily be very beneficial for you then go down the route of self-publication, it just means that you have a little bit more work because you’ll have to then take care of the… you’ll have to find development editors, if you need any, you have to hire copy editors, you have to work with designer artists for the cover, but also for any graphics that you use. And so, you have that production part that an established publisher would take her off.

And then what the final thing I’d say, again, that’s related to the value that your product to create and how big or focused the audience, the group of readers are likely to be. I have a preference to write and to read, I have to say fairly focused books. So, I mean, if you think about writing a book on agile, then I’d say, well, maybe there’s a specific topic within the big Agile realm that is interesting. Even if you say I’d like to write a book about product ownership, I’d say like, that’s still so big. Maybe write the book about, product backlog, or even specific product backlog management aspects. You could write a book on prioritization, and as always as any product development effort, it’s a balance between having a product that is too focused or your market is too small and it’s no longer attractive and appealing. And a book that is too big and a product that is too bloated and does too many things for too many people and then really doesn’t offer a compelling value proposition.

Gene Gendel

Transcript:

Speaker: Miljan Bajic 00:30

What do you think is one of the biggest, or maybe I misunderstood things about agile agility?

Speaker: Gene Gendel 00:40

I like analogies and some people say just cut to the point cut to the chase. I like you to run, just levered. I usually put this through for my own analogy, like tobacco and alcohol industries are tightly controlled in the United States and other places as well. You can’t just start making cigarettes, you cannot just make an alcohol and sell it. You have to have a license. If you break the law. There are some repercussions. Agile has become the mainstream, aftermarket, business making intrapreneurship for many. And then some people make this because they want to make a lot of quick money. Large consultancies reinvent the wheel, midsize consultancies trying to follow big ones and trying to stand the bandwagon. In fact, this is one of the biggest omissions and disservices to organizations, clients-organizations, but also our clients-organizations themselves, because it has become almost like a vicious cycle. People have lost the a lot. They lost the authenticity and the initial meaning of the word agile, its intentions. And I mean, today I’m shocked. I should be no longer be shocked. But I still get shocked when you talk to some people at some large organization, people that are in charge of Agile transformation adoption. Anything you asked him who wrote the scrum guide and they wouldn’t know and you ask them to name at least one agile manifesto co-signers and they wouldn’t know. And what they guided by are, like internal design playbooks, and prescriptive manuals and executable files, we talking about 1000s and 1000s of pages, Wiki pages, conference wiki, Box Notes, PowerPoints. So I think the biggest problem for me with Agile is that it has lost its initial authentic meaning. Like if you do a litmus test, and almost anyone’s meaning of the word agile with the word adaptive, or the synonymous word, it’s not going to match. So I think the biggest challenge for me is that it’s just so much stuff out there is no longer relevant.

Speaker: Miljan Bajic 03:22

Yeah. How much do you think we as coaches and consultants, the community that we’re part of, how much have we contributed to that? Do we get the easy pass? Or are we a part of the problem as well?

Speaker: Gene Gendel 03:40

Well, I think we’re part of the problem as well, let me explain how, and I’m going to be totally agnostic. I mean, you and I, we are in a part of a probably much better, much more professional community than many others out there. But I’m just going to say I’m going to be very agnostic and generic. People that are in business of giving superficial one time fly by, one nightstand training with certification which has depreciated in value over the last few years dramatically. I don’t think they add much value with regards to educating masses, well, maybe so they add value because they hopefully and this is a big assumption, right? Those better ones, they deliver stuff and it’s authentic, original value. But there are so many second and third market delivery people that just snap certifications at deep discount, resell through less than appropriate and less than ethically appropriate second and third resellers. So, like I said, my initial statement was, it’s not a tobacco alcohol industry where you have to be very careful what you do. Everyone there either has a certification or accreditation or a license, or a badge. So for non-educated consumer. It’s so easy to get confused. I mean, there’s so many of them out there today, especially online, you know, 9.99, 39.99, you get a badge. Some companies sell badges, along with a false promise that because of this certification, someone’s going to get hired. We’ve seen this movie, right? Staffing firms and some less than reputable shops out there, they would essentially present a training or certification as the get your foot in the door green card to get hired. And then once you pay for the badge, they’re gone. I’ve heard these stories, these are unpleasant stories. And I feel sorry for the people that fell for this.

Speaker: Miljan Bajic 06:10

Well, yeah, but like I recently wrote about this, I think I even shared with you about the desire, like I use this analogy between cooks and chefs and recipes. So there’s so much and I think you talked about it, and also in the context of Shu Hari, but like, there’s so many people that are looking for recipes, and not necessarily wanting to become a chef or not wanting to understand the patterns behind some of these frameworks. And what we get is that a lot of times people don’t have the ingredients that we promised in these frameworks, and they’re not able to put anything together. So it’s almost like a having recipe, without ingredients, or understanding how to put it together, so..

Speaker: Gene Gendel 06:55

And you’re right, and to my point, many companies are, you know, when you look at what an average company wants to do, they don’t really want to become a learning organization. They wants to become an organization that has executed best practices, according to some, prescriptive guide, the playbook that most likely has been syndicated. And created internally. Or probably just as bad if it came from some large consulting firm that essentially was sold it to them, you know, for $8,000, $9,000 a day. That’s a [inaudible] [07:41] service, right? And you know, but it’s a playbook. Take it, take the deck. It’s because it’s in the deck.

Speaker: Miljan Bajic 07:50

And we’ve seen that you and I have worked with large organizations, publicly trade [07:55] organizations where one of the big companies comes in, and we’re sitting at that same table with those big companies. And what the internal leadership is buying is the confidence, right? They’re buying those playbooks, they’re selling these big consulting companies saying, here’s the playbook, or this is what we’re going to do. And how much does it have to do with the lack of leadership understanding organization, what they buying, and just buying the conference assuming that somebody can come in and fix that problem rather than them trying to fix their own problems.

Speaker: Gene Gendel 08:29

You’re right, I agree with you. It’s one of the biggest emissions I’ve seen. And the right also, I fully agree that because people that are decision makers are not the same people that understand the impact, we get these bad decisions. I’m assuming there is nothing more grotesque about this, when a large company hires a large consultancy, because they have a large batch. Because guess what, if they flunk, if they fall flat on their face this whole effort, the hiring company will say, Well, that’s the large consultancy’s fault. I mean, they must have known better. So I’m getting out of jail with a free card. I’m not responsible, and that’s at the time of the when forgive my French, something has defense, but when you’re in the initial state, of course, everything is hunky dory, and how could they be wrong? A billion-dollar company. Did you actually know that majority of their consultants are young, ambitious, well spoken, eloquent graduates from best universities in the world, but with zero or very minimal industry experience. And when you take that, in combination with a very smooth, very well polished PowerPoint deck, and a Valentino suit, now becomes a very big impact. It makes a big impact, it makes a great impression on the hiring company. It can be wrong.

Speaker: Miljan Bajic 10:06

Yeah. They also like a lot of times, one of the things that they do bring those large consulting companies in, is either to help them be more efficient, right? Or either to save money. And the way that they define agility or business agility is obviously different than probably what we would define it. I’m interested to know, like, how do you define business agility?

Speaker: Gene Gendel 10:38

Well, funny you said that they think it’s they maybe going to be saving money. God knows you and I cost 1/3. Large consultancies charge simply because we don’t have a gazillion of people in our digital perfection department to work on desk and fine prints. Just value with almost no overhead, right? I mean, whatever our….. anyway.

Speaker: Miljan Bajic 11:07

I’m not talking, like saving in that instance. It’s about saving the company money in efficiencies in other areas by actually doing Agile or adopting the agile practices or, as you know like installing agile.

Speaker: Gene Gendel 11:27

I’m with you. So the business agility to me is, first of all, I think business agility is a huge part of organizational agility. One thing I don’t support, and I don’t subscribe to is that when business agility, or agility in sales, or agility in other management, or agility in XYZ, Organizational Domain is viewed as a standalone, independent endeavor that can be literally treated by its own as a silo. And one of the reasons why I think this is happening is because, again, for the same reasons, for someone, hey, business agility is going to be a great momentum, let’s do stuff in there. I’ve met some great people in business agility, communities that really get it, they come from a standpoint of organizational ecosystemic agility, and perhaps they spend more time with business people, and users and customers, I get that. But for many people, it’s just a way to justify why they don’t want to focus on anything else. So I want to think of organizational systemic agility, with business being a part of it. So I think any organization, business could be marketing sales operation, right? Then there’s technology, there’s HR, there’s vendor management, there’s, side strategies, you name it. So I don’t consider these independent entities. I consider the as part of the much bigger ecosystem.

Speaker: Miljan Bajic 13:24

Yeah, give an example. Like if you go back about a year ago, when the whole COVID crisis hit, and if you look at the food industry, especially the grocery store industry, right? I had couple of clients in that space, and they never saw themselves as IT companies, right. And then all of a sudden, when we had crisis, and people couldn’t go into the stores, they suffered, because they weren’t able to adjust, I had something told me mean somebody was, you would put in order, this is March 2020, you will put in an order, you wouldn’t get half of this stuff. When you go to the grocery store, they would come out and take your credit card, go back and run it at the cashier, come back, give you your card back. And then they will bring the groceries that they had for you. And I, first of all, don’t want to deal with that crap. So, I obviously went to a shop somewhere else where I usually don’t shop, but they had that infrastructure already in place. And from a business agility. There are companies that actually benefited from this whole crisis. And there are also companies that actually just expose themselves to how vulnerable they are. Just in how quickly they can respond.

Speaker: Gene Gendel 14:50

Yeah, look, so I was just talking someone else earlier today, as much as COVID has caused so much damage and devastation. And I mean, I got a very short end of the stick last year, and I’ll be pretty open about that. But for some people, and for some companies, it has been a rather more successful period maybe because the we’re in business of producing something that people need the most, somebody saved a ton because of not traveling and not commuting. Spearing on food. I mean, it’s almost they have to take the good with the bad. I mean, I speak from my own experience, and unfortunately, I didn’t get that luxury. I know some people that did I’m not jealous, I’m just stating what I know.

Speaker: Miljan Bajic 15:48

Was it late last year, I think it was in December, you wrote agile lyrics home. And I’m just going to read here one part of it.

Speaker: Gene Gendel 16:04

Go ahead.

Speaker: Miljan Bajic 16:05

So Agile is the way to advance for promotion don’t miss opportunities thrive with devotion. Scrum master is a merely a junior role. An enterprise coach is your ultimate goal. And by the

Speaker: Gene Gendel 16:23

And by the way, first of all, thank you for quoting this. People that will be, if they watch it. Hopefully they will understand there’s an irony in this right? people hopefully will [inaudible] [16:34], that very page with the lyrics. It’s got the actual guitar play from a good friend of colleague of mine, Aaron Perry, and I think she’s amazing singer and guitar player, so she put it in music.

Speaker: Miljan Bajic 16:51

We’ll include the video down at the bottom in the description, and people can check it out. I watched it and it’s pretty good. But coming back to this topic, I mean, obviously the whole song resonated with me, but especially this part here, and coming back to our earlier discussion about just agile and certification business, a lot of people are just seeing this as an opportunity to switch careers or make more money. You know, Scrum Masters make anywhere from, you know, 100 plus K to 170. I’ve heard people make 170. So it’s a pretty good pay at least in the United States. So a lot of people want to become Scrum Masters not even knowing what it takes to be a good or really good scrum master. What are your thoughts on this and kind of as you were writing this poem, what was going through your head?

Speaker: Gene Gendel 17:57

Mixed feelings, sadness. So, some irony, I always like to turn everything I don’t like into a sarcastic joke. Just helps cope with it. And of course, and you probably have, since all my ridiculous graphics. You know, unlike other professional cartoonists, I try to pretend I am a cartoonist, but I try to put irony and dysfunction into graphics. So what went through my head at that time, so both you and I have and this is where you’re going to keep me honest and tell me if your journey was light. We went through a very long journey of gaining an accreditation by the organization that has been in business for many years, and maybe you know, agree or disagree about some of its history, but on the coaching front, it has been the most reputable organization out there. The coaching offshoot, the coaching leg of it, and both of us, you and I went through a very challenging, a very long journey of becoming certified enterprise coaches, literally was a journey. I mean, I kicked off my journey in 2010, I think and I fled mind back in a couple of months after that, pressure because of my own ignorance. I didn’t do it right, partially because of the process, which wasn’t ideal. And I said, no, screw it. I won’t come back to it until I have time because it was never the main goal for me. I wasn’t in pursuit of the batch. I did my work; I think I was adding lots of value I was learning. But long story short when I went through the process the second time around, it was a long journey, tons of learning along the way. And I bet you’ve done the same, it wasn’t an easy gift to you, right? And I also have mentored many people since then, people that were on the same journey. So I know people that really want to get this kind of accreditation, or this kind of credential. They invest a ton load of time and effort into it.

Speaker: Miljan Bajic 20:22

And money, too. I mean, I remember like going to, and traveling to just meet some of these people to understand from their perspective, observe. So it was like a commitment, not just from that, but it was financial commitment too because they require you to put a lot of this into practice before what you’ve done and also to build relationships.

Speaker: Gene Gendel 20:49

Yeah, I’m totally with you on this. And so the sad part is this. It is me and you and a bunch of other people, a small fraction of people that really took it seriously. Today, and this is because of the supply and demand thing. And I wrote about this many times as well. Everyone, their mother, even enterprise coach. So you can always look them up graphics and even funny SQL I call it as when their HR database is being updated overnight with a SQL statement where you update values, senior project managers, senior Agile coach, junior project managers, Scrum Master, for crying out loud. If that’s what you do, then why would you expect your organization to change? So for many people, it’s a fast track. Just because there was a bandwagon moving at high speed. Agile, agile let’s jump in on the bandwagon. So it looks like my PMR responsibilities are winding down. Where is that next train that I need to jump on? Next agile release train to jump on right.

Speaker: Miljan Bajic 21:59

What would you tell somebody that is serious. But their goal is not enterprise agile as you said here, it’s not the ultimate goal. But it’s the journey, they really do want to become a really good organizational and Agile Coach, what would you recommend somebody just starting out right now? Before what would you do? If you were starting, what would you do? Given what you know now.

Speaker: Gene Gendel 22:33

Look, today, there are more opportunities today to pursue the same journey you and I went through than there was 10 years ago, or even five years ago. So you know, we got mentoring programs, we got people like you and I that are out there to probably give some guidance and help. There is a will, there is a way. The challenged today. And by the way, tell me if you think otherwise, if you disagree, but even today, majority of companies do not have recognition for certified enterprise coach by scrum Alliance or certified team coach by Scrum as much as they should, because these are the best people out there. But because the word Agile has been grossly grotesquely diluted, it just rubs up the wrong way. You walk in the organization, anyone who has been at certain pay grade. So it’s like an if statement. If you’re on a certain pay grade, and if you want to do Agile, then you will be some sort of an enterprise person. If you want to do Agile, and if you are at the junior pay grade, then your options are a scrum master or some sort of ill-defined team level BA like product owner. Just because the pay grade isn’t there it doesn’t give you enough opportunity. So I would recommend people that are really genuine about this still pursue the right way. I mean, their ways to invest themselves. Education. Look, what we have today is so much more. There’s so much more richness now than we had back when we were doing this. So I think there’s a will, there’s a way the challenge with this is that the market has been grossly diluted. So just like I would recommend to individuals not to shy away from pursuing this as an opportunity. I would also recommend companies that hire be much more discriminative and more scrutinized. When it comes to picking their talent, their bringing on talent.

Speaker: Miljan Bajic 25:04

So it’s both ends, organizations being able to kind of screen and hire better, but also for people that are interested pursuing that. Yeah, I agree. And one of the things that I say in knowledge value, which goes back to what you said about, there’s a lot more opportunities today, because there are more companies that are interested in pursuing these agile ways of working. The way I explain and I use another analogy, which is like, you know, I grew up in Sarajevo and 1984 Olympics were held in Sarajevo, so skiing is big there, and skiing in Sarajevo is different than in Maine, or New Hampshire, or Vermont, where my family or when we came to United States, we came to Maine and I continued skiing up there, but it’s totally different. You know, we joke around, it’s more like skating down the bunny hills. Because I see, there’s no really mountain, these are just large hills compared to what we see in Europe. And then when I move out here, West, it’s different type of terrain. So a lot of times SCRUM masters are like comfortable on their own mountain, in their own organization in their own team, they’re not willing to say, hey, I’m going to take a risk and go somewhere else and get some more experience, and then I want to go somewhere else, and get more experience. So it’s like, analogous to like having, skied in many different conditions in areas. So you can become a well-rounded skier. And I don’t see many people willing to take that risk, I used to take that risk. And I would, you know, obviously, it was easier when you’re younger, but I think that’s what shaped my journey and made it easier, not easier. But as far as learning faster, I was able, and willing to do that.

Speaker: Gene Gendel 26:58

So it’s funny, you say this, you see for people that are really into the role. So people that are into intrapreneurship, and discovery and learning, they welcome these challenges, and they welcome these opportunities to change organizations, maybe if it’s a large enough organization, as the first step would be to change different divisions or different organizational verticals, going from one to another, although someone could rightfully argue that, as long as you under the same logo, you’re pretty much in the same structure and culture, which is true, you still can improvise, but people that just want to get by and therefore ride, they really don’t see much value in learning. I call it fast trackers, because there’s fast, fast, fast, off the chain of command, those people will not be so much interested in pursuing opportunities elsewhere. So there will be just very “Suddenciary” [28:03] very localized. And, of course, they might say it will be very limited, very narrow. So I think this is a good indicator. I call these domesticated people institutionalized. Maybe it’s not a good way to.. I mean, I treat others the same exact way I want people to treat me. So if you’ve been with the same organization for 15-20 years and haven’t seen a daylight, then you can’t expect anything from that person, especially if that person didn’t get as much.

Speaker: Miljan Bajic 28:50

Yeah, I mean, similar to both you and I immigrated to this country. And I think it’s similar like that, when you’re exposed to the completely different environment, the different culture, you kind of start seeing things from a different perspective, things that you saw, in your own bubble, now start looking a little bit differently than what they did when you were in that bubble.

Speaker: Gene Gendel 29:13

I agree. Very true. And I’ll go even as far as to say, you know, we don’t want to digress outside of the conversation into, you know, history or politics. Well, many people that I’ve met in my life during at least the last 20-30 years, some of them are very successful in their own ways. Just because they have become very successful in their own little, I’m sorry, in their own huge bubble. Yeah, their bubble is pretty big, but it’s still a bubble.

Speaker: Miljan Bajic 29:50

What you’re saying it’s like it’s not necessarily the indicator of but usually might be helpful to change perspectives, I guess and look at things in a different [cross talk] [30:00]

Speaker: Gene Gendel 30:01

Exactly whether it’s history or politics or anything else, I think there’s a wisdom. Right? Depending where you sit, you send in your views, depending on where you sit. Right. So…

Speaker: Miljan Bajic 30:20

So you’ve been involved with the community so many different ways. And one of the things that I really enjoy is, especially in last year, what you’ve done with the New York, the less community in New York, and as far as I know, like, it’s the biggest less community out there and sports active, I think, you know, one of the nice things that I see is the caliber of speakers that you bring, and I was watching your interview with Dave Snowden. And yeah, and I invited Dave, he actually came to Agile Maine, I don’t know if it was the year that you came. But what kind of grabbed my attention? I think you asked, there was a question around, how’s a large-scale Scrum in relation to complex adaptive systems? And he said something along the lines is, less is not how you scale complex adaptive systems. And I understand it from and kind of agree with him in a way that depends what type of complex adaptive systems if you truly going from a complex adaptive system, I agree with him. And I don’t know what were your thoughts when he answered that question? What was going through your head and maybe reflectively looking at is, what are your thoughts on?

Speaker: Gene Gendel 31:47

So first of all, I respect Dave, Dave’s view, and he’s a pretty well-known and very eloquent speaker, and he doesn’t sanitize. And that’s nothing else, even if I would disagree with him, I would still respect him for his candid blunt and sanitize views, and sanitize in the way that he doesn’t sugarcoat it. He doesn’t sugarcoat what he wants to say. I think he did make, if I recall correctly, he didn’t make some statements about less, I need to actually go back to that video on the replay what he said exactly. And I kind of knew that I wasn’t looking for him to give any blessing or pave the road for Less. In fact, I wasn’t even aware of his, you know, degree of understanding of what Less is, you know, that he probably have read plenty about Less. Given that there are free books and a very comprehensive website. So I wasn’t so much concerned about what he will or will not say about less. In fact, I wanted to complete, I know the “card blog, Sheila” [32:58] together. What really outweighed it, and that’s why I really wanted his perspective was his candid and an uncensored view on some of the challenges and dysfunctions that exist in the industry because of large consultancy business, and partnerships between large, very expensive consultancies on one hand, and very large, expensive, but makes you feel good, agile frameworks. And I’m not referring to Les and I will not even mentioned that other XYZE framework, because people will figure out what that is, I think those come as a horse and carriage. And he alluded to something so that was worth having him there, just that one few sentences, he had referred as essentially with you what he called an industrial model. When a consultancy gets overly big, a certain degree size wise, in order to feed itself. It needs to generate business. So if I’m a large consultancy, and you’re my client, I will not engage with you in a way that will produce short, incremental, meaningful, sustainable results. Because this sort of engagement does not justify the effort for me, because I need to feed my cohorts of workers that sit; the back office people, right. But if I were to engaging with you, I would dig in for a long time. I would pack and install something that is big, heavy, complex and of course not cheap, right. I would always considered that plus the tooling solutions. I actually referred to it as the triple taxation. If you’ve seen some of my other cartoon, [cross talk] [35:11] triple taxation, large consultancy, big scaling framework and monumental tool and solution. So it’s a triple tax donor organization and paid three times to live in a really big city, city state. [inaudible] [35:29]

Speaker: Miljan Bajic 35:31

Yeah, so that’s a really good point. And if you look back at, you know, transformations, and if you look at the data, like, you know, if you look at from your own personal experience, if you look at the data, at least when I do that, like 90 plus of these transformations doesn’t matter if it’s agile, whatever, fail. And nobody talks about that Agile is popular. And any of these, you know, Lean was popular. Any management that becomes mainstream is obviously popular. But why do you think, besides what you’ve said so far, that it’s such a high rate, and do you agree with it, do you think it’s that the in that 90s range? And

Speaker: Gene Gendel 36:16

What do you mean, failures?

Speaker: Miljan Bajic 36:18

Failures. Yeah, like, [cross talk] [36:19]

Speaker: Gene Gendel 36:20

Yeah, I totally agree that majority of these transformations are complete failure, I don’t have the numbers, I haven’t run the stats, but I can tell you majority of them are failing. But also, we have to understand is that very few companies will openly admit to the fact that they have failed, because it’s the status quo. Especially if this is a watch consultancy driven effort and multiple credibility are at stake, who’s going to have to say, we have screwed up. Companies that are smaller, I shouldn’t say smaller, because this is really not size specific. This is really based on the internal culture, which is secondary color to or structure. And very much, depends on the mindset of senior management. If they were in the experimental mode, if they really wanted to do deep and narrow, to try and see if it works, what fails, what succeed, what success, then they wouldn’t mind reporting back to the world that they have made some mistakes, and then they have learned from them. Of course, if they have engaged, not large consultancies that, send armies of people to them at a very high buck. But maybe smaller people like you and I, or some smaller boutique more focused organizations that help with agility. That would be much more comfortable to share back with the world that a some of the stuff we tried, fail, and some of it materialized. Look, it’s all about keeping your face, right, above water, your head above water, if you invested $85 million in the transformation. And three, four years down the road, you did the books, you realize, okay, that’s how much money we spent on this huge consulting firm. But what did we gain from it? And their answers, almost nothing or nothing? Then who’s ever want to go on the record and say, Oh, guys, you know, what, we lost 85 million dollars. Haven’t really gained anything back. And, we’re so brave, we’re going to share, share this with you.

Speaker: Miljan Bajic 38:53

Yeah, I mean, but what I’ve seen is like, this is when the management or leadership changes, right? Everybody gets couple years shot. You’re out. New guy comes in brings his own team. This is what I’ve seen in many instances where a senior leader is hired to drive the transformation. They have their own team, they have the previous consultants where they work with, they have a shot at it, if they don’t meet or the board or the senior leadership at that company is not happy with it, they bring somebody else and there is now a lot of that transparency. Sometimes you take two steps back one step forward, sometimes it’s the other way around. But as far as transparency, it’s not very clear to the employees and I think that’s why one of the things where people are so disengaged at work.

Speaker: Gene Gendel 39:48

If you lose, I always say there is only one thing like dating, right? I’m sure you and I have been there, right? There’s only one time we can make a first impression. Screw up once it’s going to be very hard for you to get back on track and prove otherwise. So when an organization makes a bad impression on its individuals, and therefore discourages the incentivizes its own people, then it’s going to be very difficult to gain back credibility and trust. And so people will just shy away, oh that’s another change management fad. And that’s another management, so or reorg, 101. And we know, once people hear reorg, people go oh shit. For you, my friend got it [40:48]. Someone’s going to be let go. The funny thing is in large scale Scrum, and I chose to stay away from one of the things that I tried to demote more than less, we actually stress very strongly the difference between job security and role security. We want people to be safe in their jobs, and be able to provide for themselves and their families. But it’s not the same as a role security. Because their role security problem is that with that, we have lots of local optimization around individual roles. So if we’re in business, you and I where there are no longer guess, operated lightbulbs out there in the street, then why do we need a role of someone who’s going to be lighting them up at night? We have electricity, so we can rely on automatic switches. So if we optimize for that role, we’re not going to be optimizing for the whole system, we’ll be paying 1000s of people for the role that is no longer needed. But these people, maybe they have some other skills, we can repurpose these good people. That’s the job security. So organizations need to understand that and if they treat Agile transformation, as a way to get rid of people. Well, I think it’s sad.