Easy Agile Podcast Ep.27 Inclusive leadership

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

‍

"Every time I meet with Tony, I'm always amazed by his energy and authenticity. In this conversation, that really shone through."

In this episode Hayley Rodd - Head of Partnerships at Easy Agile, is joined by Tony Camacho - Technical Director Enterprise Agility at Adaptavist. They are delving into the highly discussed subject of team alignment, discussing what it means to have synchronized goals, cross-functional collaboration, and a shared agile mindset.

They also cover the fundamental building blocks to get right on your journey to team alignment, like the power of listening and embracing mistakes as learning opportunities, stressing the importance of following through on retrospective action items + so much more.

We hope you enjoy the episode!

Share your thoughts and questions on Twitter using the #easyagilepodcast and make sure to tag @EasyAgile.

Transcript:

Hayley Rodd:

Here at Easy Agile, we would like to say an acknowledgement of country. This is part of our ongoing commitment to reconciliation. Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast and meet you today. The people of the Darova-speaking country. We pay our respects to elders past, present, and emerging, and extend the same respect to all Aboriginal, Torres State Islander and First Nations people listening in today. Hi all and welcome to the Easy Agile Podcast. My name is Hayley. Here's a little about us here at Easy Agile. So we make apps for Atlassian's Jira. Our applications are available on Atlassian's marketplace and are trusted by more than 160,000 users from leading companies worldwide. Our products help turn teams flat Jira backlog into something more visually meaningful and easy to understand.

From sprint planning, retrospectives and PI planning our ups are great for team alignment. Speaking of team alignment, this is what this episode is all about. Today I'm joined by Tony Camacho. Tony is the technical director of Enterprise Agility for Aligned Agility, which is part of the Adaptiveness group. I've met Tony a few times during my time here at Easy Agile and have learned that he's one of the most generous people along with being funny and a clever human being who is incredibly knowledgeable about Jira and a bunch of other agile related topics. It's really wonderful to have Tony on the podcast today.

Hey, everyone, we've got the wonderful Tony Camacho on the podcast today. This is our first time recording from our Easy Agile Sydney office, which is super cool. Tony, I'm not sure if you know, but Easy Agile is based out of a place called Wollongong, which is just south of Sydney. But we've got a Sydney office because we've hired a bunch of Sydney team members recently who wanted a place to come and hang out with each other. So we created this space, but it's 7:00 AM in the morning, so I'm all alone right now. That's how much I love you. So Tony, let's get started on the questions. Team alignment. What does it mean for a team to actually be aligned?

Tony Camacho:

So for us in an agile space that we're having, it's a collective understanding, a synchronization of your team members towards goals, principles, your practices that you're going in. Even more so I would even go down to the point of cadence, you would have those synchronizes. So it's a matter to be consistent with your agile principles and values, your mindset, your shared goals and vision, your synchronized work practices, DevOps, [inaudible 00:02:44], how we're going to put this out. Cross-functional collaboration between the teams, getting your tea shaped partners/teammates shining at that moment, learning from each other, roles, responsibilities things of that type. That's what it means to me. It really means.

It's all about human beings and at that point, having everybody aligning and working to our common goal, that objective that we want to do for the business partner. There's the gold that we're all after as a team. Does that make sense for you guys? We have the same objectives for this initiative and our practices. And finally for me, which I know this is not typically is we're coming to an agreement on the tools we're going to use and how we're going to use them and have a system source record where we know where we can get our troops, our dependencies, find out which teams do have capacity and move forward from there. That would be my overall definition of an agile team.

Hayley Rodd:

Wow.

Tony Camacho:

And teams.

Hayley Rodd:

You've had lots of experience over the years. I guess where my mind goes when you say all those really wonderful things about team alignment is that in my experience when team alignment is when people get it right, it's super great. When people get it wrong, it's really hard. And I actually think it's pretty hard to get team alignment right. You got to really work at it. What's your experience in that?

Tony Camacho:

To me it's like it can be a bad marriage or a great marriage, but it needs work. As we know, all relationships need work. We're human beings, we're not the same. Each one of us brings something to the table of value. So let me give you one example that I've lived with on a team. I'm an extrovert by nature, and I'm a developer, an engineer and typically that is not two skill sets that you hear together. So I've had to learn that when I'm working with my teammates that happen to be sometimes introverts slow down, listen, wait. They've also had to try to learn to respond faster because as an extrovert, if I ask you a question, all of a sudden I'm looking at you, I'm not getting a response, I'm thinking you're not understanding the question. I rephrase the question and now you're in a deficit to two questions.

And now I'm even worse because now I'm like, "Hayley isn't understanding me. What's happening here? Let me rephrase it again." And it can easily fall apart. What I have seen when teams aren't in alignment is that the team isn't a team any longer. It's miserable to go to the team. It's miserable to come into work, when the team is truly aligned, you're rocking and rolling. It's a feeling like you've never had. It's hard to explain to people that when you see the team, because you know it when it's working and you obviously know when it's not working, you're starting to miss deadlines. Integrations aren't happening on time. You don't have a single source of truth. You start having people explaining the same thing in two, three different matters, different priorities. We're not working from the same hymnal. The thing that I took from my... I'm an SPC, so as an instructor, the one thing I always try to explain to everybody, you may have the best of everything out there, but that's not necessarily mean it's going to work together.

So you have to have that type of understanding, how we're going to work together, what is our priorities, what's the tool sets we're going to have and what is our values as a human beings to this team if that... I'm hoping that helps describe some of the things that I've seen that have gone really bad. I have seen it at, I can share a customer that I have seen it gone, but we started off with good intentions. It's a financial institution in the United States and they were trying to make the jump to mobile applications. And at first we were on the same page as a team, but they decided that they didn't believe that cadence was required to be the same across the board. They didn't believe that we could use the same one tool set, we could use multiple different tool sets.

They had spreadsheets flowing all over the place. And what was happening was we lost trust. We were redoing work, there was ambiguity everywhere. We were misaligned and we started paying for it because our customers started complaining. They could see it in the quality of the work. One team had one schema, one background, one type of... You could see the difference when they integrated, it seemed like it was two applications being put out there mashed together. And when you're misaligned, that comes through very, very quickly in your work. There's a saying that we have here. There's a scrum master, I know her name was Sophia Chaley, one of the best I ever met. And what she will always tell people is what a team delivers is what the team is doing is learning. It's building knowledge, it's expressed as code. When we're misaligned, we're learning different things and we're expressing it differently in the code, if that makes sense.

Hayley Rodd:

Like thinking about the fundamental building blocks of team alignment, is there something that a team really needs to get right to be successful at alignment? And what is that in your mind?

Tony Camacho:

Oh, that is for sure. They had to get that right. First of all, the size of the team.

Hayley Rodd:

Yeah, okay.

Tony Camacho:

Human beings, and I'm not referring back... Going back to say for our scrum practices, I am a CSM. I do know they recommend 8 to 13 people. My best teams have been typically a little bit larger than that. But we had to have the same agreed to the size of the team where it didn't became, didn't become too large where we were over running each other and we weren't listening to each other. We had to understand our goals. We all had the same goals. We used to practice this by, when I worked at Microsoft, we used to have what we used to call our elevator speech. And we would stop somebody and I would go, we're working on this. Watch your elevator speech for this. And if your elevator speech wasn't... It wasn't meant that it had to be in sync with mines, but if I didn't understand it, we had a problem.

Or if it was a different goal where I'm looking at you going, but we're building a Volkswagen, but you're describing to me a Lamborghini, we have a problem. And those were the type of things that we also had to have to make sure that we had the right... Same practices and the tools. That's where I find Easy Agile exceeds. I mean it just exceeds, it meets above the market. It's transparent and it shows everything in front of you right there for me. So when we had the same tool and we were having the same cadence and we could see our dependencies and we could see what I had to deliver for somebody else or somebody had to deliver it for me, that was the types of things we had. We had to have respect. Somebody seems to always forget that we always had to have respect for each other.

We had to embrace the same values of collaboration, adaptability, transparency. The practices that we all know, but somehow we seem to forget when we get into a place where we are not aligned and if you respect my ideas and I respect yours and we're working together, we do not have to agree. But that respect will drive us a long way towards getting to that project vision that we want. And we're trying to meet the customer's needs. And those are the type of things that we needed. We needed leadership. Leadership, I can't say, and if you notice I'm not using the word management, leadership is where you're putting yourself out there in a situation where it can go bad for you as a person, as that leader, trying to make sure that we're making the right choices empowering the people and making them very clear what they can make decisions on and they can't. And it sounds so simple when I talk to you like this, but every time I've had to do some type of transformation, the baggage that sometimes we bring as human beings, the fears, the lack of trust that we have, that's where the scrum masters of product owners come in. And then you need something to make sure that you're having that vision to communicate that vision across. As I mentioned before, some of the tool sets that we have out there. Is that making sense for you at all?

Hayley Rodd:

Yeah, it really does. It's really resonating with me. I think when you talk about coming together as a team and putting together a set of values and a vision, it seems so much like a a "duh" moment. It's like, of course you would do that as a team, but I think at the end of the day as teams, we get in the daily business as usual and we think, I don't have time to get together as a team and set that vision because I've got to do X, Y, and Z, that's due next week. But I think it's one of those fundamental building blocks that really sets you up for success to do X, Y, Z quicker down the track. So that's what I've taken away from that.

Tony Camacho:

And I would agree with you. And you came up with a perfect example because a lot of people do that. I have ABC to do for next week, daily. I don't have time. And the problem is that if they would suddenly realize, and it does become apparent to your practices. So once you agree on your practices, your daily standups, if you're doing that, your retros at the end of your sprints and moving forward, once the person feels that they have that respect for you and they're not fearful, they can share that with you, "Hayley, I'm having a problem. I'm having way too much work. I don't know if I am going to be of value here. Or Do you really need me?" "Yes Tony, I do need you, we're going to discuss this and let's discuss your A, B, C and see how I can help you." And they suddenly realized they're not on an island alone. Developers by nature being introverted, we have to break that habit. We have to be able to share. And it's funny, I'm not saying share my lunch, fine, sure, let's share our lunch, but share the workload.

The one thing that I always try to mention to teams, and again that's... I'm sorry, but I do believe in Easy Agile, using this tool. That's where easy Agile also to me makes it apparent. A story belongs to a team, not to a person. And once you know that you suddenly realize, I'm not alone. I'm here working as part of a bigger thing. And most human beings want to be part of a bigger thing. You suddenly realize that it's almost like the baseball metaphor that I use for teams. And I know the market is not baseball, but I think it would apply for other sports, be cricket or sports like that. When I'm batting, it's me against everybody. When I'm on the field, it's us against... I prefer being with the us. And generally that's where things like that, let's do that.

Also, when you're working with more people as a team, there's things that happened there. You minimize the project risk, which I hate using the word project. It should be initiative. It's long living. You're usually a much more adaptable. I don't know all the answers. So when I worked with you, Hayley, and you showed with me some things there, you're one of the most humble people I've met, and I loved it. But when you walked through, you walked me through the tool, it became very apparent, you know it, you feel it, you love it, it's part of you. And that to me is invigorating. It's energy. Who wouldn't want to work with somebody like you? Why not? Let's do this. Right?

Hayley Rodd:

Thank you Tony. I guess one of the things that I wanted to touch on is when you're in a team and you're coming together as a team, you're working on something, how does an individual who seeks recognition for what they're doing, how do they get that? Or how do you leave that? How do you put that ego aside and say, "I'm doing something as a team to the better of the team?" Have you ever come across that or considered that? I'm interested in your thoughts.

Tony Camacho:

So the people that I felt that needed to have that typically how I... Yes, that's a great question because I'm thinking specifically. There was one, a scrum master that I thought that did it the most amazing way ever. Basically she would call out the ideas even if it wasn't that person's, yeah. I feel that Hayley is... You're not having a good day, Hayley. You're not having a good day. And I know you are not getting used to doing, working in the scrum team. It's new to you and everything else. And what she did typically was in front of everybody would be, and it wasn't even your idea sometimes. And she would just say, and Hayley came up with this wonderful idea that's going to save us something, move us forward. Hayley said this to me, it made us think as a team. And we went around it, we talked and we did it.

And that person always usually would be like, "Wow, I got credit for something. Good scrum-masters will see that. Or good product owners will point that out." The other way that I've done it was using something like Easy Agile. It's a great tool to use, believe it or not. I would back off, I'm a developer, but I also played the role of Scrum masters for years. I would step back and I would let one of my teammates run it, hear their voice, feel empowered. It's amazing when you can have people feel empowered because what you're all talking about, there really is about a lack of trust, a lack of psychological safety. And it's for us to be an aligned team, you have to have trust there and you have to break down the fear of judgment. So the other thing that one time happened with a scrum master that I thought was wonderful was is that again against Sophia Chaley, chief stood in front of her room when there was this a bad sprint.

The sprint didn't end well. And she stood up in front of everybody and she basically went, "Sometimes you win, sometimes you learn. This was a learning sprint." She pulled up Easy Agile, she was using at a time, pulled it up, showed the things that didn't work out the way they thought they were going to work out. And she said, these are the actions we're going to take to improve this. And then when somebody who was in management, again not using the term leadership, now I'm using the term management on purpose, was looking to assign blame. Her response was, not screaming, not raising her voice. Her response was, if we need to get rid of somebody or blame somebody, blame me. But I'm here to solve the problem. Let's move forward.

Hayley Rodd:

Wow.

Tony Camacho:

She wouldn't tell. And that was to me was one of the most outstanding moments I've ever seen. And she was at that point actually using Easy Agile that wasn't a financial institution in the United States. I would let you know that teachers use it, figure it out. And she basically showed the board and just went through everything and did that. That was leadership. That was leadership. And generally your teams will follow leadership and they will suddenly step up and you'll see that that's what people who want to stand up. Now, not everybody wants to do that. Some people want to just be team members and that's okay. That is perfectly okay, but the thing that's not okay is that if they don't have trust, right? And to me, that's the biggest thing. When you have people who are resisting change or siloed in their world, they suddenly realize if you can get them to open up it's really, they're just telling you, I don't feel safe.

I've been doing this all my life. I'm great at it and now you're asking me to do this. And you need to somehow get them to get the feel that they are bringing something of value. They are helping you move forward. And you're meeting them halfway if you have to. But yeah, that's the biggest problem I've ever seen that we've always, it always comes down to the human being in that. The rest of it, you can always come, you can always change that. But there's some of the things that you also have to do. I think that some people run into Hayley that I think me and you live in our world as we're moving up is sometimes we are, there's an ambiguity of the things that we have to do. And I've seen you do that, people in our roles will have suddenly, even if it isn't part of our role, will take it on and we have to learn. That's it. But yes.

Hayley Rodd:

Yeah, I think that, yeah, it's so true that the [inaudible 00:19:23] the psychological safety needs to be there. And I think back to so many teams that I've been a part of that it isn't there. So you have to feel like you got to lay your mark or put your mark on something and show your value. Because if you're not showing your value, then you get questioned. And so I think that that's such a common thing that I see in teams and it actually creates, not a camaraderie, but a competition between teammates and it breeds the wrong environment. So it's just really interesting. One thing that I did want to touch on that you spoke a lot about a couple of questions ago was respect and making sure that teams have respect for each other. How does a team member show respect for their teammates? What are some really good examples of respect and how can we display it or embody it or enact on it as team members?

Tony Camacho:

So let me show you a lack of respect right now. Yeah. Hayley, we're talking about this.

Hayley Rodd:

Looking off camera, avoiding me. Yeah.

Tony Camacho:

One of the main things was to really to learn to listen. Sit down, believe it or not, I found the best thing is sometimes taking a deep breath, listening, not responding, recognizing what that person may be feeling and going through at that moment because it's hard what we do. It's half art and it's half science. Let them learn that making a mistake is not a failure, it's a learning moment. Have that discussion there. Take their concerns real. So it's funny because you just made me think of something. That's one thing where I could show respect to my teammates would be as a scrum master, if I was a scrum master, hold effective retros. Really listen to what they're saying in the retros, report back on the things that you said you're going to improve in the retros. So we said these are the three things we're going to improve on or these are things that are assigned to me.

Make it real. Make it a story. Show it on the board and say, "This is where we're going. This is what's happening. This is what I'm blocked by. Can somebody help me?" But I am working this for you. Get them, really be sincere. I don't mean buying pizza or bring a lot of scrum masters will bring pizza and donuts to the office. No, it's make their lives really better. Be that advocate up for them. And if you're a teammate, be an advocate for each other and be sincere. Have the bravery to stand up and say that's not a fair assessment. But the biggest thing is to really listen. Because a lot of times when somebody's saying something to me, I'll make it personal. Me, I have sometimes have, I know I'm feeling uncomfortable, but I cannot explain why. And just having you there, looking at me and talking and going through it, I suddenly realize it may have been something different and I want to hear your ideas.

But I would have to, if I wanted to show myself to help that teammate, I also got to make myself vulnerable. If you're coming to me, I should share, but I should active listen, right? And really I respect your different perspective. It's okay. We all have different perspectives. Problem I find is that in ourworld, that we're moving so fast sometimes we don't stop to listen. We lack patience. We're moving too fast. So I'll share one for you that I'll be sincere. I had something medically came up and I was being a little abrasive with the team. So finally I called a meeting with our team and they saw me cry. I was okay with it. I was like, "I had no reason to be like this. You guys were showing me love, you were showing me respect, you're backing me up, helping me with my work. And I was still being utterly terrible."

And it hurt me. It hurt that I was doing that, but I needed them to see me and I needed them to listen to me, give me that second to get it off my chest. And in the end I started crying. A 60-year-old man crying in a meeting going, "I shouldn't have done that to you. That was wrong." And it wasn't contrived. Some of the people there were 20 year old people on my team and they were in tears. And it was because they felt, they told me after this, they felt my pain that I was in, because I wanted to help. It's the most frustrating thing. To your point before, how do I feel? I wanted to help. I wanted to be there and I couldn't. Physically, I wasn't there. My mind was all over the place and I was being rude, being blunt, and I could use some other terms. Please don't. But that's really the main thing for me was it's really simple what we do. I just listen and just show respect for other people. And sometimes we forget.

Hayley Rodd:

I think that so many of the messages that you are talking about are not just for developer teams, they're for every team, every team in every walk of life. I think that they're just so fundamental to successful human relationships, whether it be personal or professional, I think so. I think there's just so many good messages. One thing that I wanted to touch on was that you're talking about active listening and when you think back on your career, and maybe this is totally off script, but when you think back on your career, how have you become a better active listener over the years? How have you improved that skill? As you said, you're an extrovert, you want to get in there, you want to fix the problem. How do you get better at that?

Tony Camacho:

I had some very, very smart people that put up with me, listened to me, and then had the courage to approach me after and teach me and teach me and didn't embarrass me in front of anybody. Did it in a manner that they said, "Do you think maybe this could have been better Tony?" As I said, I'm 61 and still I'm an extrovert and I still have high energy and I still make mistakes. As I tell everybody, every day I wake up, I make a mistake, I just got up. But I could have stayed in bed longer. But also the thing that I've learned, and it's just by the nature of getting older, it's not the age part of it. It was watching people come up trying to do the same thing I did that I failed at and I was an instructor for Microsoft for a long time.

And seeing how, because to me seeing how a person's minds works is amazing. So what happens is I'll just... You know what I tried that, it didn't work for me, but I will say after class with you to show it to me again because maybe you solved it. I'm not that arrogant. And the nature of our business is that I find this, that the more you learn, the more you realize how little you know. That was the biggest thing that opened my eyes. Now it's like, oh my Lord. You meet somebody like John Kern, you meet somebody like Sophia Chaley who come from different perspectives, brilliant people, and you suddenly see that they happen to do things slightly different and you just watch them and you're like, "Wow." And the thing that I love about our job, which I guess you must love, everywhere we go, every team we work with, it's different. It's different.

Everybody always asks me, how do you do that. And I'll tell them, "Look, I will share with you the ways I did it. I have a varied background. I've always been consulting." I've done the ATM space, I did for space enabled warfare, I've done for health industry, everyone's been different. Someone from government regulation, but most of the time different human beings. So I have a saying, I've earned every scar in my back, their minds. I've learned people, you have to give people the chance to have their scars. Yes, it may be pain, I'm not saying fail, I won't let them fail. But sometimes people want to do something. So that's the way I would do it. Let them do it. And I just watched and learned that what happened was as I went in and the more I learned and I suddenly realized how little I know, I was like, I started with FORTRAN, I used to work in the dead 28.

And then you start working your way up and you start realizing, "Wow, I don't know as much as I thought I know." And I had the luck of running into working at Microsoft and having the pleasure of meeting Bill Gates. Now, no matter what you say about Bill Gates, because a lot of people do say some crazy things and some of them may be true or may not. But the one thing you can't take away from him is you go into a room with him and you suddenly see how he puts all these ideas together and comes up with a bigger picture. You suddenly realize, "Wow, people tell me I'm really smart, not that smart." And then you learn, humility is a good thing.

Hayley Rodd:

Yeah, I think humility is just such an important asset to have and to try and grow on because leaving your ego at the door and being open to learn from other people and not think that everything is definitely a life lesson that sometimes you need to go through. And some people go through it and still don't take away the life lesson. So yeah, I think it's so interesting. I guess we don't have too much longer left, but I wanted to touch on thinking about it from an ROI perspective. How important is team alignment from a return on investment? What do you gain from a business perspective when you have an aligned team?

Tony Camacho:

So I'm going to use a term that I dislike and Hayley, you can smack me the next time we meet. But I'm trying to use it as, I don't because it's effective resource utilization, right? But I'm not referring to human beings to that point because it may be human beings. The problem is that's a large market. But as Agile people I won't refer to you as a resource, I refer to you as a fellow human being, you are a partner on my team. You're my teammate. You're not a piece of wood. But that is unfortunately a term that is used. And we will have effective utilization, we'll have common goals across our organization. If you're using any of the message less, bad, safe, pick it, you start focusing on your value streams. You should have improved product quality because we have the same cadence. We're putting things out there and we're having the same views there.

You'll have I think better customer satisfaction and loyalty. They start seeing your product quality going up, being consistent, look and feel and hopefully you are delivering what they want. When you have your teams aligned, you're much more adaptable. Hayley, your team's got capacity? I don't. We don't have capacity to do this. Do you have capacity? Yes I do. Or we find someone or we break it down together and we present an idea to our partners. That's the things I like and I think in the end you have reduced risks at that point.

Also, I think that the thing that they have in is that it's indirect, but nobody knows about. Nobody really talks about it is that if I was upper management C-suite, when we start doing this and we're having the teams aligned, first of all, your teams become safer, your teams feel more comfortable, they're working with the same people. They start becoming very effective and they start producing ideas. They're the knowledge workers. They know this better than anybody else and then they feel empowered to share ideas. The places that I thought that I had the best teams was once they asked... Well, and I got it, I don't know how, I was running a train and they asked to talk to the CTO and all they wanted to do was to talk to the CTO and make that person human. They asked her what she did in a previous job. Amazing. She worked as a factory worker and she also worked in construction. She used to drive, one of the things, nobody would've believed this. And what happened was they started sharing ideas with her and she embraced them. You know what that did to the team, the teams all, they were like, now that's out there, that's ours. Look at that. That was ours. I mean ownership, it's unbelievable.

And unfortunately we are working on a capitalist market, which is fine, that's who we are. I mean we're in IT, it's a return on investment. Return on investment in the end, you start seeing much more efficient use of your money, much more efficient use of your dollars. Also, I would also imagine for the people above who are in the C-suite, they suddenly realize that the organization is going in the same direction. I think psychologically they feel that we now I have this team behind me pushing towards the same goal where a lot of times, every time I do an agile transformation, the first thing we always hear is we know they're working. We don't know what they're working on. And that's where something like Easy Agile bridges that and then you can use that information to go further. And that's wonderful because then at that point, everybody's on the same page. So you're a team now all the way from top to bottom. As opposed to I'm going to my team at work and that's it. So it's just really about return on investment, making sure that we are hitting our customers with everything we got. And I don't mean in a bad way, but we're delivering for our customers with everything we got. It's now efficiency, right? And that's it. That's about it.

Hayley Rodd:

Yeah, that's so powerful. I think it sort of nicely ties everything together because we've talked about a lot of things in the last half hour or so. And I think that at the end of the day, if you can get team alignment, just as you said, there's this ROI that can really shine through and it's a powerful thing for the whole organization to get right and to see the fruits of that work. So one last thing. Can you share your perspective on PI planning? I know you just mentioned safe a little bit for being the initial launchpad for team alignment.

Tony Camacho:

I love it. You have everybody in the room, you get to meet the people, you start making those connections to people. You start seeing them as human beings, not as this email or this text that you're sending across that you're going through there. So could I share one real experience from that? That's a PI planning house.

Hayley Rodd:

Please

Tony Camacho:

Do. So when I was working at Microsoft, I work for product quality online, which I know right now, considering the problems Microsoft is having, you're pretty much going now, "You suck Tony."

Hayley Rodd:

Never.

Tony Camacho:

No, we had our people distributed all over the world. And what was happening was that when I would talk to my short teams, I would ask them, and I was being facetious at a point because I just couldn't get the true answer was I would ask him, can you build the Twin Towers by tomorrow? And the answer would inadvertently be yes. Next day would come. Obviously you can't do the twin towers overnight. Ask them again, will you get it by next week? The answer would be yes. And they were feel for all of that. So when we had the PI planning, we did.

Microsoft went, got a hotel room in Seattle, a hotel room, a hotel in Seattle, rang our offshore teams. And then when they got to see me in person, they suddenly realized that I wasn't telling them I need the twin towers by tomorrow. I really wanted them to tell me when they could get me the twin towers. And I would defend it because they saw me right there in PI planning, defending, saying, "No, this is not possible." And when they saw me doing that, suddenly it was like the sky's open, sun's came through and now I was getting true answers. And what happened was it gave him an opportunity. And I realized that guys, you keep hearing me as sermon. It's always about the human beings, it's about those connections. It's about seeing the people. It's hard. It's two days of a lot of work. But once you get that work done, you come out of there a line, sharp direction. We know what our north is, now, do we know exactly where our true north is? As an agile team, we shouldn't, right? We should be refining it as we get there.

Find out exactly. But we know more or less where the direction is. We more or less know we're all on the same page. We all know that what we have to deliver to make this work out what other people have to deliver for us or we have to deliver for other people. So we suddenly feel part of something bigger. Bigger, right? We are now talking to the, if you're a developer or an engineer, software engineer, you're starting to see the power brokers and why they're doing this. You get the chance to ask them questions. What more could you ask for, right? I finally get to see the people who are making the decisions and I can ask them why. And they can tell me what the business value is and I can make the argument to them that maybe I don't think that's as much business value or we need to fix these things first before we can get that right and move our way on. What more could I ask for? I have an opportunity to make my case and I get to see the other people I'm working with. It becomes, when you're dealing with 125 people and you're on a train, you will become family.

We spend more hours sometimes with these people than we do with our family members at times. And it also gives you a sense of... Besides trust, a sense of a safety. You know it's not just you, it's all of us. So the saying that usually I see that the better executive say, I heard that in one PI planning, you fail, I fail. I fail, you fail. My job is to keep you employed. Your job is to keep me employed and to keep this company together. It's synergy, right? So it's amazing.

Hayley Rodd:

Beautiful.

Tony Camacho:

Yeah, I know. I'm all about the human. Sorry.

Hayley Rodd:

No, I am right there with you. I'm so glad that we got to have this conversation. We've talked a lot over the little while and every time we meet, I'm flabbergasted by your energy and your authenticity. And I think that this conversation that really shown true, so thank you Tony for taking the time to be with us. I'm going to say goodbye to all our listeners. I'm going to say another big thank you to Tony. So Tony is part of aligned agility and that is part of The Adaptivist Group. And yeah, thanks Tony for being here with us and thank you for everyone who has tuned in and listened to this episode of the Easy Agile Podcast. Thank you.

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