Easy Agile Podcast Ep.5 Andrew Malak, Chief Product Officer at Spaceship
"I really enjoyed my conversation with Andrew Malak. We talk integrating agile techniques and tips on how to achieve a culture of accountability"
Andrew is a firm believer that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes.
Enjoy the episode!
Transcript
Teagan Harbridge:
Welcome to another episode of the Easy Agile Podcast. I'm Teagan, head of product here at Easy Agile. And we've got a really exciting guest on the show today, Andrew Malak from Spaceship. He's the chief product officer. Andrew is a true believer in creating products and experiences that solve customer problems. He believes that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes. In his current role, Andrew aims to help people take control of their wealth from a young age, educating good money habits and helping people invest where the world is going. Andrew is a family man who loves his time with his wife and children. And believe it or not, he uses agile techniques in his personal and professional life. Andrew is an economics geek. He plays and coaches soccer, football. He's a big Liverpool supporter, loves to travel, loves amazing architecture, and loves working with children.
Teagan Harbridge:
There were so many takeaways from my chat with Andrew that I really struggled to pair it down to three. But if you say tuned, here are some of the things that you're going to learn from our chat with Andrew. Why we should stop using the term agile transformation and start calling it an agile evolution. Why it's important to be open-minded to our own limitations so to break the old mindset of protecting original scope. And tips on how to achieve a culture of accountability. So I hope you enjoy. Andrew, can you tell me a little bit about Spaceship?
Andrew Malak:
Oh, fantastic. Well, thank you very much for, first of all, having me, Teagan. Spaceship is a business that's on a journey to make good money habits and investing accessible to all people. So what we look for is trends to do with industries or companies who are building the future of both industry or economies. We invest in them for the longterm, we break down barriers of entry for people, we give them a fee-free product under $5,000, no minimum investments. It's really easy to sign up. You simply download an app and you sign up and make one product selection decision, and you're done. You can start investing on autopilot. We allow you to also invest your superannuation in a not too dissimilar way.
Teagan Harbridge:
So tell me a little bit about who your target customer is, then. Because it seems like you're trying to make something quite complicated accessible for maybe first time investors.
Andrew Malak:
Well, you're absolutely right. There's a niche segment of people out there at the moment, millennials or even gen Zs, that we just don't think have been well serviced by the incumbents. And what we're trying to do is resonate with these young people as much as possible. We're trying to reduce industry jargon and really make things simple to them, because investing doesn't have to be complex. It's really about a lot of discipline around, if I can manage my personal P&L, or money in, money out, then I can create a cash buffer that can go into my assets column on my balance sheet. That's really what we're trying to do. And that kind of language, if we can get it right, can really simplify things that have typically been in the hands of financial advisors and accountants and give it back to everyday Australians who are starting out in their investment journey.
Teagan Harbridge:
Yeah, awesome. And you've been on quite a journey before landing in the FinTech space as the Spaceship CPO. So can you tell me and our audience a little bit about what that journey has looked like?
Andrew Malak:
Oh, where do I start? If you asked a graduate Andrew Malak what he'd be doing now, I don't think I would've been speaking about this because at that point in time in my career I didn't know this space would actually be around, if that makes sense. So I'll go back to my younger years, and I always thought I was going to be an architect. I had this fascination with bridges and I wanted to design things and see them come to life. And let's just say that I do that in different ways right now, but I started out working in CommSec on the trading floor. I moved on to work as a business analyst, and that's where I started my critical thinking into how businesses work and how things can be made more efficient.
Andrew Malak:
I dabbled in teaching for a little bit, I taught high school economics and religion for a little bit. And then I eventually landed in a product role at St. George Bank prior to the merger with Westpac. At that point in time, the light bulb really came on. I realized, "Hey, I like creating things. I like to change things. I don't like to just do things," if that makes sense. And that wondering mind that doesn't like the conform was finally let loose, if that makes sense. And I haven't stopped enjoying it. I loved my time at Westpac, made lots of friends, worked on really cool, successful projects, and implemented lots of things that had great results. Worked on lots of things that have failed miserably and learnt a lot out of that. And when the opportunity at Spaceship started to surface late last year, it was just too good an opportunity to not really come in and have a go. So yeah, it's been quite the journey.
Teagan Harbridge:
Yeah, wow. And I love a good failure story. And you said you've had lots. Can you think, just off the top of your head, what one of those big failures has been?
Andrew Malak:
Where do I start? I think our first attempt at taking a digital experience to allow customers to acquire a product online was quite a failure that taught us a lot. We basically took the systems that our back office staff used and just made it available to customers. And the real good learning out of that is there was a lot of traffic and a lot of demand, but not enough completion ever. And the best learning that came out of that... This is back in 2006, so internet speeds were just starting to pick up. Broadband was starting to go mainstream and customers' trust around doing more transactions that used personally identifiable data was starting to normalize at that point in time. Up until then, people quite reserved thinking, "I'm going to lose my personal data," et cetera. So when we decided to do that, we saw that there was a lot of demand but we quickly came to the realization that we used to train staff for four to six weeks on how to use the systems before they knew how to service customers using them.
Andrew Malak:
But then we've deployed it into production for customers to self-service and realized quite quickly that the experience for customers had to be much more guided than the experience for a staff member. This is where the evolution of usability or design thinking started to come in. We started thinking of, "Well, how do we make these things so easy that a first-time user can go end to end and not encounter friction?" And this is where our understanding of design principles, customer testing using verbatim and anguage that can resonate with a first-time user becomes critical to the execution. It's not just good systems but it's good user experience sitting on top of systems.
Andrew Malak:
That's probably the one that resonates with me the most because I've held that to a very high regard throughout my whole career. Now everything I do I think of, "Where's the friction? How do we make sure there's no friction? What's the customer going to feel throughout this experience? How are we creating unnecessary anxiety in that experience for the customer, and how do we move that away? How do we become more transparent but still be simple?" And yeah, that's probably the one that resonates the most.
Teagan Harbridge:
Seems like a tremendous learning opportunity early enough in that project and something that's stuck with you since, so great learning opportunity.
Andrew Malak:
Absolutely.
Teagan Harbridge:
We've got a ton of customers who are at all stages of their agile transformations, and I know that this is something that you've had experience with if we go back to your St. George, Westpac days. Can you give our audience any tips or stories that you encountered when you were going through those agile transformations? What lessons can you share with our audience?
Andrew Malak:
Oh, I have lots of lessons to share, actually.
Teagan Harbridge:
This is what I love.
Andrew Malak:
Look, I like to position it more as agile evolution more than agile transformation because no matter what you try to do, you're not just going to drop waterfall and become agile next morning. Honestly, I've seen so many attempts and every single time I see that the graduality of the change is a better predictability of the final outcome that you're going to land. So ultimately the Holy Grail that everyone's aspiring to is that, as a leader, you can rock up to a team stand up unexpected and then, without being told who is in what role, who the product owner is, who the engineer is, who the QC is, who the designer is, it becomes hard for you as the leader to work out who's who because at that point in time the team is so well converged on customer outcomes that they will self-organize themselves around what each person needs to do.
Andrew Malak:
And most of the language being used is really around, what are we trying to define the customer? What's the best thing to do within the capacity that we have to deliver this feature to market as quickly as possible, capture value for the customer and the business as much as possible? This takes a long time to get to, where you can start normalizing to a standardized, common set of goals, common cadence, and common ways of working. And I think it's ultimately about how much empowerment you can give people and how much as a leader you can relegate yourself in the background to allow them to work it out themselves as long as you're coming in and nudging things along the way and helping people course correct along the way. So the good news is that I actually think at Spaceship, we're pretty close to getting there.
Andrew Malak:
We have been running scrum and we have been running sprints for a long time, but it has been largely ceremonials. But over the last quarter, we've done a really good job at embedding more cross-functional people into these teams. But the goal for us is that now we feel like our throughput has actually increased and that the constant flow of information between the teams is becoming more natural and there is actually less ambiguity between the teams around, "All right, we built it this way. The API is no longer consumable. It doesn't fit what we're trying to do from our front-end and there's less back and forth." So we can really see that the amount of friction between persons in the team is really starting to reduce dramatically and we're starting to see that throughput really increase. Having said that, the best way to go about an agile transformation is just get started.
Andrew Malak:
You can sit and plan out things and plan towards utopia as much as you want or you can actually just get going. So when I say by get going, I say you have to start by getting buy-in from all the leaders of the different cross-functional teams, because if you don't have that buy-in at the leadership level, it's just not going to work because there's going to be blockers, there's going to be escalations. And if all these things result in conversations around, "Should we keep doing this?" Or, "Hey, maybe this is not the right thing to do." That needs to be off the table really early on and it needs to be a total commitment at the leadership level that we're going to make this work and whatever we encounter we're just going to fix forward. Once you have that commitment at the leadership level, you need to very clearly define the values that the team is going to be handed to work with, because agile itself, it's not a process, it's a set of values that the team needs to just take and start working with.
Andrew Malak:
So we could go and rattle individuals and interactions over processes and tools or working software over comprehensive documentation. Well, give these to the team and they're going to say to you at day one, "We can't go to all of that straight away." So they might actually say that day one, "We're still going to need some documentation because we're not comfortable yet. We don't understand the language of the other people in the scrum team well enough to be able to go and actually code off the back of a conversation." But by the 10th sprint, the 20th sprint, that misunderstanding of what the product owner wants or what the designer is trying to achieve in an experience starts to become embedded in the mind of the engineer.
Andrew Malak:
The engineer understands the customer a lot more, and then you can make do with less process and less documentation and less negotiated outcomes and more commonality across the team. The other thing that then starts to kick in at that stage is that ability of the team to pivot in response to a change and not see that as a threat to what they're trying to achieve. The old ways of working was, define that scope, protect that scope, and not let things disturb that scope, whereas if you're halfway through a project and you get some really good information that tells you that maybe you are not on track to achieve a good outcome, you should be welcoming that. And the team itself in the beginning is going to find that an irritation, but over time they'll become more comfortable with pivoting off the back of new information.
Teagan Harbridge:
Yeah. It's a big mindset shift. I was just having a discussion today about, where does being agile and being reactive, where's that line in the middle. And when does taking information and pivoting because you think something will be better, when can we break that mindset of, "Oh, we're just being reactive?" No, we're being responsive.
Andrew Malak:
Yeah, yeah. And look, I think the word reactive itself naturally has a negative connotation to it, but agility in mindset allows you to flip that on its head and say that no one can work things out in totality to 100% of what's possible, so being open-minded to our own limitations first and foremost allows us to acknowledge that when new information comes in, it is because we didn't think through the solution 100%, but let's also be okay with that because no one can. So I think it's flipping on its head and acknowledging it upfront and saying that this is going to happen, but when it comes we will assess the information we have with the capacity we have with how far progressive we are and make a decision that's right for us, for the customer, and for what's possible.
Andrew Malak:
So I take it as the more information you get along the way, the more reinforcement of, are you doing what's right or should you pivot and change at that point in time? The other thing that happens really early on is that if you as a leader can create a really clear vision around customer outcomes and establish your first cross-functional team and hand over that vision to the team, it becomes theirs. Don't hand over the backlog to the team. Don't give them a ready backlog, just give them the vision and then tell them, "You guys work out what your backlog looks like." When they come up with their own backlog, as long as you as a leader don't see that it's just a list of Hail Marys in it and there is a fair bit in there that is well spread out between hygiene things, strategic things, and a few moonshots and the balance is right, if the team has come up with their own backlog, the motivation they have to build their own ideas just goes through the roof.
Andrew Malak:
And that's what you want to achieve. You want to achieve clarity that the work fits with the vision and the motivation that you get out of the backlog being created by the team itself gets you that throughput enhancement. The other thing that you're going to struggle with really early on is chunking things down to fitting within the sprint cadence. I think that's one that's often been my biggest challenge when moving towards agile practices early on. Typically in the first few sprints, you always have overruns and things don't complete in the sprint because we end up thinking we can do more than we can and it takes us a while to work out, in wrapping up something that becomes shippable in a sprint, you probably take a little bit less in that sprint because you've got to test it or you've got to do a release in that sprint, or you're going to do a PIR in that sprint, or you're going to do a lot of retros in that sprint. Start to sort of formulate what you're going to take through the next planning cycle.
Andrew Malak:
So you've got to budget to that capacity, and I'll find that teams underestimate the magnitude of that work. So be okay with that. Overruns in the first few sprints don't mean you've failed, it means you're learning how to plan better. And then make sure your retros and your pivot off the back of that into your next planning sessions is taking information that is now new to you, and making sure you're working with it. I think as the leader, though, you have to set the expectations that teams can make mistakes and that it's a safe environment.
Andrew Malak:
And I've seen many agile... I was about to use the word transformation, even though I've just said I don't believe in transformation. Any teams that are adopting agile principles expecting that in their first few sprints they don't have any hiccups, and that if throughput falls in the first few sprints, then there's a bit of a, "Oh, well you told me this thing was going to increase our throughput." Yeah, but not straight away. So I think just being realistic with yourself and what's possible, and that shift in itself, until it normalizes, takes a bit of getting used to. The teams need to know it's a safe environment, that if their productivity suffers, if they make mistakes or if they break things, it's going to be okay. We'll fix forward.
Andrew Malak:
But then also there comes a point in time where we have to be very clear about the culture of accountability around using that capacity really well. So what I've found, that the best use of that is the showcase. And what we've done at Spaceship, because we're trying to reduce the amount of ceremonies, we've combined both the planning playback in a sprint as well as the showcase into the same ceremony. So what we do is we play back what we built last session using a demonstration of working software and comparing the amount of work we've executed versus what was planned in the previous sprint. We're saying we've got 80%, 90% through the work and this is what it looks and feels like, and this is what we're deploying to the customer. Then we actually showcase what we plan to do in the next sprint.
Andrew Malak:
And that's part of the showcase, is our hand on heart commitment to, "This is what we as a team are committed to doing in the next sprint." And then that accountability to the organization becomes something that keeps us on track throughout the sprint. As distractors or things that are not committed in the sprint come our way, we quickly think about, all right, can we accommodate these things? Do they need to be done? Are they going to take us off track with what is planned? Are they important enough? Is it a major defect of production, and can customers no longer access our app? Well, drop what you're doing and attend to that. Otherwise, if it's not material, keep focused on the work that you've committed to in front of the organization.
Andrew Malak:
After this you're going to start to experience some growing pain, and the growing pain is good because it means that agile is working and more teams or more feature opportunities become possible for the business. There's going to be a lot more hype around moving to agile. Other teams are going to come across and say, "Oh, how do we piggyback off what you're doing?" Et cetera. This is good. This is good, but what it means now is that some new risks are going to actually start to be introduced. Working with common code, common dependencies, or even common people being needed to be doing multiple things just means that you now need more coordination. I'd say to anyone who reaches this point in time, this is where people feel compelled to start introducing some new roles, coordination roles. And I'd just say, be careful because that can start add to your overhead really quickly.
Andrew Malak:
I find the best way to ensure that teams continue to be in sync is with the right dialogue at the right level with the right rhythm. And this is where I think keeping it simple to just the scrum of scrums works really well. I like the scrum of scrums to be balanced between both product owner and tech lead from each team being present, and a cadence of one to two times per week works really well. And as long as the product owners across the teams and the tech leads across the teams know what the other teams are working on, know what could impact their own work from a release perspective or scheduling perspective or an environment perspective, I think that tends to work really well as well.
Teagan Harbridge:
Yeah, wow. Lots of nuggets in there and certainly things that resonate with our experience here at Easy Agile, being a small company that's grown really quickly. So I can definitely relate. We've had conversations about, do we introduce new roles into this company? We've introduced a new cadence of meeting rhythms only the last couple of months, so we're going through these things too.
Andrew Malak:
Absolutely. Absolutely. What have been your biggest learnings so far?
Teagan Harbridge:
I think that you cannot underestimate communication, and it really does come back to that cadence and that rhythm with the team. And we're experimenting at the moment with a daily huddle where we're talking about, how do we embed showcases more regularly in our cycles? We've got a big demo at the end of the cycle. How can we make that a more ingrained part of our culture? And it really does come back to that culture of accountability as well. So yep, it's all resonating.
Andrew Malak:
Yeah, absolutely. Look, you can go to whatever industry you want but the problems are usually similar. And the great thing is that having these conversations is very important to fast-tracking your way forward, because your problem is not unique to you. Someone else has seen it in someone else has figured out a way. And I think what I like about the FinTech industry is that we compete on products and services, but there's a lot to learn from each other. And even if you just go outside of FinTech, there's a lot to learn from other industries who have adopted agile practices.
Teagan Harbridge:
If we take a bit of a flip, we've gone from your professional career and your experience into a more personal level. You mentioned that you use agile techniques outside of work. So I'm not sure if many others are in the same boat, but can you elaborate on this? What does that mean? What does that look like?
Andrew Malak:
Okay, I hope you don't think I'm extremely weird. We actually have a family campaign. So I guess if I go back to how we've come to actually doing this. Becoming parents, we would look at our children and see so many things that we want them to be better at. And in trying to give them constant feedback, which felt like the feedback was so much that it's all being drowned out because there's so much of it. In fact, my oldest son actually gave me that feedback. He goes, "Dad, why don't we focus on one thing at a time?"
Andrew Malak:
And I was like, "Wow, okay." For a ten-year-old to tell me that, that was amazing. So we came to realize that we needed to narrow and focus on one improvement area at a time, and we don't move on to the next one until we've actually closed out the first one. For example, my oldest son, very clever boy. We're trying to focus with him on the discipline of process over just getting the answer right, because he is clever and nine times out of 10, ask him a question, he's got the answer and he just wants to say it.
Andrew Malak:
But we've started to try to break down the question and work more on the process with him so that in following the process, coupled with his natural ability, we will get more answers right more often. And that's what we're working through at the moment. So our family's scrum wall at the moment has a mix of things on it. Everyone has their own swim lane, and in each swim lane there are a few tasks, some related work or study, some relating to household chores, some related to health or exercise, and some related to acts of kindness. And what we aim to do is make sure that we're moving things across in all four categories every single day. So yeah, you can use agility wherever you'd like but I think that mindset in general, that if I wake up every day and do things that make me better than I was yesterday, then I'll get to keep moving forward in my personal life as well as my professional life.
Teagan Harbridge:
And do you have WIP limits?
Andrew Malak:
We don't at the moment, and we're not doing showcases at the moment. We'll see how we can introduce them in the future.
Teagan Harbridge:
And how was the introduction of a Kanban board at home? How was that received by the family? Have they enjoyed it, has there been any feedback?
Andrew Malak:
Well, it wasn't actually planned. It started by just sticking some Post-its up on the fridge to remind us of stuff. And then one day I said to my wife, "You know what? This reminds me of what we do at work. Why don't we formalize it?" She had a bit of a chuckle but then one day she came back and then she found it there. So yeah, it wasn't really planned.
Teagan Harbridge:
Awesome. And you've already been super generous with your time so I'll close it out with one final question. What advice do you wish someone would have given you when you took the leap from product management into product leadership?
Andrew Malak:
Yeah, that's a really good question. I think first and foremost, that you've got to make sure that you drop your need for perfectionism, because first and foremost, you might have been the best product manager yourself. You might have been amazing. And I'm not saying I was, but if you were and you step up in leadership role, you're going to have people of different abilities working for you. And what you need to understand is that they're going to need some time learning their role and learning their trade. And just don't get in the way of them learn. So for example, you might see someone doing something that may not be the best or most optimal use of that capacity in that sprint. You might feel the urge to jump in and course correct. But if you let them go and just hear their feedback post the retro, they might've had that learning themselves, and a learning that they get for themselves rather than being told by their leader is going to be much more useful for them.
Andrew Malak:
You have to drop your need to make decisions and be in control because, again, the more you can relegate yourself to a servant leadership role and let the team make decisions, when they make decisions and now have to go back up that decision with execution, they're more likely to put their heart and soul into it. The more they feel like you are going to make the decisions, the less inclined they are to think through problems themselves, and then they'll keep bringing the problems back to you. So every time someone asks you a question that has a black and white answer, throw it back to them and ask them what they think, because that way you're coaching them to work it out themselves. And then the last thing that's really important is, I feel like it's really important to think through how your organization allows you to be different and take advantage of that differentiation.
Andrew Malak:
So for example, at Spaceship here, because we're small, we're not a large corporate, our customers are a little bit more forgiving. So you have a limited capacity to build experiences and you can't do all things at the same time. Understand that and take advantage of it, and get your team to also learn that. Because if you're trying to how the all edge cases, it will take a lot longer to get something to market and you might use a lot of the team's capacity to build edge cases. And you can't really afford that when you're in a start-up.
Andrew Malak:
So for example, we launched a new investment portfolio yesterday. We launched the Spaceship Earth portfolio, our first sustainable investment portfolio and it's a sign of more things to come hopefully in the sustainability space. But in launching that, we knew that we have a limitation in our experience or our product set today where each customer can only have one portfolio. We knew that existing customers would want to invest in sustainable investing, but our commitment to them is that it's in our backlog and it's actually the next feature that we're actually going to take to market.
Andrew Malak:
And in explaining that to our customers, they've been very understanding, that they know our throughput is limited but they also know that their voice is being heard and we are building the things that they're telling us about. So I would say that the best piece of advice to tell my young self is to make sure that you get the balance right between the voice of the customer. That's going to tell you all the hygiene things that your product lacks in terms of experience or gaps. And then get the balance between new strategic things that you can go after and new things that you can take to market, as well as a few Hail Marys every now and again. We call them moonshots. They may or may not work, but it's exciting, and if it works, can 10X your volume. And they are the things that are likely to go viral. So getting the balance right is very important.
Teagan Harbridge:
It's been wonderful, Andrew. I've definitely taken a lot away from our chat today, and I'm sure our audience will too. So thank you again so much for your time, and good luck.
Andrew Malak:
No Teagan, look, thank you very much. And it's been a pleasure speaking to yourself and Easy Agile, and I wish you guys all the best too.
Teagan Harbridge:
Awesome. Thanks Andrew.
Andrew Malak:
Have a good afternoon.
Related Episodes
PodcastEasy 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.
PodcastEasy Agile Podcast Ep.9 Kit Friend, Agile Coach & Atlassian Partnership Lead EMEA, Accenture.
"From beer analogies, to scrum in restaurants and neurodiverse teams, it's always a pleasure chatting with Kit"
Kit talks to agile methodology beyond the usual use case, like working with geologists & restaurant owners to apply scrum.
Kit also highlights the need to focus on a bottom-up approach, providing a safe space for leaders to learn & ask questions, and whether neurodiverse teams are key to effectiveness.
This was a really interesting conversation!Be sure to subscribe, enjoy the episode 🎧
Transcript
Nick Muldoon:
G'day folks. My name's Nick Muldoon. I'm the Co Founder and Co CEO of Easy Agile, and I'm delighted to be joined today by Kit Friend from Accenture. Kit is an agile coach at Accenture and he's also the Atlassian Practice Lead there. Kit, good morning.
Kit Friend:
Morning, Nick. Sadly only the Practice Lead for a bit of things, but I try my best. It's a pleasure to be with you, for the second time we've tried this week as well, in the lovely world of broadband dependent remote working and things. But here's hoping, eh?
Nick Muldoon:
It's beautiful, isn't it? Now, for those of you at home listening in just so you've got a bit of context, Kit is a father to two, he lives in London, and he's been at Accenture now for a little over 10 years, right?
Kit Friend:
Yeah, September, 2010. Fortunately I met my wife in pretty much the same summer, so I only have to remember one year, and I can remember one by the other. So it helps when I'm trying to remember dates, and sort things through because I'm not very good with my memory, to be honest with you.
Nick Muldoon:
Oh well. So for me, the reason to get you on today, I'm super excited to hear about the journey that you've been on in Accenture, and I guess the journey that you're on with your clients, and on these various engagements. Before we dive into that though, I wanted to know, can you just tell me what is one of your favorite bands from the '90s, from the early '90s?
Kit Friend:
Yeah, and I really enjoy that we had a delay between things, because it's like one of those questions, because I'm like, "Hmm." And I think I'm a victim of playlist culture, where it's like naming an entire band feels like a real commitment. It's all about tracks now with things, right? But I have narrowed it down to two for my favorite 90s band and I think I'm going to commit afterwards. So my undisputed favorite 90s track, Common People by Pulp, right? Hands down, yeah, it's right up there. For me, I studied at St Martins, the Art College, so for me Common People is the karaoke track of my university days with things there. So Common People by Pulp, favorite track.
Kit Friend:
For bands wise though, I was split between... Initially I went Britpop, I was like, "Cool, that feels like a happy place for me." Particularly at the moment in our weird dystopian society, I listen to Britpop and it's kind of happy. So Blur was right at the top for me for band commit of the 90s thing then. But then I remembered that Placebo is actually technically a 90s band, even though I did not listen to them as a 13 year old Kit and things. So I think Placebo edges it for me on favorite 90s band of things, just about. But I do have to admit, even though it's not my favorite 90s track, I do think Wonderwall is perhaps the best song ever written.
Nick Muldoon:
Oasis? Love it.Kit Friend:
Yeah, for track wise. But for me particularly I was at Oktoberfest with some colleagues a couple of years ago and I don't think any other track could get 600 drunken Germans up on benches together with everyone else, all the way around from the world, with a rock polka band singing at the top of your voices at 11 o'clock at night or something. So yeah, that smorgasbord, but I'll commit to Placebo for favorite band in that weird caveated sentence.
Nick Muldoon:
I love it, thanks for that, Kit. And so it's interesting because you touched on then that you went to St Martins, which was an art college. So I'm interested to know, what did you study? What are your formal qualifications and then what led you into this world of Agile delivery and continuous improvement?
Kit Friend:
Yeah. I mean to do the Twitter bio caveat that all the opinions are my own and not Accenture's before we go down the journey of things. Although it must be said I am trying to convert as many of my colleagues and clients to my way of thinking as possible. But so I studied St Martin or studied at St Martins College, so in the UK certainly, I don't know what it's like in Australia, but when you go and do an art and design degree they basically distrust your high school education. They're like, "Nah, everything you've done before is..."
Kit Friend:
So they make you take what's called, or they advise you to take what's called a foundation year where you try a bunch of stuff. So you come in thinking you're going to be a painter or a product designer or something, and they're like, "No, no, no. You haven't experienced the breadth of the creative industries and things." So I did one of those, which was amazing, and I came in thinking I was going to be a product designer. Ended up specializing in jewelry and silversmithing and things, so I made like... Yeah, sort of wearing long black trench coats and things, I was making gothy spiky armor and all sorts of things, and [inaudible 00:04:24] work with silver. So I do have a Professional Development Award in Welding from that year, so that was my first formal qualification on that. I'm a really bad welder though.
Kit Friend:
Then at the end of it I was like, "I don't really know what I want to do still." As you do as you go through university, so my formal degree title, adding to my trend of very long unpronounceable things, is, Ba Hons Art And Design And The Environment, Artifact Pathway, and what it was was... Your face is-
Nick Muldoon:
Yeah, I'm trying to process that.
Kit Friend:
Yeah. I think the course only existed for three years, it felt like a bit of an experiment, or it only existed in that format. So we had architecture students doing the first part of their architectural qualification, we had what were called spatial design students who were, I think, designing spaces. They weren't interior designers, they were a bit more engineery and then we had this weird pathway called Artifact, which was the rest of us and we weren't quite as strict as product designers, we weren't artists. We were making objects and experiences and things.
Kit Friend:
Yeah, it was a really interesting experience. I mean towards the end of it I began specializing more and more in designing ways for communities to come and build things and do stuff together, and it's a bit weird when you look backwards on things. You're like, "I can directly trace the path of the things I've done since to that sort of tendency [crosstalk 00:05:54] liking bringing people together."
Nick Muldoon:
So yeah, do you think that community building aspect was kind of a genesis for what you've been trying, the community around Agile transformation you've been developing over the past decade, or?
Kit Friend:
I don't know. It's easy to trace back to these things, isn't it? But I guess I've always-
Nick Muldoon:
You don't see it at the time.
Kit Friend:
... liked bringing people together to do things. No. It's a theory anyway, isn't it? An origin story theory as we go. So I did that and then I complained lots about my course, I was like, "This is rubbish. This is all really random and things." So I got elected as a Student Union Officer, so I don't know how it works in Australia but in the UK you can be elected as a full time student politician effectively, and you can do it... You take sabbatical either during your course or at the end of your course where it's not really a sabbatical. So I was the Student Union, served full time for two years after I finished my degree, which is a bizarre but educational experience.
Kit Friend:
Again, it's about organizing people, like helping fix problems and having to be very nimble with... You don't know what's happening the next week, you're going to protest against unfair pay or you're going to have someone who's got their degree in trouble because of their personal circumstances and things, so it's a really interesting mix. So yeah, that's where I started my journey into things.
Nick Muldoon:
So it's interesting for me, because you talk about this, the early piece of that is, "We don't trust anything that you've learnt prior to this and we're going to give you a bit of a smorgasbord and a taste of many different aspects." How does that relate to an Agile transformation? Because I feel like we went through a decade there where an Agile transformation was literally, "Here's Scrum, do two weeks Scrum, story point estimates, no rollover. If you rollover we slap you on the wrists."
Nick Muldoon:
There probably, 10 years ago, there wasn't a lot of experimentation with different approaches to delivery. It was just, "We're going from this Waterfall approach to this Agile approach." Which back then was very commonly Scrum. Why don't we give people the smorgasbord and why don't we give them three month rotations where they can try a bit of Scrum and a bit of Kanban and different approaches?Kit Friend:
Well, I guess it's practicality, isn't it? These things. It's a challenge, and it's a challenge, it works within a contained place. I teach a lot of our product container courses for our clients and we always use the David Marquet video of Greatness Summary. What's great about the David Marquet situation, he's got this Petri dish, right? Literally a submarine, aint no one interfering with his submarine crew. So he can do that, he can go, "Well, let's try this thing." I vastly oversimplify because it's an amazing story, right?
Kit Friend:
But you've got that space to do something and try something out, and actually when we do talk to clients and colleagues alike about Agile transformations, I think one of the things that I say consistently in terms of the role of leadership is they do need to create a safe space, a little place where they protect and they're like, "In this space we're doing Agile, we can experiment, we can do these things. Leave my guys alone. Trust me within that."
Kit Friend:
I think where I see Agile going well, it is where there is a bit of that safe space protected to do things. I've got colleagues who work in companies where they go like, "Okay, we're going to try now and all we're going to ask you to do is forecast your next week's volume of stories. Everything else is up to you, you can choose to apply Scrum, you can use Crystal, DSDM, whatever it is. All you have to do for us as a company is give us a high level view of these metrics or something." So there's flexibility. I think when I think about your journey as an Agilist and trying to do things though, people saying try a bit of everything, it's lovely advice but it's a bit difficult to actually do because it's like we still need to make things, we still need to do stuff practically.
Kit Friend:
So when I talk to people who are starting off their journey or both clients and colleagues who are wanting to move through things like that, like what do they do first, I still say Scrum is a really good place to start because I think there's that quote from somewhere, it's probably in the Scrum Guide, about, "It's simple to understand but complex to get right." And you would think with complex and chaotic situations, right? But I think that-
Nick Muldoon:
And the discipline required is-
Kit Friend:
Yeah, yeah. But discipline's a good thing, right?
Nick Muldoon:
Mm-hmm (affirmative). But not everyone has it.
Kit Friend:No. But one of my colleagues, Nick Wheeler, he uses the phrase, "Too many beanbags, not enough work done to talk about Chaotic Agile." I think you've got to have that focus on getting things done, right? Value delivery has got to be there, as well as it being a pleasant working atmosphere and balance. So it's about somewhere between the two, and I like Scrum because it gives people something too... It's a framework, right? It gives people something to hang off to start their journey, otherwise I feel like you could spend months debating whether you have an Agile master and what do they do? Where do we go? Do we have a person who holds the vision and things?
Kit Friend:
I think when people are starting off I always say, like, "Why not try Scrum? Why not see? Try it for a couple of sprints and see what works for you and then see what comes out in the wash." I mean if they're in an area where there's some fundamental contradictions, like, "Yeah, I'm not going to force sprints on a call center, right? It doesn't make sense." I was talking to someone yesterday who works on a fraud team, and it's like I'm not going to ask her how much fraud is going to be committed in two weeks time, or as part of MPI, right? It's absurd.
Kit Friend:
So in those circumstances, yeah, you start with Kanban methods and processes and practices instead. But for people who are building products, building things, I think the Scrum is a pretty good fit at the beginning. So yeah, that's my answer, so both. Why not have both is the answer to that, I guess, on the way. Yeah. It'd be interesting to see what other frameworks rear their heads. I mean I found the other day a scaled Agile framework called Camelot that involved lots of castles and things in the YouTube video. I thought that was marvelous. But there's room for a lot of planning and thinking.
Nick Muldoon:
As soon as you saw Camelot, for some reason my mind goes to Monty Python. I don't know quite why. But what's this flavor of scaled Agile called Camelot? Can you tell me about it? Because I'm not familiar with it.
Kit Friend:
I've seen one YouTube video on it, Nick. For anyone Googling it, you can find it related to the X Scale Alliance. I think it's a picture of the Monty Python Camelot on the front page.
Nick Muldoon:
Is it actually?
Kit Friend:
Yeah, yeah. I'm pretty sure weird things. And you know what it's like with techy geeks, right? There's a lot of embedded Hitchhikers' Guide To The Galaxy and Monty Python references in component names and things. So I'd be unsurprised. What I like about something like the Camelot model, other than me thinking Monty Python and castles and things, is it does evoke something in people. I think when we're talking to people about Agile we do need to evoke a feeling with them. We need to get people going, "Oh yeah, I kind of get where you're going."
Kit Friend:So I always like to do the cheesy uncapitalize the A, what does agile mean to you? Yeah, is it about being nimble? Is it about being flexible and that kind of thing?
Nick Muldoon:
I mean I'm conscious you've obviously done Lean Kanban in university, you've done Scrum Alliance Training and Certification, Prince2, Scaled Agile of course. Why do you do all these things? I mean is it curiosity? I mean is it there's an expectation from clients that you have these certifications? And would you go and get a certification in Camelot? Or even one that I was introduced to recently was Flight Level Agile, Flight Level Agility. Which is a different way of-
Kit Friend:
Ooh, another one?
Nick Muldoon:
Yeah, another one. A different way of describing. Actually I remember, bit of a sidebar sorry, but Craig Smith from... who was at the time I believe was working at Suncorp, an Australian bank. He did 46 Agile methods in 40 minutes or something like that, and he spent a minute and he introduced people to all of these different approaches.
Kit Friend:
Yeah, and methods versus frameworks and things is a fun one to draw the lines between. I mean I've been surprised actually how few times I've been asked for certifications around things. It's changing a bit more, and I've seen definitely more enthusiasm from our clients, and in fact I'm seeing new people within Accenture which is really nice, to require and encourage certification. I don't think it's necessary that the safe course then guarantees that you're going to scale Agile successfully, right? But it's a good way of demarking whether people have done their homework and have put some effort into [crosstalk 00:14:50] knowledge.
Nick Muldoon:
And they got the foundational baseline stuff.
Kit Friend:
Yeah. Now in terms of your question around Brett, so my view is that if we try and attach the word coach to ourselves... I think I've seen country by country different trends, so when I look at my colleagues in the States there's a bit more codifying on the term Agile Coach. There's an attachment to ICA Agile and Lisa Adkins work and all sorts of different things over there which is good. Certainly in the UK and Europe, I see it as a lot more varied at the moment and it's a term that's attached to a lot of people.
Kit Friend:
If you look at people, just anyone on LinkedIn with a CV title or little bio title Agile Coach, you can see a big variety of people who've been doing different Agile frameworks for like 20 years doing things, and you can see someone who's been a Scrum Master for three months and then switched jobs, and they'll have like Agile Enterprise Coach as their title. And you're like, "Hmm, how many people have you ever done Scrum with? And have you done anything but Scrum?" And my view is if 40-
Nick Muldoon:
But I mean Enterprise Agile Coach because I've done Scrum with my team of six people in a-
Kit Friend:
In an Enterprise, right?
Nick Muldoon:
In Enterprise.
Kit Friend:
But my feeling is if all you can do to a team that you're coaching is offer one way of thinking and one approach to doing stuff, how are you coaching them then? There's no breadth to what you're able to offer. But if all you've experienced is Scrum and then you get landed with a team doing fraud investigation, how are you going to guide them on a path which doesn't include sprints and those things? I mean you might do, because you're going to take things from Scrum that become sensible, but you need that spectrum.
Nick Muldoon:
Give us a sense, Kit, what is the most quirky, or unusual perhaps is a better way to frame it, what is the most unusual team that you have introduced to Agile practices and Lean principles?
Kit Friend:
So I've got to embarrass my colleague Giles, because mine is not the most interesting. So Giles was looking at introducing Scrum to geologists for site surveying and things, which I love as an example to talk about because it's so-
Nick Muldoon:
Wow. Yeah.
Kit Friend:
When you unpack it's so interesting to think about what that would mean, and I need to catch up with him to see how far through they got actually applying it. But because it's like, "Why would you do that?" And then it's like, "Ooh, actually, they probably have a really big area to survey. Wouldn't it better to introduce some feedback loops and look at how you slice down that problem to get some value and learning delivery out of things?"
Nick Muldoon:
That's interesting.
Kit Friend:
So I really, really like that. Yeah. Then I always reference when we're teaching, there's a restaurant called Ricardo's in London that I have to make sure it's not gone out of business. I think it's still in business, but-Nick Muldoon:
Well, I thought it-
Kit Friend:
Well, COVID, right? I think he's their owner, Ricardo. At least he's the person that's inspired their name. He applied Scrum and it's beautiful, looking at the exercises they went through when they put it in place. And on his website, which I'll ping you the URL for the show notes, but they do this cross functional teaming thing where they got all the staff at the restaurant to look at the role types that they needed, and then their availability and things. They were like, "Only this one guy can do the bar. Maybe we should up skill some other people to be able to work on the bar?" And I love that thinking of applying those elements of stuff.
Kit Friend:
So back to your question though of where have I applied unusual things to my teams, I haven't done any really quirky ones, to be honest with you. I mean I think having a background in art and design I find it... When I talk about iteration and all those areas, my mind immediately goes back to projects where we made things and did stuff and have it there, and particularly when people get panicked in a business situation I think back to... I used to freelance doing special effects with my dad whilst I was at university, because it's a great way to make cash for things. My dad worked for the BBC and freelance. I think about that immediacy and panic when I'm talking about Kanban and handling ops and incidents and things, and I'm like, "You guys don't need to panic, it's not like you're on live TV." And they have a countdown of three, two, one, right?
Kit Friend:
No one has that in our business. We panic sometimes when something falls over, but there's never that second by second delay. So I think the quirkiest places that I've applied Agile thinking are probably before my career in technology. They were in that kind of place where we're making creative things and doing stuff, and it's there where you're like, "You would never do a 400 line requirements document for a piece of product design or jewelry, right?" You would produce something rough and see what people think about it, and build things in so there's a balance there.
Kit Friend:
I mean when you're launching live products though, you do some strange things, right? And you have some fun memories from that. So I remember when we launched YouView in the UK, which is a public credential because it was for Accenture. Fine. But during launch day a colleague of mine, Ed Dannon and me, we became shop display people for the day so we were at the top of John Lewis in Oxford Street in London demonstrating the product, and that was a part of our Agile working for that week because that's what they needed. That was how we delivered value was physically being the people going like, "Hello, Mrs Goggins. Would you like to try this YouView box at the top of things?" So I remember those days fondly.
Nick Muldoon:And so was that capture on a backlog somewhere, or?
Kit Friend:
Do you know what? YouView is where I was introduced to my love of dura, so I suspect, yeah, I don't think we did formally add a backlog somewhere. It would've been nice too, wouldn't it? I'd like to claim that my entire Accenture career could be constructed out of Dura tickets if I piled them one on top of each other for 10 years. Certainly about a 60%-
Nick Muldoon:
How many Dura tickets do you reckon you've resolved over the years?
Kit Friend:
God. How many have I duplicated is probably the question, right? Which is like 8,000. There's always duplicate of things. It's got to be in the thousands, hasn't it?
Nick Muldoon:
Tell me, you've, okay, over thousands of duplicates resolved. But you've been doing this for a while in the Atlassian space, and obviously with the Agile transformations at scale. How have these engagements at scale evolved over the past seven or eight years? And what do they look like in 2021 with this completely remote mode of operation?
Kit Friend:
Yeah. Starting at the end of that, I see light, I see goodness in things. But I guess similar to how you expressed 15 years ago, 10 years ago everyone was like, "Do Scrum and have some story points and things." I think during that period, if we go back like 10 years ago, so we're like the early 2010s or whatever we call the teens in the decades, I think we see a lot of people experimenting with early versions of SAFE. They'll do wheel reinvention and people simultaneously going, "Let's have a big meeting where everyone plans together. How do we normalize story points? You shouldn't, maybe we should. How do we do metrics there?" And that kind of stuff.
Kit Friend:
So I think certainly what I've seen is a lot of people trying out those things as we go through, and then trying to weave together concepts like design thinking and customer centricity, and there are all these bits of stuff which feel good, but they weren't very connected in any way that was repeatable or methodical or codified. Then what I quite enjoy, and linking back to your last question, is then the branching of the approaches to things. You've got SAFE, which is laudably to everyone who works on that, right? They try and write down everything.
Kit Friend:
I always say this to everyone, you're like, "Thank goodness someone decided to go on that website and make everything clickable and everything." Because when you do need to reference one of those elements, it's a godsend being able to go and go, "Yes, here is the page that talks about Lean budgets. I might not agree with everything on it, but it's a really good starting point. It's a really good point of reference to have."
Kit Friend:
Then you've got the others, and I do use SAFE at one end of detail, and even if you're doing SAFE correctly you don't do it by the book and copy and paste, right? And that kind of thing. But there is a lot of detail and a lot of options there. At the other end of the scale you've got things like Less, where it's intentionally about descaling and it intentionally focused on simplicity. Look at the front pages of the website, and on the SAFE website you've got everything. On the Less website it looks like we've done it on a whiteboard, right? And that's intentional, both of them are intentional at the end of the scale. Then we've got Scrum on the scale, which seems to be the new, rising, kind of darling of things at the moment, and that was the other thing. So what I see now-
Nick Muldoon:
And they all have a place, don't they?
Kit Friend:
Yeah.
Nick Muldoon:
It's interesting that there's a large enough audience and market for all of these to succeed, and there's a lot of overlap between them in the various ideals and practices that they suggest that you experiment with.
Kit Friend:
Yeah. I mean what I've seen in the past few years is that I think people often get laudably enthusiastic about the scaling bit. So they take a look at a word like Lean Portfolio Management or a business problem they have of how can I capacity manage? And they go straight to the scaling frameworks without stopping at the teams on the way, and that's definitely a tendency I hear more and more from friends, colleagues, geeky friends, colleagues, clients, right? They don't make that initial investment in getting the teams going well, whether it's Scrum or whether they're running in anything else.
Nick Muldoon:
Sorry. But hang on, are you saying then, Kit, that people are actually coming into a scaled Agile transformation and they haven't got the team maturity? Sorry, forgive me, but I felt I guess my belief and my understanding was that these scaled Agile transformations, for the most part, are building on top of existing successful team transformations.
Kit Friend:
I think that is how it should work right. We should be going bottom up, or at least to a certain extent. In the SAFE implementation roadmap it talks about reaching a tipping point and having... I mean you can start with Waterfall and the SAFE implementation roadmap, but it talks about ad hoc Agile and those things there. I think when people in large businesses and organizations come with a problem though, they're coming with a big problem and they want to fix that, and yeah, it's a difficult message to land, the, "Hi, you've got one to two to five years worth of getting your teams working before you can deploy the fancy portfolio management Kanban and see a flow of things right." Because people are nice. Most people are nice, most people are enthusiastic, most people want to fix things, and so they want to fix that big scaley thing.
Kit Friend:
But it's difficult to land, the, "No, you've got to fix these things at the bottom." I was describing to a colleague, Lucy, last week, and I said, "If you want an answer a question of how do I capacity manage and how do I balance demand across a large organization, you should imagine each of your..." Let's pretend they're Scrum teams without debasing it for a moment. Let's pretend your Scrum team is like a bar with a row of different glassware on it, and each time box is a different sized pint glass or a schooner or whatever you have. Now, my capacity management for a single team is me with a big jug of beer and I've got all the work that I want to do in that beer. My whole backlog of things. My capacity management for a team is pouring it in and hopefully I guess it right. I probably don't and I spill some beer in the first ones as we go through. But over time I'm trying to guess how much beer I can pour into each time box of things and we go through.
Kit Friend:
Now, the only way that I can know how much I can fit in in the future is if I see what I've got in the past, like how it went and can I predict the size of the glass, and over time I can, and we stabilize. So everything's a pint glass after a while, after we've experimented with everything there. Now, if we don't have that ability to forecast and measure, get the actual data back via some tooling at a team level, how can we manage across multiple teams? Right? You can't. You can't have a big top down roadmap where you're like, "Yeah, we want to launch the easy Agile bank across all these areas and go into the teams." Unless you have that team level maths that you can rely on.
Kit Friend:
It doesn't matter whether that's story points or whether you're doing no estimates stuff and you're just measuring flow or you're using Monte Carlo, whatever it is. You need some mathematical way of helping people understand the flow of work and what's happening there, and ideally tying it back to value with some data. Workout whether is your easy Agile bank actually a good idea or should we pivot and do something else? Yeah, is it delivering the thing that customers want when we've given them easy Agile bank beta at the beginning of things.
Nick Muldoon:
How good do you think clients are these days? So here's the thing, I guess, you talk about early transformations and it was, "Hey, we're going to go Scrum." But now there's the design thinking, I mean there's devops, there's DevSecOps, there's so many different aspects now that people are exploring and they're exploring at the same time. How do you help the client navigate this? Because they get it from every different angle from different aspects of the business, and in fact it's just got to be overwhelming, quite frankly.
Kit Friend:
Well, it's overwhelming for us trying to help right, right? People like yourselves, I mean you're like, "How do we cope with this weird specific configuration that they want to feed into easy Agile programs?" So I think that the light at the end of the tunnel that I referenced before is I see a lot more people coming with an ask of helping them get the bottom up things right, so they understand there's a pincer. We can't ignore-
Nick Muldoon:
Get the foundation.
Kit Friend:
Yeah. But we can't ignore that there's the big business, right? There's the people expecting big things and they've drunk the Agile Kool-Aid, they've read the article and they want to be there. So there is that top down pressure, but I am seeing more and more asking for advice and help to do things at the bottom. On a couple of areas recently, my current theory of the day, and I have a favorite theory every six months or so so this won't be the same later in the year, but I really, really like training the product owners first to help with that transformation. My current theory is that it's because they're like the battering ram to help the business understand what's happening with these delivery teams, and build the bridge and link between things and form that.
Kit Friend:
Because if you don't have the product owners being the conduit and the voice of the business and the customer and the voice of the team back to the business in doing things, I think the rest of it falls down. So my theory at the moment is that if you start by training the product owners that's the best way to begin things and it helps with the scaling body scaling, the focus on the team level to help do things.
Kit Friend:
To be honest, even if they're not doing Scrum, I think that the role of a product owner, relatively close to what the Scrum guy says, if we take out the sprint references and things, I think that's a sensible thing to have in every cross functional Agile team, regardless of what you're doing. And it's a distinct personality type, right?
Kit Friend:
I often talk when people are doing our Agile Foundations course, where we're like, "Here's everything. Find your place." I think that most people, or certainly most people I train, fall quite clearly into a product owner or a Scrum Master style personality type. I'd say about 80% you can tell, like, "You're a producty person. You're a Scrum Mastery type person. Or if you're not doing Scrum, a coach, a facilitator, a team builder." Maybe about 20% can flit between the two, and they're special people. The Unicorns as we have in every industry and type, but most people fit into one of those. I think it's good to think about how those personality types work in your business.
Kit Friend:
The other thing I love about training the product owners first, it really unveils upon them that, let's say, we're now at... "Hi, Nick. Yesterday you were the business owner for this process and doing things. You're now a product owner, go. And you can only have till Monday." If we train you, you're like, "Oh my God, I didn't realize I was now accountable for the value of this whole team delivering. It's my problem to make sure they're delivering good things? I didn't know that." So if we do that training right at the beginning I think it sets a baseline of expectations of what we're asking of those people, and the responsibility that's placed on them. Yeah.
Nick Muldoon:
When you're doing this Agile Foundations course that you run for folks through, are you doing a DISK profile as part of that? Again to assess their personality type.
Kit Friend:
No, no. That would be really good. What a great suggestion. I can include that.
Nick Muldoon:
Well, I'm merely inquiring because I wonder. I'm just thinking about it now, I'm wondering, are there personality types that are more likely to be the product owner? Is a product owner more of a CS and is a... Yeah, I don't know.
Kit Friend:
I don't know. I mean it's one of those things, isn't it? I forget the number of personality types and roles I've been assigned in various bits of my career. I can't remember. Back when I was a Student Union Officer, I'll have to look up the name of it, but we had the ones where, "Are you a completer finisher or a shaper?" And all sorts of those things there, and then DISk was relatively popular. We've got a Gallup Strengths Test within the Accenture Performance Management Tool, which is actually really interesting.
Kit Friend:
The bit I like about the Accenture one is when you join a new team you can bunch yourself together in the tool and see what people's different strengths and personality traits are, so you can be like, "This team's very heavy on the woo. Or you're a team that's full of energy or ideas with things, and it's quite interesting too." I mean it's nice to see the strength, but it's also interesting to notice where you might have gaps and you're like, "I need to make sure that someone's keeping an eye on quality because we all get very excited and run fast."
Nick Muldoon:
Do you remember, this would have to be a decade ago now, I'm sure, but I think his name with Larry Macaroni or Larry Macayoni, and he was working for Rally Software at the time, and he did a very wide ranging study of the effectiveness of Agile teams? And I'm just thinking back on that now, because he was looking at things like defect rates, escaped bugs versus captured bugs and all sorts of other bits and pieces. But I don't think he touched on the personality traits of these teams and whether even Dave the Cofounder here at Easy Agile, my business partner, he was talking. He shared a blog article this morning about neurodiverse teams and I'm just trying to think, do we know is there a pattern of DISK profile distribution, neurodiversity distribution, that leads to a more effective team?
Kit Friend:
I don't know. I haven't read. Yeah, it's Larry Maccherone, but it's not spelt the way I suspected originally. I put in Macaroni, based on your pasta based pronunciation of things. So it looks like it's the quantifying the... What's it called? Quantifying the Impact of Agile on Teams, which is really interesting.
Nick Muldoon:But I don't know if that sort of study has been done since he did it back then.
Kit Friend:
Particularly the personality types is interesting, and neurodiversity is another interesting element. So I've got dyslexia and dyscalculia, and one of the bits I've found-
Nick Muldoon:
What's dyscalculia?
Kit Friend:
Well, just like dyslexia, there's quite a spectrum covered by one term of these, so it's large. But effectively my particular diagnosis, I have problems processing sequences of numbers. So you can read me out a sequence of numbers and if it's exactly that, I can cope with it normally because I can do visual processing, because that's my creative industries background, it's what we do, right? We visually process. But I can't repeat them back to you backwards, I can't reprocess them as units of stuff with things. My wife says-
Nick Muldoon:
How did you even come across that?
Kit Friend:
So a retrospective again, so my sister was diagnosed with dyslexia at school, and she's got a more traditional dyslexic diagnosis. So when you hear dyslexia, people normally associate it with not being able to read and spelling and grammar and that kind of stuff. Dyslexia, as you might know from [inaudible 00:35:00] is actually... I'm waiting for them to split it, to be honest with you, because it's so broad. But my diagnosis of dyslexia is more about my short term memory processing, so it's the ability to process. I can read and write fine.
Kit Friend:
My sister got diagnosed at school, had blue glasses, all the conventional grammar and spelling related elements of dyslexia. My dad got diagnosed then in his mid 50s, I think at the time. So he started working at the University Arts London, my art college, my dad still runs the woodwork shop in central St Martins in their beautiful new campus in King's Cross in London. He got diagnosed with things, and I was like, "Hmm. I know it's hereditary, I should probably get checked." So I think I was 25 or 26, and one of the lovely bit... I mean there's many lovely bits about working at Accenture, but a large corporation has really, really good support networks and things.
Kit Friend:
So I pinged the right people around, and they were like, "Yes, of course we can support you getting an assessment. We'd love to make sure that you're able to function." So I got an assessment done and they were like, "Yeah, you're dyslexic and dyscalculic on this kind of area." But the more interesting thing was that they were like, "Here's the coping mechanisms that you've developed." And the coping mechanisms was a list of my career and choices and education. It was like, "You will choose things where you can do abstract thinking and drawing." It was really funny because I never felt like it blocked me at school, I quite enjoyed exams and things.
Kit Friend:
But I was terrible at revising, right? I can't go through notes and do things there. Looking at my diagnosis I was like, "It's because I don't process things that way." I have to process things visually, I have to draw, I have to chunk things. Now I look at the way that I work with Agile teams and I coach teams, and I create abstract references to things, right? I'm teaching product owner and Scrum Master courses on Mural where we move things around and create objects.
Nick Muldoon:
Or the example that you used before, Kit, with the beer glasses at the bar.
Kit Friend:
Yeah. I can't deal with numbers in abstract, right? I have to deal with them in an analogy or I have to be able to visual them. I'm hopeless at coding, I can't store concepts like variables in my head. They just fall apart, it's like building with sand in front of me and it's all dry and crumbly. And I think in fact when I looked at that diagnosis and I was still, what? I'd be like three or four years into my career at Accenture. I looked at the way that I'd begun to get slowly addicted to tools like Atlassian and Dura, and I was like, "Ah, I'm compensating for the fact that I have basically no ability to memorize things in the short term." I'm helping visualize stuff in the way that I help teams and build tasks and things, in a way that means I'm outsourcing my short term memory to this lovely tool where we do things there.
Kit Friend:
Yeah. I've grown to love it, I think you have to work with it right. I speak to some of my colleagues, I teach at the moment with an Agile coach called Lucy Sudderby and another one called Charlotte Blake, and I'm like, "Thank you, guys, for compensating for my dyslexia. I appreciate that you kind of balance out my inability to memorize anything." Yeah, hopefully they feel they benefit from some of the quirky strengths of it when we go through, but it's a balancing act, right?
Nick Muldoon:
That's very cool. Thanks for sharing that.
Kit Friend:
No worries.
Nick Muldoon:
I'm just thinking about it now, as you mentioned coaching with Lucy and Charlotte, and going back to something that you said earlier, Kit, with respect to... I don't know if you said the leaders, but basically the folks at the top drinking the Kool-Aid. I'm interested to know, how do you create, going back to this other thought that you had, I'm trying to connect dots, going back to this other thought that you had right up at the top about the psychological safety, right? And that feeling safe. How do you provide a safe space for these leaders that could be CEOs of business units or execs, GMs, whatever they happen to be, provide a safe space for them to actually ask questions and do Q&A and learn without feeling?
Kit Friend:Yeah. Because we forget that they're people too, right?
Nick Muldoon:
Yeah.
Kit Friend:
There's this idea that these leaders are somehow insurmountable, they have no fear. But we need to build a safe space for everyone around things, I think you're right. I think we get the same sort of question when people talk to me about how they can convert people to Agile or make the case for things in an organization but not sure about it. I think that the answer, relatively saying, in that we need to give them some data, some facts. So my view is that it's not good to come to people and talk about...
Kit Friend:
I somewhat cynically criticize when people talk about Agile ways of working, and they'll often abbreviate it to WAW or something as well. I think when we talk about agility too abstractedly, and I say the phrase wavy hands too much, but when we talk about it within specifics too much, it encourages a sense of anxiety and it's a nebulous, wishy washy kind of thing so I like to bring some data to people. My favorite ones to use, and I need to get updated stats, but the Sandish Chaos Reports are an amazing project management journal, where they talk about success and failure of Waterfall versus Agile projects.
Kit Friend:
Now, there's a bunch of questions it leads you to about how do they classify Agile and all sorts of things. But indisputably, what it tells you is that the traditional way of doing things that we are told is secure and safe, if I go to a procurement team or a finance team and I go, "I'd like to build this thing, guys." They're like, "Great, give me the milestones, give me the plan." And there's this inbuilt assumption that that's a safe and responsible and proven way to do things.
Kit Friend:
The Sandish Chaos Reports tell you it's a terrible way to do things, right? They're like, "Statistically, doesn't matter what you're building, what industry, what you're doing, it's a terrible idea to fix scope at the beginning, trust your plan and have a system which fails when you have any change." And when you unpack it, like when we talk about agility overall, what are we saying? We're saying it's not a good idea to begin something and for it only to be able to succeed within fairly tight boundaries, where no one changes their mind for the duration of the thing, everything goes exactly as you plan and when does that ever happen with technology? And the world doesn't change for the duration of your thing.
Kit Friend:
Most of the time when we're talking about these project things, like how long are they? Three months to three years is the window I usually give. Three months, I see rarely in any industry these days, right? These big efforts where people are trying to do these things at scale, you're talking multiyear. What are the chances that the scope can be frozen for that period? Pretty low, and also what's the chance that the people that you asked for the requirements at the beginning really knew them all? Everyone's normally really nice, they try their best.
Nick Muldoon:The chance that the people you ask at the beginning are going to be there when you actually get to the next-
Kit Friend:
Yeah. There's a whole set of fundamental problems with that. So I like to bring that kind of data to our leaders when they're asking about the case for agility, so it's not about, "Do you want to sign up to use a framework?"
Nick Muldoon:
But let's say, Kit, that they've made the case for agility, they're there, they're doing it. What's the space that you provide for them? Do you have a CEO round table where they can go and they've got a shoulder to cry on and go, "This Agile transformation is going harder than I thought it was going to be"?
Kit Friend:
Agilists Anonymous, [crosstalk 00:42:19] company. Yeah. I think it is a good idea to pair them up, so I get a lot of requests at the moment for us to provide coaches directly to support leaders. I've also seen a trend in reverse mentoring, separately big companies. But that kind of idea of, okay, you've got these people who are really experienced, and their experience is relevant, right? We're not saying that the CEO's 30, 40, 50 year career in something is invalid now and we know better than them. But they're trying to match that up with these, not even emerging, right? Because the Agile Manifest is 20 years old now. But they're trying to match these up with these foreign, new practices and things they've got, and that requires a bit of hand holding. So yes, there's a personal angle there. I don't think necessarily a round table is the way to do it per se, but giving them someone that they can chat too and, yeah, an ability to relate and go like, "What is this thing?" And decode the jog, I think is really useful.
Kit Friend:
So data about success rates is important, right? But the other data that's really important I think to help provide that sense of safety is about value delivery, and this is where I think most people are still having trouble. We've just about got to the point where people can start to attach a concept of benefits and value at the start of things. Now, often that's still too big. We talk about the value of the entire project, can you assign a notion of value to every epic and story in your backlog or whatever units of stuff you're doing?" Probably not, right? Can you do it in a pound or dollar or euro or whatever your local currency is figure? Probably not. But can you even rank them one to 10? Maybe with things.
Kit Friend:
So I think the evolution of OKRs and KPIs coming in, and people starting to internalize that more, offers some hope. It's still relatively immature in most organizations and you're still kind of getting there. I feel like every sort of practice and things, it's probably going to have some misinterpretation, enthusiastic and well meaning interpretation, but you're going to get some people using it somehow to Waterfall things probably in some areas. But bringing that data that gives them some sort of feedback loop that makes sense to those people in those senior positions I think is really powerful. The opposite of this is where they expect to see RAG statuses and milestones and that's the only data they get from their teams, right?
Kit Friend:I sat down with an executive of an organization a few years ago and I was like, "Please invest in your tooling. Please do it." And he's like, "Why would I need to? I have these slides where they tell me green and the dates are there." And I was like, "I love that you're trusting, and I like to trust." The trust in the teams was really, really good. But I knew the teams and I knew they didn't have any tools. It was project managers getting stressed and running around, and then I knew that all the RAG statuses were going to go, "Green, green, green, green. Red." It was the Watermelon Effect that was going to happen, right?
Kit Friend:
So when I see conversations like that happening, I want to empower them. I want to empower them with data and bring those things together. I think that data about why doing Agile is really important, the data about how it's really going on your teams, and the ability to make decisions based on it is really important. There's the Scrumming case study on the Saab Gripen is lovely because they, in one of the articulations, they do the sequence of morning standups and allegedly, according to the case study, I'm pretty sure it's true, they do 7:30 in the morning, which is insane. I don't know why they start at 7:30 in the morning in Sweden, but apparently they start at 7:30 in the morning. But they do a sequence of standups and the idea is by the end of the hour the cascade of standups means that any impediment can reach the executives within the hour and they can fix it.
Kit Friend:
That feeling of connection, that trust in teams and that show of progress, real working things being the way that we communicate that we're making progress, I think that's how we build some safety in and help our leaders do things. Not RAG statuses and milestones and Gantt Charts. They have to have that realness with things, hopefully.
Nick Muldoon:
It's interesting. It makes me think, we did a factory tour recently and it's a factory that makes air conditioning manifolds for commercial buildings, and they actually-
Kit Friend:
What? Why were you touring an air conditioning factory? Were you buying some air conditioning?
Nick Muldoon:
No, no, no. Lean principles, right? You want to see the application of the principle.
Kit Friend:
Wow, you're living it, you're living it. It's wonderful.
Nick Muldoon:
Yeah. So they do breakfast from 6:15 to 6:45 or 6:30, something like that, and then they get going. I think they do their standup at 7:45 after they're actually in the flow, they come together, "Okay, where are we at for today? What are we working on?" Then that rolls up to the ops team and then that rolls up to the leadership team, and then at the end of the day they do their closing huddle for the day, "Hey, have we got all of our tools? Are we back? What are we going on with tomorrow morning?" So it was like the start and the finish of the day and it's really interesting.
Nick Muldoon:
Just thinking about, we introduced an end of day huddle in COVID, when we were all on Zoom all the time, and I think it was very useful. But then of course as we get back into the office, it drops away. It's interesting how things evolved, right?
Kit Friend:
Yeah. And you're the big Head Honcho, right, Nick? I have a worry niggle with end of day meetings, about whether they're for the team they're for people to feel they're across stuff, and I find it interesting because I'm having to take people through practicing for Scrum Master exams and things, lots at the moment, and I really like talking about how standups are for the team. They're for the developers, they're not for the product owner even, they're certainly not for the stakeholders. Now, I consistently see with a lot of these Agile ceremonies, I'm like, "Who's getting the benefit from that meeting? Is it someone getting a status check in or is the team getting it?"
Kit Friend:
And if the team enjoys it, if the team gets something from the end of day huddle and things, I'm cool with it. But sometimes I see things, and the two anti patterns I see with leaders joining, of any level, joining the meeting, so the first is that they use it as like their aeration platform. The team's ready to go with their standup and then the leader of whatever level pops in and he's like, "Team, I've got this update for you." And then it's like 10 minutes of their amazing update and mini vision for the day, and then at the end it's like people are going, "Yeah, now do your standup. Now do the Scrum kind of thing." And then the other thing is that where it becomes like a status check in for stuff, and I'm like, "It's not what it's for, guys. We should be focused on [crosstalk 00:48:57]-"
Nick Muldoon:
We do. So we can get done with 22 people in six to eight minutes.
Kit Friend:
That's slick.
Nick Muldoon:
It's taken time to get here, but what we actually started out asking for was one good thing, and that's typically a family, community thing, what are you going on with today, do you have any blockers? And it's interesting now that we're having this chat, Kit, I do not see blockers come up very often, so I wonder why that is.
Nick Muldoon:
Yeah, anyway. Hey, Kit, I'm conscious of time. I've got one last question for you.
Kit Friend:
Yeah, go for it.Nick Muldoon:
What are you reading at the moment? What books are you reading or have read recently that you'd recommend for the audience to read?
Kit Friend:
Yeah, I'm between businessy books. I need to find a next one. One attribute, and it's probably not my dyslexia, I think it's just because I'm lazy, I'm really bad at reading business books, like serious books with things. So I rely on audiobooks lots to consume meaningful data. I really, really enjoyed listening to Lisa Adkins Coaching Agile Teams audiobook when she released it, because I knew I wasn't going to get through the book and so-
Nick Muldoon:
Did she narrate it?
Kit Friend:
Yeah, which is even better, right?
Nick Muldoon:
Cool, yeah.
Kit Friend:
So lovely to hear from the authors' voices when they're doing things. So I'd really recommend that, and then accompanying it after... I mean either way round, listen to the Women In Agile podcast series on coaching Agile teams, because they talk about each other and there's a whole episode on language, and she talks about how between writing the book and narrating the book, reading it, there was bits of language where she just cringed and she was like, "I can't believe I wrote that." And it really resonates it with me, thinking about my Agile journey and how I would cringe at what I did with teams five, six years ago. As we all do, right? You look back with hindsight.
Kit Friend:
So Coaching Agile Teams is really, really good, and I'd recommend. When [crosstalk 00:50:54]-
Nick Muldoon:
Isn't that beautiful, right? Because if you look back and you cringe, it shows that you've evolved and adapted and you've learned, and you've improved?
Kit Friend:
Oh yeah, if you look back and don't cringe, either you were perfect which is unlikely, right?
Nick Muldoon:
Unlikely. Unlikely.
Kit Friend:[crosstalk 00:51:07] things, or you're oblivious which is more likely. I don't mean you personally, Nick. So Coaching Agile Teams is really good, I still recommend the Whole Time if people are trying to get their head round what it's like to work in Agile, what's there. I used to recommend The Phoenix Project, and then I really enjoyed The Unicorn Project more for filling in a team. Your talking about the air conditioning factory just reminded me because of all the Lean kind of things. I really like that, and I struggle when I explain to people because I'm like, "It's not dry, it's a novel about an Agile transformation, but it's not [crosstalk 00:51:42]
Nick Muldoon:
It's not. I love it. I get up and I read the newspaper, right?
Kit Friend:
Yeah.
Nick Muldoon:
That's my thing in the morning, and I would never read a business book at night. But The Phoenix Project and The Unicorn Project, I've read them several times as bedtime books.
Kit Friend:
Yeah. To your kids, Nick? Do you sit there [crosstalk 00:52:01]
Nick Muldoon:
I will. I'll get there. I'm starting to teach them about Lean principles, build quality in. Yeah.
Kit Friend:
Yeah. If you haven't done it already, getting your kids to story point Lego is really amusing and I've enjoyed a lot. I know it's just like time gym, but I enjoy doing it with my son, Ethan, because you know how difficult it is to get adults to get relative sizing in units, and kids just get it. It's wonderful how they just don't get distracted by the fact that you've got an abstract unit, and they're like, "I get that idea." I got Ethan story pointing in five minutes, I've struggled to get some adults story pointing in like five days and they argue about, "Do you mean it's days, ideal days, hours?" Things.
Kit Friend:
So yeah, Unicorn Project I think are really good. I haven't actually read it all yet, but I do want to read and I recommend the whole time because of a really good podcast, 99 [inaudible 00:52:51] Invisible Women by Caroline Criado Perez. So when we talk about being customer centric and about really knowing who we're providing our products for, I think there's a really powerful story around making sure we understand the data and when we're going through, and Invisible Women has some amazing, horrifying, but amazing stories and bits of data and narrative around it. So I think those would be my three at the moment, three's a good number to ask people to start with, isn't it?
Nick Muldoon:
Okay, cool. Kit, this has been wonderful. My takeaway is I've got to read The Invisible Woman, because I haven't heard that book.Kit Friend:
Invisible Women, there's lots of them is the problem, Nick.
Nick Muldoon:
Invisible Women, okay. Thank you. That's my takeaway that I've got to read. Kit, this has been beautiful, I really enjoyed our chat this morning.
Kit Friend:
It was a pleasure as well. Thank you so much for having me, Nick.
Nick Muldoon:
I hope you have a wonderful day, and I look forward to talking about this journey again. I want to come back and revisit this.
Kit Friend:
Yeah. Let's do a check in. We should do our DISK profiles for the next one maybe, and we can find out maybe I'm meant to be a product owner and you should be, I don't know, you'll be like test lead or something it'll say. I don't know. We'll find out.
Nick Muldoon:
It's beautiful. All right, thanks so much, Kit. Have a wonderful day.
Kit Friend:
And you. Bye now.
PodcastEasy Agile Podcast Ep.8 Gerald Cadden Strategic Advisor & SAFe Program Consultant at Scaled Agile Inc.
Gerald shared that companies often face the same challenges over & over again when it comes to implementing agile, but the real challenge and most crucial is overcoming a fixed mindset.
"Gerald helps massive companies work better together while keeping teams focused on people and on the customer. I'll be revisiting this episode."
Gerald also highlights the difference between consultants & coaches, and the value of having good mentors + more
I loved this episode and know you will too!Be sure to subscribe, enjoy the episode 🎧
Transcript
Sean Blake:
Hello, and welcome to this episode of the Easy Agile Podcast. Sean Blake here with you today. And we've got a great guest for you it's Gerald Cadden a Strategic Advisor and SAFe Program Consultant Trainer at Scaled Agile, Inc. Gerald is an experienced business, an IT professional, Strategic Advisor and Scaled Agile Program Consultant Trainer SPCT at Scaled Agile. Thanks, Gerald. Welcome to the Easy Agile Podcast. It's really great to have you on as a guest today, and thank you for spending a bit of time with us and sharing your expertise with our audience on the Easy Agile Podcast.
Sean Blake:
So I'm really interested and I'm interested in this story that... For all the guests that we have at the podcast, but can you tell me a little bit about your career today? I find that people find their way to these Agile roles or the Agile industry through so many diverse types of jobs in the past. Some people used to be plumbers or tradies, or they worked in finance or in banking. How did you find your way into working at somewhere like Scaled Agile?
Gerald Cadden:
Good morning, Sean. Thanks for having me here guys. I'm very happy to be here with you guys today. Career things are always an interesting question. I'm 53 and so when I look back I wonder how do I get to where I am? And you can often look at just a series of fortunate events. And I worked in retail shoe stores and then I decided to do something in my life. Did an IT diploma then did a degree and I started working in the IT side. I pretty much started as a developer because that was where the money was and so that's where you wanted to go. I didn't stay as a developer long. Okay. All right. I was a terrible developer so I wasn't good at it. It was frustrating.
Gerald Cadden:
I moved into some pre-sales work and that led me to doing business analysis and I really liked the BA work because I got to work with people and see changes. I could work with the developers, still got to work really directly with the customer which was much more interesting for me. So I spent a lot of time in BA doing the development work, doing business process reengineering my transitioned over to rational unified process. When it was around spent countless hours writing use cases doing your mail diagrams, convincing people on how to make the changes on those. And then Agile came along and I had to make a complete brain switch. So all of this stuff that I'd learned and depended on as a BA suddenly disappeared because Agile didn't require that as an upfront way of working. It required that to be in the background if you wanted it and it was more a collaboration.
Gerald Cadden:
So about 2004, 2005 started working with Agile a lot more by this time I was living in the U.S. So that's where I got my agile experience, stayed there for a long time. Got great experience and then I moved over to working with SAFe around 2011. The catalyst for that as I was working for the large financial firm in New York with a team there. And we were redesigning a large methodology for them to implement Agile at scale. Went to a seminar in 2011 at an Agile conference saw Dean Leffingwell presentation on SAFe and just looked up and went, "Well we can stop working on our methodology. It's done."
Gerald Cadden:
So hardly after that meeting I ran outside and tackled Dean Leffingwell because I wanted him to look at my diagrams and everything and give me some affirmation that I was doing the right thing. Dean is got a very frank face and he pulled his frank face and he looked at me and just said, "You know what? Just use SAFe?" And I'm like, "Yeah, we will." And so I started my SAFe journey around that time and we implemented that financial company and I've been on that journey ever since.
Sean Blake:
So take us back 10 years ago to 2011. And you're working at this financial company, you've heard of this concept of SAFe really for the first time you started to implement it. How did the people at that company respond to you bringing in this new way of thinking this new framework? It sounded you already had the diagrams on the frameworks and the concepts forming in your mind did you find that an easy process? I think I already know the answer, but how complex was that to try and introduce SAFe for the first time into an organization of that magnitude?
Gerald Cadden:
Yeah, this is a very large financial firm, a very old financial firm so very traditional ways of working. So what's interesting is the same challenges SAFe comes up against today they're present before SAFe even began. And so the same challenges of the past management approaches trying to move to faster ways of working was still there. So as we were furiously drawing diagrams in Visio, trying to create models for people to understand it was hard to create a continuum of knowledge and education that would get people to move from the mindset they had to the mindset we wanted them to have. And it was an evolving journey for myself and the team that I was working with. I work with a really great guy and his name is Algona, a very, very smart man.
Gerald Cadden:
And so the two of us we're always scratching our heads as to how to get the management to change their minds. And we focused on education, but it was still a big challenge. I finished on the project as they started with SAFe. I moved to different management role in the company that we continued the work there. Michael Stump he used to work for Scaled Agile I think he works now at a different company, but he continued a lot of that work and did a really good job and they did implement SAFe. They made changes, but they faced all the same challenges. The management mindset overcoming moving away from the silos to a more network structured organization. Just the tooling, just the simple things was still a challenge and there's still a challenge today. So the nature of the organization is still evolving even in the modern day Agile world.
Sean Blake:
You mentioned there that part of the challenge is around mindset and education. Have you found any shortcuts into how you change a team's mindset? The way they approach their work, the way that they approach working with other teams in that organization? I assume the factor of success has a lot to do with, has the team changed their mindset on the way they were working before and now committed to this new way of working? And can you talk to us a little bit about how do you go about changing a team's mindset?
Gerald Cadden:
Maybe I'll change the direction of your question here, because what I've found is usually you don't have to work too hard to change the mindset of a team. Most of the teams are really eager to try new things and be innovative. You only come across some people in teams who may be their career path has got them to a certain point where they're happy with the way the world is and they don't want to change. The mindset you really need to change is around that leadership space and that's still true today. So the teams will readily adapt if management can create the environment that allows them to do it and if they can be empowered. But it's really... If you want to enable the team it's getting the leadership around them to change their mindset, to change the structures that are constraining the teams from doing the best job they can.
Gerald Cadden:
And so that for me was the big discovery as you went along and it's still true today. As Agile has been evolving I've noticed that people don't always put leadership at the top of the list of challenges but for me it's always been at that top of the list. A lot of people want to look at leadership and say things about them unflattering things, but you have to remember these are human beings. And the best way to come to leadership is to really begin with a conversation, help them understand. They know the challenges, but we need to help them understand what's causing the issues that are creating those challenges.Gerald Cadden:
As you work with them and educate them you can to open their minds up a little more. Does that mean they'll actually change? Not necessarily. Political motivations, ideologies other things constrained leadership from moving. But conversations and education I think are the way to really approach leadership. And getting to know them as a person, take an interest in their challenges, take an interest in them as an individual. So create that social bond is an important thing. As a consultant that was always hard to do because as a consultant you're always seen as an external force and it's hard to build that somewhat social relationship with that leadership and build that trust.
Sean Blake:
Yeah, that's so true. Isn't it. I remember on an Agile transformation that I was on previously, how Agile coach really would spend just as much time with the leadership team as they would with us the Agile team. And it seems strange that the coach was spending so much time trying to really coach the leadership team on how they should think about this new way of working, but you put it in the right context there it's so important that they create that environment for their people and for their teams to feel safe in trying something new. Yeah, that's really important.
Gerald Cadden:
I think if you looked at how Agile evolves, when you look at the creation of the Agile manifesto and its principles and then the following frameworks like ScrumXP, et cetera it evolved from a team perspective. So everybody made the assumption that we needed to create these things for the teams to follow, but as people worked with teams they found that it wasn't the teams at all the teams adapt, but the management and the structures of the organizations are not adapting. And so that's really where it went.
Gerald Cadden:
I can't recall the number of countless Scrum implementations you worked on and you just hit that ceiling of organizational challenges. And it was always very frustrating for the teams. I think there's a an opposite side to that too is that too many in the Agile world just look at the teams as the center of the world and you can't approach it from that way either the teams are very important to delivering value to the customers, but it's the organization as a whole that delivers value. And I think you really have to sit back and just say, "The teams are part of that how do we change the organization inclusive of the teams?"
Sean Blake:
Okay. That's really interesting. Gerald, you've spoken a bit about teams and mindset, when you go into an organization, a big auto manufacturer or a big airline or a financial services company and they're asking for your help, or they're asking for your training, how do you assess where that organization is up to? What's their level of maturity from an Agile point of view? Do you have organizations that are coming to you who have in their mind that they're ready to go SAFe and then you turn up on day one and it turns out no one has any real idea about what that type of commitment looks like?
Gerald Cadden:
Yeah, it's a good question. Because I think as I look back at the history of this, in 2011, 2012 when SAFe really got going, as you went forward I mean, there was no concept of where to begin. Consultants were just figuring it out for themselves and like most consulting or most methodologies they got engaged in an IT space and at the team level. And people would try to grow from the team level upwards. And at some point we need to know I've struggled a lot with this because I was just trying to figure out where it is that. So my consulting hat was always on to sit down, talk to people about their challenges, find a way to help figure out how to solve the challenges whether it was going to be Scrum or SAFe or whatever is going to be right.
Gerald Cadden:
Those are just tools in the toolbox. But when Scaled Agile as I was working with... Excuse me, as I was working with SAFe, Scaled Agile brought out the implementation roadmap. It produced so much more clarity that came later in my time with SAFe and I wish it had come earlier because it really began to help me clarify that initial thing that we call getting over the tipping point. How to work with the organization you're talking to, work with the right people, understand their challenges, help them understand what causes those problems, which is the more traditional ways of working the traditional management mindset, help them connect SAFe as a way to overcome those challenges and begin to show them. If you looked at the roadmap it's this contiguous step-by-step thing, but what you find in reality is there are gaps between those steps and in those gaps is the time you as a transitional team are having lots of conversation with the management.
Gerald Cadden:
If you put them through a training class they're not going to come out of the class going, "Oh, wow that's it. We know what to do." It takes follow-up conversation. You have to have one-on-ones one on many conversations, cover topics of gains so you can remove the assumptions or sorry the misassumptions. So it's a lot of that kind of work that the roadmap its there for those who are implementing SAFe today use it. It is one of the most helpful tools you'll have.
Sean Blake:
Awesome. Yeah. I think just acknowledging the difference between the tools in the toolbox and then the other fact that you're dealing with humans and you're dealing with attitudes and motivations and behaviors and habits there's two very different things there really. It sounds you need to take them all together on that journey.
Gerald Cadden:
Yeah. A side to that we train so many SPCs like SAFe program consultants. We train them, training them out of classes all the time with us and our partners. The thing that you can, you can teach them about the framework, but you can't necessarily teach them how to be a good consultant or a good... I want to say I use the term consultant and coach, right?
Sean Blake:
Yes.
Gerald Cadden:
Sometimes I like to say a good consultant can be a good coach, but a good coach can't necessarily be a good consultant because there's another world of knowledge you need to have like how do you sit down and talk to executives? How do you learn the patients and the kinds of questions you need to ask, how do you learn to build those relationships and understand how to work the politics? So there are things outside the knowledge of an SPC that they need to gain. So young people coming in and running to do this SPC course I want to prepare you for everything, but it gives you the foundations.
Sean Blake:
So when you're in a organization or you're coaching people to go back to their organization how do you teach them those coaching skills so that when they come in and they've got to learn the politics, they've got to identify the red flags, they've got to manage the dependencies, they've got to bring new teams onto the train. How do you go about equipping that more human and communications of the toolbox really?
Gerald Cadden:I think you can obviously teach the fundamentals of the framework by running through the training courses. But mentoring for me is the way to go. Every time I teach a training class I make it very clear to people when they go back and they're starting a transformation don't go this alone. Find experienced people that have done this and the experience shouldn't just be with SAFe their experience should be having worked with large organizations having experience with the portfolio level if necessary. Simply because there are skills that people develop over years of their career if they don't have at the beginning.
Gerald Cadden:
I mean, if I look back at some of the horrific things I had said in meetings and in front of executives my boss would put his hands up in front of his face because I was young and impulsive and immature and I see that today. So when I first came to the U.S I worked with some younger BAs and they would say things in a meetings and you quickly have to dance around some things to, "We didn't really want to say that right now." So I think mentoring is the skill. We can teach you the tactical skills, but teaching you the political skills, the human skills is something that takes mentoring and time.
Sean Blake:
Mentoring so important in that context. Isn't it?
Gerald Cadden:
Yeah.
Sean Blake:
Okay. So let's rewind 12 months ago to March 2020, a month that's probably burned into a lot of people's mind is the month that COVID changed our lives for the foreseeable future. I know that Easy Agile had a lot of content out there, articles about how to do remote PI Planning, how to help your virtual teams work better together and we didn't know that COVID was coming we just saw this trend happening in the workforce and we had this content available.
Sean Blake:
And then I was checking out our website analytics and we had this huge spike in what I assume were people in these companies trying to work out for the first time, how to do PI Planning virtually, how to keep very literally their release trains on the tracks in a time where people were either leaving the state, working from home for the first time, it's really like someone dropped the bomb in the middle of these release trains and people scrambling on how we are we going to do this virtually now? Did you have a lot of questions at the time on how are we going to do this? And how have you seen companies respond to those challenges?
Gerald Cadden:
Yeah. I remember being in Boulder, Colorado in January of 2020 and I just come back from vacation in Australia and that's when COVID was coming around and you were hearing about things in January, 2020. I was talking with my colleagues and we were wondering how bad this is going to be within two months the world was falling apart. And for us I think a good way to tell that story is to look at what Scaled Agile did. We knew our business that it was very reliant on our partner success and it still is today. And so as we began to see the physical world of PI Planning and training, as we began to see that completely falling apart the company had to quickly adapt.
Gerald Cadden:
We already had a set of priorities set for the PI and we implement Scaled Agile internally in the company. At the time we're running the company as a train itself because it's 170 all people. So they had to reprioritize the different epics, we pushed a new features and it was all about what do we need to change now to keep our partners afloat by getting them online and a really good team at Scaled Agile in a really cross-company effort to get short-term online materials created to keep the partners upright so they could keep teaching. They could find ways to do this, to do PI Planning, to do they're inspecting adapts all online. And so we pushed out a lot of material just simply in the form of PowerPoint slides that they could then incorporate into tools like Mural, Al tool. SAFe collaborate we went about developing this and we've been maturing that over time.
Gerald Cadden:
And so now we're in a world where we have a lot more stability. We saw a big dip like everybody else, but the question is, are you going to come out of that dip? And so what we did notice within probably even the second quarter of that year where the tail end of it we saw it starting to come up again, which our partners starting to teach more online. So the numbers told us that the materials we're producing were working. So for us it was just a great affirmation that organizing yourself the way we did organize yourself, the quick way we could adapt saved us. So Scaled Agile could have gone the way of a lot of companies and not being able to survive because our partners wouldn't have survived. We had the ability to adapt. So it's a great success story from my perspective.
Sean Blake:
Well, that's great. We're all glad you're still around to tell the story.
Gerald Cadden:
Yes we are.
Sean Blake:
And Gerald, whether you're reflecting on companies you've worked with in the past, or maybe even that internal Scaled Agile example you just touched on. Are there specific meetings or ceremonies or checking points that are really important as part of the Agile release train process? What are the things that really for you are mandatory or the most important elements that company should really hold onto during that really set up stage of trying to move towards the Scaled Agile approach?
Gerald Cadden:
So I interpret your question correctly. I think for me when you're implementing the really important things to focus on as a team first of all is the PI Planning. That is the number one thing. It's the first one people want to change because it's two days long and everybody has to come and it can cost companies a quite a significant sum of money to run that every 10 to 12 weeks. And so you will run very quickly as I had in the past in the car company you run very quickly into the financial controller who wants to understand why you're spending $40,000 a quarter on a big two-day meeting. And so they lie, they start questioning every item on the bill, but that's the most significant one.
Gerald Cadden:
PI Planning is significant. The inspect and adapt is the other one simply because at the end if you remove that feedback cycle, what we call closing the loop if you remove that then we have no opportunities to improve. So those two events themselves create the bookends what we get started with and how we close the loop, but there are smaller events that happen in between the team events are obviously all important. But more significant for me is the constant, the event for the product management team or program management team how are you going to filter them, excuse me.
Gerald Cadden:
Who are going to need to get together on a regular basis to ensure that then we call this the Sync. So this is the ART Sync or the POPM Sync. You need to make sure those are happening because those are these more dynamic feedback loops and ensure the progress of good architectural requirements or good features coming through so that when you get to PI Planning the teams have significant things to work on. So if you had to give me my top three events, PI Planning, inspect and adapt, and the ART Sync and product POPM Sync.
Sean Blake:
Awesome. I know there's always that temptation for teams to find the shortcuts and define the workarounds where they don't have to do certain meetings or certain check-ins, but in terms of communication it must be terribly important for these teams to make sure they're still communicating and they don't use the framework as an excuse to stop meeting together and to stop collaborating.
Gerald Cadden:
Yeah. I mean, I went through when I started implementing at the large car company in the U.S I decided to rip the bandaid off. They had several teams working on projects and they weren't doing well, when I looked at the challenges and decided we're going to implement SAFe some of the management they were, "Are you crazy? Why would you do this?" But they trusted me. And so we did rip the bandaid off and we formed them all into a not. We launched set up. And I remember at the end of the PIs some of the management have had a lot of doubts that were coming up after they sat through the PI and they said they just couldn't believe how great that was.
Gerald Cadden:
Even though the first PI was a little chaotic they understood the work and the collaboration, the alignment, just the discussions that took place were far more powerful for them. And teams were happier, they were walking out to a different environment. So it changed the mood a great deal. So I think the teams their ability to be heard in one of the most significant places is during PI Planning, they get that chance to be heard. They get that chance to participate rather than just be at the end where they're told what to do.
Sean Blake:
Mm-hmm (affirmative). So it really empowers the team.
Gerald Cadden:
Yeah. Absolutely.
Sean Blake:
That's great. So as a company moves out of the implementation phase and becomes a little bit more used to the way of doing things what's the best way for them to go about communicating that progress to the wider organization and then really evangelizing this way of working to try and get more teams on board and more Agile release trains set up so that it's really a whole company approach.
Gerald Cadden:
Yeah. A good question. So I think first of all the system demo that we do. So the regular system demos that take place, this is an event where you can invite people to. So when you get to the end of the program increment, the 10, 12, or the eight, 10 or 12 weeks and you're doing your PI system demo that's a chance for you to invite people that may be in the organization who are next on the list and they're going to be doing this, or they're curious, or if you have external suppliers who you're trying to get on board as part of the training have them come. Have them come to these events so they can just participate. They can see what goes on and it takes away some of the fear of what that stuff is. It gives them work much.
Gerald Cadden:
So the system demo whether you do it during the PI, but definitely the PI system demo and you want that one. So more ad hoc things and one of the things that I've seen organizations really fail to do is when they're having success the leadership around the train need to go out and I hate the term evangelize, but go out and show the successes. Get out and talk about this at the next company meeting present where they were and where they are now. But as part of that don't share just the metrics that show greater delivery of value show the human metrics, show how the team went from maybe a certain level of disgruntlement to maybe feeling happier and getting better feedback, show with how the business and technology have come closer together because they're able to collaborate and actually produce value together rather than being at odds because the system makes them at odds.
Sean Blake:Awesome. Gerald is there anything else you'd like to share with our audience before we wrap up the episode? Any tips or words of encouragement, or perhaps some advice for those who are considering scaling up their Agile teams.
Gerald Cadden:
I think that the one piece of advice again, I'll reiterate back to the earlier point I made is as you are going through the implementation process and you're starting to launch your train and train your teams figure out how you're going to support them when you launch. Putting people through an SPC class or through all the other classes they won't come out safe geniuses. They'll have knowledge and they'll have the enthusiasm and have some trepidation as well, but you need good coaching. So figure out as you're beginning the implementation pattern where you're designing the teams et cetera, figure out what your coaching pattern is going to be. Hire the people with the knowledge and the experience work with a partner for the knowledge and experience. They shouldn't stay there forever if you work with consultants.
Gerald Cadden:
Their job should be to come in and empower you not to stay there permanently, but without that coaching and coaching over a couple of PIs your teams tend to run into problems and go backwards. So to keep that momentum moving forward for me it's figure out the coaching pattern. The only other one I would say too is make sure that you get good collaboration between product and the people who are going to be the product management role on architecture, get rid of the grievances, have them work together because those can stifle you. Get in and talk about the environments before you launch. You don't want funny problems when you, "Oh, the architecture is terrible." Okay. Let's talk about that before we launch." So just a couple of things that I think are really important things to focus on before you launch the train.
Sean Blake:
Awesome. I really appreciate that Gerald. I've actually learned a lot in our chat around. It's the same challenges that you had 10 years ago it's the same challenges that we have today. The really the COVID is the challenge of how do you focus on the mindset change. We've talked about the teams are eager to change. There might be a few grumbly voices along the way, but really it's about leadership providing a welcoming and safe environment to foster that change and the difference between being a coach and a consultant, the importance of mentoring. Wow we actually covered a lot of ground didn't we?
Gerald Cadden:
I may get some hate mail for that comment, but...
Sean Blake:
Oh, we'll see. Time will tell. Thanks so much Gerald for joining us on the Easy Agile Podcast. And we appreciate you sharing your expertise with us and the audience for the podcast. Thanks for having you.
Gerald Cadden:
Happy to do it anytime. Thanks for having me here today.
Sean Blake:
Thanks Gerald.