SAFe from the Business Owners point of view with Fredrik Carleson
Join Murray Robinson and Shane Gibson in a conversation with Fredrick Carleson, who has successfully managed a 1500 person SAFe program in a Swedish government department. We explore the challenges of Safe and it’s alignment with Agile values so you can decide if SAFe is right for you.
In this discussion, Frederick emphasises the importance of agile leadership, autonomous customer focused teams and the need to address root cause problems within your system asas you scale. Join us for a fascinating and critical discussion of SAFe.
Subscribe
| Spotify | Apple Podcasts | Google Podcasts | iHeart Radio | PlayerFM | Amazon Music | Listen Notes | TuneIn | Audible | Podchaser |
Podcast Transcript
Read along you will
Shane Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson.
Murray I’m Murray Robinson.
Fredrik And I’m Fredrik Carleson
Murray Hi Fredrik, we invited you to come on today to talk about SAFe. I’ve seen you write about SAFe on LinkedIn and I understand you’ve been a product owner of a large SAFe team for some years .
Fredrik Well, I’m actually a business owner in a value stream or release train as it’s called in Safe. At the same time, I’m wearing the hat as a section manager and lean agile leader as well for big governmental agency.
## Frederik’s Background and Experience
Murray Tell us a little bit about your, background and ~~ ~~experience with Agile product development and software.
Fredrik I belong to the Commodore 64 generation. Some of you might remember that first home computer. That was also during the time where role playing where I come from was very big. So my interest was Commodore 64, role playing and skateboarding. And the reason why I’m bringing up roleplaying is because I think that roleplaying and agility goes very close hand to hand. Because as a dungeon master, or game master, you’re basically telling a team who has different characters, like a thief, a fighter, what’s happening, and then the team have to decide what actions to do and how to meet the goal of the scenario. And as a dungeon master you know, you actually become quite a good scrum master from the start.
So I started out as a consultant. I worked with traditional waterfall projects and I always felt there was something that really didn’t match my beliefs of how to handle a team. And later on, I went to a startup. I went to work for some agencies in the United Nations. I lived some time in Bangkok and worked in Copenhagen, Denmark. ~~ ~~Here I could try some different project methods. We tried ~~ ~~very classical waterfall and we also tried Rational Unified Process and Prince2. At some time we merged with another organization and we decided to try Scrum in 2007 or so. I also went to have a course with Ken Schwaber to get a certificate.
We did some scaling before the popular scaling frameworks came. So we actually invented our own scaling framework. After that went to a private organization as head of product group, where we actually used Less to scale up. But for the last two years I’ve been in a governmental agency where I started up a new section from scratch. And also then, trying out SAFe.
## Diving into SAFe
Fredrik And this is a large implementation of SAFe. We have about 1, 500 people in the IT organization trying to work together in this huge SAFe implementation. I’m not a guru, I’m not an expert, but I’m a practitioner.
Murray Yeah, and you’ve been doing SAFe for how long now?
Fredrik It’s roughly two years now. And my conclusion of the two years is Safe is more or less impossible to grasp. It’s so much. You just look at the picture at the front screen when you go to the website and you almost get afraid. And I also believe it promotes hierarchy. It’s very clever in the way that for large traditional organizations who have a traditional management structure, Safe seems to fit in. So you get tempted to say, Oh, we can become agile and still keep the old structure. And this, causes a lot of problems. ~~ ~~
## Challenges and Criticisms of SAFe
Shane One of the views I have watching SAFe be rolled out in organizations in New Zealand, is It is often used by organizations that want to change their slippers. They can look at the Safe map and they can go well here’s my current role in middle management and I can see another title that looks like what I do so I’m just going to change my title.
Fredrik Yeah, and the thing with roles is confusing. I think everyone is stepping on each others toes because ~~ ~~SAFe introduces quite a lot of new roles. So they have redefined the classical scrum roles. They have the product owner, but the product owner is mostly focused inwards towards the team, and then they have the product management, which is on top of that. And they’re supposed to look at the roadmap one to three years ahead in time, and also to talk to external customers. And then on top of that, you have the business owner. That’s basically my role, whose role it is to form the strategy and the vision and the long term goals. And to have long term goals is fine, but it takes the traditional product owner roll and splits it into three roles. And of course you have the release train engineers, you have the solution train engineers and so on. ~~ ~~I guess the assumption is it’s supposed to be because you scale up, so you need some kind of extra overhead on top of the teams. But in my personal experience, it causes more confusion than it actually does help.
Murray How is it working for you as a business owner? Is it helping you to achieve your goals of meeting your user’s and ~~ ~~customer’s needs? ~~ ~~Does it provide you with that contact with customers that we talk about a lot in Agile. Is it allowing you to achieve your business goals?
Fredrik In some sense. In Safe you have strategic themes, the business goal for the entire organization. In our value stream we try to see which of these business goals can we actually take into our value stream in order to provide value, but I think the biggest problem with the value streams and which I see happen a lot of times is that the value streams we create are actually not value streams. We always have some dependency on other value streams or even support value stream which means that we actually can’t take something from start to end. That means that I’m not close to customers.
From a customer centric perspective, I would like to be involved in the entire value stream. For example, if somebody wants to buy something, you first put something into the catalog, and then you go into the shopping cart, and then the module quotation. If you want to take a feature and you want to provide value, you should be part of that entire customer journey from start to end. But we can’t do that because we just control the shopping cart. We can’t control anything around it. Meaning that it gets very confusing and you get a lot of dependency and you have to do a lot of coordination. And coordination is something we want to avoid. That means the trains are not autonomous.
Murray I found that SAFe does a lot of dependency management. So you put up the boards with the red string all over. it and It feels like SAFe accepts the dependencies that already exist in the organization and it tries to work around them. Whereas, in Agile, I think we’re really about trying to minimize dependencies as much as possible between teams and groups. We bring the skills into the team or we treat another team as an internal product that provides us with a service.
Fredrik Yeah, ~~ ~~ it allows dependencies. But it’s not just in the release train. On top of that, you have the same thing between the release trains. And even between the value streams. So it becomes even more complicated, which means that we have to add extra project management on top of everything. Instead of trying to fix the root cause, which is how can we collaborate effectively? How can we make the communication flow better. And you do that by having fewer people communicate to. It just adds a lot of extra processing and relearning because you need to have more and more people involved all the time, and more and more people need to be informed of the decisions. It makes the entire process very slow. Instead of having the autonomy for a team to take something from start to end. So I think you’re absolutely right.
Shane For Safe, it sounds like it’s people who aren’t doing the work talking to other people about the work being done, and as you go up those conversations, we naturally lose context. So is that what tends to happen?
Fredrik It happens and the way we try to mitigate it is that in Safe, we use epics features and user stories. Epics can be at the program level and the train level. That program epic is then broken down into a lean business case which looks exactly like the Rational Unified Process vision document, which is quite funny. And then you break it down into features and ideally the trains and the teams pull from these features and then talk to the right Feature or Epic owner to get clarification on the requirements or what the goal is. Unfortunately, a lot of things happen during this way. So it’s more often pushed down into the trains. And because one train can’t finish all of this, it has to be coordinated across several trains.
Murray What I’ve seen in the Safe program I worked in, and also what I’ve heard from other people is that there is a lot of push downwards onto teams. And that what’s happening is that people at the management level are spending about two months preparing for PI planning. Everybody gets together all 1, 500 people or whatever it is for two days, and they agree on a detailed plan for five or six sprints. They commit to the plan, and then management expect that the plan will be delivered.
The team I was working in, the program manager and the person in your role, we’re pushing twice as much work into the team as the team had historically been able to do. And then they would demand that it be done, even if the team couldn’t do it. So it was ~~ ~~a very unhappy group. Everybody felt very disempowered because things were being pushed at them and they were told off for not delivering. How common is that?
Fredrik I do have the same experience. Safe doesn’t want it to be that way, but I do think it does happen automatically because of the structure and the way PI plannings are set up. So we have this phenomenon of every time before a PI planning, people rush to finish the lean business cases because otherwise they might miss the slot for the next three months and they have to wait another three months before they actually can get it into the PI planning. Now, what Safe says is you shouldn’t do that. It shouldn’t have the planning of capacity for a hundred percent for each sprint. For the first sprint you should plan for 80 percent capacity, in the second sprint 60 percent and in the last one for 40 percent because things happen, there are changes and you get more and more uncertain. Unfortunately because everybody wants to have their thing in and everybody screams this has highest priority. And management say, we need to have this because we have deadlines. You made estimates, which we turn into commitments. It gets fully occupied with capacity. And some part of me thinks if Safe acknowledges that we can’t plan for three sprints ahead, so we should only have 40 percent capacity in the last sprint, why do we even bother to have PI plannings for three sprints ahead? Why don’t we skip it and just keep with sprints. Because then we get a more flow. Because this, is like having huge batches. In Lean Theory, you want to have small batches to get flow through the process.
Murray Yeah it, feels like a series of three months projects with a preparation of a month or two, overlapping the last one. So it doesn’t feel agile, but it doesn’t feel waterfall either. It feels like a sequence of three month projects with a fixed time, a fixed scope, a fixed team.
Shane Is this a case of people taking the PI planning process and corrupting it by making it three month planning and forcing commitment. Or is that actually part of the pI planning scope? ~~ ~~
Fredrik The purpose is, good and supposed to be lean, agile, but I think in practicality, it’s very hard, especially if you have an organization with a culture that is traditional. You actually read into it from the knowledge that you have previously of product management, and you take those ideas into the Safe implementation, because that’s what you know. And it takes a long time to get an agile mindset and to actually understand the agile principles.
## Comparing SAFe with Agile Values
Murray I want to ask you whether you think Safe Is actually agile. And I’d like to do that by going through the values in the agile manifesto and getting your opinion. First of all, do you think SAFe prioritizes individuals and interactions over processes and tools?
Fredrik No, I don’t think so, because you don’t have effective collaboration in SAFe when you scale up. It becomes very processed. What I see happening in SAFe, everybody focus on, is this according to SAFe? And people forget common sense. And common sense is actually what we need. Sometimes I get very frustrated. I’ll say just forget about safe. If we were allowed to do whatever we wanted what would you do?
Murray Yeah, so it sounds like Safe is a heavy process.
Fredrik Yeah. ~~ ~~I think safe promotes rituals rather than events because there are so many and so complicated that you forget the purpose and only focus on the ritual.
Murray Let’s go to the second one. Would you say that Safe prioritizes working software, working products over comprehensive documentation.
Fredrik I think the purpose of SAFe is to have a working product because you set business objectives and goals. Doesn’t say much about documentation. I think it’s very much based upon the organization that you live in, how much documentation you need. So it is a product focus for sure in safe.
Murray What about the third value? So we value customer collaboration over contract negotiation.
Fredrik I think the customer is forgotten because you remove the ability for the teams to talk to the customers. You move that too high up in the hierarchy and to people who are too far away . And in the PI planning, you make those estimates into commitments. ~~ ~~You forget the value in the process. They focus too much on deliverables.
Murray Coming to the last value then. In Agile, we value responding to change over following a plan. So where does SAFe sit on the scale of responding to change over following a plan in your experience?
Fredrik Not good at all. It really doesn’t work. If you could turn it into having long term goals instead, that would be fine, but as we focus too much on deliverables, it’s very hard to respond to any change. And especially as you fill the capacity in each sprint 100%, you can’t get anything urgent through. So you get a lot of queues and waiting times and handovers. The biggest impediment of Safe is the PI planning and the waiting time and the allowing dependency, not trying to fix the problem. That really is a killer for responding to change.
Murray So what we’ve got then is that SAFe violates three of the core values of Agile. So it feels to me like Safe is not Agile.
Fredrik No. And sometimes I wonder for a traditional company, if they want to be agile, could SAFe be a stepping stone? Would you at some stage get some wisdom and some insight into how you work Agile and that actually you remove Safe and become Agile for real?
Shane When people say to me if we want to start with a thousand people working on something, if we don’t use SAFE, what should we use? And the answer is don’t start with a thousand people working on something. A thousand people working on something on day one is crazy. You haven’t built your ways of working. You haven’t adapted your mindset, you haven’t discovered and explored.
Fredrik Yeah. I agree. And you usually carry a backpack from whatever you have used previously. And that’s the culture you have and the knowledge you have. You take what you know, and just give it a new name. ~~ ~~
Murray I wanted to comment on is it a good stepping stone? It’s not many people doing proper Agile. They’re either doing waterfall in sprints with one of the big professional services firms, or they’re doing Safe. And they always say, Oh, it’s a stepping stone. But I don’t think it is because a lot of people learn that this is what Agile is. I have met Agile coaches who’ve come out of a big bank where they’ve done water scrum fall and then they go and try and implement that everywhere because that’s what Agile is from their point of view. You’re getting all these people who are getting this major misunderstanding of Agile and the organization’s only getting a minor benefit.
Fredrik Yeah, on a LinkedIn query, I asked people, do you believe that structure forms culture? And I can see we’re completely divided. About one third says yes, one third says no, and one third says it depends. And the question is do we need to break down the traditional hierarchical organizations and create a new structure in order to help remove some impediments to get some new ways of thinking? Or is it so that we first can change culture and the mindset and that automatically will change the structure? It’s a little bit like the chicken and the egg and maybe it’s both.
Shane So for me it comes back to transformation. We’re going to transform the organization. And so, digital transformation, organizational transformation, those big programs fail. An organization put SAFE in to transform the organization and the way they work. It falls into that trap.
Fredrik Yeah.
## Alternatives to SAFe
Fredrik Let’s pretend that we are top management of a traditional company and we want to make it agile. What would be the first step if we’re not going to use Less or any of the scaling frameworks. How can we do it?
Shane Easy. As the leaders of the organization, we adopt an agile mindset ourselves. We show the behavior and then we encourage that behavior across the organization.
Fredrik Yeah. Leadership is the most important part. Get the right leaders and the organization will change into having an agile mindset.
Shane One thing I do like about SAFE when I’ve talked to people in New Zealand who have used it is that at the PI planning, senior leaders turn up at the beginning and talk to the team about what’s important. I see that as a valuable practice, to have the leaders come and set the vision on a regular basis for the people doing the work. ~~ ~~
Murray I agree with that. I think that Agile starts with the leadership team.
So Frederick if you were going to advise the Safe rule makers, the body that creates Safe And tell them what they needed to change to make it truly agile, what would you tell them to do?
Fredrik I would say, make it much more simple. Remove some of the overhead. Reduce the amount of roles. Don’t try to make it so big. Instead, try to see how you can create smaller autonomous units of 50 or so people. Figure out how to increase the zone of control for those teams so they can take their own decisions and actually can take something from A to B. Don’t focus on trying to add another layer of product management or coordination roles on how to sync dependency between different value streams or trains and so on. Focus more on principles and maybe not so much on events.
Murray What about PI planning?
Fredrik It should be removed because it’s an impediment. It creates, large batches. And it makes people focus more on what should be delivered the next three months rather than adapting and focusing on the goal we want to reach and how to actually get an even flow through the organization.
If there is something very important that you need to get through, you shouldn’t have to wait for three months. You just talk to the right team and they can say, okay, sure, we can get this into the next Sprint planning. And that was actually my suggestion when we had last inspect and adapt. That we should focus less on what we do in the PI planning and focus more on how we can get the flow throughout. It shouldn’t matter if you are a few days late with a lean business case, just work on it. Let it take the time it takes and then try to get it into the next sprint, for whichever team that can take it.
Shane So just picking up on that term inspect and adapt, is that a core part of SAFe?
Fredrik There is the concept of inspect and adapt. Teams can choose if you want to use Scrum, XP or Kanban. And of course, there you have the retrospectives. But you also, at the end of each Program increment, have inspect and adapt for the entire train. We try to see what you can improve and change. That actually works quite well. ~~ ~~It’s a bit like the overall retrospectives that you have in Less. And there has been a lot of good things coming out from the inspect and adapt that improved the work. What I find is if you have good teams. despite how strange systems are and organization making it very difficult, if you have good teams, they manage to find ways to deliver despite all of this governance stupidity.
Murray In the SAFE program I was helping I found the teams were really miserable. They were being forced to do twice as much as they could realistically do. And all the issues they were raising were being ignored or they were being told off. So they were miserable and they’d given up and were very unhappy.
Fredrik That’s terrible.
Shane But to be fair, I’ve seen that in Scrum as well. I have seen Scrum teams that are forced to over commit to work they know they can’t do. That have senior people sitting in their retrospectives to make sure they don’t say bad things. So I have seen bad behavior with some of the other approaches as well.
Fredrik Yeah, I don’t like estimates. I’m more for no estimates and put a goal in. Because estimates always lead to commitment in the end. And it shouldn’t. There becomes too much focus on the estimates and what can be delivered rather than meeting the goal. And I really liked that in the Scrum Guide 2020, that they changed that. Focus on goals.
Murray That is good. Early scrum did talk a lot about commitments and that did cause some of the behavior you were talking about as people thought that it was fixed scope. And scrum has recognized that and moved away from it because they recognized it was creating problem. We just had Joshua Kurievsky on and his view is that you can tell if your team is agile or not because they enjoy their work.
Fredrik I’m not sure I agree on that. The teams I have are somewhat happy. I think they have some psychological safety and enjoy the work. But it’s on the higher level that agility completely fails. It’s all the dependency and not being able to deliver something of value quickly. But I think you can have happy ~~ ~~functional teams in SAFe and still fail. So that’s why I say it doesn’t have to be the measure of being agile just because you have happy teams because you can still feel at an organizational level.
Shane Okay, so you’ve got a lot of coaching behavior and a lot of leadership behavior as well. So is it expected that the business owner within SAFE would do those things?
Fredrik I’m 100 percent certain it’s because I’ve been a Scrum Master before and bring that behavior with me.
Murray I’ve spoken to a couple of senior Safe trainers and they’ve told me they treat Safe as a toolkit. And because they have experience in other things, like scrum and lean and so on. They modify it in the direction of a lighter weight process. And they will argue that Safe has also changed and Is focused on goals and PI plans are not supposed to be fixed commitments. So that behavior doesn’t come from Safe, they argue.
Fredrik It makes sense to me. But then you might as well use Less because that’s exactly what Less says. Start with something small, minimal, and then use some different tools and try and just build onto it. Instead of having Safe, where you start with everything from the beginning and then take away things. Why start with a completely complicated package with everything? Why not just start small? Add things as you see them work. Adapt to the culture and the context and the organization you’re working with. For me, SAFE feels like you’re adding everything that is good into a big mishmash of things.
As if baking a cake you take everything you like strawberries, whipped cream and oh, bacon. I like bacon as well. Let’s put some bacon into it. Then tomatoes. I like tomatoes. Oh, we need something that is healthy. Let’s. Put some broccoli into it oh, and some caramel sauce. Then you get this mismatch and everything by itself is great. But together, it becomes not so good. ~~ ~~
Murray What’s the alternative? What would you recommend people do instead if they need to do a big program of work with large numbers of people.
Fredrik I would probably say do you really need to scale? Because the most effective teams I work with, no matter which organization, is small teams sitting next to the customer. They can make wonders. And for every team you add, you need so much more overhead. And efficiency goes down . Every time you double you don’t get doubled output. The outcome, that you get diminishes for every team that you add.
So I would say start small, start very simple, and if you’re going to do value streams, for example, Before you do that, make sure you have the prerequisites to create a value stream. Make sure you can have continuous integration or continuous deployment. And also make sure that there is the capability for the team to take something from start to end. That actually have the authority and the mandate to do it. So I would fix the underlying impediments, because if you start scaling and you don’t fix the impediments, you just bring them with you and they become worse, the bigger the scaling you have.
Murray You’ve talked about less a few times. What’s the value of less in your opinion?
Fredrik I think It’s much more lean. You have much less overhead. Where I worked as a head of product group, we had 20 teams. And we had one product owner. And then we had divided teams into areas of about five teams. And for each area, we had an area product owner. And that was basically overhead that we had. And then we had scrum teams. And the scrum teams were experienced. And in each area and each team, they had worked for a very long time, and they could actually take something from start to end without being dependent on others. Of course, in that implementation we had other problems preventing us from becoming really agile. And that was because we didn’t have DevOps and we had a monolith product. We couldn’t do fast testing and we couldn’t do automated testing, so we had test cycles that were three weeks if we had to test the entire product. So that implementation was actually to go towards more microservices, or at least breaking it down into modules that could be each deployed by itself in order to shorten the lead time to production. But from a management perspective and from an organizational perspective, Less was much more effective.
The negative thing I can say that the pressure on the product owner. And myself as an HPG was enormous. We worked so many hours it was just incredible and that is not needed in SAFe because you have so many roles and so much overhead. So in that sense, SAFe is more relaxed. And I also liked that Less is basically Scrum. It’s much more simple and easier to understand.
Murray Yeah, If you start doing Agile and you start raising issues, you’re going to find that a lot of those issues are impediments in the organization for everybody. So if you start tackling them and fixing them at a root cause level, then you’re starting to fix the organization to allow everybody to move faster. And then once you’ve got one team working well, you can have two teams, three, four, five teams and you can start to deal with scaling issues. We need some coordinated architecture across the teams. We needed some coordinated user experience design. So we maybe need an architect and a user experience designer to sit with the product owner and work across the teams. There’s a whole lot of patterns. You can choose the ones you want. You can inspect and adapt, you can tailor. But the point is that you can scale something that works rather than, scaling something that doesn’t.
~~ ~~ We had Scott Ambler on recently. He’s doing disciplined agile delivery with PMI and they’ve come up with something called choose your wow, or your ways of working. It’s a big menu of patterns that you can choose from with some guidance. Which, seems pretty good, actually.
Fredrik I’m not familiar with Disciplined Agile, but the concept seems interesting, but you need to know what to pick, or have the mindset of let’s try this, and if it doesn’t work for us, then let’s try something else.
Shane Yeah, personally I’m a toolkit fan. But yeah, you have to be given permission and have the ability to try something and go actually that toolkit piece didn’t work for us. What are we going to try next? For me, that’s all about inspecting, adapting and acting, that’s what we should be doing every day. So it fits with me more than what I see SAFE providing.
Fredrik Yeah.
Murray I guess you’re confirming things that we were quite worried about. And I’ve had some experience of. I think if you didn’t have all that experience with LESS and Scrum, you wouldn’t know there was a problem or an alternative.
Fredrik I guess then I would think, oh, this is probably how it should be. And that’s a false belief to have. And that’s why I think as well, if you don’t know anything else, it’s hard to question it. If you haven’t seen a working team and you haven’t seen a really effective team being able to deliver value, working close with customers all the time. You want to get back to that because you love that. Then you know what you want and then you strive to get that. And then you come into other companies and you just see the governance structure trying to work against that. Then you get frustrated. And then you want to fix this. How can I beat the governance system?
Murray I completely agree with that.
## Final Thoughts and Conclusion
Murray I also think it was interesting that we were able to go through the Agile values and say that safe only aligns with one of four of them and it does not align at all with the other three. It’s heavily process oriented, ~~ ~~PI contract oriented, plan focused. And yeah, it gets stuff done but it’s violating all of those other core values of the Agile Manifesto. Agile came out of the lightweight process movement, and Safe is definitely not lightweight. I’d like them to call it something else ~~ ~~maybe Rup 2. 0 because that would be more honest.
I also really like the direction you’re going in with Less and descaling, lots of customer collaboration fix the problem before you scale. Autonomous empowered teams that can deliver value from beginning to end.
Fredrik In the end, it’s all about creating the conditions for delivering as often as possible to get quick feedback and to navigate through all the risks to reach the goal. And it’s all about taking the right decisions. And we usually don’t take the right decision. And if you take a decision that is valid for three months. Then you get more disastrous effects. And if you take a decision that is valid for a week, because then you can change quicker.
Murray And I’d really like to get rid of PI planning as well. I think ~~ ~~it causes a lot of blockages.
Shane But it is a jewel in the crown, right? When I talk to people who are in a safe environment, all I hear is PI planning, followed by release train engineer. Those are the words I hear all the time. None of the other stuff ever gets told to me.
So my view I have a bias against SAFE. I don’t believe in it. I don’t believe I’ll ever do it. I Love that you’ve done Less. ~~ ~~ I’ve read about it. I’ve never managed to be lucky enough to work with people, to use it. But the Less way of thinking fits better with the way I think than SAFe does.
I believe SAFe is ~~ ~~a bunch of components. So I think there’s some value there by treating it as a pretty menu to find some things. The lean business case sounds interesting. Also, I like the 80, 60 40 capacity. We know that any estimate we do gets rougher and less accurate the more time it is. So when we look at what’s three or five iterations out, actually thinking that there’s less capacity is a good way of thinking about it.
I’d also echo what Murray said around the fact that you have been doing lots of different things in this space for so long. I really appreciate that as well, because I think that helped us have a balanced conversation given we’re not big fans of SAFE .
Murray It’s funny you talk about roleplaying games because I’m going off just after this to play roleplaying games with a group of friends that I’ve been playing with for 30 years.
Fredrik When I interview people for positions, I ask them, have you done role playing? And if they have, then I know that they actually can work together in a team very well and have an agile mindset.
Murray Cause there’s a lot of communication required and you do a lot of planning, but you’re also completely autonomous. And isn’t it funny that in our own lives, We can make decisions about mortgages, partners, divorces and marriages but at the workplace, we’re not expected to be able to make decisions about anything really, except minor things. There’s very little freedom in many organizations cause we don’t trust people.
Fredrik Correct. People spend five years as an engineer being trained to solve problems. And then you come into an organization and you’re not allowed to do that. Why?
Murray All right, ~~ ~~great to talk to you.
Shane Thank you. We’ll catch you all later.
Subscribe to the Non Nonsense Agile Podcast
We will email when we publish a new episode, no spam, pinky promise