Dispelling Agile Clickbait

[Darren] (0:02 - 0:22) Everyone's trying to have a piece of that cake without really having the agility to redirect, so you end up with something like Logitech's AI button on their mouse. Welcome to the DevOps Sauna, the podcast where we deep dive into the world of DevOps, platform engineering, security, and more as we explore the future of development. [Pinja] (0:22 - 0:32) Join us as we dive into the heart of DevOps, one story at a time. Whether you're a seasoned practitioner or only starting your DevOps journey, we're happy to welcome you into the DevOps Sauna. [Darren] (0:37 - 0:41) Welcome back to the DevOps Sauna. I'm here once again with Pinja. [Pinja] (0:42 - 0:43) Hey, how are you doing, Darren? [Darren] (0:43 - 0:51) I'm doing pretty good. I think as well as can be expected for a Tuesday. How about things on your side? [Pinja] (0:51 - 1:04) It is indeed again a Tuesday. It is going well. The weather here in Helsinki is kind of nice. Spring is really here, I think. I'm not sure how many second winters or third winters we're still going to get, but nevertheless, we're here. [Darren] (1:04 - 1:35) Yeah, it's been surprisingly nice outside. There was a topic we had in mind, which was something that keeps coming up on LinkedIn. Whenever we're on LinkedIn, we always stumble across these random people who want to declare things as a thing of the past. We've seen this with basically everything we've ever worked with. The one we're talking about now is we're seeing people saying agile is dead. I think this is more of a specialist subject for you, Pinja, but I have to start by asking, is Agile dead? [Pinja] (1:38 - 1:50) That's a very difficult question. The Agile as we know it or used to know it might be a thing in the past if I want to be very controversial about this opening statement here, perhaps. [Darren] (1:50 - 2:10) Okay, so it could be a thing of the past. As you know, I'm a technical person who, by nature of being a security person, tends to work alone a lot, so I've managed to avoid a lot of these frameworks and all of these things. Let's just get to the core of the point. Why are people so disappointed with Agile? [Pinja] (2:11 - 3:31) Let's take an organization that I've seen quite a many of these ones. We go in, and the management says, like, hey, we need new Agile ways of working. Could you please come and help us implement Scrum? Then we encounter these teams and they sit very crumbly there in the corner of the meeting room where we meet for the first time and they say, Scrum was the thing that made us fail in the first place. If we think of Scrum as a framework, there's a lot of things that they put on a piece of paper. For example, Scrum Guide. We who are familiar with Scrum, we know Scrum from their ceremonies. There are meetings that come across every usually two weeks or three weeks, depending on the length of the sprint. But it's often when we see an organization start with this, we see that they have added these so-called ceremonies, and then they wonder, why didn't we succeed? Why did nothing change? Usually that's where people have this disappointment. We did everything that the guide said. We can also take a Scaled Agile Framework called SAFe, and that's also the same thing. We just added this on top of our existing structure, our existing working, and we took everything that the guide said, but we failed. It just made us busier than ever and just crankier. [Darren] (3:31 - 4:06) This is what confuses me. When you're working in one of these methods, you have these sprints, you have these ending meetings, you have dailies, all to catch up with what's going on. Then in other episodes, we're talking about developer experience, where we're talking about wanting to make things better for the developers and get out of the developer's ways. Now, this framework just seems to be about adding overhead. What happens here? The benefit is obviously, I think we actually have to take it back further. What's the purpose of Agile? [Pinja] (4:07 - 5:18) Let's talk about, perhaps let's even take one more step back and let's talk about Agility instead of Agile. If a company, an organization is Agile, what does it mean? Let's go to the terminology, so Business Agility, for example. Now we're talking more than just teams doing Scrum, teams using time in their dailies or their sprint demos, but basically the business's ability to adapt quickly and effectively to changes, because that's what Business Agility is all about. If we think of the future, for example, and I think it's safe to say that even though some of us try, we're still unable to predict it, and there are so many unknowns. What I say is going to happen in the next six months is definitely not going to happen 100% as I predicted. We don't know it, and definitely it will be different, but for sure it will be different from what I think it would also be. When we say that an organization or a business is Agile, so that there is Business Agility, the organization is able to adapt to these kinds of changes because nobody can see into the future. [Darren] (5:19 - 6:19) Okay, then I have to ask the question from a security perspective. NIST 2.0, the security framework from the EU, came into knowledge a year before it was implemented, and most companies are still struggling to catch up with it. They had a year of notice. They had now six months of implementation time. Can I ask if any businesses are actually Agile? The same happened with the ISO 27001 certificate. That process went through a new version in 2022 and there was like a, I think, three-year changeover period to go from the 2013 version to the 2022 version. So a nine-year cycle with a three-year release gap. They basically have three years to update it and there are still companies who are just starting the process now. So it's like, where is this Business Agility? I'm really struggling to see it. [Pinja] (6:20 - 7:24) It is, yeah, well, it's not some blob in the quarter that we can definitely see. It is not in the organizational models often. Some people say that it's in the Scaled Agile Framework or save the organizational picture that they have built. But it's, yeah, that's actually a very good question. Why are still so many companies unable to adapt to these kinds of changes? So we've known of a change. We do have, let's say, we have our goals that exist in the company, and we want to deliver x value to our customers. We want to deliver y value to our customers. We want to fix our technical debt, and at the same time, we want to actually implement the NIST 2.0 requirements. So does our list of priorities actually adapt to that kind of a change? And what does it mean when we say that now we need to use this amount of time, this many resources to NIST 2.0, as an example, instead of our prior engagement, prior decisions, and prior priorities? [Darren] (7:25 - 7:45) Okay, so if we talk about SAFe for a moment, because if we bring it back to the definition of Agility, Agility tends to be someone who is small and nimble, and that's what the idea is. SAFe is then scaling up, and if you scale Agile up, does SAFe not kind of break the ideas of Agility? [Pinja] (7:45 - 8:47) This has been discussed many times in different circles. Is SAFe actually agile or not? And I think there is a safe place for SAFe. I'm kind of avoiding your question, Darren, for a moment here. And there is a place and a time for it, definitely, because we, as it says, it's scaled. So we take one Scrum team and then we apply multiple Scrum teams, and all of a sudden we have an Agile release train. So, how do you manage that in a very Agile manner? It's to say something that is small and nimble, perhaps, but is able to make quick changes based on the changing scenarios and changing situations. But what if you have a ship to maneuver like this? So we do not perhaps break the idea of Agility, but for bigger organizations, if it's not SAFe or something equivalent, then what really? I'm not saying everybody should follow SAFe now, but it does kind of bring some sense of organization to the big companies. So it has its time and a place. [Darren] (8:48 - 9:00) So it's something like a compromise between as much Agility as you can get while acknowledging the fact that you're a giant corporation who just can't maneuver that quickly? [Pinja] (9:00 - 10:26) You would say that, yeah, because when you actually start building this huge organization, you want to give as much autonomy to the teams as possible. But then again, you need to be aligned with those decisions that are being made. Let's say you have a banking system, and you have five teams that are working in the same system within the bank. And in the bank, you always have those connections. You have your legacy system, you have your customer management system,s and everything in between. And whenever you make those changes, you need to consider the others. So, how do you secure that everybody's aligned? Does it mean that you take your Scrum Master to every single meeting with the business owners of the other systems? Or do you add an additional layer where you have somebody called the Epic owner who's responsible for the bigger piece of work called the Epic? And do you then add the business owner who's responsible for the higher level business discussions so that you don't have to bring everybody into those same discussions, but you have a very detailed, let's say, a table or something, a RACI table, for example, to detail what can the team design on their own to give them as much autonomy as possible. So it's a bit of a compromise. But then again, if you want transparency, if you want the cooperation between the different parts of the organization, then that might be your choice. And I'm not saying that this is the only option, aside from anarchy, basically, but it's an option. [Darren] (10:26 - 11:08) Yeah, I'm not sure anarchy is an option that I think a lot of people will go for, at least not deliberately, it may end up in that direction. But so it sounds like the situation people end up in is this compromise between accountability and this autonomy. And that is why people are saying Agile is dead, because they're running into these frameworks which are promising agile as something that will just allow for freedom of movement, and then what is being sold is kind of colliding head-on with reality of an inertia-bound organization. Is this the point people are trying to make when they're saying Agile is dead? [Pinja] (11:09 - 12:15) That's when I've been reading these LinkedIn posts, because I'm always interested when somebody says Agile is dead, and they gain maybe 1,000 likes or interactions within the first hour, because yes, we really want to see Agile dead. But then again, we look at these pieces of paper, the frameworks that we got, we could look at the Scrum Guide and the Scaled Agile Framework, for example, and they're based on an ideal situation, which does not happen in real life. So I see more and more of our customers and other companies as well to look beyond the frameworks and see what is actually that would bring us Agility as a company. So maybe they might be taking some essence of Scrum, they might be taking some principles from there, but they're making their own, because we have different kinds of companies, and they have their own special characteristics as well. So we cannot say that this framework, for example, Scrum, would work for every single company. And to be honest, I have never seen any company do Scrum by the book and succeed. [Darren] (12:15 - 12:56) Okay, so people get too attached to these frameworks, they don't understand that there is a flexible and a kind of mutable element to it, based on the company itself. I can see why that would be frustrating for probably everyone involved actually, because if you have an Agile Coach trying to teach everything by the book and a company that has the misfortune of existing in reality and having to deal with this kind of position where the ideal situation is quite far at times from what it should be, like trying to apply a set of rigid rules to that doesn't seem like it's going to be helpful to anyone. [Pinja] (12:57 - 15:03) No, it is not helpful to anybody. And there is a reason why these frameworks are proposing what they are proposing. So it does come from the whole idea of, hey, let's share information, let's enable communication between people and different parts of organization. We want to enable getting rid of blockers as fast as possible. So we get back in time, let's say the days of Lean. Let's get rid of waste, for example. How do we get rid of waste? We have to talk to one another, of course. So I have a blocker, I cannot proceed. I need somebody from the other team, for example, to help me. I need somebody in my own team to help me solve this blocker. How can we do that? And if I'm just sitting in my own lair here at home and not talking to anybody, I've pulled the curtains and I'm just sitting with my own code here. That's usually not the way to solve that problem and that blocker. But let's say we get together once a day in an ideal situation, if everybody was working on the same thing, that might actually help. And now I'm, of course, exaggerating here, as we know. But it's about just checking as often as possible, are we on the correct track? So we have our goal, the goal might not change. We want to deliver the value, we want to implement this to whatever it is. So it's about checking the direction often in the team. And then, when we scale up from that, is our ship or the actual release training, the Scaled Agile Framework, for example, is that still on the correct path? And if it's not, how do we fix that? But if we think of organizations and teams, having a daily once a day might work for somebody. But if you have a team that is working on multiple different things, do they want to sit in a daily meeting every single day and listen to something that doesn't actually help them forward, or where they cannot help the others go forward? That is bound to cause some friction in the team and the organization. [Darren] (15:04 - 15:52) Yeah, so it sounds like maybe framework is, because I feel like framework is something that people will understand as like a minimum set of something that they can build on, when actually these are something closer to guidelines, like you're not supposed to do everything. You're supposed to mix and match the parts that work for your company, the parts that work for you. Like, as you mentioned, I worked on a project where there was an eight o'clock daily meeting every morning, and anyone who knows me knows I'm not awake until half past 10. So that didn't work for that particular project. And you actually, in our notes for this, you wrote this interesting thing that you wrote about cargo cult thinking. And can you explain more about that and this lack of flexibility? [Pinja] (15:53 - 16:38) It is the, if we think of the rigid following of the frameworks, it's kind of the, actually, the very opposite of Agility, at least from my opinion. And we want to have the ability to redirect when we see that something is not working. And too often we see that. I'm not saying this is the fault of Agile coaches or anything. I'm not saying that this is completely the fault of organizations themselves, that they tried on their own, and they didn't succeed. But it is often the, let's say, essence of Agility that we keep on forgetting. The frameworks are nice. They're nice on paper. They give us some help ahead. But if we start looking at them in a too strict of a way, we don't get anywhere with the process. [Darren] (16:39 - 17:20) Yeah. And it seems like that's kind of built into the definition of being Agile. It's the ability to change direction. Like you have a framework that's designed to help an idealized, but still large inertia-bound organization move direction. So, of course, it's not going to apply directly to you, but there should be things in there for you to take to maybe not be fully Agile because change is difficult. Redirection is difficult. The momentum that's built off in these projects is not just something that dissipates immediately unless you're running extremely small teams, or maybe you're in a startup situation. [Pinja] (17:20 - 18:22) Yes. Those are a completely different situation. Let's say startups are a perfect example where you can apply the, we call it the PDCA loop. So the plan, the do, the check, and adjust loop at a very fast pace. One of the key principles of Agility is that you plan something, you do something, then you check, was this the correct thing to do? Did this take us into the correct direction? And then you adjust accordingly. And of course, we want these feedback loops to be as fast as possible. And when I say as fast as possible, that means also as fast as it makes sense to be, for example. But in a startup, you can do that as often as you want, right? Because you have a small organization. Everybody knows one another. Everybody should be aligned in the direction. And you might work in the same office. You see all the three people that you have in the company. But we take a large bank that's got tens of thousands of employees and thousands of people already in IT. It is not as easy to work it that way. [Darren] (18:22 - 19:29) Yeah. The numerics of Agile kind of stagger me because we talk about backlog refinement. So we have these traditional implementations. You get everyone in a room for two hours, once every two weeks, you end up with like 20 people sitting in a room for two hours that turns into like half of FTE just of backlog refinement. You've basically hired half a person just to refine the backlog. And then that doesn't seem like an agile thing to do. Because we've looked at value stream mapping quite a bit. And we have this one picture in Eficode that's like, its defined value being added in essentially two steps out of the entire stream. And that's when coders are coding and committing and building. So the idea that your agile solution would have a person whose half of their job would be basically backlog refinement, that's just, that's a huge amount to go into it. It works if you have three people, but 20 people in a team, even larger, that's just, this is overhead that I don't think needs to be there. [Pinja] (19:30 - 21:18) Yeah. And many times when we talk to organizations who are struggling with this, like, Hey, we, like we have people who are sitting in the meeting and they have nothing to say about these items that we're refining here. What do we do? And one of the first things I say is like, look, you can actually scale this down to a half an hour meeting, basically every two weeks. And it will be an information sharing meeting. It's a checkpoint. So the actual refinement work happens somewhere else. So you don't have to sit in a two-hour meeting, trying to multitask at the same time as somebody is talking about something else that doesn't really apply to you at all. And actually have the refinement work done somewhere else outside of that meeting. And I often use this analogy that if you take the Scrum book as an example, the Scrum guide as a recipe book, and then you might know, for example, that this is what I need to do in order to get the muffin. So then what do we add? We want to add the eggs. Okay. So that might be the backlog refinement. And this is where I'm saying that refining your backlog is kind of essential. We call it as one of the silver bullets of Agility. But does it need to happen in a meeting? But when you get more familiar with the recipe, for example, you get more familiar. What does the egg and this in case the backlog refinement do? You might be able to substitute something else, with another way of doing it. Let's say you don't want to eat eggs. You might be allergic. You might be a vegan. You might want to substitute that for a banana. So it might do the same thing. Let's say the backlog refinement practices outside a meeting might do the same thing as sitting in a backlog refinement session for two hours every two weeks. But it is crucial to know why a Scrum guide says that I should do this for a couple of hours every two weeks instead of just taking it away immediately. That, well, it doesn't work. It doesn't apply to us. So let's just get rid of it. [Darren] (21:19 - 21:48) So what you've described so far, it sounds like these are business processes, but it seems to be more about the people and how people's brains work and how they engage with their work. So, like, yeah, it seems obvious not to have people in backlog refinements if they're not adding things to it. But it seems to be trying to, like, form the company in a way that teaches the people how to move forward correctly rather than having these rigid rules. [Pinja] (21:48 - 22:53) Yeah, that's very much what I, at least myself, think about this is the principles behind all of this, even if I was not part of refining a task or a work item, let's say. But it might be very crucial for me to be informed about it. We need to share the information. We need to be aware of what's going on. And in order to be self-organizing, which is one of the key goals of Agility as well, so that we don't have to take every single decision to a committee meeting, as an example. But we need to be aware, where are we going? Do we have the strategy aligned in order to get our vision in place? Those are very key principles here. And once we have the, let's say we have the mandate, the team has a mandate to make decisions. They have the ability to communicate in a way that suits them and is in line with everybody, what they're doing in the organization. And then we have our ways of doing it. And actually we're sharing the information. Everybody then can actually check if we're, again, going towards the same goal that we have agreed. [Darren] (22:53 - 23:18) Okay. So there's a lot of what I would say opposing mentalities when it comes to development work. You have ideas like asking forgiveness and not permission. You have ideas like move fast and break things. So I'm just, I'm trying to, I guess these frameworks are then the way of trying to maybe not crush these mentalities, but at least direct them in the correct way. [Pinja] (23:18 - 24:03) Yeah. And I hear it often that moving fast, breaking things, or failing fast is one of the phrases being used, but it's more about let's learn fast. What is, what do we need to do? What should we not do? We as people, we always want to simplify things in order to understand them as like, I use the recipe analogy myself. It's a way for me to understand this better. And it's a way that I've been teaching some of the organizations that I've been consulting and coaching in how to understand this better. So these frameworks as well, they are a way of simplifying things because sometimes we do need models. And that's one of the common sayings in consultancy is that all models are wrong. Some are more useful than the others, but real life cannot be put on a piece of paper. That's for sure. [Darren] (24:03 - 24:35) Yeah. I guess it goes back to the recipe analogy because you know, anyone can cook the muffin, but only you know how your oven works. Only you know where it is good to bake in the oven. It's like, it brings it back to the idea that everything needs to be a bit more flexible. One question about that though, is there like a limit? One thing I'm thinking is like, we have this idea of too large to fail. Do you think that applies to Agility? Are there just companies that are so large that Agility doesn't apply, or shouldn't apply? Can they just barrel forwards? [Pinja] (24:36 - 25:09) I have not yet seen a company that would not benefit from Business Agility. I have seen companies that might not benefit from Scrum, but Business Agility is an inherent, let's say, characteristic of an organization that might benefit you. If we think of the very essential definition of Business Agility, it is the business's ability to change when something comes up. Because I'm not sure if there is an industry or a company that has not faced any changes, especially in the past couple of years. [Darren] (25:09 - 26:03) Yeah, I don't think we'd find a company like that very quickly. So basically what you're saying is Agile is good on all scales, or at least applicable on all scales. So the idea of it being dead is probably clickbait. But if there's one actual thing we can add here as a concrete reason why Agility is important, I think it would probably be AI, just because the development of AI is going so quickly and accelerating so quickly. We're seeing exponential rates of change. And the idea that maybe a company is not able to redirect quickly enough to take advantage of these things. Or I think we see a lot of weird things happening in AI. So everyone's trying to have a piece of that cake without really having the agility to redirect. So you end up with Logitech's AI button on their mouse. [Pinja] (26:05 - 26:58) Yeah, they figured that everybody needs an AI button on their mouse and at their disposal at all times. And this is a really good example, because of what we've seen in the past couple of years with the rise of generative AI and LLMs, because they become household tools for everybody, not just for organizations, but for private people as well. So being able to respond to that change. There aren't that many industries that can just bypass this development in our time and in the technology field, basically. But it's, again, the one key thing what I've seen with companies is that if you try to add AI, whatever it is, if it's, let's say, it's GitHub's Copilot, it's ChatGPT ability for your business people, but if you add that to your organization, your organization is non-agile on a business level, you're not going to end up with Agility in the end. That's for sure. [Darren] (26:58 - 27:20) And I think that's something we need in the times of AI, because if you're not able to react to the changes, your AI might be useful and functional at this point in time, and next week, it will be a relic. It could already be a dinosaur, and you're struggling to catch up. So it feels like AI solidifies the role of Agility. [Pinja] (27:21 - 28:00) It does. And one thing to add here is that, yes, we do often think of an Agile person, somebody who's small and nimble. But if we think of a football player on a field, what does it take for that player to be Agile? They have a goal, a literal goal to make here. So they know what their vision is, but it has taken hours, tens of thousands of hours, at a minimum level, to get to that point where they can be changing their direction when their opponent is running towards them, for example. And the same thing here. You need to have a goal, we need to have a strategy, those in place. Otherwise, you don't know what you're going to do when the change hits you and the organization. [Darren] (28:00 - 28:08) So, do you think we can then debunk the claim? Can we just say Agile is not dead, Agile is very much alive, and you're just doing it wrong? [Pinja] (28:10 - 28:17) Yeah, I think it's safe to say that Agility is very much needed, especially in the current times when things are changing so fast. [Darren] (28:18 - 28:42) But if you're sticking to these rigid frameworks, it's not going to help. You can't apply a rulebook to your company full of living, breathing people who have different ways of working, who have different ways of existing, and all of them, for every reason, require flexibility. You can't just take a generic set of rules and throw it at the company and hope that, oh, this will make us Agile. [Pinja] (28:43 - 29:03) Correct. So it's as if you're trying to make the muffins and you forget that, or try to overlook the fact that you're allergic to those eggs. So you need to be able to modify the recipe to your own diet, and not just apply it just as a, hey, let's add on this, and this will be looking really good when we glue this on top of everything else. You'll get a stomach ache from that. [Darren] (29:04 - 29:17) Yeah, that doesn't sound pleasant, but I am glad we managed to dispel this particular bit of clickbait. I don't know if we're going to be dispelling more clickbait going forward, but there's plenty of it on LinkedIn to be dealt with, so maybe we'll get back to it. [Pinja] (29:17 - 29:17) For sure. [Darren] (29:17 - 29:20) That's all we have time for. Thank you for joining me again, Pinja. [Pinja] (29:20 - 29:22) Thanks, Darren. It was fun. [Darren] (29:22 - 29:24) And we hope you join us next time in the zone. [Pinja] (29:30 - 29:33) We'll now tell you a little bit about who we are. [Darren] (29:33 - 29:35) I'm Darren Richardson, security consultant at Eficode. [Pinja] (29:36 - 29:40) I'm Pinja Kujala. I specialize in Agile and portfolio management topics at Eficode. [Darren] (29:40 - 29:43) Thanks for tuning in. We'll catch you next time. [Pinja] (29:43 - 29:51)