Easy Agile Podcast Ep.33 How to Align Teams Through Strategic Goal Setting
In this episode, we dive deep into the challenges of aligning teams with strategic goals across organisations of all sizes. From fast-growing startups to large enterprises, teams everywhere struggle with the same fundamental issue: translating high-level objectives into actionable work that drives real value.
Our guest Andreas Wengenmayer, Practice Lead for Enterprise Strategy and Planning at catworkx (the #2 Atlassian partner worldwide and #1 in EMEA), shares his 11 years of experience helping organisations bridge the gap between strategic vision and team execution.
Want to see these concepts in action? Andreas and Hayley hosted an interactive webinar where they demonstrated practical techniques for strategic goal alignment using Easy Agile Programs. Watch the recording here→
About Our Guest
Andreas Wengenmayer is the Practice Lead for Enterprise Strategy and Planning at catworkx, one of the leading Atlassian Platinum Solution Partners globally and the #1 in EMEA. With over a decade of hands-on experience helping enterprise teams scale agile effectively, Andreas specialises in bridging the gap between strategy and execution. His work focuses on guiding organisations through complex transformation programs, optimising portfolio planning practices, and helping teams adopt frameworks like SAFe with clarity and purpose. Known for blending pragmatic insight with systems thinking, Andreas brings stories from the field - ranging from fast-moving startups to complex, multinational enterprises.
Transcript
Note: This transcript has been lightly edited for clarity, readability, and flow while preserving the authentic conversation and insights shared.
Recognising the signs - when teams aren't aligned
Hayley Rodd: Awesome to have you here. So I'm going to start with a bit of a reality check. We've worked in organisations across the spectrum from really fast-growing startups to really big enterprises. From your experience, when you walk into a PI planning or quarterly planning session, and I'm sure they're pretty hectic, what are the telltale signs that teams aren't truly aligned on what success looks like?
Andreas Wengenmayer: That's a great question - one I hear frequently. You can imagine, especially post-COVID when teams returned to in-person planning sessions. Back in 2017, we'd have huge arenas with hundreds of people in one place. People are happy to see each other, excited to chat with colleagues from different locations. This became even more pronounced after COVID, when everyone was working from home more frequently. That's a good sign - the mood is positive.
But you also notice some teams under pressure. They'd rather be working on actual deliverables. They know they have to be there, and it takes two full days to complete all the planning. Meanwhile, they're carrying a mental backlog - technical debt, unfinished work from the previous PI, catching up on delayed items.
This is what I often observe: teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.
Teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.
Sometimes you have to step in and ask what's really underneath. What's the actual cause? People say, "Yeah, I have to be here because that's the format, but I'm not engaged." Maybe it didn't work well in the past and there's lingering skepticism.
The prevailing attitude then becomes: "This isn't really collaborative. Leadership plans from the top anyway. The outcomes are predetermined - here's the plan, just make it work and update your boards." When people feel they can't meaningfully contribute or influence direction, they simply go through the motions.
My favourite example happens at the end when teams must formulate their objectives. It becomes a box-checking exercise - create something that satisfies the coach or Release Train Engineer so everyone can "get back to real work."
What good alignment actually looks like
Hayley Rodd: You've touched on so many things there. I can imagine walking into that room and feeling the pressure. People getting caught up in minor details rather than talking about root causes, or not asking the five whys to get to that root cause. You also touched on getting buy-in across the organisation. When people are really nailing it, when alignment is really there, what does that room feel like?
Andreas Wengenmayer: Yes, I've fortunately experienced those environments, and they're actually more common than you might think. When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.
When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.
You can see it immediately in people's body language and interactions. The energy in the room is palpable. If people appear resigned or intimidated, afraid to speak up, that's typically a red flag. The opposite creates magic.
Think about high-performing teams, like being a Scrum Master with an exceptional group. The best teams aren't just collections of highly skilled individuals in specific roles.
The best teams are those who communicate openly, genuinely enjoy each other's company, maintain positive energy, and actively support one another. This dynamic enables remarkable achievements. Maybe someone knows a contact in another tribe, release train, or department who can provide crucial answers and facilitate communication. Communication is absolutely fundamental.
That collaborative spirit is the hallmark of truly effective teams.
Hayley Rodd: Absolutely. We would know it in our day-to-day work, right? If your teams aren't communicating, if they're too overburdened as you said, it's not a good place to start. But if you can get that starting point right, if you can get that communication right, so many things will flow after that.
Andreas Wengenmayer: Absolutely. Looking back at any planning cycle, the real test is: did you plan the right things? You only know at the quarter's end whether you estimated capacity accurately.
Here's the crucial question: How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?
How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?
When you're permitted, encouraged, even, to be genuinely open and honest, you become much better at assessing realistic capacity. What makes stakeholders universally happy is predictability. You want confidence that your plans will actually materialise, that your commitments will be fulfilled.
Success breeds success, creating a positive foundation for the next PI. It's a continuous cycle that can spiral upward toward excellence or downward toward dysfunction.
The startup vs. enterprise spectrum
Hayley Rodd: Let's talk about the two ends of the spectrum. You've got a lot of experience, so I love hearing about this. Small companies will often say, "We're agile, we can pivot quickly, we don't need formal goal setting." Then enterprises are going all out on OKRs, cascading objectives, saying they're aligned because they've got those things in place. Yet both struggle with the same core problem. What's really going on?
Andreas Wengenmayer: You're absolutely right. I've been in agile projects since 2014, 11 years now, and I've seen a lot of companies pre-COVID, post-COVID, different sizes.
Starting with the really small ones, startup companies - what's really astonishing is that some very small startup companies tend to become overly complex, which is amazing. Some want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.
Some startups want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.
Maybe that's part of startup CEO culture - where everyone's a CEO on LinkedIn, and they think, "We're corporate, we have to be like that." They mostly get to their senses in the end, but small companies tend to be overly complex and overblown when it comes to technology, tooling, and organisation.
On the other end, large corporations sometimes seem to try their best to become truly agile - living the values everywhere. Still, it's a challenge. In most cases, there's some kind of hybrid planning going on. There's still a roadmap, which is good, but at some level, some people still stick to classical approaches, have some waterfall going on in the back.
I personally have never seen, for example, a full SAFe organisation where it's done truly at every level. There's a good balance and it should be healthy, but it all comes down to execution.
I feel like mid-sized companies are often the healthiest when it comes to that.
There's a balance of method and tooling, but you still need a solid understanding of goal setting and tracking. This includes pivoting when goals aren't right and learning from how you did things in the past. The gap between management and teams isn't that huge, and it's easier to bridge.
Avoiding death by KPI
Hayley Rodd: You've touched on so many fundamental things around getting the method and tooling right, but also that cultural aspect. I love the insight around mid-size organisations often striking that balance well. When we're thinking about the enterprise risk - which could be "death by KPI" or OKR, do you agree? Can you paint a picture of what that looks like and how it actually makes teams less focused?
Andreas Wengenmayer: Absolutely. There is such a thing as "death by KPI." KPIs are important to get a clear picture - you do need metrics, and there's merit to it. But as always, it's about choosing the right KPIs, the right metrics.
My favourite example is comparing story points across teams or ARTs. You measure velocity, and I have to repeat again and again: it's only individual to one team. You shouldn't compare it to another team or across tribes or ARTs - that doesn't work because you're creating the wrong incentives.
You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.
You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.
You want predictability - you want to meet a certain range. So it's not a great KPI when it comes to monitoring progress across teams. They have better KPIs in place.
Other metrics tend to create what I call bureaucracy. If you spend too much time creating reports, you have less time to create anything of value.
Hayley Rodd: I think there's so much in what you're saying about people being realistic and honest, open to pivoting or changing a goal if it's not the right one. Admitting to that is really difficult because no one wants to admit that what they set out to do is failing. But understanding that failure can sometimes be a benefit - you can learn from that. There's so much in that cultural aspect, right?
Andreas Wengenmayer: Absolutely. Coming back to goals rather than KPIs - KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.
KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.
You could be a small company like a startup - you're in a canoe, you're rowing. Or you're a large company - you're like a big freighter. Still, if you don't set the right course, the right goal, you will never reach your destination. Your team can be as proficient and perfectly working as they could be. If the course isn't right, hopefully you have enough provisions on board to survive a long journey.
Where organisations get stuck in goal setting
Hayley Rodd: Where do organisations typically get stuck? Is it defining the goals, communicating the goals, or translating them into action - that execution point you made before?
Andreas Wengenmayer: It could be basically any one of those. If you have a smaller or mid-size company, it's easier to communicate - you don't have to bridge as huge a gap. But still, you have high-level goals that have to be translated into real work. Real value is created in the teams.
If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?
If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?
That's when communication and breaking down goals becomes really important. Breaking them down the right way, having them visible and transparent, and creating that feeling of contribution. You make it visible that you're not just working for yourself or your team, but you're really contributing. You understand what you're working on and why you're doing it. Purpose is critical.
Bridging the strategy-to-sprint gap
Hayley Rodd: That's a really good segue into the next question about translating strategic vision into team-level objectives that people can grab onto and execute. Leadership will often say something like "increase customer satisfaction," and teams are left going, "What does that mean for me in my sprint this week?" How does an organisation bridge that gap between the high-level leadership view and what we can do in our sprints as a team?
Andreas Wengenmayer: First of all, you as company management need to take the time. There have been, and still are, a lot of approaches with company values, putting posters on walls, creating marketing. Those are all values - that's what a company is like. Then you link it with your products, services - great services, customer satisfaction. Okay. Then comes the real challenge: we want to succeed and create the next service, software solution, or product.
The goal is clear on a high level, but how do we break it down? That's when the real work comes into play - breaking down the goals into smaller pieces.
It's like building a LEGO space station when I was a kid. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.
It's like building a LEGO space station. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.
Hayley Rodd: Nice. A colleague of mine often says you eat an elephant one bite at a time - similar thing, right? When you see that big goal, it's really overwhelming. But if you can break it down into those chunks and smaller pieces, it becomes so much more manageable and achievable. People can get behind that vision.
Managing moving targets
Hayley Rodd: In fast-moving environments, goals often shift. We're agile, we're always moving. How do you help teams stay connected to a moving target without either ignoring changes or constantly thrashing around?
Andreas Wengenmayer: Back in the nineties and early 2000s, there was a computer game that wasted a lot of time in offices where you were shooting at geese in Scottish Highlands. It was a big phenomenon because people were trying to get the next high score.
If you think of moving targets, it's a bit like that. Imagine you're doing your work - whether you're a hunter or developer doesn't matter - but you approach, you take aim, and the geese keep flying up. You miss the target. Same thing if you have moving goals.
It's harder to aim and approach them right. What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.
What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.
That doesn't mean you can't learn from mistakes or wrong goals. You can adjust them, but you have to adjust them in the right place and time, which is during planning. Of course, if something security-related comes up, you have to act, but it has to be agreed upon, and you still have to communicate it and create understanding.
Keeping goals visible and actionable
Hayley Rodd: Even when goals are well-defined, keeping them visible and actionable throughout a PI is tough. What practices or tools have you found most effective for maintaining connection between daily work and high-level strategic objectives?
Andreas Wengenmayer: Good question. Having the goals present at all times helps a lot. If you just meet for planning, have your goals set, and never look back during the PI, it doesn't do you any good.
That could be a piece of paper on the wall like we had back in the day - and still could be if you're working in the office. Also, choose the right tools to track the goals and create acceptance for tools. Really use them. Look into them - whether it's an OKR tool or some other solution, even PI objectives. Are we still on track?
What really helps is if it's not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.
What really helps is if your tool is not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.
It helps keep the vision and goals present.
Hayley Rodd: When I was a teenager in my final year of high school here in Australia, I wanted a specific score on my final exams. I had a big poster in front of my desk that I sat at for hours every day studying. Looking back, I didn't know what I was doing - I just wanted to visualise my goal, and I didn't know the psychology behind it. But I'm happy to report I got that mark and above.
I think it was as you were saying - that constant reminder, that piece of paper worked for me. In organisations, we're looking for something a bit more complex sometimes, but I like your "keep it simple" advice. It doesn't always have to be super complex. It can just be a checklist, progress bar, or piece of paper - something that helps you feel connected to the goal and reminds you of it often.
When good work doesn't align with goals
Hayley Rodd: Have you seen situations where teams were delivering lots of work - good work, but it wasn't clearly contributing to company goals? What tends to cause that disconnect?
Andreas Wengenmayer: Yeah, that happens quite a bit. I can think of one example with very technical teams, like in semiconductors. Very smart people - everyone has a PhD in physics, material science. Awesome, smart people who tend to love their job. They're awesome, but they're also perfectionists who can still improve things and want to make them even better.
If you're in the business of producing machines used to produce semiconductors, for example, it's a complex task with a complex supply chain or value chain. You're creating lithography machines to create wafers used by other companies, and in the end, you have a customer planning the release of a new phone.
Your customer waits, the end customer waits, and you have to deliver on time. Sometimes this creates a challenge because teams still want to improve and make it even better. That's when economics come into play - the view of the big picture. You still have to communicate it. You shouldn't discourage such a great team, but you need to get the bigger perspective back to the teams and create acceptance instead of saying, "Hey, stop what you're doing, it's good enough." You don't want that. It all comes back to transparency and communication.
On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.
On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.
Hayley Rodd: If you don't do that planning at the start, you're setting yourself up for misalignments. If you're not communicating that plan regularly, you're setting yourself up for that busy work and people getting distracted. It's just so common. That planning part is so fundamental to getting it right.
One piece of advice for frustrated leaders
Hayley Rodd: We're on the home stretch now. If you could give one piece of advice to an engineering or product leader who's been frustrated because their teams seem to be going through the motions of PI planning or quarterly planning without real buy-in, what would it be?
Andreas Wengenmayer: I can resonate with that so well, and many can. I'd say: take the time to find out what's really going on. Investigate the root cause. It's like if you have a house and you're trying to fix a crack in the wall - you can look at the crack and do some superficial fixing or use a thick layer of paint, but you still have to find out what's causing that issue. Maybe something deeper.
You mentioned the five whys - that can be one way, but you have to have some understanding of the right way to approach people. You don't want to put anyone on the spot. Looking for a scapegoat doesn't help anybody.
We need to look at what's behind it, what's causing it. It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.
It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.
People have to understand why they're doing it. There has to be purpose and understanding - enough time, no distractions, and a positive atmosphere where everybody can contribute and be open.
You don't want people saying nothing because they don't dare to criticise or say no.
The connection between goal clarity and team motivation
Hayley Rodd: What's one thing you wish more organisations understood about the connection between goal clarity and team motivation?
Andreas Wengenmayer: We could get back to the boats we mentioned before. You want to arrive at your destination. If you're not clear about the destination, or maybe some people in your rowing boat don't want to go there, they might not join the rowing. If your crew is not invested, it will take you longer to reach a destination, or you won't get there as well.
It's the same thing. Motivation is key, and I don't talk about superficial motivation that just annoys everybody. Motivation is a positive environment where people rely on each other. They really like spending time with those people.
"Hey, I really like to go to lunch with you and talk to you" - not "I'd rather be home and not talk to anybody." You're not annoyed if your teammate asks you a question; you're happy to help. You're feeling safe that when you have a problem or question, you will get help.
That creates the right kind of motivation - that positive environment, and that can make a lot of things happen. It comes back to openness and transparency, not as buzzwords, but to get the clear picture. As a stakeholder, you get the correct current state because you get true answers.
I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.
I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.
Wrapping up
Hayley Rodd: There are so many key themes coming up throughout our conversation. You've talked about ongoing communication across teams, really planning with purpose, getting that context and buy-in to help with motivation, and allowing for radical candour - being really open if something's not working and being okay to call it out. So many cultural and communication elements are critical to the success of quarterly planning, PI planning, and organisations generally. Great takeaways.
We're going to end it there, but I want to end with a teaser for our interactive webinar that you and I are doing together on September 4th, which dives deeper and shows how to operationalise the ideas we've chatted about here using Easy Agile Programs and linking back to the fundamental services that catworkx provides organisations.
Andreas, it's been super wonderful to chat with you. I look forward to our webinar coming up on September 4th.
Andreas Wengenmayer: Thank you so much for having me. Looking forward to September 4th and seeing you again, talking more about tooling, boats, duck hunt, and anything in between.
Ready to transform your strategic planning?
The conversation doesn't end here. Andreas and Hayley hosted an interactive webinar where they showed how you can put these strategic alignment concepts into practice.
They spoke about:
- Practical techniques for breaking down strategic goals into actionable team objectives
- How to maintain goal visibility throughout your PI cycles
- Real-world examples of successful alignment transformations
Related Episodes
PodcastEasy Agile Podcast Ep.24 Renae Craven, Agile Coach on team alignment and taking a leap out of your comfort zone.
"I had an inspiring conversation with Renae around the benefits of leaping out of your comfort zone and aligning team behaviour " - Chloe Hall
Chloe Hall- Marketing Coordinator at Easy Agile is joined by Renae Craven - Agile Coach, Agile Trainer, Scrum Master Coach and QLD Chapter Local Leader at Women in Agile.
Join Renae Craven and Chloe Hall as they discuss:
- Renae’s journey to becoming an Agile Coach and Agile Trainer
- Taking a leap out of your comfort zone
- The importance of taking time to gather feedback and reflect
- Building a team environment where everyone feels safe to contribute
- Aligning team behaviour and how prioritising learning impacts team delivery
- Why sitting all day is bad for you and how to bring movement into your work routine
- + more
Transcript
Chloe Hall:
Hello and welcome back to the Easy Agile Podcast. I'm Chloe, Marketing coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dhuwal speaking country. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islanders and First Nations people joining us today. Today we have a very exciting episode for you. We will be speaking to Renae Craven. Renae is an Agile coach, Agile trainer, scrum master coach, BASI Pilates instructor, and runs her own Pilate Studio.
Renee is also a chapter local leader at Women in Agile Brisbane and is the host of the podcast The Leader's Playlist alongside David Clifford. Renae's passion in life is to help people to be a better version of themselves by raising your awareness of areas they wish or need to improve them and to support them in their learning and growth through these areas. According to Renae, coaching is not about telling people what to do. It is about questions to allow them to dig deeper, uncovering realizations and their desire for change. Welcome to the podcast, Renae. Thank you so much for coming today. Really appreciate it and very excited to unpack your story, your journey, and all the success you have achieved, which is amazing. How are you today anyways?
Renae Craven:
I'm all, I'm good. Thank you, Chloe. It's Friday, so I'm always a bit wrecked on a Friday. Looking forward to sleeping in on the weekends and things like that. So yeah, Friday I'm already, always a little bit dreary, but other than that I'm fine.
Chloe Hall:
Well, that's good. Friday afternoon definitely can always do that to you. I'm very pumped for a sleep in as well. I think let's just get straight into it. So some of that I wanted to start was I just want to unpack you as a person, Renae, and kind of your story, who is Renae and the journey you've taken to become so successful today. So if you wanted to provide a little bit of background about yourself.
Renae Craven:
How far back do I go? So I did IT at uni, Information Technology at uni. So I started my career out as a graduate developer, software developer, pretty crap one at that.
Chloe Hall:
Surely not, I don't agree with that. I can't see it.
Renae Craven:
I knew enough to get by, but it was definitely not going to be something that I was going to do for the rest of my life. But back then I was 20 and kind of just was doing things that you were supposed to do when you grow up. You're supposed to go to school and you're supposed to do well in grade 12 and go to uni and get a degree and then get a job.
Chloe Hall:
Definitely.
Renae Craven:So yeah, I ticked all those boxes and found myself with a degree in a job in a good organization. And I was in that development job for a couple of years and then I kind of moved more into team leadership and I was a team leader for a while and then I became a scrum master back in 2010. So that was when I discovered Agile.
Chloe Hall:
Okay. Yup.
Renae Craven:
And I think the rest is kind of history. So when I discovered Agile, things started to make more sense to me. Talking to people, having teams, working together, collaborating together, solving problems together, getting multiple brains onto a problem. That kind of thing was one thing that I never made sense to me when I was a grad straight out of uni. And I'm like, "What do you mean?" Because even during my university, I was a little bit different and I was remote. I did university remotely years ago and with a group of four others, there were four others, it was a group of five. We did everything together, we did all our group assignments, we studied together, we ate lunch together, we just kind of did.
Chloe Hall:
So with the exact same group?
Renae Craven:
Yeah. All the way through uni. I went from that kind of group setting to working and more of an individual on my own like if I've sat in a cubicle with walls that were higher than me, I didn't have to speak to anyone else if I didn't want to. And that never really sat well with me. It was never kind of who I was. So when Agile was, Scrum specifically was here's all these people we're going to throw together in a team and here's all of the problems and you work out together how you're going to solve it.
Someone's not going to tell you what to do or how to solve it, you've got to figure it out as a team, it was a much more, cool this is what makes sense, this works better. Why wasn't it always like this? So yeah, that's kind of where my Agile journey started and it kind of progressed as I did scrum mastering for quite a few years in different organizations, different scenarios, different contexts. And then I guess I was able to comfortably call myself an Agile coach I would say maybe 5, 6 years ago. I mean, there's nothing really that you can do that you go tick, Oh, I'm an Agile coach now.
Chloe Hall:
There's no kind of straightforward degree or certification.
Renae Craven:
No, it's really just experience. And I had experience around and people were telling me, "You can call yourself a coach, an Agile coach now, you've got plenty of experience". I'm like, "Yeah, but I feel like there's so much more that I need to know or that I could learn". So I don't really feel comfortable. But I was working for a consultancy, so that was just how I was being marketed anyway. So that was kind of 5, 6, 7 years ago that that started to happen. And then I do other things as well, like Agile training. I love training people, I run training courses, do the coaching as well. And then I've got my Pilates as well.
Chloe Hall:Just an all rounder, a lot going on, that's for sure. I think as well, I just want to unpack, you had that transition when you were a graduate developer and you found it quite isolating. And then you came into this concept of Agile when you are working in teams. Was it when you started doing that Agile, did that kind of spike like a passion, a purpose of yours and that's what led you down that Agile training, Agile coaching road?
Renae Craven:
I think, I mean purpose, I still don't know if I know what my purpose is in life. Passion. I think what it helped me understand about myself is where some of my strengths were. And my strengths aligned with what was needed to be a scrum master and a coach later on. So the ability to facilitate, that's a big part of being a scrum master, a big part of being one of the key things about being a coach. And that was just something that I was kind of naturally able to do, but I didn't know until I started doing it, if that kind of makes sense.
Chloe Hall:
Yeah. I feel like, isn't that always the way, It's like you don't know something or you don't really know your strengths until you just step into it. You've really got to get out of your comfort zone and just try new things, experience new things. Otherwise, you're never going to know.
Renae Craven:
Yeah, exactly. So yeah, can't trying to create that equal participation in a room or in a workshop from a facilitation and facilitating a group of people from different walks of life to an outcome and just letting it kind of flow and let the conversations flow. But still, you've got to get to this outcome by the end of the day or end of the workshop. That was something that I was naturally able to do. And I mean, my first workshop, how I facilitated that, I don't even remember what it was, but I'm sure how I facilitate now is very, very different. But it was still something that I loved doing, that I enjoyed doing. And the training part of it, it's funny because at school I used to hate public speaking. I used to hate.
Chloe Hall:
You sound like me.
Renae Craven:
Yeah. All of that, how I used to get up in English and do an oral exam and things like that. I hated all of that stuff. I was very happy to just hide in the background and never answer a question or never cause any trouble or be disruptive or whatever. Except in maths class I was a little bit disruptive in math class.
Chloe Hall:
I am resonating so much with you right now because I was literally the exact same. And I've always had a bit of a passion for math. So in maths I was super outgoing, would ask so many questions. But in English my biggest fear was public speaking. I just could not stand up for the life of me. It was the worst. I was always so nervous, everything about it. And I think that's really interesting to see how far you've come today from what you thought back then. Was there any type of practices, lots of work that you had to do on yourself to get to this point today?
Renae Craven:I think similar to what you said before, you got to get out of your comfort zone. And I think, especially early on in my career, that being pushed out of my comfort zone. There's a few leaders that I was working for at the time that, well a handful of people that over the years have pushed me out of my comfort zone. And in the earlier days where I wouldn't have done that for myself. So doing that for me or I didn't really have a choice because I was a good girl and I followed orders back then. It was just something that I went, "Oh okay, well that's cool". I'm glad in hindsight, I'm glad he did that because I wouldn't be where I am right now if I wasn't thrown into the pilot team, the pilot agile team. So yeah, there's things like that where I've been pushed into my comfort zone and just had a go and found out that, oh, it wasn't so bad after all.
Maybe I could do that again. And then you start to build your own kind of resilience, you go, well I've did this before so that's not much harder. I reckon I could do that. Or it's kind of thinking about it like that, but it's also changing. It was shifting my mindset to be you've got to get out of your comfort zone, you've got to screw up to learn. The way that it was at school where you got rewarded for being correct, you got rewarded for doing the right thing. And that's not how I learn. That's not how a lot of people learn. You have to screw up to then go.
Chloe Hall:
Definitely.
Renae Craven:
Okay, well next time I do that I'll do this instead.
Chloe Hall:
Yeah, definitely.
Renae Craven:
Or getting that feedback of how you did this, well next time maybe you could do this or whatever it is. Just getting that feedback. Whereas, I never got any of that at school. It was always Renae's perfect angel child, whatever it was.
Chloe Hall:
Still, nice though, but yeah.
Renae Craven:
Nice for the parents. Can we have more of Renae's in our class, nice for mom and dad. But in hindsight, it didn't really do much for setting me up for how.
Chloe Hall:
For reality.
Renae Craven:
Yeah
Chloe Hall:Really.
Renae Craven:
Exactly.
Chloe Hall:
Especially because I've recently gone through that transition from graduating uni into a full time job and working for Easy Agile, I'm always being pushed out of my comfort zone in a good way. Everyone's so supportive, they're always like, "Oh Chloe, try this, try that". And I'm just like, "okay, yep, I can do it". And if it doesn't go amazingly well that's okay. I've learned something and I can do it better next time.
Renae Craven:
Yeah.
Chloe Hall:
You can't just sit in your comfort zone forever, you don't get that feeling of when you do something outside of your comfort zone, you just feel so good after and you're like, oh, prove to myself I can do this.
Renae Craven:
Yep. And I think the big part of that is acknowledging the learning is sitting down. So one of the things we do, I do as a coach is one of the key times for a team or an individual to learn is to actually sit down and reflect back and then what was good, what was bad, and what am I going to do differently the next time. And I coach teams to do that, but I have to do that myself as well. So kind of realizing that as a practice, that's something that I have to do is sit down and when I do these things I would need to gather feedback and then I have to sit down and reflect on how it went. What I think I can do better or do differently the next time around I do something like this so that I am also myself improving in the things that I do. So it's really having that time and that practice to learn to sit down and what did I learn?
Chloe Hall:
Yeah, I do. And I agree with that. You need to take the time to understand, reflect, realize what you have learnt. Otherwise, life is so busy and you just keep going and going and going and you can just completely forget and it's good to take that moment. I really like how that's something that you do in your Agile coaching as well. What else do you do when you're coaching teams? What other elements are there?
Renae Craven:
Some of the stuff I've already spoken about, having that equal, trying to get that equal participation, equal voice. Trying to, the buzzword is psychological safety, but trying to make, trying to build an environment for a team where everyone feels safe to ask a question or to voice their opinion or whatever it is. And when we've come from, as a coach, what we're doing is usually coaching teams, people, organizations, through a shift from a certain way of working to an Agile way of working. And that means that the whole telling people what to do and when to do it and how to do it is gone. That's gone. And now you want to build that capability within the team itself. So creating that safe space so that the
team can ask questions and understand what they have to do so that they can collectively deliver something as opposed to someone just telling them what to do.So it's using your brain, using the collective group brain as well, instead of just having, not using your brain really, just waiting to be told what to do and then you'll know what to do, you just do it. But collectively solving a problem together as a team and then figuring out as a team how we're going to solve that or how are we going to deliver that is something that is quite, that's the bit I love as a coach, working with teams, building that kind of environment where they do feel safe to ask the dumb questions and things like that.
Chloe Hall:
And not have to be like, I think this is a silly question, but you definitely want to remove that.
Renae Craven:
And I think the other part is the learning still, it's exactly the same. It's taking the focus, trying to get the focus off, we must deliver and then we'll do some learning stuff if we get time trying to flip that around so that your, "No, no, no, you need to learn in order to get better at delivery". So take that focus, because a lot of teams will just say, we've got all these deadlines, all of this delivery pressure, we have to get this stuff done. We don't have time to sit down and think about what we've learned or how we can get better as a team. They're never going to get better as a team if they just keep in this endless delivery cycle. Making the same kind of time wasting things over and over and over again. So it's kind of flipping the mindsets of the teams as well to go, "No, hang on, we need to do this otherwise we're not going to get better as a team".
Chloe Hall:
Yeah, definitely. And I think that's where the Agile retrospective fits in perfectly. And I know I actually just came out of my retrospective with my team and we do that weekly and it's so good to come out of that with action items too. And it's like, okay, next week this is how we're going to get better. This is how we're going to advance, this is our focus and there's also no hidden problems because it comes up every Friday, we talk about it. So you're not going into Monday the next week with a grudge or you're annoyed about something with the workflow of the team. You've addressed it, you've left it in the last week, you've brought the action with you obviously, and hopefully it's going to get better from there.
Renae Craven:
Yeah, absolutely. And that's the key. It's the whatever we've decided in our retrospective of what we're going to do differently, we're doing that differently the next day or Monday in your case. It's not something we talk about and then we just kind of ignore it and we just talk about it again in two weeks time or whatever it is. It's the putting into practice the decisions you make as a team and those retrospectives all of the time. They're not massive actions either. They're just little tweaks here and there.
Chloe Hall:
Yeah, there's small things.
Renae Craven:
They just kind of build up over time.Chloe Hall:
And that's the thing, it's like if you do it on a regular occurrence, they are small things, but if you are not doing it regularly, then that's when they build up and they become big things, big problems and massive blockers within the team as well.
Renae Craven:
Yeah, absolutely.
Chloe Hall:
Yeah. So I'm wondering too, Renae, when you do your Agile coaching and your Agile training, so you do that on an individual basis as well as teams. Do you think there's an aspect of the mindset, the agile mindset there, and does each individual need to come to work with that agile mindset for the team to be able to flow better?
Renae Craven:
Mindsets. If everyone had the same mindset then it would be robots or.
Chloe Hall:
True.
Renae Craven:
The world would be very boring.
Chloe Hall:
Very good point.
Renae Craven:
I think that's a bit, for me when I think about a team, an agile team, as long as there's some alignment on how the team behaves, why they exist, what their purpose is and how they treat each other and how they solve problems together, then the mindsets of the individuals within that team, they can be different. And that's fine as long as there's that agreement amongst everyone of this is how we are going to behave. I come up against people all the time who have been forced to work in this agile way. So their mindset's definitely not in the mindset that you need for an agile team, but if they're in an agile team and there's people in that team that have got the mindset or the behaviors that you need to have in order to deliver in an agile way, over time it kind of balances out.
And over time those the mindsets will start to shift as well as they see how other people in their team are behaving, how their leaders are behaving, things like that. So I kind of always think of it as more of a behavioral thing than a mindset thing. How do we make decisions, like I said, how do we treat each other, how do we approach problems, who are our customers, all of that sort of stuff. It's more that behavior that I like to, instead of me thinking, oh, they don't have the mindset, they don't have the mindset, I just kind of look at how they behave. Because at the end of the day, you can't force that
mindset. But as a team, when they start humming to working together as a team, they're going to be delivering what they need to deliver. And they all just, that's the whole cross-functional part of it. You're bringing together different minds, different backgrounds, different experiences, different skills, all of that stuff.Chloe Hall:
Definitely.
Renae Craven:
You're putting them in a team together so that they can use their skills. They're all those different pieces to solve these problems.
Chloe Hall:
Yeah, no, definitely. I think the way people behave, it has a lot to do with it as well. And I think on that too, you can be in the right type of mindset, you can behave in the right way. And that has a lot to do with the way you're showing up at work as well. It's the way you come to work. If you're had a bad morning, then that's going to impact how you are that day. Or if you've waking up that morning and you have kind of a set morning routine that gets you into that good routine for the day, that good mindset and behavior, then it can help a lot. And I think as well, this is something I'd love to chat to you about too, because you've got the background of Pilates, you're in your own studio and you've been a instructor for how many years now?
Renae Craven:
It'll be a year and a half since I qualified.
Chloe Hall:
Yeah. Nice. Yeah, so I'm also an instructor. I've been teaching I think for about six months now. But I'm just wondering too, so you've got your two passions, Pilates studio owner and then also an Agile coach. Is there that element of setting yourself up for the day in the morning, do you think if someone, they meditate have the type of morning routine they exercise, can they behave better at work essentially? What are your thoughts on that?
Renae Craven:
Yeah, I think definitely the better you feel in yourself or the way feel within yourself, definitely has a direct correlation to how you come across how you behave at work. So yeah, if you've had a rushed morning or a traffic was crap on the way to work or whatever it is, then definitely you're going to be quite wound up by the time you get to work.
Chloe Hall:
Yeah, definitely.
Renae Craven:
It's going to impact the way that you respond to questions or respond to people or respond to your team or whatever it is. Yeah, absolutely. But myself, I don't really have a set routine in the morning. I go to gym but I don't go to gym every day. But the mornings that I do go to gym, I never feel like going because no, I just want to sleep.Chloe Hall:
It's early. Yeah.
Renae Craven:
Yeah. But I have to go in the morning or I won't go to gym. Gym's something that, it's a bit of a love hate relationship. I know I have to do it, but I don't like doing it.
Chloe Hall:
Not even after? That feeling after?
Renae Craven:
Afterwards is good. It was like, but from, oh thank God that's done.
Chloe Hall:
Yeah.
Renae Craven:
Tick I'm done for the day.
Chloe Hall:
Out of the way.
Renae Craven:
If it was in the afternoon, if I went to gym in the afternoon I wouldn't go. It would just be, "Nah, it's too hard or I can't be bothered, I'm too tired". So getting up first thing in the morning, I set my alarm 15 minutes before my gym class starts.
Chloe Hall:
Wow. That is effort.
Renae Craven:
I know.
Chloe Hall:
That is good.
Renae Craven:
I race to get there but I have all my clothes set out the night before so I don't even have to think. I just get out of bed, I put my clothes on and I get in the car and I drive to the gym and.
Chloe Hall:
I do the same thing.
Renae Craven:
I do my class, I haven't had time to talk myself out of it just yet. But afterwards it's like, oh yes, excellent. That's done for the day. And yeah, it is nice to know that you have done that for the day as you start your work day as well. So on my gym days, that's probably my routine to get myself ready for work. But other days they're a little bit more relaxed I guess. I think if anything having a coffee is my, I cannot deal with the world without coffee. So whether I'm at home or I'm in the office, the first thing I'll do is if I get to the office I'll get a coffee on the way in. So I'm drinking coffee as I walk into the office. So yeah, I guess that you could call that my routine.
Chloe Hall:
No, I think a lot of people, a lot of listeners as well will be able to resonate with that. And I used to be like that and then it just, coffee wasn't sitting well with me. I found it was just really triggering my nerves for the day and everything. So it was so hard. I went from drinking two to three coffees a day to getting off it and now I'll drink like a matcha instead. But that was such a big part of my morning routine as well and getting off it was one of the hardest things I've had to do.
Renae Craven:
Yeah, I did that once. I detoxed for one of those health retreat things years and years ago and I had to detox off coffee and everything actually.
Chloe Hall:
Oh really?
Renae Craven:
Before two weeks leading up to it and yeah, coffee was hard.
Chloe Hall:
Yes.
Renae Craven:
Very, very hard. Because I love the taste of my coffee. I just have it straight, I don't have any milk so I love the taste of my coffee.
Chloe Hall:
Yeah, wow. Okay.
Renae Craven:
But maybe it's also the other benefits of not wanting to kill people that coffee does to me as well. I can deal with the world now. I've had my coffee.Chloe Hall:
You're like okay, all right. Who needs coaching now? Who needs training? And I'm ready to rock and roll.
Renae Craven:
Yeah, I'm good now.
Chloe Hall:
Yeah. Nice. Yeah. Well the reason as well why I wanted to talk about the whole exercise correlation with work was because I did read your article on LinkedIn about what sitting all day is doing to your body and you're saying how Pilates can help with that. The section that I think resonated really well with me was when you said, when COVID-19 shut down the world and confined everyone working from home, those people who were working in the office environments, you found yourself sitting bent over a PC at home all day and it's back to back virtual meetings, you don't really have that chance to get up, have a break, go for a walk around and everything. And I think, I'm sure a lot of our listeners will be in that reality and even after COVID it is still the case. So I think just for the sake of everyone listening, is there any tips or anything to get you up, get you moving so you're not experiencing that on the daily.
Renae Craven:
I think the other difference is before COVID, sure you were sitting at your desk all day at work but you are also walking to the office and walking to meetings and walking to the kitchen and walking to go and buy your lunch and things like that. And you weren't kind of back to back meetings either. So you had that chance and if you were walking from room to room so you were getting up. Whereas at home it's just back to back meetings and I don't know about you but I run to go to the bathroom in between meetings.
Chloe Hall:
Yeah. I do. I actually do. Yesterday actually bit triggered by that.
Renae Craven:
I did that too yesterday actually. And even at the height of COVID, the back to back meetings were so bad. I didn't even have a lunch break. I was working, I was making my lunch in meetings and daylight saving as well. It always throws things because Queensland stays where they are and it throws everything out so. So in my article actually, it was more of a paper that I had to submit as part of my instructor course.
Chloe Hall:
Oh cool. Yeah.
Renae Craven:
And as well as my 600 hours of practice and.
Chloe Hall:Yeah. I can relate, I didn't have to do the article though.
Renae Craven:
So I kind of just pulled bits out of that and because I thought this is still relevant and maybe it will resonate with people and especially the people that I'm linked, LinkedIn is the audience, right? So that just things that happen from sitting, sitting down's bad for you, full stop. Where you're working or sitting on a couch all day, whatever it is, sitting down's bad for you. And the longer you sit, the more kind of slouched you get. The more your spine is always kind of in the rounded state, the less you are using your back muscles, your back extensors, the more you're sitting down your pelvis, your hip flexes are shortening because you're always sitting down and that kind of tightens your lower back. And then you've got your, even just using your mouse, you've got that shoulder that's doing extra stuff or backwards and forward stuff constantly. And then your neck as well and your traps, everything gets kind of tight.
So things that you can do. I wrote a, my article's got an example class plan to undo the effects of sitting down all day in an office job. But that class plan uses all of the apparatus. So there's things you can do on the mat or the reformer or the Cadillac or under chair. But I run a few online classes after work and they started during COVID and they're still going. And I designed those specifically to undo, I know those people have been sitting down all day. So my classes are very much unraveling everything that they've done the all day.
Chloe Hall:
The body.
Renae Craven:
I mean my classes, my math classes anyway, they're usually focused around, I mean tips for people not actually coming to a class but undoing, you're doing the opposite of what you've been doing all day. So if you sit all day, stand up, walk around, at least listen to your smart watch when it tells you take a break. Stand up and take a break. And walk out to the letter box and get some sunshine at the same time, if you're lucky there's not much suns around these days.
Chloe Hall:
If it's out, make a run for it.
Renae Craven:
Doing kind of shoulder rolls and neck stretches and hip flexors stretches so that you, like I said, just undoing, doing the opposite of what you do when you're sitting. So think about the muscles or the tendons or whatever they're, even if you're not familiar with what they are, you know there's some at the front of your hip. And when you're sitting you can imagine that they're not being used, they're just being stuck there. So straighten them. Stretch them. If you're rounded all the time in your spine, then press roll your shoulders back, press your chest for and use your back muscles. And I don't even know if people are that familiar with back extensors. I don't know if people understand that. Because you've got your spine and then you've got these muscles that they're twisted that run either side of your spine. I can't remember the scientific name for them right now.
Chloe Hall:No. Me neither.
Renae Craven:
We just call them back extensors. And when you straighten in your spine, they're working and you're switching them on. It's just working your bicep, strengthening that muscle when you straighten your spine and you can even go past straight and go kind of backwards. You are using those back muscles and you're strengthening those back muscles and it'll stop you being like a rounded.
Chloe Hall:
Yeah, just bent over in the computer all day.
Renae Craven:
Hunched over.
Chloe Hall:
Yeah. That's it. You don't want that.
Renae Craven:
So it's really just doing the opposite or yeah. Joining online classes. I can put you through some exercises.
Chloe Hall:
Yeah, well we'll definitely share that article as well with this podcast so people can see that program or might be something that helps. For me at work we're very fortunate that we have a standing desk and I think that that is just so amazing. Because if I work from home, I don't have a standing desk and I can feel the difference. My body just feels, you just don't feel right and I feel more fatigued and yeah, I just need to get up and move more often.
Renae Craven:
Yeah. If you stand all day, it's the same thing. You've got to sit as well. You've still got to do the opposite. Standing is like, because you can get slouch when you stand as well, so you can still over time get tired and kind of slouch over or you're still kind of tense in your shoulders and things like that. So you can kind of need to still be aware of your posture when you're standing and just self-correct or still go for walks, still give everything a chance to move the way it's supposed to move not stand still all day.
Chloe Hall:
Yeah, definitely. On that, Renae. Yeah. Thank you so much for coming on the podcast today. Really enjoyed this chat with you. I think there's a lot that our listers will get out of it and I definitely want to continue more of this Pilates conversation too.
Renae Craven:
Thank you Chloe. Thanks for having me.
Chloe Hall:No worries, thank you.
PodcastEasy Agile Podcast Ep.5 Andrew Malak, Chief Product Officer at Spaceship
"I really enjoyed my conversation with Andrew Malak. We talk integrating agile techniques and tips on how to achieve a culture of accountability"
Andrew is a firm believer that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes.
Enjoy the episode!
Transcript
Teagan Harbridge:
Welcome to another episode of the Easy Agile Podcast. I'm Teagan, head of product here at Easy Agile. And we've got a really exciting guest on the show today, Andrew Malak from Spaceship. He's the chief product officer. Andrew is a true believer in creating products and experiences that solve customer problems. He believes that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes. In his current role, Andrew aims to help people take control of their wealth from a young age, educating good money habits and helping people invest where the world is going. Andrew is a family man who loves his time with his wife and children. And believe it or not, he uses agile techniques in his personal and professional life. Andrew is an economics geek. He plays and coaches soccer, football. He's a big Liverpool supporter, loves to travel, loves amazing architecture, and loves working with children.
Teagan Harbridge:
There were so many takeaways from my chat with Andrew that I really struggled to pair it down to three. But if you say tuned, here are some of the things that you're going to learn from our chat with Andrew. Why we should stop using the term agile transformation and start calling it an agile evolution. Why it's important to be open-minded to our own limitations so to break the old mindset of protecting original scope. And tips on how to achieve a culture of accountability. So I hope you enjoy. Andrew, can you tell me a little bit about Spaceship?
Andrew Malak:
Oh, fantastic. Well, thank you very much for, first of all, having me, Teagan. Spaceship is a business that's on a journey to make good money habits and investing accessible to all people. So what we look for is trends to do with industries or companies who are building the future of both industry or economies. We invest in them for the longterm, we break down barriers of entry for people, we give them a fee-free product under $5,000, no minimum investments. It's really easy to sign up. You simply download an app and you sign up and make one product selection decision, and you're done. You can start investing on autopilot. We allow you to also invest your superannuation in a not too dissimilar way.
Teagan Harbridge:
So tell me a little bit about who your target customer is, then. Because it seems like you're trying to make something quite complicated accessible for maybe first time investors.
Andrew Malak:
Well, you're absolutely right. There's a niche segment of people out there at the moment, millennials or even gen Zs, that we just don't think have been well serviced by the incumbents. And what we're trying to do is resonate with these young people as much as possible. We're trying to reduce industry jargon and really make things simple to them, because investing doesn't have to be complex. It's really about a lot of discipline around, if I can manage my personal P&L, or money in, money out, then I can create a cash buffer that can go into my assets column on my balance sheet. That's really what we're trying to do. And that kind of language, if we can get it right, can really simplify things that have typically been in the hands of financial advisors and accountants and give it back to everyday Australians who are starting out in their investment journey.
Teagan Harbridge:
Yeah, awesome. And you've been on quite a journey before landing in the FinTech space as the Spaceship CPO. So can you tell me and our audience a little bit about what that journey has looked like?
Andrew Malak:
Oh, where do I start? If you asked a graduate Andrew Malak what he'd be doing now, I don't think I would've been speaking about this because at that point in time in my career I didn't know this space would actually be around, if that makes sense. So I'll go back to my younger years, and I always thought I was going to be an architect. I had this fascination with bridges and I wanted to design things and see them come to life. And let's just say that I do that in different ways right now, but I started out working in CommSec on the trading floor. I moved on to work as a business analyst, and that's where I started my critical thinking into how businesses work and how things can be made more efficient.
Andrew Malak:
I dabbled in teaching for a little bit, I taught high school economics and religion for a little bit. And then I eventually landed in a product role at St. George Bank prior to the merger with Westpac. At that point in time, the light bulb really came on. I realized, "Hey, I like creating things. I like to change things. I don't like to just do things," if that makes sense. And that wondering mind that doesn't like the conform was finally let loose, if that makes sense. And I haven't stopped enjoying it. I loved my time at Westpac, made lots of friends, worked on really cool, successful projects, and implemented lots of things that had great results. Worked on lots of things that have failed miserably and learnt a lot out of that. And when the opportunity at Spaceship started to surface late last year, it was just too good an opportunity to not really come in and have a go. So yeah, it's been quite the journey.
Teagan Harbridge:
Yeah, wow. And I love a good failure story. And you said you've had lots. Can you think, just off the top of your head, what one of those big failures has been?
Andrew Malak:
Where do I start? I think our first attempt at taking a digital experience to allow customers to acquire a product online was quite a failure that taught us a lot. We basically took the systems that our back office staff used and just made it available to customers. And the real good learning out of that is there was a lot of traffic and a lot of demand, but not enough completion ever. And the best learning that came out of that... This is back in 2006, so internet speeds were just starting to pick up. Broadband was starting to go mainstream and customers' trust around doing more transactions that used personally identifiable data was starting to normalize at that point in time. Up until then, people quite reserved thinking, "I'm going to lose my personal data," et cetera. So when we decided to do that, we saw that there was a lot of demand but we quickly came to the realization that we used to train staff for four to six weeks on how to use the systems before they knew how to service customers using them.
Andrew Malak:
But then we've deployed it into production for customers to self-service and realized quite quickly that the experience for customers had to be much more guided than the experience for a staff member. This is where the evolution of usability or design thinking started to come in. We started thinking of, "Well, how do we make these things so easy that a first-time user can go end to end and not encounter friction?" And this is where our understanding of design principles, customer testing using verbatim and anguage that can resonate with a first-time user becomes critical to the execution. It's not just good systems but it's good user experience sitting on top of systems.
Andrew Malak:
That's probably the one that resonates with me the most because I've held that to a very high regard throughout my whole career. Now everything I do I think of, "Where's the friction? How do we make sure there's no friction? What's the customer going to feel throughout this experience? How are we creating unnecessary anxiety in that experience for the customer, and how do we move that away? How do we become more transparent but still be simple?" And yeah, that's probably the one that resonates the most.
Teagan Harbridge:
Seems like a tremendous learning opportunity early enough in that project and something that's stuck with you since, so great learning opportunity.
Andrew Malak:
Absolutely.
Teagan Harbridge:
We've got a ton of customers who are at all stages of their agile transformations, and I know that this is something that you've had experience with if we go back to your St. George, Westpac days. Can you give our audience any tips or stories that you encountered when you were going through those agile transformations? What lessons can you share with our audience?
Andrew Malak:
Oh, I have lots of lessons to share, actually.
Teagan Harbridge:
This is what I love.
Andrew Malak:
Look, I like to position it more as agile evolution more than agile transformation because no matter what you try to do, you're not just going to drop waterfall and become agile next morning. Honestly, I've seen so many attempts and every single time I see that the graduality of the change is a better predictability of the final outcome that you're going to land. So ultimately the Holy Grail that everyone's aspiring to is that, as a leader, you can rock up to a team stand up unexpected and then, without being told who is in what role, who the product owner is, who the engineer is, who the QC is, who the designer is, it becomes hard for you as the leader to work out who's who because at that point in time the team is so well converged on customer outcomes that they will self-organize themselves around what each person needs to do.
Andrew Malak:
And most of the language being used is really around, what are we trying to define the customer? What's the best thing to do within the capacity that we have to deliver this feature to market as quickly as possible, capture value for the customer and the business as much as possible? This takes a long time to get to, where you can start normalizing to a standardized, common set of goals, common cadence, and common ways of working. And I think it's ultimately about how much empowerment you can give people and how much as a leader you can relegate yourself in the background to allow them to work it out themselves as long as you're coming in and nudging things along the way and helping people course correct along the way. So the good news is that I actually think at Spaceship, we're pretty close to getting there.
Andrew Malak:
We have been running scrum and we have been running sprints for a long time, but it has been largely ceremonials. But over the last quarter, we've done a really good job at embedding more cross-functional people into these teams. But the goal for us is that now we feel like our throughput has actually increased and that the constant flow of information between the teams is becoming more natural and there is actually less ambiguity between the teams around, "All right, we built it this way. The API is no longer consumable. It doesn't fit what we're trying to do from our front-end and there's less back and forth." So we can really see that the amount of friction between persons in the team is really starting to reduce dramatically and we're starting to see that throughput really increase. Having said that, the best way to go about an agile transformation is just get started.
Andrew Malak:
You can sit and plan out things and plan towards utopia as much as you want or you can actually just get going. So when I say by get going, I say you have to start by getting buy-in from all the leaders of the different cross-functional teams, because if you don't have that buy-in at the leadership level, it's just not going to work because there's going to be blockers, there's going to be escalations. And if all these things result in conversations around, "Should we keep doing this?" Or, "Hey, maybe this is not the right thing to do." That needs to be off the table really early on and it needs to be a total commitment at the leadership level that we're going to make this work and whatever we encounter we're just going to fix forward. Once you have that commitment at the leadership level, you need to very clearly define the values that the team is going to be handed to work with, because agile itself, it's not a process, it's a set of values that the team needs to just take and start working with.
Andrew Malak:
So we could go and rattle individuals and interactions over processes and tools or working software over comprehensive documentation. Well, give these to the team and they're going to say to you at day one, "We can't go to all of that straight away." So they might actually say that day one, "We're still going to need some documentation because we're not comfortable yet. We don't understand the language of the other people in the scrum team well enough to be able to go and actually code off the back of a conversation." But by the 10th sprint, the 20th sprint, that misunderstanding of what the product owner wants or what the designer is trying to achieve in an experience starts to become embedded in the mind of the engineer.
Andrew Malak:
The engineer understands the customer a lot more, and then you can make do with less process and less documentation and less negotiated outcomes and more commonality across the team. The other thing that then starts to kick in at that stage is that ability of the team to pivot in response to a change and not see that as a threat to what they're trying to achieve. The old ways of working was, define that scope, protect that scope, and not let things disturb that scope, whereas if you're halfway through a project and you get some really good information that tells you that maybe you are not on track to achieve a good outcome, you should be welcoming that. And the team itself in the beginning is going to find that an irritation, but over time they'll become more comfortable with pivoting off the back of new information.
Teagan Harbridge:
Yeah. It's a big mindset shift. I was just having a discussion today about, where does being agile and being reactive, where's that line in the middle. And when does taking information and pivoting because you think something will be better, when can we break that mindset of, "Oh, we're just being reactive?" No, we're being responsive.
Andrew Malak:
Yeah, yeah. And look, I think the word reactive itself naturally has a negative connotation to it, but agility in mindset allows you to flip that on its head and say that no one can work things out in totality to 100% of what's possible, so being open-minded to our own limitations first and foremost allows us to acknowledge that when new information comes in, it is because we didn't think through the solution 100%, but let's also be okay with that because no one can. So I think it's flipping on its head and acknowledging it upfront and saying that this is going to happen, but when it comes we will assess the information we have with the capacity we have with how far progressive we are and make a decision that's right for us, for the customer, and for what's possible.
Andrew Malak:
So I take it as the more information you get along the way, the more reinforcement of, are you doing what's right or should you pivot and change at that point in time? The other thing that happens really early on is that if you as a leader can create a really clear vision around customer outcomes and establish your first cross-functional team and hand over that vision to the team, it becomes theirs. Don't hand over the backlog to the team. Don't give them a ready backlog, just give them the vision and then tell them, "You guys work out what your backlog looks like." When they come up with their own backlog, as long as you as a leader don't see that it's just a list of Hail Marys in it and there is a fair bit in there that is well spread out between hygiene things, strategic things, and a few moonshots and the balance is right, if the team has come up with their own backlog, the motivation they have to build their own ideas just goes through the roof.
Andrew Malak:
And that's what you want to achieve. You want to achieve clarity that the work fits with the vision and the motivation that you get out of the backlog being created by the team itself gets you that throughput enhancement. The other thing that you're going to struggle with really early on is chunking things down to fitting within the sprint cadence. I think that's one that's often been my biggest challenge when moving towards agile practices early on. Typically in the first few sprints, you always have overruns and things don't complete in the sprint because we end up thinking we can do more than we can and it takes us a while to work out, in wrapping up something that becomes shippable in a sprint, you probably take a little bit less in that sprint because you've got to test it or you've got to do a release in that sprint, or you're going to do a PIR in that sprint, or you're going to do a lot of retros in that sprint. Start to sort of formulate what you're going to take through the next planning cycle.
Andrew Malak:
So you've got to budget to that capacity, and I'll find that teams underestimate the magnitude of that work. So be okay with that. Overruns in the first few sprints don't mean you've failed, it means you're learning how to plan better. And then make sure your retros and your pivot off the back of that into your next planning sessions is taking information that is now new to you, and making sure you're working with it. I think as the leader, though, you have to set the expectations that teams can make mistakes and that it's a safe environment.
Andrew Malak:
And I've seen many agile... I was about to use the word transformation, even though I've just said I don't believe in transformation. Any teams that are adopting agile principles expecting that in their first few sprints they don't have any hiccups, and that if throughput falls in the first few sprints, then there's a bit of a, "Oh, well you told me this thing was going to increase our throughput." Yeah, but not straight away. So I think just being realistic with yourself and what's possible, and that shift in itself, until it normalizes, takes a bit of getting used to. The teams need to know it's a safe environment, that if their productivity suffers, if they make mistakes or if they break things, it's going to be okay. We'll fix forward.
Andrew Malak:
But then also there comes a point in time where we have to be very clear about the culture of accountability around using that capacity really well. So what I've found, that the best use of that is the showcase. And what we've done at Spaceship, because we're trying to reduce the amount of ceremonies, we've combined both the planning playback in a sprint as well as the showcase into the same ceremony. So what we do is we play back what we built last session using a demonstration of working software and comparing the amount of work we've executed versus what was planned in the previous sprint. We're saying we've got 80%, 90% through the work and this is what it looks and feels like, and this is what we're deploying to the customer. Then we actually showcase what we plan to do in the next sprint.
Andrew Malak:
And that's part of the showcase, is our hand on heart commitment to, "This is what we as a team are committed to doing in the next sprint." And then that accountability to the organization becomes something that keeps us on track throughout the sprint. As distractors or things that are not committed in the sprint come our way, we quickly think about, all right, can we accommodate these things? Do they need to be done? Are they going to take us off track with what is planned? Are they important enough? Is it a major defect of production, and can customers no longer access our app? Well, drop what you're doing and attend to that. Otherwise, if it's not material, keep focused on the work that you've committed to in front of the organization.
Andrew Malak:
After this you're going to start to experience some growing pain, and the growing pain is good because it means that agile is working and more teams or more feature opportunities become possible for the business. There's going to be a lot more hype around moving to agile. Other teams are going to come across and say, "Oh, how do we piggyback off what you're doing?" Et cetera. This is good. This is good, but what it means now is that some new risks are going to actually start to be introduced. Working with common code, common dependencies, or even common people being needed to be doing multiple things just means that you now need more coordination. I'd say to anyone who reaches this point in time, this is where people feel compelled to start introducing some new roles, coordination roles. And I'd just say, be careful because that can start add to your overhead really quickly.
Andrew Malak:
I find the best way to ensure that teams continue to be in sync is with the right dialogue at the right level with the right rhythm. And this is where I think keeping it simple to just the scrum of scrums works really well. I like the scrum of scrums to be balanced between both product owner and tech lead from each team being present, and a cadence of one to two times per week works really well. And as long as the product owners across the teams and the tech leads across the teams know what the other teams are working on, know what could impact their own work from a release perspective or scheduling perspective or an environment perspective, I think that tends to work really well as well.
Teagan Harbridge:
Yeah, wow. Lots of nuggets in there and certainly things that resonate with our experience here at Easy Agile, being a small company that's grown really quickly. So I can definitely relate. We've had conversations about, do we introduce new roles into this company? We've introduced a new cadence of meeting rhythms only the last couple of months, so we're going through these things too.
Andrew Malak:
Absolutely. Absolutely. What have been your biggest learnings so far?
Teagan Harbridge:
I think that you cannot underestimate communication, and it really does come back to that cadence and that rhythm with the team. And we're experimenting at the moment with a daily huddle where we're talking about, how do we embed showcases more regularly in our cycles? We've got a big demo at the end of the cycle. How can we make that a more ingrained part of our culture? And it really does come back to that culture of accountability as well. So yep, it's all resonating.
Andrew Malak:
Yeah, absolutely. Look, you can go to whatever industry you want but the problems are usually similar. And the great thing is that having these conversations is very important to fast-tracking your way forward, because your problem is not unique to you. Someone else has seen it in someone else has figured out a way. And I think what I like about the FinTech industry is that we compete on products and services, but there's a lot to learn from each other. And even if you just go outside of FinTech, there's a lot to learn from other industries who have adopted agile practices.
Teagan Harbridge:
If we take a bit of a flip, we've gone from your professional career and your experience into a more personal level. You mentioned that you use agile techniques outside of work. So I'm not sure if many others are in the same boat, but can you elaborate on this? What does that mean? What does that look like?
Andrew Malak:
Okay, I hope you don't think I'm extremely weird. We actually have a family campaign. So I guess if I go back to how we've come to actually doing this. Becoming parents, we would look at our children and see so many things that we want them to be better at. And in trying to give them constant feedback, which felt like the feedback was so much that it's all being drowned out because there's so much of it. In fact, my oldest son actually gave me that feedback. He goes, "Dad, why don't we focus on one thing at a time?"
Andrew Malak:
And I was like, "Wow, okay." For a ten-year-old to tell me that, that was amazing. So we came to realize that we needed to narrow and focus on one improvement area at a time, and we don't move on to the next one until we've actually closed out the first one. For example, my oldest son, very clever boy. We're trying to focus with him on the discipline of process over just getting the answer right, because he is clever and nine times out of 10, ask him a question, he's got the answer and he just wants to say it.
Andrew Malak:
But we've started to try to break down the question and work more on the process with him so that in following the process, coupled with his natural ability, we will get more answers right more often. And that's what we're working through at the moment. So our family's scrum wall at the moment has a mix of things on it. Everyone has their own swim lane, and in each swim lane there are a few tasks, some related work or study, some relating to household chores, some related to health or exercise, and some related to acts of kindness. And what we aim to do is make sure that we're moving things across in all four categories every single day. So yeah, you can use agility wherever you'd like but I think that mindset in general, that if I wake up every day and do things that make me better than I was yesterday, then I'll get to keep moving forward in my personal life as well as my professional life.
Teagan Harbridge:
And do you have WIP limits?
Andrew Malak:
We don't at the moment, and we're not doing showcases at the moment. We'll see how we can introduce them in the future.
Teagan Harbridge:
And how was the introduction of a Kanban board at home? How was that received by the family? Have they enjoyed it, has there been any feedback?
Andrew Malak:
Well, it wasn't actually planned. It started by just sticking some Post-its up on the fridge to remind us of stuff. And then one day I said to my wife, "You know what? This reminds me of what we do at work. Why don't we formalize it?" She had a bit of a chuckle but then one day she came back and then she found it there. So yeah, it wasn't really planned.
Teagan Harbridge:
Awesome. And you've already been super generous with your time so I'll close it out with one final question. What advice do you wish someone would have given you when you took the leap from product management into product leadership?
Andrew Malak:
Yeah, that's a really good question. I think first and foremost, that you've got to make sure that you drop your need for perfectionism, because first and foremost, you might have been the best product manager yourself. You might have been amazing. And I'm not saying I was, but if you were and you step up in leadership role, you're going to have people of different abilities working for you. And what you need to understand is that they're going to need some time learning their role and learning their trade. And just don't get in the way of them learn. So for example, you might see someone doing something that may not be the best or most optimal use of that capacity in that sprint. You might feel the urge to jump in and course correct. But if you let them go and just hear their feedback post the retro, they might've had that learning themselves, and a learning that they get for themselves rather than being told by their leader is going to be much more useful for them.
Andrew Malak:
You have to drop your need to make decisions and be in control because, again, the more you can relegate yourself to a servant leadership role and let the team make decisions, when they make decisions and now have to go back up that decision with execution, they're more likely to put their heart and soul into it. The more they feel like you are going to make the decisions, the less inclined they are to think through problems themselves, and then they'll keep bringing the problems back to you. So every time someone asks you a question that has a black and white answer, throw it back to them and ask them what they think, because that way you're coaching them to work it out themselves. And then the last thing that's really important is, I feel like it's really important to think through how your organization allows you to be different and take advantage of that differentiation.
Andrew Malak:
So for example, at Spaceship here, because we're small, we're not a large corporate, our customers are a little bit more forgiving. So you have a limited capacity to build experiences and you can't do all things at the same time. Understand that and take advantage of it, and get your team to also learn that. Because if you're trying to how the all edge cases, it will take a lot longer to get something to market and you might use a lot of the team's capacity to build edge cases. And you can't really afford that when you're in a start-up.
Andrew Malak:
So for example, we launched a new investment portfolio yesterday. We launched the Spaceship Earth portfolio, our first sustainable investment portfolio and it's a sign of more things to come hopefully in the sustainability space. But in launching that, we knew that we have a limitation in our experience or our product set today where each customer can only have one portfolio. We knew that existing customers would want to invest in sustainable investing, but our commitment to them is that it's in our backlog and it's actually the next feature that we're actually going to take to market.
Andrew Malak:
And in explaining that to our customers, they've been very understanding, that they know our throughput is limited but they also know that their voice is being heard and we are building the things that they're telling us about. So I would say that the best piece of advice to tell my young self is to make sure that you get the balance right between the voice of the customer. That's going to tell you all the hygiene things that your product lacks in terms of experience or gaps. And then get the balance between new strategic things that you can go after and new things that you can take to market, as well as a few Hail Marys every now and again. We call them moonshots. They may or may not work, but it's exciting, and if it works, can 10X your volume. And they are the things that are likely to go viral. So getting the balance right is very important.
Teagan Harbridge:
It's been wonderful, Andrew. I've definitely taken a lot away from our chat today, and I'm sure our audience will too. So thank you again so much for your time, and good luck.
Andrew Malak:
No Teagan, look, thank you very much. And it's been a pleasure speaking to yourself and Easy Agile, and I wish you guys all the best too.
Teagan Harbridge:
Awesome. Thanks Andrew.
Andrew Malak:
Have a good afternoon.
PodcastEasy Agile Podcast Ep.32 Why Your Retrospectives Keep Failing (and How to Finally Fix Them)
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.