Easy Agile Podcast Ep.34 Henrik Kniberg on Team Productivity, Code Quality, and the Future of Software Engineering

Listen on
Subscribe to our newsletter
  • website.easyagile.com/blog/rss.xml

TL;DR

Henrik Kniberg, the agile coach behind Spotify's model, discusses how AI is fundamentally transforming software development. Key takeaways: AI tools like Cursor and Claude are enabling 10x productivity gains; teams should give developers access to paid AI tools and encourage experimentation; coding will largely disappear as a manual task within 3–4 years; teams will shrink to 2 people plus AI; sprints will become obsolete in favour of continuous delivery; product owners can now write code via AI, creating pull requests instead of user stories; the key is treating AI like a brilliant intern – when it fails, the problem is usually your prompt or code structure, not the AI. Bottom line: Learn to use AI now, or risk being left behind in a rapidly changing landscape.

Introduction

Artificial intelligence is fundamentally reshaping how software teams work, collaborate, and deliver value. But with this transformation comes questions: How do we maintain team morale when people fear being replaced? What happens to code quality when AI writes most of the code? Do traditional agile practices like sprints still make sense?

In this episode, I sit down with Henrik Kniberg to tackle these questions head-on. Henrik is uniquely positioned to guide us through this transition – he's the agile coach and entrepreneur who pioneered the famous Spotify model and helped transform how Lego approached agile development. Now, as co-founder of Abundly AI, he's at the forefront of helping teams integrate AI into their product development workflows.

This conversation goes deep into the practical realities of AI-powered development: from maintaining code review processes when productivity increases 10x, to ethical considerations around AI usage, to what cross-functional teams will look like in just a few years. Henrik doesn't just theorise – he shares real examples from his own team, where their CEO (a non-coder) regularly submits pull requests, and where features that once took a sprint can now be built during a 7-minute subway ride.

Whether you're a developer wondering if AI will replace you, a product owner looking to leverage these tools, or a leader trying to navigate this transformation, this episode offers concrete, actionable insights for thriving in the AI era.

About Our Guest

Henrik Kniberg is an agile coach, author, and entrepreneur whose work has shaped how thousands of organisations approach software development. He's best known for creating the Spotify model – the squad-based organisational structure that revolutionised how large tech companies scale agile practices. His work at Spotify and later at Lego helped demonstrate how agile methodologies could work at enterprise scale whilst maintaining team autonomy and innovation.

Henrik's educational videos have become legendary in the agile community. His "Agile Product Ownership in a Nutshell" video, created over a decade ago, remains one of the most-watched and shared resources for understanding product ownership, with millions of views. His ability to distil complex concepts into simple, visual explanations has made him one of the most accessible voices in agile education.

More recently, Henrik has turned his attention to the intersection of AI and product development. As co-founder of Abundly AI, he's moved from teaching about agile transformation to leading AI transformation – helping companies and teams understand how to effectively integrate generative AI tools into their development workflows. His approach combines his deep understanding of team dynamics and agile principles with hands-on experience using cutting-edge AI tools like Claude, Cursor, and GitHub Copilot.

Henrik codes daily using AI and has been doing so for over two and a half years, giving him practical, lived experience with these tools that goes beyond theoretical understanding. He creates educational content about AI, trains teams on effective AI usage, and consults with organisations navigating their own AI transformations. His perspective is particularly valuable because he views AI through the lens of organisational change management – recognising that successful AI adoption isn't just about the technology, it's about people, culture, and process.

Based in Stockholm, Sweden, Henrik continues to push the boundaries of what's possible when human creativity and AI capabilities combine, whilst maintaining a pragmatic, human-centred approach to technological change.

Transcript

Note: This transcript has been lightly edited for clarity and readability.

Maintaining Team Morale and Motivation in the AI Era

Tenille Hoppo: Hi there, team, and welcome to this new episode of the Easy Agile Podcast. My name is Tenille Hoppo, and I'm feeling really quite lucky to have an opportunity to chat today with our guest, Henrik Kniberg.

Henrik is an agile coach, author, and entrepreneur known for pioneering agile practices at companies like Spotify and Lego, and more recently for his thought leadership in applying AI to product development. Henrik co-founded Abundly AI, and when he isn't making excellent videos to help us all understand AI, he is focused on the practical application of generative AI in product development and training teams to use these technologies effectively.

Drawing on his extensive experience in agile methodologies and team coaching, Henrik seems the perfect person to learn from when thinking about the intersection of AI, product development, and effective team dynamics. So a very warm welcome to you, Henrik.

Henrik Kniberg: Thank you very much. It's good to be here.

Tenille: I think most people would agree that motivated people do better work. So I'd like to start today by touching on the very human element of this discussion and helping people maintain momentum and motivation when they may be feeling some concern or uncertainty about the upheaval that AI might represent for them in their role.

What would you suggest that leaders do to encourage the use of AI in ways that increase team morale and creativity rather than risking people feeling quite concerned or even potentially replaced?

Henrik: There are kind of two sides to the coin. There's one side that says, "Oh, AI is gonna take my job, and I'm gonna get fired." And the other side says, "Oh, AI is going to give me superpowers and give us all superpowers, and thereby give us better job security than we had before."

I think it's important to press on the second point from a leader's perspective. Pitch it as this is a tool, and we are entering a world where this tool is a crucial tool to understand how to use – in a similar way that everyone uses the Internet. We consider it obvious that you need to know how to use the Internet. If you don't know how to use the Internet, it's going to be hard.

"I encourage people to experiment, give them access to the tools to do so, and encourage sharing. And don't start firing people because they get productive."

I also find that people tend to get a little bit less scared once they learn to use it. It becomes less scary. It's like if you're worried there's a monster under your bed, maybe look under your bed and turn on the lights. Maybe there wasn't a monster there, or maybe it was there but it was kind of cute and just wanted a hug.

Creating a Culture of Safe Experimentation

Tenille: I've read that you encourage experimentation with AI through learning – I agree it's the best way to learn. What would you encourage leaders and team leaders to do to create a strong culture where teams feel safe to experiment?

Henrik: There are some things. One is pretty basic: just give people access to good AI tools. And that's quite hard in some large organisations because there are all kinds of resistance – compliance issues, data security issues. Are we allowed to use ChatGPT or Claude? Where is our data going? There are all these scary things that make companies either hesitate or outright try to stop people.

Start at that hygiene level. Address those impediments and solve them. When the Internet came, it was really scary to connect your computer to the Internet. But now we all do it, and you kind of have to, or you don't get any work done. We're at this similar moment now.

"Ironically, when companies are too strict about restricting people, then what people tend to do is just use shadow AI – they use it on their own in private or in secret, and then you have no control at all."

Start there. Once people have access to really good AI tools, then it's just a matter of encouraging and creating forums. Encourage people to experiment, create knowledge-sharing forums, share your own experiments. Try to role-model this yourself. Say, "I tried using AI for these different things, and here's what I learned." Also provide paths for support, like training courses.

The Right Mindset for Working with AI

Tenille: What would you encourage in team members as far as their mindset or skills go? Certainly a nature of curiosity and a willingness to learn and experiment. Is there anything beyond that that you think would be really key?

Henrik: It is a bit of a weird technology that's never really existed before. We're used to humans and code. Humans are intelligent and kind of unpredictable. We hallucinate sometimes, but we can do amazing things. Code is dumb – it executes exactly what you told it to do, and it does so every time exactly the same way. But it can't reason, it can't think.

Now we have AI and AI agents which are somewhere in the middle. They're not quite as predictable as code, but they're a lot more predictable than humans typically. They're a lot smarter than code, but maybe not quite as smart as humans – except for some tasks when they're a million times smarter than humans. So it's weird.

You need a kind of humble attitude where you come at it with a mindset of curiosity. Part of it is also to realise that a lot of the limitation is in you as a user. If you try to use AI for coding and it wrote something that didn't work, it's probably not the model itself. It's probably your skills or lack of skills because you have to learn how to use these tools. You need to have this attitude of "Oh, it failed. What can I do differently next time?" until you really learn how to use it.

"There can be some aspect of pride with developers. Like, 'I've been coding for 30 years. Of course this machine can't code better than me.' But if you think of it like 'I want this thing to be good, I want to bring out the best in this tool' – not because it's going to replace me, but because it's going to save me a tonne of time by doing all the boring parts of the coding so I can do the more interesting parts – that kind of mindset really helps."

Maintaining Code Quality and Shared Understanding

Tenille: Our team at Easy Agile is taking our steps and trying to figure out how AI is gonna work best for us. I put the question out to some of our teams, and there were various questions around people taking their first steps in using AI as a co-pilot and producing code. There are question marks around consistency of code, maintaining code quality and clean architecture, and even things like maintaining that shared understanding of the code base. What advice do you have for people in that situation?

Henrik: My first piece of advice when it comes to coding – and this is something I do every day with AI, I've been doing for about two and a half years now – is that the models now, especially Claude, have gotten to the level where it's basically never the AI's fault anymore. If it does anything wrong, it's on you.

You need to think about: okay, am I using the wrong tool maybe? Or am I not using the tool correctly?

For example, the current market leader in terms of productivity tools with AI is Cursor. There are other tools that are getting close like GitHub Copilot, but Cursor is way ahead of anything else I've seen. With Cursor, it basically digs through your code base and looks for what it needs.

But if it fails to find what it needs, you need to think about why. It probably failed for the same reason a human might have failed. Maybe your code structure was very unstructured. Maybe you need to explain to the AI what the high-level structure of your code is.

"Think of it kind of like a really smart intern who just joined your team. They're brilliant at coding, but now they got confused about something, and it's probably your code – something in it that made it confused. And now you need to clarify that."

There are ways to do that. In Cursor, for example, you can create something called cursor rules, which are like standing documents that describe certain aspects of your system. In my team, we're always tweaking those rules. Whenever we find that the AI model did something wrong, we're always analysing why. Usually it's our prompt – I just phrased it badly – or I just need to add a cursor rule, or I need to break the problem down a little bit.

It's exactly the same thing as if you go to a team and give them this massive user story that includes all these assumptions – they'll probably get some things wrong. But if you take that big problem and sit down together and analyse it and split it into smaller steps where each step is verifiable and testable, now your team can do really good work. It's exactly the same thing with AI.

Addressing the Code Review Bottleneck

Tenille: One of our senior developers found that he was outputting code at a much greater volume and faster speed, but the handbrake he found was actually their code review processes. They were keeping the same processes they had previously, and that was a bit of a handbrake for them. What kind of advice would you have there?

Henrik: This reminds me of the general issue with any kind of productivity improvement. If you have a value stream, a process where you do different parts – you do some development, some testing, you have some design – whenever you take one part of the process and make it super optimised, the bottleneck moves to somewhere else.

If testing is no longer the bottleneck, maybe coding is. And when coding is instant, then maybe customer feedback – or lack of customer feedback – is the bottleneck. The bottleneck just keeps moving. In that particular case, the bottleneck became code review. So I would just start optimising that. That's not an AI problem. It's a process problem.

Look at it: what exactly are we trying to do when we review? Maybe we could think about changing the way we review things. For example, does all code need to be reviewed? Would it be enough that the human who wrote it and the AI, together with the human, agree that this is fine? Or maybe depending on the criticality of that change, in some cases you might just let it pass or use AI to help in the reviewing process also.

"I think there's value in code review in terms of knowledge sharing in a large organisation. But maybe the review doesn't necessarily need to be a blocking process either. It could be something you go back and look at – don't let it stop you from shipping, but maybe go back once per week and say, 'Let's look at some highlights of some changes we've made.'"

We produce 10 times more code than in the past, so reviewing every line is not feasible. But maybe we can at least identify which code is most interesting to look at.

Ethical Considerations: Balancing Innovation with Responsibility

Tenille: Agile emphasises people over process and delivering value to customers. Now with AI in the mix, there's potential for raising some ethical considerations. I'm interested in your thoughts on how teams should approach these ethical considerations that come along with AI – things like balancing rapid experimentation against concerns around bias, potential data privacy concerns.

Henrik: I would treat each ethical question on its own merits. Let me give you an example. When you use AI – let's say facial recognition technology that can process and recognise faces a lot better than any human – I kind of put that in the bucket of: any tool that is really useful can also be used for bad things. A hammer, fire, electricity.

That doesn't have so much to do with the tool itself. It has much more to do with the rules and regulations and processes around the tool. I can't really separate AI in that sense. Treat it like any other system. Whenever you install a camera somewhere, with or without AI, that camera is going to see stuff. What are you allowed to do with that information? That's an important question. But I don't think it's different for AI really, in that sense, other than that AI is extremely powerful. So you need to really take that seriously, especially when it comes to things like autonomous weapons and the risk of fraud and fake news.

"An important part of it is just to make it part of the agenda. Let's say you're a recruitment company and you're now going to add some AI help in screening. At least raise the question: we could do this. Do we want to do this? What is the responsible way to do it?"

It's not that hard to come up with reasonable guidelines. Obviously, we shouldn't let the AI decide who we're going to hire or not. That's a bad idea. But maybe it can look at the pile of candidates that we plan to reject and identify some that we should take a second look at. There's nothing to lose from that because that AI did some extra research and found that this person who had a pretty weak CV actually has done amazing things before.

We're actually working with a company now where we're helping them build some AI agents. Our AI agents help them classify CVs – not by "should we hire them or not," but more like which region in Sweden is this, which type of job are we talking about here. Just classifying to make it more likely that this job application reaches the right person. That's work that humans did before with pretty bad accuracy.

The conclusion was that AI, despite having biases like we humans do, seemed to have less biases than the human. Mainly things like it's never going to be in a bad mood because it hasn't had its coffee today. It'll process everybody on the same merits.

I think of it like a peer-to-peer thing. Imagine going to a doctor – ideally, I want to have both a human doctor and an AI doctor side by side, just because they both have biases, but now they can complement each other. It's like having a second opinion. If the AI says we should do this and the doctor says, "No, wait a second," or vice versa, having those two different opinions is super useful.

Parallels Between Agile and AI Transformations

Tenille: You're recognised as one of the leading voices in agile software development. I can see, and I'm interested if you do see, some parallels between the agile transformations that you led at Spotify and Lego with the AI transformations that many businesses are looking at now.

Henrik: I agree. I find that when we help companies transition towards becoming AI native, a lot of the thinking is similar to agile. But I think we can generalise that agile transformations are not really very special either – it's organisational change.

There are some patterns involved regardless of whether you're transitioning towards an agile way of working or towards AI. Some general patterns such as: you've got to get buy-in, it's useful to do the change in an incremental way, balance bottom-up with top-down. There are all these techniques that are useful regardless. But as an agilist, if you have some skills and competence in leading and supporting a change process, then that's going to be really useful also when helping companies understand how to use AI.

Tenille: Are you seeing more top-down or bottom-up when it comes to AI transformations?

Henrik: So far it's quite new still. The jury's not in yet. But so far it looks very familiar to me. I'm seeing both. I'm seeing situations where it's pure top-down where managers are like "we got to go full-out AI," and they push it out with mixed results. And sometimes just completely bottom-up, also with mixed results.

Sometimes something can start completely organically and then totally take hold, or it starts organically and then gets squashed because there was no buy-in higher up. I saw all of that with agile as well. My guess is in most cases the most successful will be when you have a bit of both – support and guidance from the top, but maybe driven from the bottom.

"I think the bottom-up is maybe more important than ever because this technology is so weird and so fast-moving. As a leader, you don't really have a chance if you try to control it – you're going to slow things down to an unacceptable level. People will be learning things that you can't keep up with yourself. So it's better to just enable people to experiment a lot, but then of course provide guidance."

AI for Product Owners: From Ideation to Pull Requests

Tenille: You're very well known for your guidance and for your ability to explain quite complex concepts very simply and clearly. I was looking at your video on YouTube today, the Agile Product Ownership in a Nutshell video, which was uploaded about 12 years ago now. Thinking about product owners, there's a big opportunity now with AI for generating ideas, analysing data, and even suggesting new features. What's your advice for product owners and product managers in using AI most effectively?

Henrik: Use it for everything. Overuse it so you can find the limits. The second thing is: make sure you have access to a good AI model. Don't use the free ones. The difference is really large – like 10x, 100x difference – just in paying like $20 per month or something. At the moment, I can particularly strongly recommend Claude. It's in its own category of awesomeness right now. But that of course changes as they leapfrog each other. But mainly: pay up, use a paid model, and then experiment.

For product owners, typical things are what you already mentioned – ideation, creating good backlog items, splitting a story – but also writing code. I would say as a PO, there is this traditional view, for example in Scrum, that POs should not be coding. There's a reason for that: because coding takes time, and then as PO you get stuck in details and you lose the big picture.

Well, that's not true anymore. There are very many things that used to be time-consuming coding that is basically a five-minute job with a good prompt.

"Instead of wasting the team's time by trying to phrase that as a story, just phrase it as a pull request instead and go to the team and demonstrate your running feature."

That happened actually today. Just now, our CEO, who's not a coder, came to me with a pull request. In fact, quite often he just pushes directly to a branch because it's small changes. He wants to add some new visualisation for a graph or something in our platform – typically admin stuff that users won't see, so it's quite harmless if he gets it wrong.

He's vibe coding, just making little changes to the admin, which means he never goes to my team and says, "Hey, can you guys generate this report or this graph for how users use our product?" No, he just puts it in himself if it's simple.

Today we wanted to make a change with how we handle payments for enterprise customers. Getting that wrong is a little more serious, and the change wasn't that hard, but he just didn't feel completely comfortable pushing it himself. So he just made a PR instead, and then we spent 15 minutes reviewing it. I said it was fine, so we pushed it.

It's so refreshing that now anybody can code. You just need to learn the basic prompting and these tools. And then that saves time for the developers to do the more heavyweight coding.

Tenille: It's an interesting world where we can have things set up where anyone could just jump in and with the right guardrails create something. It makes Friday demos quite probably a lot more interesting than maybe they used to be in the past.

Henrik: I would like to challenge any development team to let their stakeholders push code, and then find out whatever's stopping you from doing that and fix that. Then you get to a very interesting space.

Closing the Gap Between Makers and Users

Tenille: A key insight from your work with agile teams in the past has been to really focus on minimising that gap between maker and user. Do you think that AI helps to close that gap, or do you think it potentially risks widening it if teams are focusing too much on AI predictions and stop talking to their customers effectively?

Henrik: I think that of course depends a lot on the team. But from what I've seen so far, it massively reduces the gap. Because if I don't have to spend a week getting a feature to work, I can spend an hour instead. Then I have so much more time to talk to my users and my customers.

If the time to make a clickable prototype or something is a few seconds, then I can do it live in real time with my customers, and we can co-create. There are all these opportunities.

I find that – myself, my teams, and the people I work with – we work a lot more closely with our users and customers because of this fast turnaround time.

"Just yesterday I was teaching a course, and I was going home sitting on the subway. It was a 15-minute subway ride. I finally got a seat, so I had only 7 minutes left. There's this feature that I wanted to build that involved both front-end and back-end and a database schema change. Well, 5 minutes later it was done and I got off the subway and just pushed it. That's crazy."

Of course, our system is set up optimised to enable it to be that fast. And of course not everything will work that well. But every time it does, I've been coding for 30 years, and I feel like I wake up in some weird fantasy every day, wondering, "Can I really be this productive?" I never would have thought that was possible.

Looking Ahead: The Future of Agile Teams

Tenille: I'd like you to put your futurist hat on for a moment. How do you see the future of agile teamwork in, say, 10 to 15 years time? If we would have this conversation again in 2035, given the exponential growth of AI and improvements over the last two to three years, what do you think would be the biggest change for software development teams in how they operate?

Henrik: I can't even imagine 10 years. Even 5 years is just beyond imagination. That's like asking someone in the 1920s to imagine smartphones and the Internet. I think that's the level of change we're looking at.

I would shorten the time a little bit and say maybe 3 or 4 years. My guess there – and I'm already seeing this transfer happen – is that coding will just go away. It just won't be stuff that we humans do because we're too slow and we hallucinate way too much.

But I think engineering and the developer role will still be there, just that we don't type lines of code – in the same way that we no longer make punch cards or we no longer write machine code and poke values into registers using assembly language. That used to be a big part of it, but no longer.

"In the future, as developers, a lot of the work will still be the same. You're still designing stuff, you're thinking about architecture, you're interacting with customers, and you're doing all the other stuff. But typing lines of code is something that we're gonna be telling our kids about, and they're not gonna believe that we used to do that."

The other thing is smaller teams, which I'm already seeing now. I think the idea of a cross-functional team of 5 to 7 people – traditionally that was considered quite necessary in order to have all the different skills needed to deliver a feature in a product. But that's not the case anymore. If you skip ahead 2 or 3 years when this knowledge has spread, I think most teams will be 2 people and an AI, because then you have all the domain knowledge you need, probably.

As a consequence of that, we'll just have more teams. More and smaller teams. Of course, then you need to collaborate between the teams, so cross-team synchronisation is still going to be an issue.

Also, I'm already seeing this now, but this concept of sprints – the whole point is to give a team some peace of mind to build something complex, because typically you would need a week or two to build something complex. But now, when it takes a day and some good prompting to do the same thing that would have taken a whole sprint, then the sprint is a day instead. If the sprint is a day, is there any difference between a sprint planning meeting and a daily standup? Not really.

I think sprints will just kind of shrink into oblivion. What's going to be left instead is something a little bit similar – some kind of synchronisation point or follow-up point. Instead of a sprint where every 2 weeks we sit down and try to make a plan, I think it'll be very much continuous delivery on a day-to-day basis. But then maybe every week or two we take a step back and just reflect a little bit and say, "Okay, what have we been delivering the past couple of weeks? What have we been learning? What's our high-level focus for the next couple of weeks?" A very, very lightweight equivalent of a sprint.

I feel pretty confident about that guess because personally, we are already there with my team, and I think it'll become a bit of a norm.

Final Thoughts: Preparing for the Future

Henrik: No one knows what's gonna happen in the future, and those who say they do are kidding themselves. But there's one fairly safe bet though: no matter what happens in the future with AI, if you understand how to use it, you'll be in a better position to deal with whatever that is. That's why I encourage people to get comfortable with it, get used to using it.

Tenille: I have a teenage daughter who I'm actually trying to encourage to learn how to use AI, because I feel like when I was her age, the Internet was the thing that was sort of coming mainstream. It completely changed the way we live. Everything is online now. And I feel like AI is that piece for her.

Henrik: Isn't it weird that the generation of small children growing up now are going to consider this to be normal and obvious? They'll be the AI natives. They'll be like, "Of course I have my AI agent buddy. There's nothing weird about that at all."

Tenille: I'll still keep being nice to my coffee machine.

Henrik: Yeah, that's good. Just in case, you know.

---

Thank you to Henrik Kniberg for joining us on this episode of the Easy Agile Podcast. To learn more about Henrik's work, visit Abundly AI or check out his educational videos on AI and agile practices.

Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and the future of work.

Related Episodes

  • Podcast

    Easy 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.

    👉 Watch the recording here.

  • Podcast

    Easy Agile Podcast Ep.10 Kate Brodie, Director of Digital AI and CCAI Program at Optus

    "It was great chat about Kate's experience working in an agile environment, and learning what artificial intelligence looks like at Optus"

    Kate shares her experience of an agile transformation at Optus and the incredible impact it has had on the company. Delivering faster & enabling a sense of ownership & accountability amongst teams.

    Kate also shares some great advice from embracing hybrid roles throughout her career, a gentle reminder to never put limits on yourself and adopting a “no risk no return” mentality.

    Be sure to subscribe, enjoy the episode 🎧

    Transcript

    Hayley Rodd:

    Well, thank you for joining us here on the Easy Agile Podcast. Here in Wollongong things are a little different from when we last had a chat. We've since been put into lockdown as part of the Greater Sydney region, but I'm delighted to bring you this podcast from here in Wollongong. And also it maybe helps ease some of those lockdown blues that you might be suffering if you're in the same part of the world as I am today or if you're in another part of the world that is maybe in the same predicament that we find ourselves here in Wollongong in. So, I'd like to introduce myself. So my name is Hayley Rodd and I am the product marketing manager or one of the product marketing managers here at Easy Agile. And I have a great guest today, an old friend of mine but before we kick off with the podcast, I'd like to say any acknowledgement of country.

    Hayley Rodd:

    So here at Easy Agile, we acknowledge the traditional custodians of the land where we work and we live. We celebrate the diversity of Aboriginal people and their ongoing cultures and connections to the land and waters of New South Wales. We pay our respects to elders past, present and emerging and acknowledge the Aboriginal and Torres Strait Islander people and their contribution to the development of this tool. And now, to our guest, Kate Brodie. Kate is an old friend of mine from here in The Ngong or Wollongong if you're not from this region. And has been very successful in her pursuit of a career in technology. So a little bit about Kate. Katie is the director of digital AI and CCAI programs at Optus. Kate is now based in Sydney, Australia and is a leader in AI, digital and new emerging technology. Katie is responsible for Optus's AI, digital, portfolio and chapter working in an agile environment every day today.

    Hayley Rodd:

    Kate leads the development of new products to take to market and scale routines in an agile environment advocating for build, measure, learn culture. Most recently, Kate has been in charge of leading an enterprise first to market API consulting chatbox in Australia, compatible with Google Home. So obviously Kate is an extremely impressive person and I wanted to chat to her today about her career and also her role in the Agile team. But beyond that, I wanted to touch on women in technology and leadership, something that Kate has spoken about recently with Vogue Australia. So, thanks so much to Kate for joining us today. And I can't wait to share some of the advice from the lessons that Kate has learned through her career. Thank you so much for joining me today, Kate. It's really wonderful to see you. So could you tell me a bit about, I guess what your day-to-day looks like when you're at the office?

    Kate Brodie:

    Yeah, thank you for having me. My day-to-day is quite varied. I would say that in my role, I'm very lucky to work with lots of different people, engineers, designers, business people, marketers and more recently a lot of different partners including Google. So, a lot of my day is working between different groups, strategically thinking about how we're going to continue to create a particular vision and future together for our customers. And then parts of it are related more to the technology and how we're ensuring that we've got our teams performing at a level that will allow us to meet those goals. And yeah, day-to-day, I'm talking to a lot of different.

    Hayley Rodd:


    So, when we were chatting just before we started recording, you were telling me a little bit about your start in marketing and now you've moved over to technology, can you tell me a little bit about how you don't want people to feel pigeonholed, I guess in their careers or in their career path?

    Kate Brodie:

    Yeah, absolutely. I really believe that anyone can get into anything if they put the effort behind it. And so I really think that no one should ever put limits on themselves. For me, it was partly because I was surrounded by really great people who supported me in trying lots of different things. And I think the way in which you build your confidence and start to move between different disciplines is by getting your hands dirty and just having a crack. So, I think it's important particularly and in this day and age for people to be open and not really put strong defined titles on themselves so that they do have a sense of freedom to kind of move around and try different roles because ultimately what is available today is probably going to look very different in 30 years time so... Yeah.

    Hayley Rodd:

    And do you still consider yourself a marketer or are you something, hybrid? What are you now?

    Kate Brodie:

    I would say that I am a technologist. I think that it requires the ability to have a bit of a marketing brain because you need to know how you're going to apply it in order to make a real impact, whether that's for customers, employees or commercially. But definitely with a strong kind of technology digital focus now, I wouldn't say that I would be purely seen as a marketer these days, but definitely it's about having that broad skill set and I think marketing's critical to being able to create great products.

    Hayley Rodd:

    Perfect. So, when I think of AI, I think of self-driving cars, someone who is very new to the technology industry myself. Could you unpack, I guess what AI means for Optus?

    Kate Brodie:

    Mm-hmm (affirmative). I think that what you've just said is shared by many. Artificial intelligence is just such a broad concept and it really is related to creating intelligent machines that can ultimately perform tasks or imitate behavior that we might consider human life. And so that can range from really narrow experiences like reading a brochure in a different language using AI to kind of rate it in the language that you can understand to kind of these macro experiences like you've just described with self-driving cars and completely changing the way that we travel. So, I think that AI is such a broad term where it will mean different things for different groups. At Optus, it's about creating lasting customer relationships with people and allowing them to connect with others. And so where we use AI in a variety of different places, it can be in our products themselves.

    Kate Brodie:

    So for instance, we just recently launched a really amazing product called Call Translate. And that's where in the call you can actually interact with people in different languages on that same phone call so breaking down those communication barriers that have existed before. So that's super exciting. And then there's other places where we're using it, for instance in our sales and service functions that we can more easily automate the simple tasks and give more time to our people to grow and create those types of relationships with our customers. So, we're using artificial intelligence in many different ways, but I think it's really exciting in everything that we do, it's more driven towards how can we create a better customer experience. It's not about the technology in of itself, which is what I really like about it.

    Hayley Rodd:

    Yeah. Nice. And it sounds like that that call translation would just... Could have so many applications and have... I'm even just thinking about in this COVID circumstance we... You're trying to get a message across to people to stay home and all those sorts of things like... Wow. Okay.

    Kate Brodie:

    Yeah. And there are some beautiful stories of people who are not able to go home with their young kids, travel home to their countries where their families are. And so they can have the grandkids talking to the grandparents more easily as they are learning different languages. So, it's really cool.

    Hayley Rodd:

    Wow. That's beautiful. So, in your title, there is, I, maybe assume it's an abbreviation, but it's somebody that says CCAI. Could you tell me what that is?

    Kate Brodie:

    CCAI stands for Contact Center Artificial Intelligence and it's actually a program of work that is used increasingly by different industries and refers to a particular product that Google is working with companies on. And so it's about re-imagining your contact center. So traditionally today banks, telecommunications companies, big organizations with lots of customers have a lot of customers that contact us regularly. And so this is a way of actually, how do we use AI to increasingly get to a point where you don't need to reach out to us but instead we're reaching out to you to better optimize your experiences with us. So, that's a little bit more of a program piece that's attached to my title at the moment.

    Hayley Rodd:

    Wonderful. So, prior to your current role, we're just going to get into the Agile space, which I know you seem extremely excited about at Optus and it's had some, I guess will be changes in the... Or it has some... Helped some massive changes at Optus. Before your current role what was your experience with that job?

    Kate Brodie:

    My current role and my experience with Agile has evolved. So, a couple of years ago, we rolled out Agile at a very large scale across our enterprise. So previously we had been using Agile in our IT teams for software development, but we actually started to roll out agile for product development. And I originally started as a product owner. So I was given a goal around creating a chatbot from scratch that would be supporting our teams. And with that, our Agile transformation involved breaking down the silos of divisions. So functional divisions. We started to merge into cross-functional squads and our squad was given the autonomy and the ownership to take on a particular initiative, and in my case, it was chatbot. And so I've actually experienced multiple roles within Agile including as a product owner and as a chapter lead, which was where I looked after a particular craft of people who run across multiple squads in Agile.

    Kate Brodie:

    And now more recently, I've got squads that are working within my area to produce these products and these outcomes for us. My experience with Agile has been brilliant. The amount of impact that it's had on our company is incredible. So, over the last couple of years, and this is pre COVID, we had a big target around moving towards a really digital led experience. And so we've seen our customers who used to choose digital around six...

    Kate Brodie:

    Around 65% of our customers would choose digital a couple of years ago and now it's more like 85%. So these big swings have come as a result of, I think, breaking down those silos and working in a more Agile way. Just on that I think what I like about Agile is that it's not about showcases and stand ups, it's actually about the culture that Agile allows for. So I think it allows for a lot more ideas and innovation because you have this mix of people who didn't traditionally sit with one another being together. And then also you can just deliver faster because you can cut through a lot of noise by working together. And the last piece I think is definitely that ownership and accountability for driving an outcome as opposed to delivering a piece of the puzzle, I think, yeah, Agile's been massive for us.

    Hayley Rodd:

    So, and you said that it was a big roll out across the organization. So does that mean that everyone within Optus works within an Agile framework or is there still sections that I guess don't employ Agile.

    Kate Brodie:

    There are areas of the business that aren't completely agile at this point in time. And I think they are areas of the business that makes sense. So sometimes in research and the like, you need to have a bit more freedom to sit back and ideate, although they would adopt principles of Agile so that they time box ideas and the like. From a delivery perspective, most of the organization has transformed into Agile delivery.

    Hayley Rodd:

    Wow. So it sounds like your customers would be seeing a lot of value from the organization transforming to Agile. You said before that there was a lot of people in your life who allowed you to do things you felt confident in your ability because I guess they helped you get there. So, has there been a mentor that I guess you look back on in your career or even now that has had an impact on where you are?

    Kate Brodie:

    I think that I've had a lot of different people who have been my mentor at different stages and who I would call upon now. So, I like to probably not have one mentor, but sort of look at the variety of people and their different skills and take a little bit of this, take a little bit of that, learn from this person on a particular area. There have definitely been some people who stand out. And so, early on one of the things that was really useful for me was being supported by a particular general manager who basically sort of pushed me into digital and technology and sort of, I was just very fortunate that he believed in me and said, "Now, you can run this area." I had never really been exposed to it. This is 10 years ago when digital was still sort of seen as more of a complimentary area as opposed to core, to a business.

    Kate Brodie:

    And by him supporting me in having a go at everything that's been... That's actually one of the most pivotal moments I would say in my career very early on that that's really led the way for me to increasingly get into the area that I'm in today. And along the way, obviously, there's been many people who have made a huge contribution to where I'm at and they're both in my career, but also outside. So, people that you play sport with people that you just have, that you share different stories with, I think that often you take a little bit from everyone and hopefully you give back something to those people too.

    Hayley Rodd:

    Yeah, I'm sure you do. So, is there any... Looking back on all those people that you've had throughout your life who have helped you get to where you are, is there a piece of advice that might have stuck with you that you could share with us?

    Kate Brodie:

    There's lots of different advice. I think one of them is, no risk no return. I really do think that you have to have a crack, you have to put yourself out there. The things that always been the most satisfying experiences have been by having a go at something that I hadn't done before. So I think no risk no return is something that I definitely subscribe to. And then in terms of some practical advice, particularly as a female, I think in your career, something called the assumptive close, which is a sales technique, around almost not asking if someone would like something but sort of implying that they would. I actually would say that I use that technique not to necessarily directly sell to someone, but in everything that I do and I would really encourage most people to use it. It was some early feedback in my career and it's been quite useful along the way.

    Hayley Rodd:

    Yeah. [inaudible 00:18:51] after working in real estate for a little while, I think a lot of real estate agents also assume the sale. So, and it just it... I think it can help with the confidence and going in there and I guess almost putting yourself in a position of power in the conversation when you assume you've got this in the bag. So yeah, it probably comes naturally to some people more than others, myself included, but I would struggle with that, but that's a really good piece of advice. So yeah, I'm sure that it will be helpful for a lot of people who are listening to the podcast now. So what about... What's your proudest moment as a leader there at Optus so far? I know that you're in Vogue recently. That's an amazing moment. And as a person who's known you for a really long time, that was a proud moment for me to see someone that I'd known do that, but for you, what's the proud moment?

    Kate Brodie:

    [inaudible 00:19:58] I think probably my proudest moment is when I've launched something large. So recently we launched a large piece of technology that will change the experience for our customers, but it wasn't as much the launch as it was looking around me and seeing the people that are there with me doing it. And there are quite a few amazing people that I get to work with. And having sort of started with a few of them in the early days, a few years ago, where we were sort of spitballing ideas and we had no products to now having large products that make a real impact to Australian consumers and to our business. It's those moments where it's actually the team around you that it... I'm most proud of. It's just the high engagement and the drive and the culture that we've created where people want to work in this area and we all enjoy creating these experiences together. So I think definitely I'm most proud of the team culture and environment that we've set.

    Hayley Rodd:

    Yeah. Sounds amazing. We're lucky enough here at Easy Agile to have, I guess the same... A culture that you can be proud of as well, so, I can understand how it can be something that makes a huge impact every day. So, we're getting close to the end of our time together, but again, I guess I wanted to touch on a bit of gender diversity. So how does gender diversity benefit technology companies? What do you think?

    Kate Brodie:

    I think diversity in general is going to benefit any business and particularly technology businesses, because it's imperative that you have a representation of the population and the people that will use your technology and the experiences that you're trying to create. So I think that it's only by ensuring that we are tapping into the entire talent pool, that we can represent people and represent customers, but also we're going to get the best ideas. And so that's gender diversity but also culturally and in every sort of facet, the more that we can tap into the entire talent pool, the more we'll create better experiences, better technology, solve more of the world's problems and capture more opportunities.

    Hayley Rodd:

    Mm. Fantastic. And last question, what advice would you give a young woman hoping to enter the technology industry or a technology company?

    Kate Brodie:

    I would say go for it. I would say don't ever put limits on yourself and speak up, learn as much as you can and get your hands dirty because it's through that kind of confidence... Oh, sorry. It's through working with lots of different people and creating things with people from scratch that you'll gain your confidence as well. And always ask, don't sit there waiting for someone to sort of tap you on the shoulder, ask for that new opportunity, ask for the salary increase, ask, it won't hurt. I promise.

    Hayley Rodd:

    That's a good advice. What's the worst they could say?

    Kate Brodie:

    No, exactly.

    Hayley Rodd:

    No, yeah.

    Kate Brodie:

    Yeah. And that's why.


    Hayley Rodd:

    Or they might say yes. And then that's awesome too. Okay. Well, thank you so much, Kate, for your time. That was really wonderful. It was wonderful to catch up, but it was also wonderful to hear from someone who's so young in their career, has... But has also done so much and who has reached some amazing goals, has a team behind them. And I think that there's so many people who will watch this, myself included, who will learn a lot from you. So I really appreciate your time. Thank you.

  • Podcast

    Easy Agile Podcast Ep.11 Dave Elkan & Nick Muldoon on building Easy Agile

    On this episode of The Easy Agile Podcast, join Nick Muldoon and Dave Elkan, Co-CEO's and Co Founders of Easy Agile. As they look forward to the next phase of growth for the company, they wanted to take this opportunity to reflect on their journey so far.

    Nick and Dave talk growing a start-up in regional Australia, finding the right people, sustaining a positive team culture and the importance of having values driven teams.

    "Our purpose is to help teams be agile and in doing that, we're doing that for ourselves, we're constantly trying to learn and adapt and experiment with new things. I hope that was a useful little tidbit and journey from Dave and I on how we got Easy Agile to this point."

    - Nick Muldoon, Co-CEO, Easy Agile

    "There's these funny little hacks and analogies and I think that's a longterm vision thing. If you are running a business which doesn't have that longterm vision and purpose, then you can go actually in multiple directions at once, and you're not going to make any progress."

    - Dave Elkan, Co-CEO, Easy Agile

    Be sure to subscribe, enjoy the episode 🎧

    Transcript

    Nick Muldoon:

    Good day, folks. Nick Muldoon with co-founder, co-CEO of Easy Agile, Dave Elkan. Before we kick off, we'd just like to do an acknowledgement to the traditional custodians of the land on which we broadcast and record today, the Wodiwodi people of the Dharawal Nation. We pay our respects to elders, past and present, and extend that same respect to any of our aboriginal folks that are listening today.

    Nick Muldoon:

    Dave, just a bit of a reflection on five and a half years of business?

    Dave Elkan:

    Business? Yeah, a rollercoaster. It's been great fun.

    Nick Muldoon:

    It is a rollercoaster, isn't it? I guess, where's the best place to start? The best place to start is at the start.

    Dave Elkan:

    Yeah, I mean we can go before the start. There's always a good prequel. We can do a prequel episode later, I guess. But I guess the earliest I remember working with you, Nick, was at Level 15 at Kent Street, at Atlassian. There was this redheaded guy down the one end of the building, working on Atlassian GreenHopper and I was busy working on the Kick-Ass team at the time, building the new issue navigator, which is now the old issue navigator, back in 2011. And then you screwed off to San Francisco and I followed eventually, and then we hung out there for a while, didn't we?

    Nick Muldoon:

    Yeah, I remember that because we sat down, I was back to get married, and we sat down and had a coffee and a yarn about you and Rin relocating to San Francisco and how it had been for Liz and I, and what the process was like and all that sort of stuff.

    Dave Elkan:

    That's a great opportunity to acknowledge our lives in this amazing journey as well and if it wasn't for those, we probably wouldn't have gone to San Francisco in the first place, because a large part of the promotion of going overseas and doing that for me anyway, and for yourself, I'm pretty sure.

    Nick Muldoon:

    Yeah. Well, Liz was this big conversation of go overseas and experience something new and I was quite comfortable in Sydney and enjoying my role with product management at Atlassian, but it was really a push to try and experience and do something a bit different.

    Dave Elkan:

    Absolutely, same here. And you were there for over four years, in San Francisco, and I was there for three. But you came home, you got married, and I just grabbed you for a coffee and we sat there in Martin Place and had a chat, and you said, "Yeah, it's great. Come over, you can stay with me for two weeks." And I'm like, "Oh, I barely know you."


    Nick Muldoon:

    Yeah, but it was so much. I mean, even not knowing Liz or I, it was way better than the alternative. So for folks listening in, the Atlassian apartment, at the time, was in a fairly rough part of The Tenderloin in San Francisco, and it probably wasn't the greatest introduction if someone was relocating to San Francisco.

    Dave Elkan:

    No. But to cut a long story, there's a lot of good stories here I'm sure we can tell one day, but eventually, we both had daughters in San Francisco and we wanted to be home and closer to family. Then we came home to Sydney and found that the traffic is 20% worse or 50% worse than when we left and we were uprooted. So once you've been uprooted, you've got to plant yourself back somewhere and it's quite easy to change at that point, and you've chosen to go outside of Sydney.

    Nick Muldoon:

    Yeah, this Wollongong regional lifestyle.

    Dave Elkan:

    Yeah, where you can have a full block of land to yourself without breaking the bank and you can, relatively speaking, like times have changed a bit in that space, but since then, that's what we were chasing, wasn't it? And we looked at Newcastle, and-

    Nick Muldoon:

    Looked at Newcastle, looked at Brisbane, Adelaide, we even went through Wagga Wagga. We had the most amazing Indian meal in Wagga Wagga, we were almost like, "This is the place. If we can get food like this in Wagga, we're sweet." Bit too cold, but we ended up settling on Wollongong, in large part because of the proximity to the beach and the Early Start Discovery Space for the kids and just a pretty cool, chill place to raise a family. There are aspects of it as well, I think, that really reminded Liz and I of San Francisco. We used to go to the farmers market down at the Ferry Building a lot on a Saturday morning, and we found the farmers market on a Friday in Wollongong on Crown Street North, so there were these similarities to kind of enable us to transfer from one city to the other fairly easily.

    Dave Elkan:

    Yeah. It's a pretty easy place to live and to be. The way I like turn it, is it's just far enough away from Sydney.

    Nick Muldoon:

    Yeah, a nice little national park in between.

    Dave Elkan:

    That's right, it can't really encroach on us, it's not allowed. You can't build there so you're always going to have that buffer. But I do remember going back to Sydney for a niece's birthday and having been charged $9 an hour for parking at the beach, considering you don't even have a parking sticker anymore because I wasn't a resident, and I was like, "Wow, it's really expensive." But for anyone coming to Wollongong or the other way, you can park for free at the beach. That's just kind of like a good litmus test of the difference that we're talking about here.

    Nick Muldoon:

    Mm-hmm (affirmative). Yeah, I guess this regional life, like we didn't really have a tech industry here. We come from Sydney where, 10 years ago, there was this emerging tech scene and SydJS, SydCSS, other meetups up there, and in San Francisco we were thrust right in the middle of it. I remember, we were chatting the other week about a meetup where we met, the Ruby Creator at a Heroku meetup, I think it was, and a session on [detrace 00:06:17] at that company that's gone bust now, whose name I can't even remember, but we were in the heart of all the meetups in San Francisco. Then in Wollongong, there was none of it, and so it was like a question of what could we do to build a community here as well, try and meet other like minded folks?

    Dave Elkan:

    Yeah, it was definitely that desire, wasn't there? And we set out to do that, and I think it was Rin who termed it Siligong. I remember we were actually talking about Siligong Valley before we actually left, and we just decided to make that the name of the community. I was actually looking back on my old emails the other day and I was like, "Oh, we actually talked about Siligong before being in Wollongong," so that's pretty cool.

    Nick Muldoon:

    I remember early days because I think you and Rin returned on flight with [Umi 00:07:08], and Umi was six or eight weeks old.

    Dave Elkan:

    Yeah, October.

    Nick Muldoon:

    If I'm not mistaken, I dropped you at your mom's place so that you could catch up with your mom and Ken and that was kind of like home base. And it was a couple of months after that or something, where we finally had you down here. I think you stayed with Liz and I when you came down here-

    Dave Elkan:

    Yeah, again for two weeks.

    Nick Muldoon:

    ... for another couple of weeks, and we were really talking about the genesis of what was, at the time, what was termed Arijea Products, and a brand that we never ended up sticking with. What do you remember about those early days and trying to get the business off the ground?

    Dave Elkan:

    Actually, come to think of it, you were staying in, not Coniston, [Carmila 00:07:59], it was actually less than two weeks because we all had little kids and it was just a bit crazy. So I think Rin and I organized... we came down and did inspections and we stayed with you whilst we're doing that, and then we were able to secure a place in Fairy Meadow and we moved down, so we were going back and forth a bit at that point. And then it was this six months of just literally... I didn't have a bike, I just walked to work, which is super new to me. I've always caught the bus or ridden my bike.

    Dave Elkan:

    Some of you may know I've never commuted to work and I hopefully will never have to do that, and we've engineered our lives around that kind of concept. But I think that it was really great, I was just living within two kilometers' walk of work, and that was for at least the first six months until I moved to Balgownie, but it was great time of my life and we had a brand new baby and just concentrating on the business, trying to [crosstalk 00:09:00]-

    Nick Muldoon:

    I remember, we really didn't have much of an idea of what we were doing in early days. We chased down one area and we said, "No, that's not appropriate," and then we kind of turned our attention to something else.

    Dave Elkan:

    Yeah. We were chasing our tails a little bit. We, at one point, had five products with two people.

    Nick Muldoon:

    That's right.

    Dave Elkan:

    I think that, that's too much, but with good conversations with the fellows around us at IXI, that we were able to have... like they were asking good questions and I remember Rob and Nathan asking us, "What is it you're good at?" And I think it was Rin, was like, "Okay, you've got this app idea, who're you going to market it to? Look at your networks." And it was, all those arrows started pointing towards Agile.

    Nick Muldoon:

    Yeah, I think it was this idea that Rin had like, "You can build it and they will come, or you can figure out your go-to market and your distribution piece, and what's the audience that you've already got, and how do you leverage the audience that you've already got in Agile Software Development to kind of seed and build that audience, and get some momentum?" And that's what really kicked us along and got us going. If I'm not mistaken, I think we'd actually... not that we had a lot of outgoings, but I think we were actually break-even by June of 2016, and it was kind of like this, "Hurray," moment because we were not going to have to get on the train and commute to Sydney for working at Atlassian or something like that. We'd found product-market fit and we could kind of pursue and go to the next stage.

    Dave Elkan:

    That's right, yeah. There's a lot in that story as well, like how we found product-market fit and the steps towards that and lots of learnings from that time as well, which is great to share eventually, I guess, but we might go down a rabbit hole if we jump into that one. But I certainly do remember good considered conversations that were held by lamingtons and tea in the Mike Codd building at the Innovation Campus at University of Wollongong, where we started. And that was really just a time to... it felt different to my prior, at the time 15 years of experience, where you actually, it's okay to stop and talk and think about what you're doing, whereas in the past, it's just been, "Go, go, go, build this thing." And it's like, "Oh, okay," so that was really refreshing for me and I think that, that was a really good step in opening up what became the story map, which was our first really successful product.

    Nick Muldoon:

    Mm-hmm (affirmative). You mentioned the lamingtons and tea, it was probably at least 50% of our time getting the business off the ground, was lamingtons and tea. It was chatting about stuff, it wasn't writing code, we didn't have customers to speak of. It was really trying to figure out what sort of market did we want to pursue, what solutions did we want to provide and what sort of business did we want to create? That was a large part of our time getting it off the ground.

    Dave Elkan:

    Absolutely. And for those listeners out there who don't know what a lamington is, it's actually a delicious piece of sponge cake dipped in chocolate sauce and then coconut, shredded coconut, so I know you can buy them in US, we actually did that at Atlassian and they were a huge success, especially because they had cream inside them as well, so real good for a cup of tea or coffee, whatever you take. But the thing is that it's a good idea to sit down with a co-founder and talk a lot more than you type, that's the kind of rule I took out of that.

    Nick Muldoon:

    It's interesting because it was kind of like that approach to talking instead of typing that was kind of like the genesis of one of our values, this engaged system, too. And I don't think you'd read Kahneman's book at that time, and that was something that came later, but even just this idea of, "Now, let's just take the time to think and process this sort of stuff," and the context [crosstalk 00:13:09]-

    Dave Elkan:

    No, I do remember. Sorry, yeah. I did a presentation at Lansing Summit in 2017 on Engaged System too.

    Nick Muldoon:

    16 or 17?

    Dave Elkan:

    16 or 17, I can't remember which one it is.

    Nick Muldoon:

    '16 because you went to Barcelona in '16.

    Dave Elkan:

    Barcelona, and that's what I did there, wasn't it? Yeah, so that was early on that I read Thinking, Fast and Slow, which I highly recommend.

    Nick Muldoon:

    And the context around this, for folks listening; in mid 2016, Dave had a nine month old daughter. My daughter was two years old and I had a newborn and you were to have... your number two was on the way, right? So we were building a business as we were starting and establishing our families as well, so it was, "Let's do it all," in a new city. Like, "Let's do it all at once."

    Dave Elkan:

    Yeah, you might as well, right? Just bite it all off and rip the Band-Aid off and get it done. I mean, my daughters were only 18 months apart, so that kind of... just get it over and done with. Get the hard part done and then you can go and enjoy yourself afterwards, just kidding. It's great to have lots of kids at a young age, like I really do miss that time. But yeah, we were pretty crazy, but we got through.

    Nick Muldoon:

    It gave us a constraint as well, didn't it? Because we couldn't burn the midnight oil, we couldn't flog ourselves from 05:00 AM to midnight because we simply did not have the energy and we had to get kids fed and bathed and off to bed and all that sort of stuff. So it brought a cadence and now that I reflect on that, there was another value that was kind of coming out of that, which was with respect to our balance and establishing balance in our lives.

    Dave Elkan:

    Yeah I do remember, sorry to interrupt, a tweet idea, I can probably dig it up, which was me hanging out cloth nappies or diapers on... it must've been, it was in Balgownie so that must've been after six months. But I was hanging out nappies and I must've been working from home that day or something like that, but that was just like me balancing life like that, with work. And I think it came back with like work, life, family balance or something like that. We would expand that to work life, family, community balance, is what we try and chase.

    Nick Muldoon:

    Mm-hmm (affirmative). How did we get on this journey around the values and kind of establishing the values? When was that in the life of the business?

    Dave Elkan:

    I can remember the place we were in, we were actually in our Crown Street office when we really sat down and really hunkered down into that, so that would've been 2018.

    Nick Muldoon:

    I think in November 2018, we held our first advanced Easy Agile, and that's where you ran the session, "What got us here won't get us there." And so at that point in time, we had the two products, we had Easy Agile User Story Maps and Easy Agile Roadmaps, and we had changed our brand from Arijea Products to Easy Agile, to kind of focus our energy on the Agile space. We divested the other three products that weren't focused on Agile, so we'd sold those off to another Atlassian Solution marketplace partner. I think that's where we started having these conversations around the next evolution of the growth of the business. Then it was in 2019 where we were back in Crown Street, back in the office, where we were having that conversation about codifying, establishing, writing down our values.

    Dave Elkan:

    That's right, and it's a highly valuable process to go through and to really just pause on the day to day, and really focus on it. That's something I've always had trouble with, like I've always got things to do, but once you just extract yourself from that process and zoom out and look at the company and what you've come up and what you hold dear, that's when you can really start having those conversations, but making it an actual thing. I think that you can't just do it on the side, you can't just do it as well as other things, it's really got to be like the priority as I like to say. Priority is not a plural, it doesn't make any sense if it's pluralized, but that should be the one thing you do in an ideal circumstance, like you just do it and really focus on it, because it's really hard.

    Dave Elkan:

    And it shouldn't, I guess not in one sitting, but at least when you do it, make it a serious thing because if they're real values and you live them, like they just are pretty immutable, they just keep moving forward with you. If you found you're not living them, then you should absolutely revisit them, but we've been lucky enough in that the values we put forward have stayed true and I really feel like, of all the companies I've worked at, even Atlassian, like these ones I've lived every day in very distinct ways.

    Nick Muldoon:

    Mm-hmm (affirmative). So what are the values we've got? We've talked about better with balance, and we talked about that a little bit. We also talked about engaged System 2 like this System 2 thinking. What are our values?

    Dave Elkan:

    Be the customer, give back, and [crosstalk 00:18:30]-

    Nick Muldoon:

    [crosstalk 00:18:30] was a big one, and commit to team. So better with balance, give back, be the customer, punch above our weight, Engaged System 2 and commit as a team. Go back to the conversation that we were having in 2017 around give back, that was something that was really System 2. How did we think about giving back to the community and what that meant to us as a company?

    Dave Elkan:

    I think it goes back to what you said before about the community in San Francisco we experienced and what we did here with Siligon and just making that a focal point for us to give back to the community. It doesn't build itself, like the community has to be actively built by somebody has to put their hand up and start it, and I think we did that. Since then, like we've enabled heaps of other people to be able to give back in a really easy kind of way like, "Let's host a meetup," "That's fine, here's our framework to go build that on." And also just the daily communication we have amongst each other on our Siligon Slack, which is just super valuable.

    Nick Muldoon:


    Super active, too.

    Dave Elkan:

    Oh, super active, especially in lockdown, lots of people on there talking about all sorts of things.

    Nick Muldoon:

    I think maybe one of the other things, so Dave and I experienced this at Atlassian, which was this idea of the Pledge 1%, but in our first or second year of Easy Agile, Atlassian along with Salesforce and a bunch of other companies came together to actually codify and build the foundation around Pledge 1% and ask other companies to commit to that. And we made that commitment in 2017 if I'm not mistaken, to do Pledge 1% donations and now, where I guess we're kind of doing Pledge 2% donations, but what was the drive behind our Pledge 1% to Room to Read?

    Dave Elkan:

    It's in part laziness, because I really want a system to these kinds of things and unfortunately, when you're starting a business it's hard to dedicate the time and to think about that. So I took the easy System 1 option, which is to go with what we experienced at Atlassian, which was to back Room to Read, which is a great initiative to help ensure that young ladies, specifically in third world countries, get at least a higher education, get out of primary school, get into high school, and once they've gotten to that point, it's far more likely they're going to be independent. And with that kind of thing, like that investment, it's like restarting at the beginning and enabling countries and people to help themselves. If they're educated, that's a huge step in the right direction to both fighting overpopulation, climate change, all these things which benefit from those people doing well in life.

    Nick Muldoon:

    Mm-hmm (affirmative). Yeah, continually improving their lot in life, right? Like raising standards of living through education.

    Dave Elkan:

    That's right.

    Nick Muldoon:

    And if we think about punching above our weight as one of these other things, I mean I remember that was something that we talked about before we wrote down our values, that was something that we really did focus a lot of energy on. You mentioned before, there were two of us and we had five products in the marketplace. I'm not exactly sure that was a great example of punching above our weight, because we might've struggled a bit, but what are some examples of where we've punched above our weight as a small team from regional Australia?

    Dave Elkan:

    One of our products that we built initially was really a bit of a thorn in my side, it was continually breaking and it wasn't playing to my strengths, which is traditionally front end development. So after that and getting burned by that and having to stay up all night and fix it, I opted towards apps which are more front end focused, and so we've built Easy Agile User Story Maps and Easy Agile programs and Easy Agile Roadmaps primarily as front end apps. As a matter of fact, Easy Agile Roadmaps, for the first two years, didn't even have a server, it was just a static file in a bucket in CloudFront. That's the way Atlassian Connect works, it allows you to host apps that way, and that really can't break, it's just providing a different view on Jira in essence, but architecturally, it's quite simple. So therefore, we could easily... that was a way of punching above our weight, which also allows better rebalance, so they're kind of complimentary in that respect. What other ideas [crosstalk 00:23:24]-

    Nick Muldoon:

    Yeah, if not much can go wrong, then you don't have to be on call, and you don't have to fix things out of hours, so you don't wake up blurry eyed and fat finger and have a bug the next day that compounds the problem.

    Dave Elkan:

    And if you take the analogy too far, like you could think punch above your weight is like being able to punch someone really hard and then knock them over, but this is more like just definitely, you're running around the big [fur 00:23:44]. You're not even engaging in babble, you're just sidestepping it. That's why we've run those products, and until recently, we actually do have servers now for them, and once again, it's still very simple, but they're very well monitored so if something does go wrong, that we're on top of that.

    Nick Muldoon:

    I think one of the other aspects with respect to technology in punch above our weight, is we've quite often... I think maybe you mentioned before, with respect to Room to Read and the give back, the laziness, but we are lazy in certain respects and we just want to automate things. And I remember the XKCD comic that you share, with what is the right time to automate something and when do you automate it to get the return on investment that you want? But I feel like we've made some fairly good decisions around when to automate things and even around how we provide customer support or the old test and deploy, toying around with products, we've done these things at pretty good times so that we can deliver products to a global audience of a couple of thousand customers, from Wollongong out of timezone with those customers.

    Dave Elkan:

    Yeah. It's also being ahead of the curve as well, so I think Inception Week, which is something we do every fifth week now, we give up one week to provide the team with the space to explore new things. Amazing things have come out of that, which otherwise, if you would just week to week, week to week, you would never actually realize, but when it comes to mind is our dev container, which is a docket container which contains all of the parts which are required to develop our apps. So you just check out this one repository, run a script and it sets up your entire develop environment. It's a great way for the team to share the tools that help them punch above their weight, so it's a huge punch above our weight thing and that came out of Inception Week. So I think Inception Week's a punch above thing, and also the dev container's a huge punch above thing.

    Dave Elkan:


    We used to have so many problems with individual versions of this or that on everyone's computer, and now that's just all gone, it's never happening again, it's never come back to bite us since, and I think it's an overwhelming success. Sure, it does need an all new RAM and all new CPU, but it does... we'll get there, like it's going to get better.

    Nick Muldoon:

    RAM and CPU are cheap, it's okay.

    Dave Elkan:

    You can never get time back, right?

    Nick Muldoon:

    Yeah, absolutely. So when we think about these things, how intentional do you think we were around the values in our approach to building and scaling a company versus things that just kind of happened?

    Dave Elkan:

    For a large part of the starting of the business, there was a lot of, "Just get it done," kind of mentality stuff, which has to happen. However, I want to hop back to when we started, everything was chaos. I remember this, early 2018, mid 2018, we'd come in on Monday, go, "What are we doing today? What's this week? Let's look at the backlog and have a look." And there was no forethought whatsoever.

    Nick Muldoon:

    And we'd kick a couple of things off the backlog and we'd just work through on that weekend. That was it, right?

    Dave Elkan:

    Yeah, pretty much. And so you proposed the idea, it was at the beginning of the year, it must've been 2018. Was it 2019? Either way, let's just do one week on clarity, which is our internal CI room, essentially, and just knock out a bunch of products and problems. That was the first time we started really focusing, because since we had so many products, I think we actually might've sold them by now at this point. Yeah, I think we definitely had. However [crosstalk 00:27:28]-

    Nick Muldoon:

    But we still had Roadmaps, Story Maps, Clarity Week, EACS, like we had other internal systems that we used and the team was actually growing beyond Dave and me, and it was growing. There was Jared and Satvik and Rob, and so the team was growing at that point in time as well. So it gave us the opportunity to put a number of people onto one problem for a period of time, like a week.

    Dave Elkan:

    That's right, and from that came this idea of focus, and we started doing focused sprints, so product focus sprints, which highlighted another terrible problem of run over, if you did run over in your estimates, then you would have to come back like in nine weeks or something and it was just [diabolical 00:28:12].


    Nick Muldoon:

    That's right.

    Dave Elkan:

    So we dropped [crosstalk 00:28:14]-

    Nick Muldoon:

    What did we do? We did two weeks on Story Maps, two weeks on Roadmaps, two weeks on internal systems, two weeks on something and then one week on Inception Week?

    Dave Elkan:

    Inception Week. Yeah, I think [crosstalk 00:28:26]-

    Nick Muldoon:

    I can't even remember now, what that other thing was.

    Dave Elkan:

    It was nine weeks in total, wasn't it?

    Nick Muldoon:

    Yeah.

    Dave Elkan:

    [crosstalk 00:28:31] Roadmaps-

    Nick Muldoon:

    If you missed it and you didn't ship it, then we went onto the next product and moved that forward, and then we'd come back to it.

    Dave Elkan:

    In ages away. And it was super stressful for the team and we quickly destroyed that, the week we went with a more flexible approach to it, where we dropped the hard mandate of you have to exchange products now, we let them run over a bit and then we'd adjust the story points to the next one, blah, blah, blah. And then eventually, I'm scratching my memory, but essentially, we got to a point where we introduced opportunities, which was based loosely on Shape Up by Basecamp and we took a bunch of things from that, but most things of that didn't really gel with our way of working and our values.

    Nick Muldoon:

    I mean that whole opportunity cycle, we've evolved three or four times now.

    Dave Elkan:


    And they were ideally just two or four weeks of work, and then we'd do Inception Week and Tech Debt week, and we have a dedicated Tech Debt week as a mandate. We dropped that since, and we've got to now we have four weeks of work, which includes Tech Debt and then we have Inception Week, and that's kind of cool, right? Like we still have this mandate of Inception week, not Tech Debt week. That's the last thing; I feel like the mandates... because it's like kick starting your motorbike, you've got to really give a good kick and that's essentially what we've been trying to do over the last three years, is like get this thing running. I think we've-

    Nick Muldoon:

    Built momentum.

    Dave Elkan:

    The engine is now running... yeah. The engine is now running and we're pulling the clutch out. It's just that the mandates slowly fall away and the team finds their own way, but I still feel that, that cycle is the most important thing, that five weeks where we stop, everyone knows what's happening. Because if it just runs off into the future forever, you can't compute that in your mind, but you can see forward five weeks and go, "I'm going to plan this work, it's not going to be done to a Nth degree because that's kind of a bit weird," it's just like, "Let's try and achieve this and let's bite off one bit at a time." Then we have a break with Inception Week, let our creative juices flow and then we'll come back to it the next round.

    Nick Muldoon:

    Right, so I have to call timeout here. So this is a sidebar for everyone listening at home; Dave just used this analogy of kick starting the motorcycle and then pulling the clutch out. So one of the things that Dave does tremendously well, is he grabs these analogies and he uses these analogies to simplify what I otherwise feel can be fairly complex kind of concepts, and simplify them and communicate them really nicely. That's not one I've heard before but there's a new one we can add to the repertoire, Dave. I love it.

    Dave Elkan:

    Thanks, mate.

    Nick Muldoon:

    What other sorts of things? Because I guess we're charting this journey over five and a half years, where it's gone from Dave and Nick and the addition of Satvik and Teagan and Jared and Rob and Brad, and a few people over time, to the point today where we are 27, 28 people. What are some of the other markers along the way, that we've kind of gone through, that have shifted or evolved how we operate? Like the Easy Agile operating system that we've talked about in the past.

    Dave Elkan:

    Well, it's something that we've just discussed in the execution kind of level. Obviously, every six months, everything just goes and explodes and you have to fix it, like there's always some major thing that happens every six months, and I feel like that's good and that's healthy, and that continue to run into those things. Either they're internal or external and I feel like we're dealing with an external one right now, which I don't really want to touch in this podcast, but I think that they're healthy for the business to adapt to. But certainly, I think in that time, like really understanding that it's the people that count, right?

    Dave Elkan:

    The business is in there, like it's a thing, but it's nothing without the people who worked for it, and it's in service of the people who work here, as well as the customers. And so that's something we've come out of it. What do you think, Nick? Like the cultural aspects of what we've built, what do you think stands out to you?

    Nick Muldoon:

    I certainly think there's these inflection points. I mean, I remember a conversation with Jared when we were in Crown Street Mall, and it was in 2019 and we were talking with the team around the kitchen table there, and we could get eight people around this kitchen table and we were talking about growing the team to take advantage of the opportunity and responding to requests from customers and all that sort of stuff. I think Jared said, "Well, I quite like it the way it is."

    Nick Muldoon:

    And then I fast forward to an interview with Jared, which went into the five year video that we saw just before Christmas and that was around his trajectory and how he's evolved and adapted professionally and personally along with the company. I think that's the story for all of us as team members, we've all kind of been on a journey together and we're all learning and adapting together. We do live, in many respects, we do live this Agile approach where we do reflect and we take the time and we think and we experiment with new approaches to getting work done.

    Nick Muldoon:

    Even, I think... and we've been talking about this a bit recently with respect to pace, that first version of our learning and development program, where we wanted to provide funding for people to go and pursue something that they wanted to learn about. But we got that out, "Hey, that was a morning's worth of work," we put out an L&D, people started using the L&D program, and we called it our Version one of our L&D program, and today we're on Version, I don't know, 1.4 or whatever it is, of our L&D program. There's a lot of things that have gone out and we tweak and we improve them over time to make them ever better and better suited, perhaps, to the current state of play within the team. Is that fair?

    Dave Elkan:

    Yeah, it is. It is, and I think that; A, I've never worked at a business who has anything like that, and where they actively encourage you to use it, spend the money, make yourself better. If you make yourself better, the team will get better, if the team gets better, the customers get better outcomes, and the company continues to improve, and it will be probably a better place for you to work in the future. So it's really a holistic kind of perspective, rather than, not narrow minded, but myopic or focused on just output. It's outcomes of output and I think that could be another value of ours, if we were to have seven, it'd be outcomes over output. So really stopping, having that permission to stop and think, and system to it and think about what it is you're trying to achieve, rather than just blindly doing stuff.


    Dave Elkan:

    So from a developer's perspective, the fastest code is the code that doesn't exist, and so if you can do something differently, which doesn't require 100 steps or just decide, "Hey, this is really tricky right now, this bit of code we're trying to work on or this feature is really hard. Can we just delete the feature?" And we did it on notice, I know that sounds pretty bold, but quite honestly, that kind of discussion is really healthy to have. I want to encourage the team to think that way and I think that learning development is also something you can do to bring people into it, look at their trajectory as a way of gauging their abilities, and giving them really... throwing fuel on the fire in that respect and seeing them ramp up in their ability, and help those around them.

    Nick Muldoon:

    Yeah, so take us through that, because that's something that we definitely talked about a few times, like when we've been looking at candidates and in a hiring huddle around candidates, we've talked about those that are on a certain trajectory and that we think that we can accelerate that trajectory. Where did that come from?

    Dave Elkan:

    Where do thoughts come from? I'm not sure, that's a good question. I couldn't tell you, but I think it's pretty obvious when you look at someone's CV and you see... now, there's nothing wrong with people who have long tenured positions, but if you talk to someone and they can't really say what they've done in the last 10 years and they've donned that one position for 10 years and they haven't really got anything striking they can tell about how they've made that better, that kind of says a lot about that person. Maybe they would come in and they'd just coast... they're a coaster, right? If they're coasting, that's fine, it's their call, but at the same time, we look for people who are actively trying to make their impact bigger through their work, help those around them. And you can see that, you can see, "Oh, look. They've been at the same company, that's fine, but they've gone and done these different roles or they've seen this kind of improvement in their approach."

    Nick Muldoon:

    This comes back down to that article, that Financial Review article, the mid-career annuity, so this was an article that we must've been kicking around in 2016, 2017, and it was around a Japanese term, mid-career annuity. You could have 20 years of experience in a role or you could have 20 first years of experience, and I think early on, and maybe it still occurs these days, I think it probably does, but it felt like we were getting 20 quarters of experience. Over that five year period, there was always some big, new challenge that we needed to learn and adapt and incorporate into the business over the first five years. So we were always learning and adapting, and we wanted folks that were on a similar journey and they were learning and incorporating and adapting and experimenting themselves.

    Dave Elkan:

    Yeah, it's something definitely, that can be learned, and I think that if you bring on new stars, they can just get that, this is what they do by default because you've put them into that environment. But some environments, especially older companies, can be fairly stagnant and static, so that just reflects on people's CVs. Either there's some kind of reason why the company won't give them a promotion or give them opportunities to chase, how we have a different approach where we throw too many opportunities at people, I think sometimes, and I've seen people using their L&D so much, it is actually impinging on their better with balance value. I'm like, "Whoa, this is fantastic but don't forget you've got kids and you've got to help look after them," and [crosstalk 00:39:41]-

    Nick Muldoon:

    Temper your enthusiasm, yeah.

    Dave Elkan:

    Yeah. So that's something to look for.

    Nick Muldoon:

    Stopping and reflecting on five and a half years, what's the purpose of the business, what's the goal over the next couple of years?

    Dave Elkan:

    Have fun, learn, what about you?

    Nick Muldoon:

    Definitely learning.

    Dave Elkan:

    Stay in business.

    Nick Muldoon:

    Oh, yeah. Stay in business, sustainable growth is always a good one. I think that's important. Yeah, I don't know, it's interesting. I feel like some days, it can be really fun and other days, it's not fun at all. That's probably due in large part, like when we started this, we were not in service of anyone but ourselves and one another, and now I feel like we are in service of a team of people that are themselves in service of the customer because we've got a couple of thousand of them. So it's the responsibility and the accountability's changed, and the way that fun comes about is, these days... it used to be fun to have lamingtons and chat, and these days, typically, there's someone else in the crew that is organizing the event that often participate in that I find fun and enjoyable with the rest of the team, rather than being able to carve out that time and do that.

    Nick Muldoon:

    I remember when we roped in a bunch of folks from iAccelerate and we went into town and we'd go into town and we'd go and we'd get a Laksa in town and we'd get a bowl of Laksa. It's been harder to do that in the past 12 months, given the global environment and all that sort of stuff, so hopefully we can find a bit more of that in 2022.

    Dave Elkan:

    And maybe ramen. There's ramen now.


    Nick Muldoon:

    Oh, and it's great, you know it.

    Dave Elkan:

    Yeah. I think refining what we do and continuing to think more about that, so specifically with the engineers, I like to use a goal based... goals are big at Easy Agile, I think you should talk a bit about goals, but we use them to help guide people in chasing down things they want to achieve, and we can align those things with what the business does to an extent. Then, you can actually go and achieve your professional and goals through the business and the business is the vehicle to do that, rather than having to it outside. That's really cool, like find that harmony there so both Easy Agile can succeed and the people who work here can succeed.

    Dave Elkan:

    I think it actually is quite difficult, like you go, "Hey, take a step back, think about what you want to achieve, give that to me, and then I'll see what I can do to change the course of the business to help you accomplish that. What can we do? Maybe there's a middle ground we can chase down together." And that's something new to me and I'm kind of using that instead of performance reviews so make sure you do your goals, people. [crosstalk 00:42:44]

    Dave Elkan:

    But yeah, also you've made sure, you want to look back in time and you want to see yourself in the future, reflecting with the team. When they've gone and moved on, [crosstalk 00:42:56]-

    Nick Muldoon:

    Oh, yeah. Absolutely. I was even chatting with Elizabeth Cranston this week and I was saying, "I can picture in the future, you're living down at Narooma down the coast and I can come down and have a cheese and biccies with the families and you're looking over the bay at Narooma or something, and we're reminiscing on this period of time at Easy Agile." I can totally see that. Yeah, I think it's great and I think just on the goals, the goals are important personally, and we've talked a lot about goals in the past, with respect to tenure vision for the families and that sort of stuff.

    Nick Muldoon:

    But it's also for the business, I remember we had okay hours in place from getting the business off the ground, we've revised them every year, we've learned and adapted a lot over the last couple of years in how we think about our objectives and our key results. And the fact that we write them on a quarterly basis and we review them on a quarterly basis, but we've got these objectives that align with a business goal that's three years out, and it all kind of flows. I mean, I think we're a lot more mature around that aspect of our... I don't know, would I say strategic planning? Vision goal setting over an extended time period? We're a lot more mature around that today than we were two or three years ago. That's really exciting as well. [crosstalk 00:44:33]

    Nick Muldoon:


    Come back to what you were saying before about the backlog. We'd come in on a Monday morning, and we go, "What are we going to work on this week?" And we kind of worked over a couple years, we worked it out so that, "Ah, here's the vision for the product." It was a longer term thing, and we've elevated that and it's not like, "Hey, what are we doing for the business this month?" It's now, "Here's our longterm trajectory for the business." We've been elevating that, that's pretty exciting, I think.

    Dave Elkan:

    And at the same time, trying to get the team to lift their line of sight as well.

    Nick Muldoon:

    Mm-hmm (affirmative), mm-hmm (affirmative).

    Dave Elkan:

    And look out further afield, but not too far. You want them to be looking at what's happening next week and next month as well, but also what's the goal, what are we chasing down? What's the bigger picture? And I think that's starting to happen.

    Nick Muldoon:

    What's the analogy there about golf, Dave?

    Dave Elkan:

    Oh. No, can you tell me? I can't remember.

    Nick Muldoon:

    It was this analogy about golf, like you've got to look where you're going to hit the ball and you've got to look up. You don't want to look at the tee, you want to look beyond the tee so that you... not beyond the tee, beyond the hole, sorry. You want to look beyond the hole.

    Dave Elkan:

    That wasn't my analogy, that's why I don't remember, but I do remember someone telling us that one. But it's a good one, like it wasn't even an analogy, isn't that the literal thing that the golf tutor would do? It's like, "Where are you looking?" And then they go, "Oh, I'm looking at the hole." "No, no, you've got to look further than the hole. Look up where you want the ball to go, and then away it goes."

    Nick Muldoon:

    Yeah, raise your sights.

    Dave Elkan:

    Raise your sights, yeah. And if you are looking at your feet, then you're probably not going to go far, but if you do look up and take stock, you can probably... that's actually a soccer analogy I can give you, like from my soccer coach, like you've got to point your toe where you want the ball to go. And that's just the magic thing, it just works. You just put your foot next to the ball with the pointing at the corner of the goal you want it to go in and you kick it, and then it just happens.


    Dave Elkan:

    There's these funny little hacks like that and I think that's a longterm vision thing. If you are running a business which doesn't have that longterm vision and purpose, then you can go actually in multiple directions at once, and you're not going to make any progress. I think a good analogy I read was like with a team, if you imagine all the team members are tied to a pole with a rubber band and they're all heading in different directions, the pole's not going to move because everyone's just... and the company's going to stay static and still. But if everyone just goes in the same direction, then it's going to move along.

    Nick Muldoon:

    Shift it, yeah.

    Dave Elkan:

    Yeah. And that's something that we've bitten off recently, is our purpose.

    Nick Muldoon:

    Mm-hmm (affirmative), to help teams be agile.

    Dave Elkan:

    Yeah. It's one of those funny moments when we we're talking about, and we talked about it, we set ourselves a deadline for the sake of a better word, like we had our planning session coming up in a couple of weeks, so we sat down and talked about it. And we went around and around in circles, trying to discover what it is, not to be agile, but just, what is Agile? And we know [inaudible 00:47:45], but we were trying to codify that in words. And when you said that, like it's being agile, it was kind of one of those... the way I like to describe it is, an upside down A-moment, which is our logo as you can see on Nick's jacket there.

    Dave Elkan:

    So when that was proposed to me, I was like, "No, that's so silly." But I was like, "Oh, but I love it." And I'm not saying that being agile is silly, but the fact that it's so simple, that's what I like about it, it's easy, it's simple, and there's a lot there if you dive into it.

    Nick Muldoon:

    Mm-hmm (affirmative). Yeah. Well, why don't we wrap it there? I think that's a good place to end.

    Dave Elkan:

    Yeah.

    Nick Muldoon:

    Our purpose is to help teams be agile and doing that, we're doing that for ourselves, we're constantly trying to learn and adapt and experiment with new things, being Easy Agile and as our team members here. So I hope that was a useful little tidbit and journey from Dave and I on how we got Easy Agile to this point, and some of the things that have been on our mind.

    Dave Elkan:

    Yeah.

    Nick Muldoon:

    Thank you, Dave.

    Dave Elkan:

    Thank you, Nick. That was fun.

    Nick Muldoon:

    That was fun. Oh, goody.