Easy Agile Podcast Ep.4 Em Campbell-Pretty, CEO & Managing Director at Pretty Agile
"We spoke in detail about scaling agile, being a SAFe fellow, discipline, the traits of effective leaders and how to trust your people."
Transcript
Nick Muldoon:
Good day, folks. Thanks for joining us for another Easy Agile Podcast. This morning, I'm joined by Em Campbell-Pretty of Pretty Agile. Em is one of 22 SAFe fellows globally and she's been doing agile transformations at scale for over a decade now. She's also the author of two books, The Art of Avoiding a Train Wreck and Tribal Unity. So, all about culture and psychological safety here, and all about obviously scaling agile release trains, tips and tricks.
Nick Muldoon:
My key takeaways that I was really jazzed about, the traits of effective leaders for scaling agile transformations and being an effective organization, trust, as in trusting their people, an openness to learning and a willingness to learn, the ability to experiment and treat things as failures if they are failures, and discipline. Em and I talked a bit about discipline today as a trait of leaders. It's a really great episode and I took a lot from it, and you'll hear my takeaways at the end and what I need to go and learn after some time with Em this morning. So, let's get started. How many weeks a year are you typically on the road?
Em Campbell-Pretty:
How many weeks a year am I typically on the road? A lot, most. It would be unusual for me to spend four weeks without going somewhere. That would be unusual. I don't travel every week, but I travel most weeks, and I travel in big blocks. Right? So, I'll go and do ... Like I said, just before the lockdown, we did three weeks in Auckland, so that was in February-March.
Em Campbell-Pretty:
We went to Auckland, we had a client in Auckland, we just stayed there. So, three weeks in Auckland, came back here, and did not return to Auckland. Returned to support that client virtually over Teams and Zoom was how that one went. But yeah. Normally between running around Australia, Southeast Asia, Hong Kong, Singapore, Manila, the US, New Zealand, yeah, not home that often, normally. This has been truly bizarre.
Nick Muldoon:
So, this is a very unusual year for someone like yourself that's flying around visiting clients all over the world.
Em Campbell-Pretty:
Absolutely. Absolutely. It's been a very strange year. It's an interesting difference on energy as well. Not flying all the time I think is good for my body. I feel the difference. I also feel the difference sitting in a chair all the time. So, I was traveling a lot, but I was on my feet most days when I was working. Now if I'm working, I'm sitting a lot.
Nick Muldoon:
You're sitting down. Yeah.
Em Campbell-Pretty:
So, that's interesting. But I don't miss the jet lag at all. I don't miss the amount of time the travel consumes at all. In fact, it's been nice. I've had a little bit of head space. I've probably blogged more this year than I have in a few years because I've just had some head space and being able to think. But I don't get to see the world either, and all my holidays got canceled. So, nevermind work. I had trips to Europe. Four weeks from now, I was supposed to be in Canada seeing polar bears.
Nick Muldoon:
Aw.
Em Campbell-Pretty:
Tell me about it!
Nick Muldoon:
I would love to see polar bears. They look so cuddly on TV. I'm not sure that that would actually be the circumstance if I was to try to approach one and give one a cuddle.
Em Campbell-Pretty:
Yeah. I don't think cuddling was involved. I was told I could bring a camera and a tripod, which means obviously I'm going to stand some distance away from this polar bear and take photos. But that will not be happening either. So, no holidays and no travel for work, and of course, being in Melbourne, not even any, let's just go to [crosstalk 00:04:15].
Nick Muldoon:
Coffee or anything like that.
Em Campbell-Pretty:
Just nothing.
Nick Muldoon:
Nothing.
Em Campbell-Pretty:
Nothing.
Nick Muldoon:
Yeah, because you've been on legit lockdown.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
So, tell me then about the shift over the last 10 or 15 years in these scaled, agile transformations. Obviously today, like you described with this client in Auckland, everything's got to be remote. Presumably, not as effective. But I'd love to get a sense of what the evolution is from the transformations 10 years ago, banking, telcos, that sort of environment to the clients that you're working with today. Describe what it was like 10 years ago.
Em Campbell-Pretty:
So, 10 years ago, and it's so interesting to reflect on this now, I read Scaling Software Agility, which is a book that Dean published in 2007. Then I discovered that wasn't the latest book, so then I read Agile Software Requirements. This was 2011. I'm this crazy, angry business sponsor with this program of work I'd been sponsoring for five years that's never delivered anything, and in this cra-
Nick Muldoon:
You were the crazy, angry business sponsor?
Em Campbell-Pretty:
Yeah. Yeah, yeah. I was the crazy [inaudible 00:05:26]. I was very angry. You would be angry too if you were me. I refer to it now as the money fire. So, basically, here's my job. Right? Go to the CFO, ask for money. Give the money to IT. IT lights a match, sets it on fire. Comes back, asks me for money. I get to go back to the CFO and say I need more money. Five years. Five years. That's all I did. Ask for money and try to explain where the other money went.
Em Campbell-Pretty:
Anyway, in the strangest restructure ever, I end up the technology GM for the same group I had been the business sponsor of for the past five years. Apparently, they couldn't find anybody appropriately qualified. So, you can do it, Em. Sure. So, I'm a bit of a geek, so I read books, and I'm reading these books by Leffingwell because I'd been doing some agile ... So, I'd been doing something I'd been calling agile. Let's just go with that.
Em Campbell-Pretty:
It was interesting to me because I could see little rays of light. But it still wasn't really making anything happen, so hence the reading. These books talk about this agile release train [inaudible 00:06:46] that sounds cool. We should so do this thing. So, I set about launching this train at a Telstra in early 2012. It wasn't called SAFe, right? It was just the books and these things called an agile release train.
Em Campbell-Pretty:
Now, to look back 10 years ago, it wasn't called SAFe. People weren't running around doing this. I was not actually really qualified for the job I was in. Well, I wasn't a technology leader by any stretch of the imagination, and I decide that I'm just going to launch an agile release train. So, there were rare and unusual beasts, and I'm not sure I really understood that when I went down the path of doing it.
Em Campbell-Pretty:
I'm big on the, I read it in a book, I read it in a blog, I heard it at a conference, I'll just try it. That's very much always been my mental model. So, I read it in a book and I just tried it. Then we discover that actually, literally nobody is doing this, so it becomes Australia's first agile release train and Australia's first SAFe implementation. Oh, boy, have I learned a lot since then.
Nick Muldoon:
Well, yeah. I was reflecting on that because I dug out The Art of Avoiding a Train Wreck, right? This is one of the ones that you signed for Tegan. But obviously, you've learned a ton since then because you've managed to put together a tome of tips and tricks and things to avoid as you are pursuing these transformations. As an industry, though, well, as an industry, I guess this spans many industries, but as a practice these days, are we actually getting better at these transformations? Are there companies out there today, Em, that are still taking piles of money and setting it on fire?
Em Campbell-Pretty:
So, I think I meet people every day who hear my story and go, "Oh, my god. You used to work here?" So, I think there's still many, many organizations that have an experience that is like the experience I had back in 2010 and what have you. So, it seems to be something that really resonates with people. I guess so many of the businesses we go into now either are not agile at all or, I guess like my world was, doing something they call agile. What we find is the something that they call agile, I wouldn't say it's not agile. But it leaves a lot to be desired.
Nick Muldoon:
They're on a journey, right?
Em Campbell-Pretty:
Yeah. Yeah. Well, I guess so because they end up having a conversation with us. So, they understand that what they're doing is not enough. They understand that what they're doing isn't getting them the results that they want. I don't know that they understand why. It's interesting to me sometimes that they look to SAFe because you asked me about how's the client base changed? One of the things that's really interesting in Australia is we get far more of the small to medium sized companies now than the big ones.
Em Campbell-Pretty:
So, they're companies that consider themselves agile. But what we're calling them, the startups that are no longer startups, right? These are organizations that they're generally old 10, 20 year old startups and they're scaling and they see their problem as a scaling problem. So, that's what leads them to a conversation around the scaled agile framework.
Em Campbell-Pretty:
When we look at them through a SAFe lens, we go, "Gee, you're tiny. But okay. I can see that you can have an agile release train and it won't do you any harm. In fact, it would probably help you a lot in terms of mid-range planning," because mid-range planning just seems to be nonexistent for a lot of these organizations. Prioritization. A lot of these small organizations, very knee-jerky in terms of how they prioritize, bouncing from one thing to the other.
Nick Muldoon:
Are they reacting to the market, or are they reacting to the leaders, maybe the lack of discipline in the leadership?
Em Campbell-Pretty:
You know what? They would say they're reacting to the market. I would say they've got a discipline issue.
Nick Muldoon:
Yeah. [crosstalk 00:11:23].
Em Campbell-Pretty:
So, I read, obviously, big reader, last summer, obviously Australian summer, US winter, I read Melissa Perry's The Build Trap. Interesting book and your well respected thought leader in product management. Not a big fan of SAFe. Probably not a big fan of agile either was the takeaway I had from her book. But the thing that she does talk about that I really thought was valuable was the lunacy in chasing your competitors. So, building features because your competitors-
Nick Muldoon:
Your competitors [crosstalk 00:12:06].
Em Campbell-Pretty:
... build them, or building features to land a contract or retain a customer. So, I thought she sees all of that as lunacy, and I tend to agree. So, that was my ... I think that's quite interesting. Her perspective is you don't know if the competitor's actually having any luck with that thing that they've built. So, if you build it because they built it, you don't know. You have no idea. So, don't just build it because they've built it. It might not be doing them any favors either.
Em Campbell-Pretty:
Of course, once you start just doing random stuff for this big customer or this big client, you start to lose your way as an organization. People end up with completely different versions of their products, branches that they can't integrate anymore. It's interesting. So, when I look at that, I go, "I feel like there's a discipline issue in some of these organizations at the leadership level."
Em Campbell-Pretty:
What is it we're trying to do? What is our vision? What is our mission? What is our market? What are we doing to test and learn in that market, as opposed to just get a gun, let's do everything, grab everything? Oh, my goodness. They were doing that over there. Stop this, start this, stop this. Of course, if you're stopping and starting all the time, you're not delivering anything, and that seems to be something that we see a lot with these organizations. They're not delivering.
Em Campbell-Pretty:
I'm not saying their delivery mechanism is perfect. There's challenges there too. But some part of the problem is the inability to stay a course. Pick a course and stay a course. I'm not saying don't pivot, because that's stupid too. But being more deliberate in your choices to pivot, perhaps. Yeah.
Nick Muldoon:
Do you get a sense, Em, that there are leadership teams in various geographic regions that are more effective at this and more effective at that longterm planning and having that discipline and that methodical approach to delivery over an extended time period?
Em Campbell-Pretty:
I think regions and cultures and nationalities certainly play a role in the leadership, I don't know, persona, personality. I don't know that I could say when I've worked in this country or this part of the world that their leaders are better at forethought. I think some cultures lend themselves to lean and agile more than others. Hierarchical cultures are really, really challenging.
Em Campbell-Pretty:
That can be both a geographic thing, but it can also just be an industry thing, right? So, government can be very hierarchical. The banks can be very hierarchical. Some of the Asian cultures are very hierarchical. But some companies are just very hierarchical as well. So, who owns the company, who leads the company, all of that can play a big role in what's acceptable because so much of success in this scaled agile journey comes down to a leadership that is willing to trust the teams, a leadership that is willing to learn, a leadership that's willing to experiment, and a leadership that's prepared to be disciplined.
Nick Muldoon:
So, leadership with trusting the teams, willing to learn, willing to experiment, and with discipline. They're those four things that you-
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah, okay. I'll make a note of those, Em. I'll come back to those. Trust, learn, experiment, and discipline. I'm interested, I guess, this year being a very interesting, a very unique year for doing remote transformation work and coaching and consulting, 10 years ago, what was the percentage of remote team members distributed teams? Now, you've basically, I think the big banks in Australia aren't even going back to the office until 2021. Atlassian is not going back to the office until 2021. Twitter, Jack Dorsey, my old CEO, said, "Work from home forever," sort of thing. What's the takeaway for this year and what do you expect for 2021 and beyond?
Em Campbell-Pretty:
So, look. This year has been eyeopening, and look, some things are, as I would have anticipated, some things have been different. So, obviously, we're seeing entire organizations going online. We're seeing the teams are online, the PI planning's online, everything's online. That's actually in some ways opened up opportunity. So, where we've had clients who have had the most odd setups in terms of distribution, and you can make a train work where you've got teams across two locations. But we're big fans of the entire team is in Sydney or the entire team is in India. We don't have half the team in Sydney and half the team in India.
Em Campbell-Pretty:
But organizations really struggle with that because perhaps all the testers are in India and then you want a tester on every team and now you've got a problem. How do you create a complete team and not cross the time zones? So, the opportunity becomes if I can find teams that are not physically co-located but time zone friendly, I have a little bit more option. So, I can have a train that operates between, I don't know, Sydney and India. Or I can find a four hour overlap in their day, and I can insist that that team works 100% online.
Em Campbell-Pretty:
So, the big thing that we'd advise against is I don't want that team hybrid. Right? I don't want three people sitting in the office in Sydney and three people sitting in their homes in India. I want everybody online. I want an even playing field, and I think we can do that now in a way that is more acceptable than before. Because the same advice I was giving, gee, back when I wrote Tribal Unity, same advice. Right?
Em Campbell-Pretty:
So, 2016, everybody, equal playing field. If you're going to be distributed, everyone has to be online, as opposed to some people online and some people in a room. So, that's a more acceptable answer now than it was prior to this year. So, that's good. I think that's good.
Nick Muldoon:
In 2021, then, Em, you mean this is just going to play forward. I guess there's going to be a reversion of some of these companies back to the office because they've got huge real estate and workplace infrastructure already.
Em Campbell-Pretty:
Yeah. So, look. We're seeing clients closing offices the same way that you see some of the companies in the US doing that. We're also seeing parts of Australia and New Zealand with no particular COVID impact at this point actually going back into the office, and having created that example of teams that are crossing time zones, and then going back into the office and going back to that hybrid space. So, that's interesting and [crosstalk 00:20:08].
Nick Muldoon:
So, where you're back into that environment where you might have some people working together in an office that can get a cup of coffee together and then some that are stuck still at home. I guess there's not just even regional differences, right? If you've got a team member that's got a particular health situation, they're not going to feel comfortable necessarily coming back into the office, regardless of the situation, until there's a vaccine or something.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Yeah, okay.
Em Campbell-Pretty:
So, yeah. Look, I think it's going to be interesting. I would strongly advocate that organizations have teams that are either in person teams or online teams, and the team just either operates 100% online or the team operates 100%-
Nick Muldoon:
In the office.
Em Campbell-Pretty:
... in person and in the office, and if you have a train that has both in any train level ceremony, everybody goes to a desk and-
Nick Muldoon:
And do it online.
Em Campbell-Pretty:
... a video camera and we do it that way. I think the thing that seems to be most sticky about the physical environment and SAFe is PI planning. Nobody needs to beat. Right? That was cool. Nobody needs to beat, no one's PI planning slipped, everybody just went. They were all online. So, we'll just PI plan online. It'll be fine. We saw people use whatever infrastructure they had available to them.
Nick Muldoon:
Yeah. [crosstalk 00:21:30].
Em Campbell-Pretty:
So, I'm sure a number of people called you folks and said, "We need a tool." But some just went, "We have Google Suite, we have Microsoft whatever it is, we have this, we have that. We're just going to make it work," and no matter what they used, they made it work and they ran the events and their events were effective and they got the outcomes. The big thing that is missing is that energy. You can't get the energy of 100, 200 people in a room from an online event. But mechanically-
Nick Muldoon:
We can achieve it.
Em Campbell-Pretty:
... we can achieve it. So, we hear everybody wants to go back to PI planning in person because of the social, because of the energy, which I think is awesome. I absolutely think that is awesome, and I can see this world in which people do a lot more work from home, work remote, whatever that looks like, and then the PI planning events are the things that we do to bring ourselves together and reconnect on that eight, 10, 12 week basis. That's my feeling. Could be wrong.
Nick Muldoon:
I guess I'll be really interested to see how it plays out, and I think we should return to this conversation in 12 months, Em.
Em Campbell-Pretty:
Yeah. Oh, no.
Nick Muldoon:
I'm just thinking, what's going through my mind is one of our customers in New York, financial services company, and for one of their arts, it was 150,000 US exercised to bring their people together once a quarter.
Em Campbell-Pretty:
Yeah. Wow.
Nick Muldoon:
I'm now going, I'm like, "Okay, yes, they're doing it digitally now." That's fine. They're going to miss out on things. But if they lose the budget, do they have to fight to get the budget back? Or does the budget sit there? There's these other unknown ramifications of this shift over the course of 2020 that we're yet to see play out, I guess.
Em Campbell-Pretty:
I think you're right, and I think it would be particularly interesting for the trains that have been launched remotely. So, if the train has been launched remotely, do you ev-
Nick Muldoon:
So, not existing trains that have been working together for six to 12, 18 months. But you want to get a brand new train started. Have you done that remotely this year with some of your clients?
Em Campbell-Pretty:
Oh, we're in the process of doing it now.
Nick Muldoon:
Cool. Tell me.
Em Campbell-Pretty:
We had one, though, literally just before the lockdown. So, they did their first PI planning face to face and then immediately moved to remote working and, yeah, now working on remotely launching a train. For us, we have a playbook. It's a bunch of workshops. It's a bunch of classes. We just use online collaboration tools. We've found things that replicate the sort of tools that we would have in a physical room, and the joy of being able to read people's Post-it notes, right? This has been the absolute highlight for me, the joy of being able to read people's Post-it notes.
Nick Muldoon:
No more hieroglyphics.
Em Campbell-Pretty:
Yeah. Absolutely.
Nick Muldoon:
What is that that you wrote, Sally? Yeah.
Em Campbell-Pretty:
Everyone can say everything at once, right? So, you think about the classroom and the workshop where there's a group of people huddled around Post-its and a flip chart paper and they're still huddled in a way in their virtual huddle, but everybody can read, right? It's not that I'm not close enough, I can't read, I can't read your handwriting. There's this great equalizer is the online world. So, I think that's great. I think the challenge for the trains launched remotely is going to be do you ever get the face to face experience?
Em Campbell-Pretty:
Because if I go back over the years, one of the things we know is your first PI planning event sets the standard. So, people get this imprint in their heads of what is possible. For example, if you skip something in your first PI planning event, you just decide to, I don't know, skip the confidence vote or something weird like that, you don't do the roam of the risks or you just skip something, you never do it because you're successful without it.
Nick Muldoon:
It never gets picked up. Yeah, okay.
Em Campbell-Pretty:
You're successful without it. So, every compromise you make, and you make a series of compromises, and then you're successful despite those compromises, and that becomes a false positive feasibility. It tells you, yes, I was right. I was right.
Nick Muldoon:
I don't need to do that.
Em Campbell-Pretty:
I didn't need to do those things because I was awesomely successful and I didn't do these things. So, it's the learning [crosstalk 00:26:15]-
Nick Muldoon:
That's confirmation bias, is it?
Em Campbell-Pretty:
Yeah, that's it. That's the one. Confirmation bias. That's exactly it. Yep. Yeah, and I think there's going to be a bunch of confirmation bias in these remotely launched trains, and unless they're inside organizations where there's enough knowledge of SAFe and the physical PI planning to know that there's going to be value in bringing them together, but I can see that being a real challenge. I think trains that are launched online may never go into a physical PI planning event because of that confirmation bias.
Nick Muldoon:
All right.
Em Campbell-Pretty:
That makes me really sad.
Nick Muldoon:
I want to come back to something you said before about the leaders, and you mentioned the trust, the openness to learning and experimentation, and the discipline. I was going back over your SAFe Global 2018 talk about the seven traits of highly effective servant leaders.
Em Campbell-Pretty:
Yep.
Nick Muldoon:
Yeah?
Em Campbell-Pretty:
Yep.
Nick Muldoon:
I guess I had some questions about this, and obviously, these are four of the traits. What are the other three traits that I'm missing? Then I've got a followup question about some of the actual things that you talked about that you picked up in your trip.
Em Campbell-Pretty:
[inaudible 00:27:29] one of those four on the list I had in 2018.
Nick Muldoon:
I'll quiz you on it.
Em Campbell-Pretty:
How awkward. So, in 2018, the answer was people first, a respect for people, that sort of lens, lean thinking, manager, teacher, learner. So, we had that one. Yeah. Learner. [inaudible 00:28:00] crazy. What else did I have? [inaudible 00:28:10].
Nick Muldoon:
Yeah. Okay. I wanted to talk about that one, actually. I made a note about that. What is that, and are there examples of that in the West?
Em Campbell-Pretty:
A lot of people talk about true north.
Nick Muldoon:
[inaudible 00:28:28]. True north.
Em Campbell-Pretty:
Yeah. True north. The translation I got, which I got from Mr. [inaudible 00:28:39], who partnered with Katie Anderson for the lean study tour I did in, I don't know, '18, '17, '18, 2018, I think, so the translation he gave was direction and management sort of things. So, it's mission, right? It's strategic mission. It's that sort of thing.
Nick Muldoon:
So, just a sidebar here for anyone that hasn't seen Em's talk on this, there's a woman by the name of Katie Anderson. She runs an annual, I think, I guess not this year, but she runs an annual-
Em Campbell-Pretty:
No, not this year. She did not go this year.
Nick Muldoon:
... not this year, runs an annual lean, Kanban, kaizen study tour to Japan and visits ... Who did you visit, Em? You visited with Katie. How many were in the crew that you went over there with?
Em Campbell-Pretty:
So, I think it was a group of about 20 from memory. Katie lived in Japan for two years and then went back to the US. She lives in San Francisco, I think. While she was there, she really liked the idea of putting together these lean study tours. She was already a lean practitioner more in the healthcare side of things. So, she got the opportunity to ... We actually were on a test run tour.
Nick Muldoon:
Oh, cool.
Em Campbell-Pretty:
So, this was her experiment. She had a relationship with Ohio State University and they brought some people to the table and she brought some people to the table and they made it happen. She also had an existing relationship with Mr. [inaudible 00:30:24], who was John [inaudible 00:30:26] first manager at Toyota. So, he's a 40 year Toyota veteran.
Nick Muldoon:
Veteran.
Em Campbell-Pretty:
He came with us for the week. So, we of course went to Toyota, but we went to a bunch of Toyota suppliers as well. Isuzu, [inaudible 00:30:43]. Then we also went to Japan Post, which was fascinating. We went to a city which name escapes me right now, but they called it 5S City because all the companies in that city practice the 5S, the manufacturing 5S.
Nick Muldoon:
Tell me about it. It's not coming to mind. I don't feel comfortable or familiar.
Em Campbell-Pretty:
You don't feel good about 5S?
Nick Muldoon:
No.
Em Campbell-Pretty:
No. That's not good. So, how would I ... The 5S is five Japanese words, which I'm going to go ... Yeah. My Japanese, nothing. But it's about standardized work. So, for example, when you go into the 5S factories, you'll see the floors marked up where you need to stand to do a particular job.
Nick Muldoon:
[crosstalk 00:31:41] This is what Paul Aikas picked up for his-
Em Campbell-Pretty:
Oh, no.
Nick Muldoon:
I feel like I've seen Paul Aikas' videos of their manufacturing in the US that everything's marked up.
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Probably. That would be my guess. We should ask Teddy.
Nick Muldoon:
We can ask Paul, and we can ask all these people. There's time.
Em Campbell-Pretty:
Well, yeah.
Nick Muldoon:
Okay.
Em Campbell-Pretty:
Okay.
Nick Muldoon:
So, that lean tour, the Japan study tour, that was a super effective and motivating thing for you?
Em Campbell-Pretty:
Yeah. For me, it was very reinforcing. So, I had I guess my own lens on what lean leadership meant, and I found that particular tour to be very reinforcing around the value set that I believe is part of that. Katie [inaudible 00:32:43] created [inaudible 00:32:44] that is designed to show you that. So, she's often very clear that says this is not Japan, right? This is not a reorganization into Japan. This is not every leader in Japan.
Em Campbell-Pretty:
This is, I've hand picked a series of lean leaders to show you it being practiced. But it was certainly very reinforcing for me. So, very similar messages I picked up in terms of how I like to head, how I coach others to lead was built into the messages that she delivered. So, it was very cool. It was very cool. Some of those leaders, just so inspiring, particular kaizen. I think the thing that just really hits you in the face as you're talking to these folks is kaizen, this drive to get better.
Nick Muldoon:
All the time.
Em Campbell-Pretty:
All the time. Absolutely. It's these folks looking for, they're looking for the one second, right?
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
The one second improvements. There's a video that floats around. Have you seen the Formula 1 video-
Nick Muldoon:
Yeah.
Em Campbell-Pretty:
... where they do, yeah, the changeover in 63 and it takes them over a minute and they do the changeover in 90-something in Melbourne and it takes them six seconds or whatever it is. It's like that, right? It's that how do I find one more second, half a second? They're just so driven. If I can remove a step that someone has to take, can I move something closer to somebody?
Nick Muldoon:
Yeah. There was some comment in the presentation that you gave. There was some comment about if I have to take another five steps, that's an extra 10 seconds. Then that's an extra 10 seconds every time I do this activity every day, and that all adds up. So, how do we shave these seconds off and be more effective and deliberate about how we do this?
Em Campbell-Pretty:
That was just huge, right? I called it kaizen crazy in the presentation. I'm just so, so driven to improve, and just tiny, small improvements every day.
Nick Muldoon:
So, one of the other practices that I didn't grok out of that talk was about the Bus Stop. What was the Bus Stop about?
Em Campbell-Pretty:
Was that in that talk? Really?
Nick Muldoon:
I'm forcing you to stretch your mind [crosstalk 00:34:57].
Em Campbell-Pretty:
You are. You are. You are. You are quite right. It really was [inaudible 00:35:01]. Okay. Oh, you're awful.
Nick Muldoon:
Yes.
Em Campbell-Pretty:
Yes. Yes, you are. Okay. So, effective leaders are human was the tagline on that one. It was really about leaders being down to Earth and being one with the teams. So, things I saw in Japan, this factory run by a woman, [inaudible 00:35:42], I think it was, so very unusual. Not a lot of women leaders in Japan. Her husband took her name because [inaudible 00:35:52]. It's a really interesting character.
Em Campbell-Pretty:
But her company has a bunch of morning rituals. You always say good morning and thank you and how they talk every day and everybody talks and everyone interacts. Then one of the other places we went to, they all had their uniforms they wore in the factory. But everybody wore the uniform, right? The CEO, the office workers, and everybody wore the uniform. Everyone was one.
Em Campbell-Pretty:
Then I was thinking about my experience leading teams, and a lifetime ago, I was working with a team that decided to enter a corporate competition. This competition was about showing your colors and showing the corporate values, which were things like better together and courage, and then [inaudible 00:36:49] a rainbow thing. So, this team decides what they're going to do, is it an address up in the rainbow colors, and they're going to be better together and show their courage and they're going to do the Macarena and they're going to video it and that's going to be how they're going to win this competition.
Em Campbell-Pretty:
I did not participate in this Macarena because someone has to take photos and stuff, right? How else are they going to enter the competition? So, had to do my bit. Anyway, we also had this ritual, which was about teams bringing challenges to leadership to resolve, and they did at the end of every spring. So, they do this Macarena and they film it and they enter the competition and at the end of the spring, they bring their challenges to leadership.
Em Campbell-Pretty:
Their challenge is Em did not do the Macarena. You are our leader, you did not do the Macarena. We are feeling very challenged by that, and we're bringing this to you to resolve. So, I went and spoke to the team that raised and said, "Look. I got to tell you. I don't know the Macarena. So, sorry." I still remember this so clearly. One of the guys said to me, "I read this blog about the importance of leaders being vulnerable." You know who wrote that blog post, don't you?
Nick Muldoon:
Oh, Em. Oh. You have it.
Em Campbell-Pretty:
So, we negotiated. I said, "Look. I think I can manage the Bus Stop." For those not from Australia, we grow up doing this in high school dances. In my part of the world, anyway. So, I grabbed my leadership team and we did do the Bus Stop and it was part of proving that we too were the same as everybody else and doing our bit and responding to the team's feedback. So, yes. That is where the Bus Stop fits in. Thanks so much for that, Nick.
Nick Muldoon:
Okay. No, I appreciate that. Now, I'm glad that I got that context. I try and do similar things. Typically, it's a karaoke or something, or that we haven't done that in a while. Yeah, okay. So, I guess the thrust of that talk was really about to leaders to serve, and it was all about being in service of. It sounds like what you took from the Japan study tour was these leaders there were very much in service of their people.
Em Campbell-Pretty:
Absolutely.
Nick Muldoon:
Do you see that as a trait that is prevalent in the best performing companies that you deal with, and how likely are they over a five, 10 year horizon, whatever that happens to be, to outperform their competitors or to be more successful in their market? Or I guess however they define success?
Em Campbell-Pretty:
I certainly see a correlation between leaders that like to serve and/or choose to serve and success with scaled agile, and business, because I guess we have seen over, it's close to 10 years, is those who practice together, your framework with discipline get results, and they get significant results. They improve their ability to deliver products and services, their cost base goes down, their quality goes up, their people are happier, their attrition goes down. We see it every single time.
Em Campbell-Pretty:
What we also see is when the leaders don't walk the talk, when the leaders are paying lip service to the transformation, it doesn't stick. They don't get the results. People don't find it a better place to work. People aren't bought into the change. So, there is definitely a correlation there. You can get pockets of wonderfulness inside an organization.
Em Campbell-Pretty:
We often observe that the organization that's transformation is as successful is the most bought in leader. Most senior bought in leader. So, if you're the leader of a train and you show the right behaviors, your train will be really great.
Nick Muldoon:
Successful.
Em Campbell-Pretty:
But that means nothing for the broader organization, solution train, the business unit, what have you. You see this thing that goes from the leader. If the leader's showing the right behaviors, you get within that space, you get the behaviors, you get the change, you get the results. But leaders who say one thing and do another, people don't buy it, right?
Nick Muldoon:
I guess this is true of any organizational change, isn't it?
Em Campbell-Pretty:
Yeah.
Nick Muldoon:
You hit the boundaries of your pocket, as you said, within the organization and then you meet the real world, the rest of the organization. People, maybe they don't have enough energy or they don't feel that they can influence and change that, and so they just live within their bubble because they don't feel that they can exert the pressure outside of that.
Em Campbell-Pretty:
Yeah. Look. I've certainly, I've seen successful bubble influence organizations. Successful bubbles can become interesting. Chip and Dan Heath's book, which one was it, Switch.
Nick Muldoon:
Oh, yeah. Switch. Yeah.
Em Campbell-Pretty:
[inaudible 00:42:02]. Shine a light on bright spot or something like that. So, bright spots inspire, and if you can create a bubble in an organization that outperforms the rest of the organization, or even if it performs better than it has previously, then everybody looks. Right? How did the organization that goes from poor delivery to great deliveries is what is going on here? That inspires others to get interested. One of the really interesting things we've seen in Australia, we can trace pretty much every SAFe implementation in Australia back to the one at Telstra.
Nick Muldoon:
Yeah, right. They all spun off from that, from the people that were part of it.
Em Campbell-Pretty:
Well, no. People who came and saw it. People who were inspired by it.
Nick Muldoon:
They're not necessarily directly involved in it.
Em Campbell-Pretty:
No. People came and got inspired by it, and then they went, did their thing, and then they inspired someone else. I haven't tried to do it recently, but there was a point in time we just could web together all of them because we could count them when we could see them. But we can web together most of them still. It says you saw someone who saw someone who saw someone who actually was someone who went to visit us at Telstra back in 2012, 2013 and got inspired.
Em Campbell-Pretty:
So, that bright spot can be really, really powerful, and that's what it takes, right? You get to add a little bit of noise, a little bit of difference, and people start to ask what's going on. I wouldn't say it's foolproof. I think it still requires, so someone's got to come, they've got to see, and then they've got to have the courage to do it for their part of the organization.
Em Campbell-Pretty:
That's the hard bit, right? I can come, I can see, I can get inspired. But am I prepared to put myself out there? There's a lot to be said for leaders who are prepared to take risks. That was one of the-
Nick Muldoon:
This was your lesson about the Bus Stop, right? You have to put yourself out there and be vulnerable.
Em Campbell-Pretty:
Yeah. Absolutely. Absolutely. This was actually, I was thinking, was the thing I was talking about at last year's SAFe Summit was be safe or be SAFe.
Nick Muldoon:
Be safe or be SAFe. Tell me about that.
Em Campbell-Pretty:
So, be safe, don't take a risk, or be SAFe, as in the scaled agile framework, and take that leap of faith. It comes back to, we started talking today about when I did this at Telstra, I didn't really understand that this wasn't a normal everyday, this is what everybody did sort of thing. It was a very new thing. So, I took a risk from a perspective that I was a business leader in a technology space and I really felt I had nothing to lose.
Em Campbell-Pretty:
So, I look back and that and go, "What on Earth possessed me?" And I go, "Well, I'm this business person leading this technology team. I wasn't supposed to succeed anyway."
Nick Muldoon:
Put it all on the line, right?
Em Campbell-Pretty:
I found out later they actually had a plan for when I did not succeed. I was supposed to fail.
Nick Muldoon:
Wait. How much waste is that? Why did they plan for something before it was ... Okay.
Em Campbell-Pretty:
Organizational policies. What can I tell you? Anyway, I did not fail. I did succeed, and because I took some crazy, calculated risks, and I've seen it time and time again, right? So many of these leaders in these companies that make this change are taking a leap of faith. I'm always saying I can't tell you exactly what's going to happen. I don't know whether you're going to get 10% cost out or 50% cost out. I don't know if your people are going to be 10% happier or 50% happier. I don't know that.
Em Campbell-Pretty:
What I do know is if you listen to what we're telling you and you follow the guidance and you behave in line with those lean and agile values, you will get results. You'll get results every single time. But you've got to be brave enough to buy in and take it on holistically and not do this thing where you manage to customize your way out of actually doing the thing-
Nick Muldoon:
Doing anything.
Em Campbell-Pretty:
... that you wanted to do.
Nick Muldoon:
Yeah. Okay. Em, this was awesome. Before we finish up, I want to take two minutes. You've mentioned books a lot today and you reminded me of this quote, Verne Harnish, "Those who read and don't are only marginally better off than those who can't." So, today so far, you've mentioned Chip and Dan Heath with Switch, you've mentioned the Leffingwell series from the late noughties. There might have been a few others. But tell me, what are you reading today? You've been in lockdown. What are the two or three top books that you've read since you've been in lockdown in Melbourne?
Em Campbell-Pretty:
Oh, my goodness. It's very awkward. Every time someone asks me, "What did you just read?" I go, "I don't know."
Nick Muldoon:
I don't think I remember.
Em Campbell-Pretty:
Can't remember. It's terrible. What am I reading? I need to open my Kindle. I don't know what I'm reading. Geoffrey Moore, Zone to Win.
Nick Muldoon:
Zone to Win.
Em Campbell-Pretty:
Zone to Win. I think that's what it's called. It's a newer book. I know this year, because obviously, I've read The Build Trap this year-
Nick Muldoon:
Yep. Melissa Perry. You mentioned that one. Yeah.
Em Campbell-Pretty:
Yep. I've read the Project to Product, Mik Kersten.
Nick Muldoon:
What was that one, Project to Product?
Em Campbell-Pretty:
Yeah. Project to Product, Mik Kersten. One of the IT Revolution press books. So, released just over a year ago. Very tied up in the SAFe 5.0 [crosstalk 00:48:21]. The other book tied up in the SAFe 5.0 release is John Kotter's Accelerate. So, I picked that back up. I read it a number of years ago when it first came out. But I like to revisit stuff when SAFe puts it front and center. Seems to make some sense to do that at that point in time.
Nick Muldoon:
Yeah, okay. It's interesting that, thinking about Verne Harnish, the scaling up framework, no relation to-
Em Campbell-Pretty:
No.
Nick Muldoon:
... scaled agile, for anyone that's not familiar. But so much of the scaling up framework about scaling businesses, they draw on so much content from existing offers, existing tomes, points of reference and experience, and it's super valuable, and I guess SAFe is no different, right? It draws on this wisdom of the collective wisdom.
Em Campbell-Pretty:
Absolutely. Absolutely. [inaudible 00:49:14] It was very fun to say in the early days, we stand on the shoulders of giants, a quote from somebody else whose name escapes me.
Nick Muldoon:
Yeah, okay. Well, Em, look. I wanted to thank you so much for your time this morning. This has been fantastic.
Em Campbell-Pretty:
No worries. It's great to catch up with you.
Nick Muldoon:
Yeah. I guess my takeaways from this, I like the be safe or be SAFe, like either be safe and don't take any risks, or be SAFe and actually put yourself out there and step into scaled agile. I definitely have to go and do a bit of research on the five S's as well and learn a bit more about that. But thank you so much for your time. I really appreciate it.
Em Campbell-Pretty:
No worries, Nick. Great to see you.
Related Episodes
- Podcast
Easy Agile Podcast Ep.20 The importance of the Team Retrospective
"It was great chatting to Caitlin about the importance of the Team Retrospective in creating a high performing cross-functional team" - Chloe Hall
In this episode, I was joined by Caitlin Mackie - Content Marketing Coordinator at Easy Agile.
In this episode, we spoke about;
- Looking at the team retrospective as a tool for risk mitigation rather than just another agile ceremony
- The importance of doing the retrospective on a regular cycle
- Why you should celebrate the wins?
- Taking the action items from your team retrospective to your team sprint planning
- Timeboxing the retrospective
- Creating a psychologically safe environment for your team retrospective
I hope you enjoy today's episode as much as I did recording it.
Transcript
Chloe Hall:
Hi, everyone. Welcome to the Easy Agile Podcast. I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodi Wodi people of the Dharawal Speaking nation and pay our respects to elders past, present, and emerging. We extend that same respect to all Aboriginal and to Strait Islander peoples who are tuning in today. So today, we have a bit of a different episode for you. I'm going to be talking with Easy Agile's very own Content Marketing Coordinator, Caitlin Mackie. Caitlin is the Product Owner* of our Brand and Conversions Team*. Now this team is a cross-functional team who have only been together for roughly six months. And within their first few months, as a team, mind you they also had two brand new employees, they worked on a company rebrand.
Chloe Hall:
A new team, a huge task, the possibility of the team being high performing was unlikely at this point in time. So, the team was too new to have already formed that trust, strong relationships, and psychological safety, but somehow they came together and managed to work together, creating a flow of continuous improvement and ship this rebrand. So, I've brought for you today Caitlin onto the podcast to discuss the team's secret for success. Welcome to the podcast, Caitlin.
Caitlin Mackie:
Thanks, Chloe. It's a bit different sitting on this side. I'm used to being in your shoes. I feel [inaudible 00:01:45]. I feel uncomfortable. [inaudible 00:01:46].
Chloe Hall:
Yeah. It's my first time hosting as well, so very strange. Isn't it? How are you feeling today?
Caitlin Mackie:
Yeah. Good. I'm excited. I'm excited to chat about our experience coming together as a cross-functional Agile team, and hopefully share some of the things that worked for us with our listeners.
Chloe Hall:
Yes, I know myself, and I'm sure our audience is very excited to hear what your team's secret to success was. Did you want to start off by telling us what was this big secret that really helped you work together as a team?
Caitlin Mackie:
That's a great question, Chloe. And that's a big question. I'm not sure if there's one key thing, I suppose, it is that ultimate secret source or that one thing that led to the success. I'm sure we all want to hear what that is. I would also love to know if there's just this one key ingredient, but I think something for us, and probably one of the most memorable things that really worked for us, and there was a lot for us to benefit from doing this, was actually doing our retrospectives. So that's probably the first thing that comes to mind when it comes to what led to our success.
Chloe Hall:
Okay. Yeah. In the beginning, why did you start doing the retrospectives?
Caitlin Mackie:
So, we were a new forming team, like you mentioned before, and we seen retrospectives as another Agile ceremony, and we saw other teams doing it and they were having a lot of success from it, so we became to jump on that bandwagon. And I think with being a new forming team, there are so many things that come into play. So, you're trying to figure each other out, how we all like to work and communicate with each other, all of that. And we were the first ever team dedicated to owning and improving our website. And we also knew it was likely that we'd be responsible for designing and launching a rebrand.
Caitlin Mackie:
So when you try and stitch all of that together, and then consider all those elements, we knew that we needed to reserve some time to be able to quickly iterate and call out what works and what doesn't. And what we did understand is that retrospectives are a great opportunity for the whole team to get together and uncover any problematic issues and have an open discussion aimed at really identifying room for improvement, or calling out what's working well, so we can continue to do that. So, I think retros allowed us to understand where we can have the most impact and how to be a really effective cross-functional Agile team.
Chloe Hall:
Wow. That is already so insightful. Yeah, it sounds like the retrospectives really helped you to gain that momentum into finding who your team is, becoming a well-working, high-performing cross-functional team. So, how often were you doing the retro? Were you doing this on a regular cycle, or was it just, "Okay. We have a problem. Some blockers have come up, we need to do a retro"?
Caitlin Mackie:
Yeah. I think initially retro, we kind of viewed retros as this thing where like, "Oh, we've done a few sprints now. We should probably do a retro and just reflect on how those few sprints went." It was kind of like this thing. It was always back of our mind. And we knew we needed to do it, but weren't really sure about the cadence and the way to go about it. So now, we do retros on a Friday morning, which is the last day of our weekly sprint. And then we jump into sprint planning after that. So after bio break as well, so let the team digest everything we talked about in retrospectives. And then we come into sprint planning with all the topics that we're discussed, and we will have a really nice, fresh perspective.
Chloe Hall:
Yeah.
Caitlin Mackie:
So, I think this works really well for us because everything is happening in a timely manner. We've just had a discussion about the best things that happened in the sprint or what worked really well, so you want to make sure you can practice the same behavior in the following, and vice versa for the improvements that you want to make. So, that list of action items that come out of a retrospective provide a really nice contact, context, sorry. And you have them all in mind during sprint planning.
Caitlin Mackie:
So for example, in the previous sprint, it might have come up that you underestimated your story points or there wasn't enough detail on your user stories. So, with each story or task that you are bringing into the sprint, you're then asking the question, is everyone happy with the level of detail? What are we missing? Or we've only story pointed this or two, is it more likely to be a five? So, everything is really fresh in your mind, and I definitely think that helps create momentum. When you've got the whole team working to figure out how you can be more effective with every sprint.
Chloe Hall:
That's such a great point that you just made Caitlin. And I love how going from doing the team retrospective, that you actually can take those action items and go into your sprint and put them into place straight away. It's really good. Otherwise, I feel like if you do the sprint retrospective on the Friday, and you're like, "Okay, these are our action items," get to Monday sprint planning and you're just thinking of the weekend. That [inaudible 00:07:20]
Caitlin Mackie:
Yeah, a hundred percent. Yeah. They're super fresher mind for everyone. So, it might not work for every team, but we find it works really well for us, because we're being really deliberate with how we approach sprint planning.
Chloe Hall:
Yeah. And then with that, I could see how doing the retro, how it could easily go over time, but then your team has sprint planning scheduled after. So, it's like you can't go over time. How have you managed to kind of time box that retrospective?
Caitlin Mackie:
Yeah, that's a really, really good question. And it is on purpose as well that they are scheduled closely together. Som as mentioned above, the discussion you've had in the retrospectives provides a nice momentum going to the sprint planning, but it does mean we have to watch the clock. And initially, this can be quite awkward, because you want to make sure that everyone feels heard and that everybody has the same opportunity to contribute. And I think this responsibility falls on the scrum master, or the product owner, or whoever's facilitating the retrospective to call it out and make sure everyone has the chance to be heard. You'll naturally have people tell the longer story or add a lot of extra context before getting to the point. And then you'll have others that will be a lot more direct. And I'm a lot like the latter. I struggle to get to the point, which doesn't work well when you're trying to time box a retrospective, right?
Chloe Hall:
And I can relate, same personality.
Caitlin Mackie:
Yes. So with this, I think it really comes down to communicating the expectation and the priority from the get go. With our team and with any team, you will want to figure out who you can perform really well and continually improve to exceed expectations and be better and learn and grow together. And I think if you all share that same mindset going into the retrospective and acknowledging that it's a safe
space to have difficult conversations. And as long as you're communicating with empathy, the team knows that it's never anything personal, and it's all in the best interest of the team. And that then helps the less direct communicators, like myself, address their point more concisely and really forces them to be more deliberate and succinct with their communication style.Caitlin Mackie:
And that's really key to being able to stick to that time box, I think. And it does take practice, because it comes down to creating that psychological safety in your team. But once that's there, it's so much easier to call out when someone's going down a windy track, and bring the focus back and sort of say, "I hear you, what's the action item?" And just become a lot more deliberate.
Chloe Hall:
Wow. I couldn't even imagine like how hard it would be, with the personalities that yourself and I have, just trying to be so direct and get rid of all the fluffy stuff. I mean, look at what it's done to form such an amazing team that we have. So, you mentioned that aspect of psychological safety before. And how do you think being in a new cross-functional team... Only six months together, you had those new employees, do you think you were able to create a psychological safety space at any point?
Caitlin Mackie:
That's another fantastic question. And I feel like, honestly, it would be best to have a team discussion around this. It'd be interesting to hear everybody's perspectives around what contributes to that element of psychological safety and if everybody feels the same. So, I can't speak for the team, but my personal opinion on this or personal experience is that creating an environment of psychological safety really comes down to a mutual trust and respect. And at the end of the day, we all share the same goal. So, we all really, really respect what each other brings to the table and understand how all of these moving parts that we are working on individually all come together to achieve the goal. So, when we're having these open discussions in retros, or not even in retros, just communicating in general really, it's clear that we're asking questions in the best interest of the team and individual motives never come into play, or people aren't just offering their opinion when it's unwarranted or providing feedback, or being overly critical when they weren't asked to do so.
Caitlin Mackie:
So, none of those toxic behaviors happen, because we all respect that whatever piece of work is in question or the topic of discussion, the person owning that work, at the end of the day, is the expert. And we trust them, and we don't doubt each other for a second. And I think the other half of that is that we're also really lucky that if something doesn't go as we planned, we're all there to pick each other up and go again. So, this ties quite nicely into actually one of our values at Easy Agile is commit as a team. And this is all about acknowledging that we grow and succeed when we do it together, and to look after one another and engage with authenticity and courage. Som I may be biased, but I wholeheartedly believe that our team completely embraces that. And there's just such an admiration for what we all bring to the table, and I think that's really key to creating the psychological safety.
Chloe Hall:
I love that your team is really embracing our value, commit as a team and putting it into place, because that's what we're all about at Easy Agile, and it's just so great to see it as well. I think the other thing that
I wanted to address was... So again, during this cross functional team, and you've got design and dev, how do you think retros assisted you in allowing to work out what design and dev needed from each other?Caitlin Mackie:
For sure. So, for some extra context for our listeners as well, so in our team, we've got two developers, Haley and David, and a designer, Matt and myself, who's in the marketing. So, we're very much a cross-functional little mini team. So, we all have the same goal and that same focus, but we also are all working on these little individual components that we then stitch together. So,, I think... We doing retros regularly. What we were able to identify was a really effective design and development cycle. So, we figured out a rhythm for what one another needed at certain points. For example, something we discovered really early was making sure that we didn't bring design and dev work into the same sprint. We needed to have a completely finished design file before dev starts working on it. And that might sound really obvious, but initially we thought, "Oh, well, if you have a half finished design file, dev can start working on that. And by the time that's done, the rest of the design file will be done."
Caitlin Mackie:
But what we failed to acknowledge is that by doing that, we weren't leaving enough capacity to iterate or address any issues or incorporate feedback on the first part of that design file, or if dev started working on it and design then gets told, "Oh, this part right here, it's not possible," so the designer is back working on the first part. And it just creates a lot of these roadblocks. So in retros, this came up and we were able to raise it and understand that what design needed from dev and what dev needed from design in order to make sure we weren't blockers for each other. And the action item out of the retro is that we all agreed that a design file had to be completely finished before dev picks up the work.
Chloe Hall:
I think it's so great that you were able to identify these blockers early on. Do you think like doing the retro on a weekly reoccurring basis was able to bring up those blockers quickly, or do you think it wouldn't have made a difference?
Caitlin Mackie:
No, definitely. I, a hundred percent, think that retros allowed us to address the blockers in a way more timely and effective manner. And we kind of touched on that before, but yeah, retros let you address the blockers, unpack them, understand why they're happening and what we need to do to make sure they don't happen again. So, for sure.
Chloe Hall:
Yeah. Yeah. I guess I want to talk a little bit now about the wins, the very exciting part of the retro, the part that we all love. So, how important do you think the wins are within the retro?
Caitlin Mackie:
So important. So, so, so important. It's like, when you achieve something epic as a team, you have to call it out. Celebrate all the wins, big, small. Some weeks will be better than others, but embrace that glass half full mentality. And there's always something to be proud of and celebrate, so call it out amongst
each other, share it with the whole company, publicly recognize it. Yeah, I think it's so important to embrace the wins. It just sort of creates a really positive atmosphere when you're in the team, makes everybody feel heard and recognized for their really positive contribution that they're making. And I think a big thing here as well is that if you've achieved something epic as a team, it's helpful for other teams to hear that as well, right? You figured out a cool new way to do something, share it. If it helped you as a team, it's most likely going to help another team.Caitlin Mackie:
So I think celebrating the wins isn't even just reserved for work stuff either, right? If somebody's doing something amazing outside of work or hit a personal goal, get behind it.
Chloe Hall:
Yeah.
Caitlin Mackie:
To celebrate all the wins always.
Chloe Hall:
Yeah. And I think it's so good how you mentioned that it's vital to celebrate the wins of someone's personal life as well, because at the end of the day, we're all human beings. Yes,, we come to work, but we do have that personal element. And knowing what someone's like outside of work as well is an element to creating that psychological safe space and team bonding, which is so vital to having a good team at the end of the day. Yeah.
Caitlin Mackie:
Yeah, a hundred percent. Yeah, you hit the nail in the head with that. We talked about psychological safety before, and I definitely think incorporating that, acknowledging that, yeah, we are ourselves at work, but we also have a whole other life outside of that too, so just being mindful of that and just cheering each other on all the time. That's what we got to do, be each other's biggest cheerleaders.
Chloe Hall:
Yeah, exactly. That's the real key to success. Isn't it?
Caitlin Mackie:
Yeah, that's it. That's the key.
Chloe Hall:
So, you've been working really well as a new cross functional, high performing Agile team. How do you think... What is your future process for retros?
Caitlin Mackie:
We will for sure continue to do them weekly. It's part of the Agile manifesto, but we want to focus on responding to change, and I think retros really allow us to do that. It's beneficial and really valuable for
the team. And when you can set the team up for success, you're going to see that positive impact that has across the organization as a whole. So yeah, we've found a nice cadence and a rhythm that works for us. So, if it ain't broke, don't fix it.Chloe Hall:
Yeah.
Caitlin Mackie:
Is that what they say? Is that the saying?
Chloe Hall:
I don't know. I think so, but let's just go with it. [inaudible 00:19:02], don't fix it.
Caitlin Mackie:
There we go. Yeah.
Chloe Hall:
You can quote Caitlin Mackie on that one.
Caitlin Mackie:
Quote me on that.
Chloe Hall:
Okay, Caitlin. Well, there's just one final thing that I want to address today. I thought end of the podcast, let's just have a little bit of fun, and we're going to do a little snippet of Caitlin's hot tip. So, for the audience listening, I want you to think of something that they can take away from this episode, an action item that they can start doing within their teams today. Take it away.
Caitlin Mackie:
Okay. Okay. All right. I would say always have the retrospective. Don't skip it. Even if there's minimal items to discuss, new things will always come up. And you have to regularly provide ways for the team to share their thoughts. And I'll leave you with, always promote positive dialogue and show value and appreciation for team ideas and each other. That's my-
Chloe Hall:
I love that.
Caitlin Mackie:
That's my hot tip.
Chloe Hall:
Thanks, Caitlin. Thanks for sharing. I really like how you said always promote positive dialogue. I think that is so great. Yeah. Well, thanks, Caitlin. Thanks for jumping on the podcast today and-Caitlin Mackie:
Thanks, Chloe.
Chloe Hall:
Yeah. Sharing your team's experience with retrospectives and new cross functional team. It's been really nice hearing from you, and there's so much that our audience can take away from what you've shared with us today. And I hope that we've truly inspired everybody listening to get out there and implement the team retrospective on a regular basis. So, yeah, thank you.
Caitlin Mackie:
Thank you so much, Chloe. Thanks for having me. It was fun, fun to be on this side. And I hope everyone enjoys this episode.
Chloe Hall:
Thanks, Caitlin.
Caitlin Mackie:
Thanks. Bye.
- Podcast
Easy 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.
- Podcast
Easy Agile Podcast Ep.21 LIVE from Agile2022!
"That's a wrap on Agile2022! It was great to be able to catch up with so many of you in the agile community in-person!" - Tenille Hoppo
This bonus episode was recorded LIVE at Agile2022 in Nashville!
The Easy Agile team got to speak with so many amazing people in the agile community, reflecting on conference highlights, key learnings, agile ceremonies + more!
Thanks to everyone who stopped by the booth to say G’Day and enjoyed a Tim Tam or two ;)
Huge thank you to all of our podcast guests for spending some time with us to create this episode!
- Cody Wooten
- Gil Broza
- Maciek Saganowski
- Lindy Quick
- Carey Young
- Leslie Morse
- Dan Neumann
- Joseph Falú
- Kai Zander
- Avi Schneier
- Doug Page
- Evan Leybourn
- Jon Kerr
- Joshua Seckel
- Rob Duval
- Andrew Thompson
Transcript
Caitlin:
Hi, everyone. Well, that's a wrap on Agile 2022 in Nashville. The Easy Agile team is back home in Australia, and we spent most of our journey home talking about all of the amazing conversations that we got to have with everyone in the Agile community. It was great catching up with customers, partners, seeing old friends, and making lots of new ones. We managed to record some snippets of those amazing conversations, and we're excited to share them with you, our Easy Agile Podcast audience. So enjoy.
Maciek:
[inaudible 00:00:26].
Tenille:
Maciek, thanks so much for taking time with us today.
Maciek:
No worries.
Tenille:
[inaudible 00:00:30], can you let us know what was the best thing you've learned this week?
Maciek:
Oh, that was definitely at Melissa Perri's talk. When she talked about... Like, to me, she was talking about slowing down. And what we do in Agile, it's not just delivery, delivery, delivery, but very much learning and changing on things that we already built, and finding out what value we can give to customers. Not just ship features, it's all about value. That's what I learned.
Tenille:
That's great. Thank you. So what do you think would be the secret ingredient to a great Agile team?
Maciek:
Humility. Somehow, the team culture should embrace humility and mistakes. And people should not be afraid of making mistakes, because without making mistakes, you don't learn. That's what I think.
Tenille:
So what would be, I guess, if there's one Agile ceremony that every team should do, what do you think that might be?
Maciek:
For sure, retro, and that comes back to the mistakes and learning part.
Tenille:
Yeah. Fantastic.
Maciek:No worries.
Tenille:
That's great. Thanks so much for taking time.
Maciek:
Okay. Thank you.
Tenille:
Cheers.
Gil:
[inaudible 00:01:42].
Caitlin:
Gil:, thank you so much for chatting with us. So we're all at Agile 2022 in Nashville at the moment. There's lots of interesting conversations happening.
Gil:
Yes.
Caitlin:
If you could give one piece of advice to a new forming Agile team, what would it be?
Gil:
It would be to finish small, valuable work together. It has a terrible acronym, FSVWT. So it cannot be remembered that way. Finish small, valuable work together. There's a lot of talk about process, working agreements, tools. This is all important, but sometimes it's too much for a team that's starting out. And so if we just remember to finish small valuable work together, that's a great story.
Caitlin:
Yeah, I love that. And you were a speaker at conference?
Gil:
Yes.
Caitlin:
Can you give our audience a little bit of an insight into what your conversation was about?
Gil:
What happens in many situations is that engineering or development doesn't really work collaboratively with product/business. And instead, there is a handoff relationship. But what happens is that in the absence of a collaborative relationship, it's really hard to sustain agility. People make a lot of one-sided assumptions. And over time, how decisions get made causes the cost of change to grow, and the safety to make changes to decrease. And when that happens, everything becomes harder to do and slower to do, so the agility takes a hit. So the essence of the talk was how can we collaboratively, so both product and engineering, work in ways that make it possible for us to control the cost of change and to increase safety? So it's not just collaboration of any kind. There are very specific principles to follow. It's called technical agility, and when we do that, we can have agility long-term.Caitlin:
Great. I love it. Well, thank you so much and I hope you enjoy the rest of your time at the conference.
Gil:
Thank you.
Caitlin:
Great. Thank you.
Tenille:
Hi, Tenille here from Easy Agile, with Josh from Deloitte, and we're going to have a good chat about team retrospectives. So Josh, thank you for taking the time to have a good chat. So you are a bit of an expert on team retrospectives. What are your top tips?
Josh:
So my top tips for retrospective is first, actually make a change. Don't do a lessons observed. I've seen lots of them actually make a change, even if it's just a small one at the end. The second, and part of that, is make your change and experiment. Something you can measure, something that you can actually say yes, we did this thing and it had an impact. May not be the impact you wanted, but it did have some kind of impact. The second tip is vary your retrospectives. Having a retrospective that's the same sprint after sprint after sprint will work for about two sprints, and then your productivity, your creativity out of the retrospective will significantly reduce.
Tenille:
That's an excellent point. So how do you create [inaudible 00:05:03]?
Josh:
Lots and lots of thinking about them and doing research and using websites like TastyCupcakes, but also developing my own retrospectives. I've done retrospective based on the Pixar pitch. There's six sentences that define every Pixar movie. Take the base sentences, apply them to your sprint or to your PI and do a retro, and allow the team that creativity to create an entire movie poster if they want to. Directed by [inaudible 00:05:34], because it happens. People get involved and engaged when you give them alternatives, different ways of doing retrospectives.
Tenille:That's right. So for those teams that aren't doing retrospectives at the moment, what's the one key thing they need to think about that you... What's the one key thing you could tell them to encourage them to start?
Josh:
If you're not doing retrospectives, you're not doing [inaudible 00:05:54]. So I shouldn't say that. But if you're not doing retrospectives, if you truly believe that you have absolutely nothing to improve and you are 100% of the best of the best, meaning you're probably working at Google or Amazon or Netflix, although they do retrospectives. So if you truly believe that you are the equivalent of those companies, then maybe you don't need to do them, but I'm pretty sure that every team has something they can improve on. And acknowledging that and then saying, how are we going to do that? Retrospective's a very fast, easy way to start actually making those improvements and making them real.
Tenille:
Fantastic. Great. Thanks so much for taking the time to chat to us briefly about retrospectives.
Josh:
Thank you.
Caitlin:
We're here with Leslie, who is the president of women in Agile. Leslie, there was an amazing event on Sunday.
Leslie:
Yes.
Caitlin:
Just talk to us a little bit about it. What went into the planning? How was it to all be back together again?
Leslie:
It was amazing to have the women in Agile community back together, right? Our first time since 2019, when everyone was together in Washington DC for that event. The better part of six or seven months of planning, we had about almost 200 people in the room. Fortunately, we know the [inaudible 00:07:10] of what these women in Agile sessions that we do, part of the Agile Alliance conferences every year, right? We've got a general opening. We've got a great keynote who is always someone that is adjacent to the Agile space. We don't want to just like... We want to infuse our wisdom and knowledge with people that aren't already one of us, because we get all of the Agile stuff at the big conference when we're there.
Leslie:
So that part, we always have launching new voices, which is really probably one of my most favorite women in Agile programs. Three mentees that have been paired with seasoned speakers, taking stage for the first time to share their talent and their perspective. So that's really great. And then some sort of interacting networking event. So that pattern has served us really well since we've been doing this since 2016, which is a little scary to think it's been happening that long. And it's become a flagship opportunity for community to come together in a more global fashion, because the Agile Alliance does draw so many people for their annual event.
Caitlin:
Yeah, for sure. Well, it was a great event. I know that we all had a lot of fun being there. What was your one key takeaway from the event?
Leslie:
I'm going to go to [inaudible 00:08:14] interactive networking that she did with us, and really challenging us to lean into our courage around boundaries and ending conversations. We don't have to give a reason. If some conversation's not serving us or is not the place that we need to be for whatever reason, you absolutely have that agency within yourself to end that conversation and just move on. I love the tips and tricks she gave us for doing that well.
Caitlin:
Yes, yes, I love that too. That's great. Well, thank you so much. Appreciate it.
Leslie:
Yeah. Thanks for having me.
Tenille:
Hi, Evan. How are you?
Evan:
Very good.
Tenille:
That's good. Can you please tell me what's the best thing you learned today?
Evan:
The best quote I've got, "Politics is the currency of human systems." Right?
Tenille:
Wow.
Evan:
So if you want to change a human system, you got to play the politics.
Tenille:
Fantastic.Evan:
Which feels crappy, but-
Tenille:
It's the way it is.
Evan:
... that's the way it is.
Tenille:
[inaudible 00:09:07]. Okay, next question. What is the Agile ceremony that you and your team can't live without?
Evan:
Retrospective. With the retrospective, you can like create everything else.
Tenille:
Fantastic. That's really good. And what do you think is probably the key ingredient to a good retrospective?
Evan:
Oh, trust. Trust requires respect. It requires credibility. It requires empathy. So trust is like that underpinning human capability.
Tenille:
Yeah. Fantastic. Thanks very much.
Evan:
Thank you.
Tenille:
Yes.
Caitlin:
Right. We're here with Cody from Adfire. So Cody, how you enjoyed the conference so far?
Cody:
I'm really loving the conference. It's been awesome. To be honest, when we first got here, it seemed maybe a little bit smaller than we thought, but the people here's been incredible, highly engaged, which was always great. And plus, a lot of people are using Jira and Atlassian. So lot of big points.
Caitlin:Win-win for both, huh?
Cody:
Yeah. Always, always, always.
Caitlin:
Very good.
Cody:
Yeah.
Caitlin:
Lots of interesting talks happening. Have you attended any that have really sparked an interest in you? What's [inaudible 00:10:15]-
Cody:
Yeah. I can't remember any of the talk names right off the top, but they've all been incredibly insightful. Tons of information. It seems like there's been a topic for everything, which is always a great sign and stuff like that. So my notes, I have pages and pages and pages of notes, which is always a good sign.
Caitlin:
Yeah, that's [inaudible 00:10:34].
Cody:
So I'm I have to go back and [inaudible 00:10:35] again.
Caitlin:
Yes.
Cody:
But it's been incredible and the talks have been very plentiful, so yeah.
Caitlin:
Good. Good. And what is the one key takeaway that you are looking forward to bringing back and sharing with the team?
Cody:
Well, I think one of the key takeaways for us was that... I talked about the engagement that everybody has, but one thing that's been incredible is to hear everybody's stories, to hear everybody's problems, their processes, all of that stuff. So all of that information's going to be a great aggregate for us to take back and create a better experience with our product and all that good stuff. So yeah.
Caitlin:For sure. I love it. Now, I have one last question for you. It's just a fun one. It's a true or false. We're doing Aussie trivia. Are you ready for this one?
Cody:
Okay.
Caitlin:
Okay.
Cody:
Hopefully.
Caitlin:
So my true or false is, are Budgy Smugglers a type of bird?
Cody:
Are buggy smugglers-
Caitlin:
Budgy Smugglers.
Cody:
Budgy Smugglers.
Caitlin:
A type of bird.
Cody:
True.
Caitlin:
False. No.
Cody:
What are they?
Caitlin:
Speedos.
Cody:
Yeah. Well, I've got some of those up there in my luggage. So I'll bring the budgys out now.Caitlin:
With your Daisy Dukes.
Cody:
Exactly. Exactly.
Caitlin:
Yeah. And cowboy boots, right?
Cody:
Yeah.
Caitlin:
Well, thank you so much.
Cody:
Thank you.
Caitlin:
Very appreciate it.
Cody:
Yeah. Thank you.
Tenille:
Doug, how are you?
Doug:
I'm great. Thank you.
Tenille:
Awesome. Well, tell me about, what's the best thing you've learned today?
Doug:
I think learning how our customers are using our products that we didn't even know about is really interesting.
Tenille:
That's amazing. Have you had a chance to get out to many of the sessions at all?
Doug:I actually have not. I've been tied to this booth, or I've been in meetings that were already planned before I even came down here.
Tenille:
[inaudible 00:12:01].
Doug:
Yeah.
Tenille:
That's good. So when you're back at work, what do you think is probably the best Agile ceremony that you and your team can't live without?
Doug:
I think what I'm bringing back to the office is not so much ceremony. It's really from a product perspective. I work in product management. So for us, it's how we can explain how our product brings value to our customers. So many lessons learned from here that we're really anxious to bring back and kind of build into our value messaging.
Tenille:
Fantastic.
Doug:
Yeah.
Tenille:
Thanks. That's great. Thanks very much.
Caitlin:
He was one of the co-authors of the Agile Manifesto. Firstly, how are you doing in conference so far?
John:
Well, working hard.
Caitlin:
Yeah, good stuff.
John:
Enjoying Nashville.
Caitlin:
Yeah. It's cool, isn't it? It's so different from the [inaudible 00:12:46] what's happening.John:
Yeah. It's good. Yes. It's nice to see a lot of people I haven't seen in a while.
Caitlin:
Yeah. Yeah.
John:
And seeing three dimensional.
Caitlin:
Yes. Yeah, I know. It's interesting-
John:
It's there-
Caitlin:
... [inaudible 00:12:54] and stuff happening.
John:
Yeah, IRL.
Caitlin:
Lots of interesting [inaudible 00:13:01] that's happening. Any key takeaways for you? What are you going to take after to share with the team?
John:
Oh, well, that's a good question. I'm mostly been talking with a lot of friends that I haven't seen in a while. [inaudible 00:13:14].
Caitlin:
Yes.
John:
And since I've only been here a couple days, I haven't actually gone for much, if anything. To be frank.
Caitlin:
I know. Well, we're pretty busy on the boots, aren't we?
John:
Yeah. Yeah. But certainly, the kinds of conversations that are going on are... I was a little bit worried about Agile. Like, I don't want to say... Yeah, I don't want to say it. But I don't want to say, Agile's becoming a jump turf.Caitlin:
Yes.
John:
But I think there's a lot of people here that are actually really still embracing the ideals and really want to learn, do and practice [inaudible 00:14:00].
Caitlin:
Yeah.
John:
So I'm frankly surprised and impressed and happy. There's a lot. If you just embrace more of the manifesto, and maybe not all of the prescriptive stuff sometimes, and you get back to basics. [inaudible 00:14:22]-
Caitlin:
Yeah. So let's talk about that, the Agile Manifesto that you mentioned. Embracing that. What does embracing mean? Can you elaborate on that a bit more? So we know we've got the principles there. Is there one that really stands out more than another to you?
John:
Well, my world of what I was doing at the time, and I'd done a lot of defense department, water haul, and built my own sort of lightweight process, as we call it before Agile. So to me, the real key... This doesn't have the full-
Caitlin:
Full manifesto, yeah.
John:
But if you go to the website and read at the top, it talks about like we are uncovering ways by doing, and I'm still learning, still uncovering. And I think it's important for people to realize we really did leave our ego at the door. Being humble in our business is super important. So that might not be written anywhere in the principles, but if the whole thing at the preamble at the top, and the fact that we talk about how we value those things on the blog versus the whole... There's a pendulum that you could see both of those things collide. That, in my opinion, one the most important trait that we should exercise is being humble, treating things as a hypothesis. Like, don't just build features [inaudible 00:15:58] bottom up, how do you seek up on the answers, that's what I want people to takeaway.
Caitlin:
That's great. That's great advice. Well, thank you so much, John. Appreciate you taking the time to chat with us.John:
You're welcome, Caitlin.
Caitlin:
Yeah. Enjoy what's [inaudible 00:16:11].
John:
Thank you.
Caitlin:
Thank you.
John:
[inaudible 00:16:13] tomorrow.
Caitlin:
All right.
Tenille:
Abukar, thanks for joining us today. Can I ask you both, what do you think is the best thing you've learned today?
Avi:
Best thing I've learned?
Tenille:
Yeah.
Avi:
That's a really interesting one. Because I'm here at the booth a lot, so I'll get to attend a lot of things. So there were two things I learned that were really important. One, which is that the Easy Agile logo is an upside down A, because it means you're from Australia. So it's down under. And then the second most important thing I learned about today was we were in a session talking about sociocracy, and about how to make experiments better with experiments, which sounded a little weird at first, but it was really all about going through like a mini A3 process. For those of you listening, that's something that was done to Toyota. It's a structured problem solving method, but instead of going [inaudible 00:17:02] around it and going through the experiment, going around two or three times and then deciding that's the right experiment you're going forward.
Tenille:
Thank you. How about your time?Kai:
I've been at the booth most of the time, but from that you meet a lot of people all over the world. And we really have like one thing in common, which is wanting to help people. And it's really been nice to be in a room of people if they're at the beginning of their journey or their really seasoned, that their motivation is just to really empower others. So it's been really nice to be around that kind of energy.
Avi:
We've really learned that our friends from Australia are just as friendly up here as you are on the other side. I feel when you come on this side, you get mean, but it turns out you're just as nice up here too.
Tenille:
Well, it depends how long you've been on flight.
Avi:
Oh, exactly.
Tenille:
[inaudible 00:17:44], we're okay.
Kai:
Yeah.
Avi:Abukar:
Exactly. Good.
Tenille:
All right. One more question here.
Avi:
Sure.
Tenille:
What do you think is the secret ingredient for a successful team?
Avi:
What do I think the secret? Oh, that's a really good question. That's a-
Kai:
He's the best one to answer that question.
Avi:That's a little longer than a two-second podcast, but I'll tell you this. It may not be psychological safety,-
Tenille:
Okay.
Avi:
... just because Google said that and Project Aristotle show that. I think to have a really, really successful team, you need a really skilled scrum master. Because to say that the team has psychological safety is one ingredient, it's not the only ingredient. A strong scrum master is someone who's really skilled to create that psychological safety, but also help with all the other aspects of getting ready to collaborate and coordinate in the most positive way possible. Plus, searching for... Her name is Cassandra. On Slack, she calls herself Kaizen. You get it? It's a joke. But that's the whole thing is that a really skilled scrum master helps the teams find the kaizens that they need to really get to become high performing. So psychological safety is an enabler of it, but that doesn't mean it creates the performance. It's an ingredient to make it happen.
Tenille:
Fantastic.
Kai:
There's no better answer than that one. Let's do exclamation.
Tenille:
Excellent. Thanks very much for taking the time.
Avi:
Thank you so much.
Kai:
Of course.
Hayley:
We're here with Carey from Path to Agility. Carey, what have you been really loving about this conference?
Carey:
I think I've loved the most about this conference so far is the interaction with all the people that are here. It's really nice to get together, meet different folks, network around, have the opportunity to see what else is out there in the marketplace. And then, of course, talk about the product that we have with Path to Agility. It's a wonderful experience to get out here and to see everybody. And it's so nice to be back out in person instead of being in front of a screen all the time.
Tenille:Yeah, absolutely. Have you had a chance to get to many of the sessions?
Joseph:
I've tried to as much as I can, but it's also important to take that time to decompress and let everything sink in. So here we are having fun.
Tenille:
Yeah, absolutely. So thinking back to work, what do you think is the one Agile ceremony that you take that helps you and your team the most?
Joseph:
I think that finding different ways to collaborate, effective ways to collaborate. And in terms of work management, how are we solving some of the problems that we have? There's so many tools that are here to make that easier, which is made pretty special. Speaking to people and finding out how they go about solving problems.
Tenille:
And what do you think makes a really great Agile team?
Joseph:
Well, you could say something very cliche, like being very adaptive and change and so on and so forth. But I think it really comes down to the interaction between people. Understanding one another, encouraging one another, and just the way you work together.
Tenille:
Fantastic. Great. Well, thanks very much for taking the time to chat.
Joseph:
Thank you. It was nice chatting with you guys all week long.
Tenille:
Cheers.
Tenille:
Dan, thanks for taking the time to chat.
Dan:
You're welcome.
Tenille:
[inaudible 00:22:54] questions. What do you think is the best thing you learned today?
Dan:Oh, the best thing I learned today, the morning products keynote was excellent. Got a couple tips on how to do product management, different strategies, how you have folks about seeing their focus on the tactical and the strategic. So just some nice little nuggets, how to [inaudible 00:23:12].
Tenille:
[inaudible 00:23:13], thanks for joining us today. Can I start by asking, what do you think is the best thing you've learned this week?
Speaker 17:
The best thing I've learned this week is there's no right way to do Agile. There's a lot of different ways you can do it. And so it's really about figuring out what the right process is for the organization you're in, and then leveraging those success patterns.
Tenille:
Well, I guess on that, is there one kind of Agile ceremony that you think your team can't do without?
Speaker 17:
The daily standup being daily. I think a lot of our teams, they talk all day long. They don't necessarily need to sync up that frequently. I've had a few teams already, they go down like three days a week and it seems to work for them. The other maybe key takeaway that I've seen folks do is time boxes. So no meetings from 10:00 to 2:00 or whatever it may be, and really driving that from a successful perspective.
Tenille:
I guess on that note, what do you think makes a really successful Agile team?
Speaker 17:
The ability to talk to each other, that ability to communicate. And so with all of our teams being either hybrid or remote, making sure that we have the tools that let them feel like they can just pick up and talk to somebody anytime they want, I think is key. And a lot of folks still don't have cameras, right, which is baffling to me. But that ability to see facial expressions, being face to face has been so nice because we're able to get that. So that's the other key is just that ability to talk to each other as though I could reach out and touch you.
Tenille:
Okay. Fantastic. Well, thanks so much.
Speaker 17:
You're welcome. Thank you.
Tenille:
Okay. Rob and Andrew, thanks so much for taking a few minutes with us. Can I start by asking you, what do you think is the best thing you learned this week?
Rob:For me, it's definitely fast scaling Agile, we learned about this morning. We're going to try it.
Andrew:
For me, I really enjoyed the math programming session and learning kind of different ways to connect engineers and collaborate.
Tenille:
Great. Next up, I guess, what do you think makes a great Agile team?
Rob:
First and foremost, that they're in control of how they work and what they work on, more than anything else.
Andrew:
Yeah. For me, it's a obviously psychological safety and just having a good team dynamic where they can disagree, but still be respectful and come up with great ideas.
Tenille:
And is there one Agile ceremony that you think a great team can't live without?
Rob:
Probably retrospective. I think the teams need to always be improving, and that's a good way to do it.
Andrew:
Agreed. Yeah. Agreed.
Tenille:
Okay. That's great. Thanks so much for taking the time.
Andrew:
Thank so much. Appreciate it.