Easy Agile Podcast Ep.15 The Role of Business in Supporting Sustainability Initiatives with TietoEVRY

In this insightful episode, we dive deep into one of the most common frustrations in engineering and dev teams: retrospectives that fail to drive meaningful change. Join Jaclyn Smith, Senior Product Manager at Easy Agile, and Shane Raubenheimer, Agile Technical Consultant at Adaptavist, as they unpack why retrospectives often become checkbox exercises and share practical strategies for transforming them into powerful engines of continuous improvement.

Want to put these insights into practice? We hosted a live, hands-on retro action workshop to show you exactly how to transform your retrospectives with practical tools and techniques you can implement immediately.

Key topics covered:

• Common retrospective anti-patterns and why teams become disengaged
• The critical importance of treating action items as "first-class citizens"
• How to surface recurring themes and environmental issues beyond team control
• Practical strategies for breaking down overwhelming improvement initiatives
• The need for leadership buy-in and organizational support for retrospective outcomes
• Moving from "doing agile" to "being agile" through effective reflection and action

This conversation is packed with insights for making your retrospectives more impactful and driving real organizational change.

About our guests

Jaclyn Smith is a Senior Product Manager at Easy Agile, where she leads the Easy Agile TeamRhythm product that helps teams realize the full benefits of their practices. With over five years of experience as both an in-house and consulting agile coach, Jaclyn has worked across diverse industries helping teams improve their ways of working. At Easy Agile, she focuses on empowering teams to break down work effectively, estimate accurately, and most importantly, take meaningful action to continuously improve their delivery and collaboration.

Shane Raubenheimer is an Agile Technical Consultant at Adaptavist, a global family of companies that combines teamwork, technology, and processes to help businesses excel. Adaptavist specializes in agile consulting, helping organizations deliver customer value through agile health checks, coaching, assessments, and implementing agile at scale. Shane brings extensive experience working across multiple industries—from petrochemical to IT, digital television, and food industries—applying agile philosophy to solve complex organizational challenges. His expertise spans both the technical and cultural aspects of agile transformation.

Transcript

This transcript has been lightly edited for clarity and readability while maintaining the authentic conversation flow.

Opening and introductions

Jaclyn Smith: Hi everyone, and welcome back to the Easy Agile Podcast. Today I'm talking to Shane Raubenheimer, who's with us from Adaptavist. Today we're talking about why your retrospectives keep failing and how to finally fix them. Shane, you and I have spent a fair amount of time together exploring the topic of retros, haven't we? Do you want to tell us a little bit about yourself first?

Shane Raubenheimer: Yeah, hello everyone. I'm Shane Raubenheimer from Adaptavist. I am an agile coach and technical consultant, and along with Jaclyn, we've had loads of conversations around why retros don't work and how they just become tick-box exercises. Hopefully we're going to demystify some of that today.

Jaclyn Smith: Excellent. What's your background, Shane? What kind of companies have you worked with?

Shane Raubenheimer: I've been privileged enough to work across multiple industries—everything from petrochemical to IT, to digital television, food industry. All different types of applied work, but with the agile philosophy.

Jaclyn Smith: Excellent, a big broad range. I should introduce myself as well. My name is Jaclyn. I am a Senior Product Manager here at Easy Agile, and I look after our Team Rhythm product, which helps teams realize the benefits of being agile. I stumbled there because our whole purpose at Easy Agile is to enable our customers to realize the benefits of being agile.

My product focuses on team and teamwork, and teamwork happens at every level as we know. So helping our customers break down work and estimate work, reflect—which is what we're talking about today—and most importantly, take action to improve their ways of working. I am an agile coach by trade as well as a product manager, and spent about five years in a heap of different industries, both as a consultant like you Shane, and as an in-house coach as well.

The core problem: When retrospectives become checkbox exercises

Jaclyn Smith: All right, let's jump in. My first question for you Shane—I hear a lot that teams get a bit bored with retros, or they face recurring issues in their retrospectives. Is that your experience? Tell me about what you've seen.

Shane Raubenheimer: Absolutely. I think often what should be a positive rollup and action of a sequence of work turns out to normally become a checkbox exercise. There's a lot of latency in the things that get uncovered and discussed, and they just tend to perpetually roll over. It almost becomes a checkbox exercise from what I've seen, rather than the mechanism to actively change what is happening within the team—but more importantly, from influences outside the team.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

I think that's where retros fail, because often the team does not have the capability to do any kind of upward or downstream problem solving. They tend to just mull about different ways to ease the issues within the team by pivoting the issues rather than solving them.

Jaclyn Smith: Yeah, I would agree. Something that I see regularly too is because they become that checkbox, teams get really bored of them. They do them because they're part of their sprint, part of their work, but they're not engaged in them anymore. It's just this thing that they have to do.

It also can promote a tendency to just look at what's recently happened and within their sphere of influence to solve. Whereas I think a lot of the issues that sometimes pop up are things that leadership need to help teams resolve, or they need help to solve. It can end up with them really focusing on "Oh well, there's this one bit in how we do our code reviews, we've got control over that, we'll try to fix that." Or as you say, the same recurring issues come up and they don't seem to get fixed—they're just the same complaints every time.

Shane Raubenheimer: Absolutely. You find ways that you put a band-aid on them just so you can get through to the next phase. I think the problem with that is the impact that broader issues have on teams is never completely solvable within that space, and it's no one else's mandate necessarily to do it. When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

When an issue is relatable to a team, exposing why it's not a team-specific issue and it's more environmental or potentially process-driven—that's the bit that I feel keeps getting missed.

The pressure problem and overwhelming solutions

Jaclyn Smith: Yeah, I think so too. The other thing you just sparked for me—the recurring issue—I think that also happens when the team are under pressure and they don't feel like they have the time to solve the problems. They just need to get into the next sprint, they need to get the next bit of work done. Or maybe that thing that they need to solve is actually a larger thing—it's not something small that they can just change.

They need to rethink things like testing strategies. If that's not working for you, and it's not just about fixing a few flaky tests, but you need to re-look at how you're approaching testing—it seems overwhelming and a bit too big.

Shane Raubenheimer: Absolutely. Often environmental issues are ignored in favor of what you've been mandated to do. You almost retrofit the thing as best you can because it's an environmental issue. But finding ways to expose that as a broader-based issue—I think that should be the only output, especially if it's environmental and not team-based.

The problem of forgotten action items

Jaclyn Smith: Something I've also seen recently is that teams will come up with great ideas of things that they could do. As I said before, sometimes they're under pressure and they don't feel they have the capacity to make those changes. Sometimes those actions get talked about, everyone thinks it's a wonderful idea, and then they just get forgotten about. Teams end up with this big long backlog of wonderful experiments and things that they could have tried that have just been out of sight, out of mind. Have you seen much of that yourself?

Shane Raubenheimer: Plenty. Yes, and often teams err on the side of what's expected of them rather than innovate or optimize. I think that's really where explaining the retrospective concept to people outside fully-stacked or insular teams is the point here. You need, very much like in change management, somebody outside the constructs of teams to almost champion that directive—the same way as you would do lobbying for money or transformation. It needs to be taken more seriously and incorporated into not just teams being mini-factories supporting a whole.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way. Naturally you get team-level ones, and that's normally where retrospectives do go well because it's the art of the possible and what you're mandated to do. I think bridging the gap between what we can fix ourselves and who can help us expose it is a big thing.

I see so much great work going to waste because it simply isn't part of the day job, or should be but isn't.

You transform at a company level, you change-manage at a company level. So you should action retrospective influences in the same way.

Making action items first-class citizens

Jaclyn Smith: Yeah, absolutely. I know particularly in the pre-Covid times when we were doing a lot of retros in person, or mostly in person with stickies on walls, I also found even if we took a snapshot of the action column, it would still end up on a Confluence board or something somewhere and get forgotten about. Then the next retro comes around and you sort of feel like you're starting fresh and just looking at the last sprint again. You're like, "Oh yeah, someone raised that last retro, but we still didn't do anything about that."

Shane Raubenheimer: I think Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself. Because it doesn't matter how good you are if the impediments that are outside of your control are not managed or treated with the same kind of importance as the actual work you're doing. That'll never change, it'll just perpetuate. Sooner or later you hit critical mass. There's no scenario where your predictability or velocity gets better if these things are inherent to an environment you can't control.

Product Owners, Scrum Masters, or any versions of those kinds of roles need to treat environmental change or anti-pattern change as seriously as they treat grooming work—the actual work itself.

Jaclyn Smith: Yeah, that's true. We've talked about action items being first-class citizens and how we help teams do that for that exact reason. Because a retro is helpful to build relationships and empathy amongst the team for what's happening for each of them and feel a sense of community within their team. But the real change comes from these incremental changes that are made—the conversations that spark the important things to do to make those changes to improve how the team works.

That action component is really the critical part, or maybe one of two critical parts of a retro. I feel like sometimes it's the forgotten child of the retro. Everyone focuses a lot on engaging people in getting their ideas out, and there's not as much time spent on the action items and what's going to be done or changed as a result.

Beyond team-level retrospectives

Shane Raubenheimer: Absolutely, consistently. I think it's symptomatic potentially of how retros are perceived. They're perceived as an inward-facing, insular reevaluation of what a team is doing. But I've always thought, in the same way you have the concept of team of teams, or if you're in a scaled environment like PI planning, I feel retrospectives need the same treatment or need to be invited to the VIP section to become part of that.

Because retrospectives—yes, they're insular or introspective—but they need to be exposed at the same kind of level as things like managing your releases or training or QA, and they're not.

Jaclyn Smith: Yeah, I think like a lot of things, they've fallen foul of the sometimes contentious "agile" word. People tend to think, "Oh retros, it's just one of those agile ceremonies or agile things that you do." The purpose of them can get really lost in that, and how useful they can be in creating change. At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

At the end of the day, it's about improving the business outcomes. That's why all of these things are in place—you want to improve how well you work together so that you can get to the outcome quicker.

Shane Raubenheimer: Absolutely. Outcome being the operative word, not successfully deploying code or...

Jaclyn Smith: Or ticking the retro box, successfully having a retro.

Shane Raubenheimer: Yeah, exactly. Being doing agile instead of being agile, right?

Expanding the scope of retrospectives

Jaclyn Smith: One hundred percent. It also strikes me that there is still a tendency for retros to be only at a team level and only a reflection of the most recent period of time. So particularly if a team are doing Scrum or some version of Scrum with sprints, to look back over just the most recent period. I think sometimes the two things—the intent of a retro but also the prime directive of the retro—gets lost.

In terms of intent, you can run a retro about anything. Think about a post-mortem when you have an incident and everyone gets together to discuss what happened and how we prevent that in the future. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

You can run a retro about anything. I think people forget that you can have a retro and look at your system of work, and even hone in on something like "How are we estimating? Are we doing that well? Do we need to improve how we're doing that?" Take one portion of what you're working on and interrogate it.

Understanding anti-patterns

Shane Raubenheimer: Absolutely. You just default to "what looks good, what can we change, what did we do, what should we stop or start doing?" That's great and all, but without some kind of trended analysis over a period of time, you might just be resurfacing issues that have been there all along. I think that's where the concept or the lack of understanding of anti-patterns comes in, because you're measuring something that's happened again rather than measuring or quantifying why is it happening at all.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

I think that's the big mistake of retros—it's almost like an iterative band-aid.

Jaclyn Smith: Yeah. Tell me a little bit more about some of the anti-patterns that you have seen or how they come into play.

Shane Raubenheimer: One of them we've just touched on—I think the buzzword for it is the cargo cult culture for agile. That's just cookie-cutting agile, doing agile because you have to instead of being agile. Literally making things like your stand-up or your review or even planning just becomes "okay, well we've got to do this, so we've ticked the box and we're following through."

Not understanding the boundaries of what your method is—whether you like playing "wagile" or whether you're waterfall sometimes, agile at other times, and you mistake that variability as your agility. But instead, you don't actually have an identity. You're course-correcting blindly based on what's proportionate to what kind of fire you've got in your way.

Another big anti-pattern is not understanding the concept of what a team culture means and why it's important to have a team goal or a working agreement for your team. Almost your internal contracting. We do it as employees, right?

I think a lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally. That's simply not a thing.

A lot of other anti-patterns come in where something's exposed within a team process, and because it's not interrogated or cross-referenced across your broader base of teams, it's not even recognized as a symptom. It is just a static issue. For me, that's a real anti-pattern in a lot of ways—lack of directive around what to do with retrospectives externally as well as internally.

Jaclyn Smith: Yeah, I think that's a good call-out for anyone watching or listening. If you're not familiar with anti-patterns, they're common but ineffective responses to recurring problems. They may seem helpful initially to solve an immediate problem, but they ultimately lead to negative outcomes.

Shane, what you just spoke about there with retrospectives—an example of that is that the team feel disengaged with retrospectives and they're not getting anything useful out of it, or change isn't resulting from the retrospectives. So the solution is to not hold them as frequently, or to stop doing them, or not do them at different levels or at different times. That's a really good example of an anti-pattern. It does appear to fix the problem, but longer term it causes more problems than it solves.

Another one that I see is with breaking down work. The idea that spending time together to understand and gain a shared understanding of the work and the outcome that you need takes a lot of time, and breaking down that work and getting aligned on how that work is going to break down on paper can look like quite an investment. But it's also saving time at the other end, reducing risk, reducing duplication and rework to get a better outcome quicker. You shift the time spent—development contracts because you've spent a little bit more time discovering and understanding what you're doing.

A common anti-pattern that I see there is "we spent way too long looking at this, so we're going to not do discovery in the same way anymore," or "one person's going to look at that and break it down."

The budget analogy

Shane Raubenheimer: I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

I always liken it to your budget. The retrospective is always the nice shiny holiday—it's always the first to go.

Jaclyn Smith: It's the contractor.

Shane Raubenheimer: Yeah. It's almost like exposing stuff that everybody allegedly knows to each other is almost seen as counterintuitive because "we're just talking about stuff we all know." It often gets conflated into "okay, we'll just do that in planning." But the reality is the concept of planning and how you amend what you've done in the retrospective—that's a huge anti-pattern because flattening those structures from a ceremonies perspective is what teams tend to do because of your point of "well, we're running out of daylight for doing actual development."

But it's hitting your head against the wall repeatedly and hoping for a different outcome without actually implying a different outcome. Use a different wall even. I think it's because people are so disillusioned with retrospectives. I firmly believe it's not an internal issue. I believe if the voices are being heard at a budgeting level or at a management level, it will change the whole concept of the retrospective.

Solution 1: Getting leadership buy-in

Jaclyn Smith: I like it, and that's a good thread to move on to. So what do we do about it? How do we help change this? What are some of the practical tips that people can deploy?

Shane Raubenheimer: A big practical tip—and this is going to sound like an obvious one—is actual and sincere buy-in. What I mean by that is, as a shareholder, if I am basing your performance and your effectiveness on the quality and output of the work that you're promising me, then I should be taking the issues that you're having that are repeating more seriously.

Because if you're course-correcting for five, six, or seven sprints and you're still not getting this increasing, predictable velocity, and if it's not your team size or your attitude, it's got to be something else. I often relate that to it being environmental.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table, and I think that's a big one.

Buying into the outputs for change the same way as you would into keeping everyone honest, managing budgets, and chasing deadlines—it should all be part of the same thing. They should all be sitting at the VIP table.

Solution 2: Making patterns visible

Jaclyn Smith: I think so too. Something that occurs to me, and it goes back to what we were talking about right at the beginning, is sometimes identifying that there's a pattern there and that the same thing keeps coming up isn't actually visible, and that's part of the problem, right?

I know some things we've been doing in Easy Agile TeamRhythm around that recently, attempting to help teams with this. We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've recently started surfacing all incomplete action items in retrospectives so people can see that big long list. Because they can convert their action items to Jira items or work items, they can also see where they've just been sitting and languishing in the backlog forever and a day and never been planned for anything to be done about them.

We've added a few features to sort and that kind of thing. Coming in the future—and we've been asked about this a lot—is "what about themes? What about things that are bubbling up?" So that's definitely on our radar that will be helpful.

I think that understanding that something has been raised—a problem getting support from another team, or with a broken tool or an outdated tool that needs to be replaced in the dev tooling or something like that—if that's been popping up time and time again and you don't know about it, then even as the leader of that team, you don't have the ammunition to then say "Look, this is how much it's slowed us down."

I think we live in such a data world now. If those actions are also where the evidence is that this is what needs to change and this is where the barriers are...

Solution 3: The power of trend analysis

Shane Raubenheimer: Certainly. I agree. Touching on the trend analytics approach—we do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application. We don't actually trend or theme, to your point.

We do trend analysis on everything except what isn't happening or what is actually going wrong, because we just track the fallout of said lack of application.

We theme everything when we plan, yet somehow we don't categorize performance issues as an example. If everybody's having a performance issue, that's the theme. We almost need to categorize or expose themes that are outward-facing, not just inward-facing. Because it's well and good saying "well, our automated testing system doesn't work"—what does that mean? Why doesn't it work?

I think it should inspire external investigation. When you do a master data cleanup, you don't just say "well, most of it looks good, let's just put it all in the new space." You literally interrogate it at its most definitive and lowest level. So why not do the same with theming and trending environmental issues that you could actually investigate, and that could become a new initiative that would be driven by a new team that didn't even know it was a thing?

Jaclyn Smith: Yeah, and you're also gathering data at that point to evidence the problem rather than "oh, it's a pain point that keeps coming up." It is, but it gives you the opportunity to quantify that pain point a little bit as well. I think that is sometimes really hard to do when you're talking about developer experience or team member experience. Even outside of product engineering teams, there are things in the employee experience that affect the ability for that delivery—whatever you're delivering—to run smoothly. You want to make that as slick as possible, and that's how you get the faster outcomes.

Solution 4: The human factor

Shane Raubenheimer: Absolutely. You can never underestimate the human factor as well. If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated. Because if you're hitting your head against the same issue regardless of how often you're pivoting, that can be very disillusioning, especially if it's not been taken as seriously as your work output.

If everything I'm doing and every member of my team is doing is to the best of not just their capability, but to the best of the ability in what they have available to them, you become jaded, you become frustrated.

We run a week late for a customer delivery or a customer project, and we start complaining about things like money, budget overspend, over-utilization. But identifying systematic or environmental issues that you can actually quantify should be treated in exactly the same way. I feel very strongly about this.

Solution 5: Breaking down overwhelming action items

Jaclyn Smith: We tend to nerd out about this stuff, Shane, and you're in good company. You've also reminded me—we've put together a bit of a workshop to help teams and people understand how to get the most out of their retrospectives, not just in terms of making them engaging, but fundamentally how to leverage actions to make them meaningful and impactful.

We've spoken a lot about the incremental change that is the critical factor when it is something that's within the team's control or closely to the team's control. That's how you get that expansion of impact—the slow incremental change. We've talked about sometimes those action items seem overwhelming and too big. What's your advice if that's the scenario for a team? What do you see happen and what can they do?

Shane Raubenheimer: I would suggest following the mantra of "if a story is too big, you don't understand enough about it yet, or it's not broken down far enough." Incremental change should be treated in exactly the same way. The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth.

If we're iterating work delivery, problem-solving should be done in rapid iteration as well. That's my view.

Jaclyn Smith: I like it.

The "eat the elephant one bite at a time" analogy. If it's insurmountable, identify a portion of it that will make it a degree less insurmountable next time, and so on and so forth. If we're iterating work delivery, problem-solving should be done in rapid iteration as well.

Wrapping up: What's next?

Jaclyn Smith: I think we're almost wrapping up in terms of time. What can people expect from us if they join our webinar on July 10th, I believe it is, where we dive and nerd out even more about this topic, Shane?

Shane Raubenheimer: I think the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

With our approach that we took to our workshop, I think people will very quickly get the feeling of "this is dealing with cause and effect in a cause and effect way." So practical—to put that in one sentence, an active showing or demonstration of how to quantify and actually do what we've been waxing lyrical about.

the benefit of the webinar is going to be a practical showing of what we're waxing lyrical about. It's easy to speak and evangelize, but I think from the webinar we'll show turning our concepts into actual actions that you can eyeball and see the results of.

‍Jaclyn Smith: Excellent. That was a lovely summation, Shane. If anyone is interested in joining, we urge you to do so. You can hear us talking more about that but get some practical help as well. There is a link to the registration page in the description below.

I think that's about all we have time for today. But Shane, as always, it's been amazing and lovely to chat to you and hear your thoughts on a pocket of the agile world and helping teams.

Shane Raubenheimer: Yeah, it's always great engaging with you. I always enjoy our times together, and it's been my pleasure. I live for this kind of thing.

Jaclyn Smith: It's wonderful! Excellent. Well, I will see you on the 10th, and hopefully we'll see everyone else as well.

Shane Raubenheimer: Perfect. Yeah, looking forward to it.

Jaclyn Smith: Thanks.

Ready to end the frustration of ineffective retrospectives?

Jaclyn Smith and Shane Raubenheimer also hosted a live, hands-on webinar designed to turn retrospectives into powerful engines for continuous improvement.

In this highly interactive session, they talked about how teams can:

• Uncover why retrospectives get stuck in repetitive cycles
• Clearly capture and assign actionable insights
• Identify and avoid common retrospective pitfalls and anti-patterns
• Get hands-on experience with Easy Agile TeamRhythm to streamline retrospective actions
• Practical tools, techniques, and clear next steps to immediately enhance retrospectives and drive meaningful team improvements.

👉 Watch the recording here.

In this episode, I was joined by Sherif Mansour - Distinguished Product Manager at Atlassian.

We spoke about styles of product management and the traits that make a great product manager. Before exploring the idea of a shared brain and the role of a product engineer.

Sherif has been in software development for over 15 years. During his time at Atlassian, he was responsible for Confluence, a popular content collaboration tool for teams.

Most recently, Sherif spends most of his days trying to solve problems across all of Atlassian’s cloud products. Sherif also played a key role in developing new products at Atlassian such as Stride, Team Calendars and Confluence Questions. Sherif thinks building simple products is hard and so is writing a simple, short bio.

Hope you enjoy the episode as much as I did. Thanks for a great conversation Sherif.

‍

Gerald shared that companies often face the same challenges over & over again when it comes to implementing agile, but the real challenge and most crucial is overcoming a fixed mindset.

‍

"Gerald helps massive companies work better together while keeping teams focused on people and on the customer. I'll be revisiting this episode."

Gerald also highlights the difference between consultants & coaches, and the value of having good mentors + more

I loved this episode and know you will too!

Be sure to subscribe, enjoy the episode 🎧

‍

Transcript

Sean Blake:

Hello, and welcome to this episode of the Easy Agile Podcast. Sean Blake here with you today. And we've got a great guest for you it's Gerald Cadden a Strategic Advisor and SAFe Program Consultant Trainer at Scaled Agile, Inc. Gerald is an experienced business, an IT professional, Strategic Advisor and Scaled Agile Program Consultant Trainer SPCT at Scaled Agile. Thanks, Gerald. Welcome to the Easy Agile Podcast. It's really great to have you on as a guest today, and thank you for spending a bit of time with us and sharing your expertise with our audience on the Easy Agile Podcast.

Sean Blake:

So I'm really interested and I'm interested in this story that... For all the guests that we have at the podcast, but can you tell me a little bit about your career today? I find that people find their way to these Agile roles or the Agile industry through so many diverse types of jobs in the past. Some people used to be plumbers or tradies, or they worked in finance or in banking. How did you find your way into working at somewhere like Scaled Agile?

Gerald Cadden:

Good morning, Sean. Thanks for having me here guys. I'm very happy to be here with you guys today. Career things are always an interesting question. I'm 53 and so when I look back I wonder how do I get to where I am? And you can often look at just a series of fortunate events. And I worked in retail shoe stores and then I decided to do something in my life. Did an IT diploma then did a degree and I started working in the IT side. I pretty much started as a developer because that was where the money was and so that's where you wanted to go. I didn't stay as a developer long. Okay. All right. I was a terrible developer so I wasn't good at it. It was frustrating.

Gerald Cadden:

I moved into some pre-sales work and that led me to doing business analysis and I really liked the BA work because I got to work with people and see changes. I could work with the developers, still got to work really directly with the customer which was much more interesting for me. So I spent a lot of time in BA doing the development work, doing business process reengineering my transitioned over to rational unified process. When it was around spent countless hours writing use cases doing your mail diagrams, convincing people on how to make the changes on those. And then Agile came along and I had to make a complete brain switch. So all of this stuff that I'd learned and depended on as a BA suddenly disappeared because Agile didn't require that as an upfront way of working. It required that to be in the background if you wanted it and it was more a collaboration.

Gerald Cadden:

So about 2004, 2005 started working with Agile a lot more by this time I was living in the U.S. So that's where I got my agile experience, stayed there for a long time. Got great experience and then I moved over to working with SAFe around 2011. The catalyst for that as I was working for the large financial firm in New York with a team there. And we were redesigning a large methodology for them to implement Agile at scale. Went to a seminar in 2011 at an Agile conference saw Dean Leffingwell presentation on SAFe and just looked up and went, "Well we can stop working on our methodology. It's done."

Gerald Cadden:

So hardly after that meeting I ran outside and tackled Dean Leffingwell because I wanted him to look at my diagrams and everything and give me some affirmation that I was doing the right thing. Dean is got a very frank face and he pulled his frank face and he looked at me and just said, "You know what? Just use SAFe?" And I'm like, "Yeah, we will." And so I started my SAFe journey around that time and we implemented that financial company and I've been on that journey ever since.

Sean Blake:

So take us back 10 years ago to 2011. And you're working at this financial company, you've heard of this concept of SAFe really for the first time you started to implement it. How did the people at that company respond to you bringing in this new way of thinking this new framework? It sounded you already had the diagrams on the frameworks and the concepts forming in your mind did you find that an easy process? I think I already know the answer, but how complex was that to try and introduce SAFe for the first time into an organization of that magnitude?

Gerald Cadden:

Yeah, this is a very large financial firm, a very old financial firm so very traditional ways of working. So what's interesting is the same challenges SAFe comes up against today they're present before SAFe even began. And so the same challenges of the past management approaches trying to move to faster ways of working was still there. So as we were furiously drawing diagrams in Visio, trying to create models for people to understand it was hard to create a continuum of knowledge and education that would get people to move from the mindset they had to the mindset we wanted them to have. And it was an evolving journey for myself and the team that I was working with. I work with a really great guy and his name is Algona, a very, very smart man.

Gerald Cadden:

And so the two of us we're always scratching our heads as to how to get the management to change their minds. And we focused on education, but it was still a big challenge. I finished on the project as they started with SAFe. I moved to different management role in the company that we continued the work there. Michael Stump he used to work for Scaled Agile I think he works now at a different company, but he continued a lot of that work and did a really good job and they did implement SAFe. They made changes, but they faced all the same challenges. The management mindset overcoming moving away from the silos to a more network structured organization. Just the tooling, just the simple things was still a challenge and there's still a challenge today. So the nature of the organization is still evolving even in the modern day Agile world.

Sean Blake:

You mentioned there that part of the challenge is around mindset and education. Have you found any shortcuts into how you change a team's mindset? The way they approach their work, the way that they approach working with other teams in that organization? I assume the factor of success has a lot to do with, has the team changed their mindset on the way they were working before and now committed to this new way of working? And can you talk to us a little bit about how do you go about changing a team's mindset?

Gerald Cadden:

Maybe I'll change the direction of your question here, because what I've found is usually you don't have to work too hard to change the mindset of a team. Most of the teams are really eager to try new things and be innovative. You only come across some people in teams who may be their career path has got them to a certain point where they're happy with the way the world is and they don't want to change. The mindset you really need to change is around that leadership space and that's still true today. So the teams will readily adapt if management can create the environment that allows them to do it and if they can be empowered. But it's really... If you want to enable the team it's getting the leadership around them to change their mindset, to change the structures that are constraining the teams from doing the best job they can.

Gerald Cadden:

And so that for me was the big discovery as you went along and it's still true today. As Agile has been evolving I've noticed that people don't always put leadership at the top of the list of challenges but for me it's always been at that top of the list. A lot of people want to look at leadership and say things about them unflattering things, but you have to remember these are human beings. And the best way to come to leadership is to really begin with a conversation, help them understand. They know the challenges, but we need to help them understand what's causing the issues that are creating those challenges.

Gerald Cadden:

As you work with them and educate them you can to open their minds up a little more. Does that mean they'll actually change? Not necessarily. Political motivations, ideologies other things constrained leadership from moving. But conversations and education I think are the way to really approach leadership. And getting to know them as a person, take an interest in their challenges, take an interest in them as an individual. So create that social bond is an important thing. As a consultant that was always hard to do because as a consultant you're always seen as an external force and it's hard to build that somewhat social relationship with that leadership and build that trust.

Sean Blake:

Yeah, that's so true. Isn't it. I remember on an Agile transformation that I was on previously, how Agile coach really would spend just as much time with the leadership team as they would with us the Agile team. And it seems strange that the coach was spending so much time trying to really coach the leadership team on how they should think about this new way of working, but you put it in the right context there it's so important that they create that environment for their people and for their teams to feel safe in trying something new. Yeah, that's really important.

Gerald Cadden:

I think if you looked at how Agile evolves, when you look at the creation of the Agile manifesto and its principles and then the following frameworks like ScrumXP, et cetera it evolved from a team perspective. So everybody made the assumption that we needed to create these things for the teams to follow, but as people worked with teams they found that it wasn't the teams at all the teams adapt, but the management and the structures of the organizations are not adapting. And so that's really where it went.

Gerald Cadden:

I can't recall the number of countless Scrum implementations you worked on and you just hit that ceiling of organizational challenges. And it was always very frustrating for the teams. I think there's a an opposite side to that too is that too many in the Agile world just look at the teams as the center of the world and you can't approach it from that way either the teams are very important to delivering value to the customers, but it's the organization as a whole that delivers value. And I think you really have to sit back and just say, "The teams are part of that how do we change the organization inclusive of the teams?"

Sean Blake:

Okay. That's really interesting. Gerald, you've spoken a bit about teams and mindset, when you go into an organization, a big auto manufacturer or a big airline or a financial services company and they're asking for your help, or they're asking for your training, how do you assess where that organization is up to? What's their level of maturity from an Agile point of view? Do you have organizations that are coming to you who have in their mind that they're ready to go SAFe and then you turn up on day one and it turns out no one has any real idea about what that type of commitment looks like?

Gerald Cadden:

Yeah, it's a good question. Because I think as I look back at the history of this, in 2011, 2012 when SAFe really got going, as you went forward I mean, there was no concept of where to begin. Consultants were just figuring it out for themselves and like most consulting or most methodologies they got engaged in an IT space and at the team level. And people would try to grow from the team level upwards. And at some point we need to know I've struggled a lot with this because I was just trying to figure out where it is that. So my consulting hat was always on to sit down, talk to people about their challenges, find a way to help figure out how to solve the challenges whether it was going to be Scrum or SAFe or whatever is going to be right.

Gerald Cadden:

Those are just tools in the toolbox. But when Scaled Agile as I was working with... Excuse me, as I was working with SAFe, Scaled Agile brought out the implementation roadmap. It produced so much more clarity that came later in my time with SAFe and I wish it had come earlier because it really began to help me clarify that initial thing that we call getting over the tipping point. How to work with the organization you're talking to, work with the right people, understand their challenges, help them understand what causes those problems, which is the more traditional ways of working the traditional management mindset, help them connect SAFe as a way to overcome those challenges and begin to show them. If you looked at the roadmap it's this contiguous step-by-step thing, but what you find in reality is there are gaps between those steps and in those gaps is the time you as a transitional team are having lots of conversation with the management.

Gerald Cadden:

If you put them through a training class they're not going to come out of the class going, "Oh, wow that's it. We know what to do." It takes follow-up conversation. You have to have one-on-ones one on many conversations, cover topics of gains so you can remove the assumptions or sorry the misassumptions. So it's a lot of that kind of work that the roadmap its there for those who are implementing SAFe today use it. It is one of the most helpful tools you'll have.

Sean Blake:

Awesome. Yeah. I think just acknowledging the difference between the tools in the toolbox and then the other fact that you're dealing with humans and you're dealing with attitudes and motivations and behaviors and habits there's two very different things there really. It sounds you need to take them all together on that journey.

Gerald Cadden:

Yeah. A side to that we train so many SPCs like SAFe program consultants. We train them, training them out of classes all the time with us and our partners. The thing that you can, you can teach them about the framework, but you can't necessarily teach them how to be a good consultant or a good... I want to say I use the term consultant and coach, right?

Sean Blake:

Yes.

Gerald Cadden:

Sometimes I like to say a good consultant can be a good coach, but a good coach can't necessarily be a good consultant because there's another world of knowledge you need to have like how do you sit down and talk to executives? How do you learn the patients and the kinds of questions you need to ask, how do you learn to build those relationships and understand how to work the politics? So there are things outside the knowledge of an SPC that they need to gain. So young people coming in and running to do this SPC course I want to prepare you for everything, but it gives you the foundations.

Sean Blake:

So when you're in a organization or you're coaching people to go back to their organization how do you teach them those coaching skills so that when they come in and they've got to learn the politics, they've got to identify the red flags, they've got to manage the dependencies, they've got to bring new teams onto the train. How do you go about equipping that more human and communications of the toolbox really?

Gerald Cadden:

I think you can obviously teach the fundamentals of the framework by running through the training courses. But mentoring for me is the way to go. Every time I teach a training class I make it very clear to people when they go back and they're starting a transformation don't go this alone. Find experienced people that have done this and the experience shouldn't just be with SAFe their experience should be having worked with large organizations having experience with the portfolio level if necessary. Simply because there are skills that people develop over years of their career if they don't have at the beginning.

Gerald Cadden:

I mean, if I look back at some of the horrific things I had said in meetings and in front of executives my boss would put his hands up in front of his face because I was young and impulsive and immature and I see that today. So when I first came to the U.S I worked with some younger BAs and they would say things in a meetings and you quickly have to dance around some things to, "We didn't really want to say that right now." So I think mentoring is the skill. We can teach you the tactical skills, but teaching you the political skills, the human skills is something that takes mentoring and time.

Sean Blake:

Mentoring so important in that context. Isn't it?

Gerald Cadden:

Yeah.

Sean Blake:

Okay. So let's rewind 12 months ago to March 2020, a month that's probably burned into a lot of people's mind is the month that COVID changed our lives for the foreseeable future. I know that Easy Agile had a lot of content out there, articles about how to do remote PI Planning, how to help your virtual teams work better together and we didn't know that COVID was coming we just saw this trend happening in the workforce and we had this content available.

Sean Blake:

And then I was checking out our website analytics and we had this huge spike in what I assume were people in these companies trying to work out for the first time, how to do PI Planning virtually, how to keep very literally their release trains on the tracks in a time where people were either leaving the state, working from home for the first time, it's really like someone dropped the bomb in the middle of these release trains and people scrambling on how we are we going to do this virtually now? Did you have a lot of questions at the time on how are we going to do this? And how have you seen companies respond to those challenges?

Gerald Cadden:

Yeah. I remember being in Boulder, Colorado in January of 2020 and I just come back from vacation in Australia and that's when COVID was coming around and you were hearing about things in January, 2020. I was talking with my colleagues and we were wondering how bad this is going to be within two months the world was falling apart. And for us I think a good way to tell that story is to look at what Scaled Agile did. We knew our business that it was very reliant on our partner success and it still is today. And so as we began to see the physical world of PI Planning and training, as we began to see that completely falling apart the company had to quickly adapt.

Gerald Cadden:

We already had a set of priorities set for the PI and we implement Scaled Agile internally in the company. At the time we're running the company as a train itself because it's 170 all people. So they had to reprioritize the different epics, we pushed a new features and it was all about what do we need to change now to keep our partners afloat by getting them online and a really good team at Scaled Agile in a really cross-company effort to get short-term online materials created to keep the partners upright so they could keep teaching. They could find ways to do this, to do PI Planning, to do they're inspecting adapts all online. And so we pushed out a lot of material just simply in the form of PowerPoint slides that they could then incorporate into tools like Mural, Al tool. SAFe collaborate we went about developing this and we've been maturing that over time.

Gerald Cadden:

And so now we're in a world where we have a lot more stability. We saw a big dip like everybody else, but the question is, are you going to come out of that dip? And so what we did notice within probably even the second quarter of that year where the tail end of it we saw it starting to come up again, which our partners starting to teach more online. So the numbers told us that the materials we're producing were working. So for us it was just a great affirmation that organizing yourself the way we did organize yourself, the quick way we could adapt saved us. So Scaled Agile could have gone the way of a lot of companies and not being able to survive because our partners wouldn't have survived. We had the ability to adapt. So it's a great success story from my perspective.

Sean Blake:

Well, that's great. We're all glad you're still around to tell the story.

Gerald Cadden:

Yes we are.

Sean Blake:

And Gerald, whether you're reflecting on companies you've worked with in the past, or maybe even that internal Scaled Agile example you just touched on. Are there specific meetings or ceremonies or checking points that are really important as part of the Agile release train process? What are the things that really for you are mandatory or the most important elements that company should really hold onto during that really set up stage of trying to move towards the Scaled Agile approach?

Gerald Cadden:

So I interpret your question correctly. I think for me when you're implementing the really important things to focus on as a team first of all is the PI Planning. That is the number one thing. It's the first one people want to change because it's two days long and everybody has to come and it can cost companies a quite a significant sum of money to run that every 10 to 12 weeks. And so you will run very quickly as I had in the past in the car company you run very quickly into the financial controller who wants to understand why you're spending $40,000 a quarter on a big two-day meeting. And so they lie, they start questioning every item on the bill, but that's the most significant one.

Gerald Cadden:

PI Planning is significant. The inspect and adapt is the other one simply because at the end if you remove that feedback cycle, what we call closing the loop if you remove that then we have no opportunities to improve. So those two events themselves create the bookends what we get started with and how we close the loop, but there are smaller events that happen in between the team events are obviously all important. But more significant for me is the constant, the event for the product management team or program management team how are you going to filter them, excuse me.

Gerald Cadden:

Who are going to need to get together on a regular basis to ensure that then we call this the Sync. So this is the ART Sync or the POPM Sync. You need to make sure those are happening because those are these more dynamic feedback loops and ensure the progress of good architectural requirements or good features coming through so that when you get to PI Planning the teams have significant things to work on. So if you had to give me my top three events, PI Planning, inspect and adapt, and the ART Sync and product POPM Sync.

Sean Blake:

Awesome. I know there's always that temptation for teams to find the shortcuts and define the workarounds where they don't have to do certain meetings or certain check-ins, but in terms of communication it must be terribly important for these teams to make sure they're still communicating and they don't use the framework as an excuse to stop meeting together and to stop collaborating.

Gerald Cadden:

Yeah. I mean, I went through when I started implementing at the large car company in the U.S I decided to rip the bandaid off. They had several teams working on projects and they weren't doing well, when I looked at the challenges and decided we're going to implement SAFe some of the management they were, "Are you crazy? Why would you do this?" But they trusted me. And so we did rip the bandaid off and we formed them all into a not. We launched set up. And I remember at the end of the PIs some of the management have had a lot of doubts that were coming up after they sat through the PI and they said they just couldn't believe how great that was.

Gerald Cadden:

Even though the first PI was a little chaotic they understood the work and the collaboration, the alignment, just the discussions that took place were far more powerful for them. And teams were happier, they were walking out to a different environment. So it changed the mood a great deal. So I think the teams their ability to be heard in one of the most significant places is during PI Planning, they get that chance to be heard. They get that chance to participate rather than just be at the end where they're told what to do.

Sean Blake:

Mm-hmm (affirmative). So it really empowers the team.

Gerald Cadden:

Yeah. Absolutely.

Sean Blake:

That's great. So as a company moves out of the implementation phase and becomes a little bit more used to the way of doing things what's the best way for them to go about communicating that progress to the wider organization and then really evangelizing this way of working to try and get more teams on board and more Agile release trains set up so that it's really a whole company approach.

Gerald Cadden:

Yeah. A good question. So I think first of all the system demo that we do. So the regular system demos that take place, this is an event where you can invite people to. So when you get to the end of the program increment, the 10, 12, or the eight, 10 or 12 weeks and you're doing your PI system demo that's a chance for you to invite people that may be in the organization who are next on the list and they're going to be doing this, or they're curious, or if you have external suppliers who you're trying to get on board as part of the training have them come. Have them come to these events so they can just participate. They can see what goes on and it takes away some of the fear of what that stuff is. It gives them work much.

Gerald Cadden:

So the system demo whether you do it during the PI, but definitely the PI system demo and you want that one. So more ad hoc things and one of the things that I've seen organizations really fail to do is when they're having success the leadership around the train need to go out and I hate the term evangelize, but go out and show the successes. Get out and talk about this at the next company meeting present where they were and where they are now. But as part of that don't share just the metrics that show greater delivery of value show the human metrics, show how the team went from maybe a certain level of disgruntlement to maybe feeling happier and getting better feedback, show with how the business and technology have come closer together because they're able to collaborate and actually produce value together rather than being at odds because the system makes them at odds.

Sean Blake:

Awesome. Gerald is there anything else you'd like to share with our audience before we wrap up the episode? Any tips or words of encouragement, or perhaps some advice for those who are considering scaling up their Agile teams.

Gerald Cadden:

I think that the one piece of advice again, I'll reiterate back to the earlier point I made is as you are going through the implementation process and you're starting to launch your train and train your teams figure out how you're going to support them when you launch. Putting people through an SPC class or through all the other classes they won't come out safe geniuses. They'll have knowledge and they'll have the enthusiasm and have some trepidation as well, but you need good coaching. So figure out as you're beginning the implementation pattern where you're designing the teams et cetera, figure out what your coaching pattern is going to be. Hire the people with the knowledge and the experience work with a partner for the knowledge and experience. They shouldn't stay there forever if you work with consultants.

Gerald Cadden:

Their job should be to come in and empower you not to stay there permanently, but without that coaching and coaching over a couple of PIs your teams tend to run into problems and go backwards. So to keep that momentum moving forward for me it's figure out the coaching pattern. The only other one I would say too is make sure that you get good collaboration between product and the people who are going to be the product management role on architecture, get rid of the grievances, have them work together because those can stifle you. Get in and talk about the environments before you launch. You don't want funny problems when you, "Oh, the architecture is terrible." Okay. Let's talk about that before we launch." So just a couple of things that I think are really important things to focus on before you launch the train.

Sean Blake:

Awesome. I really appreciate that Gerald. I've actually learned a lot in our chat around. It's the same challenges that you had 10 years ago it's the same challenges that we have today. The really the COVID is the challenge of how do you focus on the mindset change. We've talked about the teams are eager to change. There might be a few grumbly voices along the way, but really it's about leadership providing a welcoming and safe environment to foster that change and the difference between being a coach and a consultant, the importance of mentoring. Wow we actually covered a lot of ground didn't we?

Gerald Cadden:

I may get some hate mail for that comment, but...

Sean Blake:

Oh, we'll see. Time will tell. Thanks so much Gerald for joining us on the Easy Agile Podcast. And we appreciate you sharing your expertise with us and the audience for the podcast. Thanks for having you.

Gerald Cadden:

Happy to do it anytime. Thanks for having me here today.

Sean Blake:

Thanks Gerald.