Easy Agile Podcast Ep.18 Top qualities of an agile leader and team

"It was great chatting to Caitlin about the importance of the Team Retrospective in creating a high performing cross-functional team" - Chloe Hall

In this episode, I was joined by Caitlin Mackie - Content Marketing Coordinator at Easy Agile.

In this episode, we spoke about;

• Looking at the team retrospective as a tool for risk mitigation rather than just another agile ceremony
• The importance of doing the retrospective on a regular cycle
• Why you should celebrate the wins?
• Taking the action items from your team retrospective to your team sprint planning
• Timeboxing the retrospective
• Creating a psychologically safe environment for your team retrospective

I hope you enjoy today's episode as much as I did recording it.

Transcript

Chloe Hall:

Hi, everyone. Welcome to the Easy Agile Podcast. I'm Chloe, Marketing Coordinator at Easy Agile, and I'll be your host for today's episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which I am recording today, the Wodi Wodi people of the Dharawal Speaking nation and pay our respects to elders past, present, and emerging. We extend that same respect to all Aboriginal and to Strait Islander peoples who are tuning in today. So today, we have a bit of a different episode for you. I'm going to be talking with Easy Agile's very own Content Marketing Coordinator, Caitlin Mackie. Caitlin is the Product Owner* of our Brand and Conversions Team*. Now this team is a cross-functional team who have only been together for roughly six months. And within their first few months, as a team, mind you they also had two brand new employees, they worked on a company rebrand.

Chloe Hall:

A new team, a huge task, the possibility of the team being high performing was unlikely at this point in time. So, the team was too new to have already formed that trust, strong relationships, and psychological safety, but somehow they came together and managed to work together, creating a flow of continuous improvement and ship this rebrand. So, I've brought for you today Caitlin onto the podcast to discuss the team's secret for success. Welcome to the podcast, Caitlin.

Caitlin Mackie:

Thanks, Chloe. It's a bit different sitting on this side. I'm used to being in your shoes. I feel [inaudible 00:01:45]. I feel uncomfortable. [inaudible 00:01:46].

Chloe Hall:

Yeah. It's my first time hosting as well, so very strange. Isn't it? How are you feeling today?

Caitlin Mackie:

Yeah. Good. I'm excited. I'm excited to chat about our experience coming together as a cross-functional Agile team, and hopefully share some of the things that worked for us with our listeners.

Chloe Hall:

Yes, I know myself, and I'm sure our audience is very excited to hear what your team's secret to success was. Did you want to start off by telling us what was this big secret that really helped you work together as a team?

Caitlin Mackie:

That's a great question, Chloe. And that's a big question. I'm not sure if there's one key thing, I suppose, it is that ultimate secret source or that one thing that led to the success. I'm sure we all want to hear what that is. I would also love to know if there's just this one key ingredient, but I think something for us, and probably one of the most memorable things that really worked for us, and there was a lot for us to benefit from doing this, was actually doing our retrospectives. So that's probably the first thing that comes to mind when it comes to what led to our success.

Chloe Hall:

Okay. Yeah. In the beginning, why did you start doing the retrospectives?

Caitlin Mackie:

So, we were a new forming team, like you mentioned before, and we seen retrospectives as another Agile ceremony, and we saw other teams doing it and they were having a lot of success from it, so we became to jump on that bandwagon. And I think with being a new forming team, there are so many things that come into play. So, you're trying to figure each other out, how we all like to work and communicate with each other, all of that. And we were the first ever team dedicated to owning and improving our website. And we also knew it was likely that we'd be responsible for designing and launching a rebrand.

Caitlin Mackie:

So when you try and stitch all of that together, and then consider all those elements, we knew that we needed to reserve some time to be able to quickly iterate and call out what works and what doesn't. And what we did understand is that retrospectives are a great opportunity for the whole team to get together and uncover any problematic issues and have an open discussion aimed at really identifying room for improvement, or calling out what's working well, so we can continue to do that. So, I think retros allowed us to understand where we can have the most impact and how to be a really effective cross-functional Agile team.

Chloe Hall:

Wow. That is already so insightful. Yeah, it sounds like the retrospectives really helped you to gain that momentum into finding who your team is, becoming a well-working, high-performing cross-functional team. So, how often were you doing the retro? Were you doing this on a regular cycle, or was it just, "Okay. We have a problem. Some blockers have come up, we need to do a retro"?

Caitlin Mackie:

Yeah. I think initially retro, we kind of viewed retros as this thing where like, "Oh, we've done a few sprints now. We should probably do a retro and just reflect on how those few sprints went." It was kind of like this thing. It was always back of our mind. And we knew we needed to do it, but weren't really sure about the cadence and the way to go about it. So now, we do retros on a Friday morning, which is the last day of our weekly sprint. And then we jump into sprint planning after that. So after bio break as well, so let the team digest everything we talked about in retrospectives. And then we come into sprint planning with all the topics that we're discussed, and we will have a really nice, fresh perspective.

Chloe Hall:

Yeah.

Caitlin Mackie:

So, I think this works really well for us because everything is happening in a timely manner. We've just had a discussion about the best things that happened in the sprint or what worked really well, so you want to make sure you can practice the same behavior in the following, and vice versa for the improvements that you want to make. So, that list of action items that come out of a retrospective provide a really nice contact, context, sorry. And you have them all in mind during sprint planning.

Caitlin Mackie:

So for example, in the previous sprint, it might have come up that you underestimated your story points or there wasn't enough detail on your user stories. So, with each story or task that you are bringing into the sprint, you're then asking the question, is everyone happy with the level of detail? What are we missing? Or we've only story pointed this or two, is it more likely to be a five? So, everything is really fresh in your mind, and I definitely think that helps create momentum. When you've got the whole team working to figure out how you can be more effective with every sprint.

Chloe Hall:

That's such a great point that you just made Caitlin. And I love how going from doing the team retrospective, that you actually can take those action items and go into your sprint and put them into place straight away. It's really good. Otherwise, I feel like if you do the sprint retrospective on the Friday, and you're like, "Okay, these are our action items," get to Monday sprint planning and you're just thinking of the weekend. That [inaudible 00:07:20]

Caitlin Mackie:

Yeah, a hundred percent. Yeah. They're super fresher mind for everyone. So, it might not work for every team, but we find it works really well for us, because we're being really deliberate with how we approach sprint planning.

Chloe Hall:

Yeah. And then with that, I could see how doing the retro, how it could easily go over time, but then your team has sprint planning scheduled after. So, it's like you can't go over time. How have you managed to kind of time box that retrospective?

Caitlin Mackie:

Yeah, that's a really, really good question. And it is on purpose as well that they are scheduled closely together. Som as mentioned above, the discussion you've had in the retrospectives provides a nice momentum going to the sprint planning, but it does mean we have to watch the clock. And initially, this can be quite awkward, because you want to make sure that everyone feels heard and that everybody has the same opportunity to contribute. And I think this responsibility falls on the scrum master, or the product owner, or whoever's facilitating the retrospective to call it out and make sure everyone has the chance to be heard. You'll naturally have people tell the longer story or add a lot of extra context before getting to the point. And then you'll have others that will be a lot more direct. And I'm a lot like the latter. I struggle to get to the point, which doesn't work well when you're trying to time box a retrospective, right?

Chloe Hall:

And I can relate, same personality.

Caitlin Mackie:

Yes. So with this, I think it really comes down to communicating the expectation and the priority from the get go. With our team and with any team, you will want to figure out who you can perform really well and continually improve to exceed expectations and be better and learn and grow together. And I think if you all share that same mindset going into the retrospective and acknowledging that it's a safe

space to have difficult conversations. And as long as you're communicating with empathy, the team knows that it's never anything personal, and it's all in the best interest of the team. And that then helps the less direct communicators, like myself, address their point more concisely and really forces them to be more deliberate and succinct with their communication style.

Caitlin Mackie:

And that's really key to being able to stick to that time box, I think. And it does take practice, because it comes down to creating that psychological safety in your team. But once that's there, it's so much easier to call out when someone's going down a windy track, and bring the focus back and sort of say, "I hear you, what's the action item?" And just become a lot more deliberate.

Chloe Hall:

Wow. I couldn't even imagine like how hard it would be, with the personalities that yourself and I have, just trying to be so direct and get rid of all the fluffy stuff. I mean, look at what it's done to form such an amazing team that we have. So, you mentioned that aspect of psychological safety before. And how do you think being in a new cross-functional team... Only six months together, you had those new employees, do you think you were able to create a psychological safety space at any point?

Caitlin Mackie:

That's another fantastic question. And I feel like, honestly, it would be best to have a team discussion around this. It'd be interesting to hear everybody's perspectives around what contributes to that element of psychological safety and if everybody feels the same. So, I can't speak for the team, but my personal opinion on this or personal experience is that creating an environment of psychological safety really comes down to a mutual trust and respect. And at the end of the day, we all share the same goal. So, we all really, really respect what each other brings to the table and understand how all of these moving parts that we are working on individually all come together to achieve the goal. So, when we're having these open discussions in retros, or not even in retros, just communicating in general really, it's clear that we're asking questions in the best interest of the team and individual motives never come into play, or people aren't just offering their opinion when it's unwarranted or providing feedback, or being overly critical when they weren't asked to do so.

Caitlin Mackie:

So, none of those toxic behaviors happen, because we all respect that whatever piece of work is in question or the topic of discussion, the person owning that work, at the end of the day, is the expert. And we trust them, and we don't doubt each other for a second. And I think the other half of that is that we're also really lucky that if something doesn't go as we planned, we're all there to pick each other up and go again. So, this ties quite nicely into actually one of our values at Easy Agile is commit as a team. And this is all about acknowledging that we grow and succeed when we do it together, and to look after one another and engage with authenticity and courage. Som I may be biased, but I wholeheartedly believe that our team completely embraces that. And there's just such an admiration for what we all bring to the table, and I think that's really key to creating the psychological safety.

Chloe Hall:

I love that your team is really embracing our value, commit as a team and putting it into place, because that's what we're all about at Easy Agile, and it's just so great to see it as well. I think the other thing that

I wanted to address was... So again, during this cross functional team, and you've got design and dev, how do you think retros assisted you in allowing to work out what design and dev needed from each other?

Caitlin Mackie:

For sure. So, for some extra context for our listeners as well, so in our team, we've got two developers, Haley and David, and a designer, Matt and myself, who's in the marketing. So, we're very much a cross-functional little mini team. So, we all have the same goal and that same focus, but we also are all working on these little individual components that we then stitch together. So,, I think... We doing retros regularly. What we were able to identify was a really effective design and development cycle. So, we figured out a rhythm for what one another needed at certain points. For example, something we discovered really early was making sure that we didn't bring design and dev work into the same sprint. We needed to have a completely finished design file before dev starts working on it. And that might sound really obvious, but initially we thought, "Oh, well, if you have a half finished design file, dev can start working on that. And by the time that's done, the rest of the design file will be done."

Caitlin Mackie:

But what we failed to acknowledge is that by doing that, we weren't leaving enough capacity to iterate or address any issues or incorporate feedback on the first part of that design file, or if dev started working on it and design then gets told, "Oh, this part right here, it's not possible," so the designer is back working on the first part. And it just creates a lot of these roadblocks. So in retros, this came up and we were able to raise it and understand that what design needed from dev and what dev needed from design in order to make sure we weren't blockers for each other. And the action item out of the retro is that we all agreed that a design file had to be completely finished before dev picks up the work.

Chloe Hall:

I think it's so great that you were able to identify these blockers early on. Do you think like doing the retro on a weekly reoccurring basis was able to bring up those blockers quickly, or do you think it wouldn't have made a difference?

Caitlin Mackie:

No, definitely. I, a hundred percent, think that retros allowed us to address the blockers in a way more timely and effective manner. And we kind of touched on that before, but yeah, retros let you address the blockers, unpack them, understand why they're happening and what we need to do to make sure they don't happen again. So, for sure.

Chloe Hall:

Yeah. Yeah. I guess I want to talk a little bit now about the wins, the very exciting part of the retro, the part that we all love. So, how important do you think the wins are within the retro?

Caitlin Mackie:

So important. So, so, so important. It's like, when you achieve something epic as a team, you have to call it out. Celebrate all the wins, big, small. Some weeks will be better than others, but embrace that glass half full mentality. And there's always something to be proud of and celebrate, so call it out amongst

each other, share it with the whole company, publicly recognize it. Yeah, I think it's so important to embrace the wins. It just sort of creates a really positive atmosphere when you're in the team, makes everybody feel heard and recognized for their really positive contribution that they're making. And I think a big thing here as well is that if you've achieved something epic as a team, it's helpful for other teams to hear that as well, right? You figured out a cool new way to do something, share it. If it helped you as a team, it's most likely going to help another team.

Caitlin Mackie:

So I think celebrating the wins isn't even just reserved for work stuff either, right? If somebody's doing something amazing outside of work or hit a personal goal, get behind it.

Chloe Hall:

Yeah.

Caitlin Mackie:

To celebrate all the wins always.

Chloe Hall:

Yeah. And I think it's so good how you mentioned that it's vital to celebrate the wins of someone's personal life as well, because at the end of the day, we're all human beings. Yes,, we come to work, but we do have that personal element. And knowing what someone's like outside of work as well is an element to creating that psychological safe space and team bonding, which is so vital to having a good team at the end of the day. Yeah.

Caitlin Mackie:

Yeah, a hundred percent. Yeah, you hit the nail in the head with that. We talked about psychological safety before, and I definitely think incorporating that, acknowledging that, yeah, we are ourselves at work, but we also have a whole other life outside of that too, so just being mindful of that and just cheering each other on all the time. That's what we got to do, be each other's biggest cheerleaders.

Chloe Hall:

Yeah, exactly. That's the real key to success. Isn't it?

Caitlin Mackie:

Yeah, that's it. That's the key.

Chloe Hall:

So, you've been working really well as a new cross functional, high performing Agile team. How do you think... What is your future process for retros?

Caitlin Mackie:

We will for sure continue to do them weekly. It's part of the Agile manifesto, but we want to focus on responding to change, and I think retros really allow us to do that. It's beneficial and really valuable for

the team. And when you can set the team up for success, you're going to see that positive impact that has across the organization as a whole. So yeah, we've found a nice cadence and a rhythm that works for us. So, if it ain't broke, don't fix it.

Chloe Hall:

Yeah.

Caitlin Mackie:

Is that what they say? Is that the saying?

Chloe Hall:

I don't know. I think so, but let's just go with it. [inaudible 00:19:02], don't fix it.

Caitlin Mackie:

There we go. Yeah.

Chloe Hall:

You can quote Caitlin Mackie on that one.

Caitlin Mackie:

Quote me on that.

Chloe Hall:

Okay, Caitlin. Well, there's just one final thing that I want to address today. I thought end of the podcast, let's just have a little bit of fun, and we're going to do a little snippet of Caitlin's hot tip. So, for the audience listening, I want you to think of something that they can take away from this episode, an action item that they can start doing within their teams today. Take it away.

Caitlin Mackie:

Okay. Okay. All right. I would say always have the retrospective. Don't skip it. Even if there's minimal items to discuss, new things will always come up. And you have to regularly provide ways for the team to share their thoughts. And I'll leave you with, always promote positive dialogue and show value and appreciation for team ideas and each other. That's my-

Chloe Hall:

I love that.

Caitlin Mackie:

That's my hot tip.

Chloe Hall:

Thanks, Caitlin. Thanks for sharing. I really like how you said always promote positive dialogue. I think that is so great. Yeah. Well, thanks, Caitlin. Thanks for jumping on the podcast today and-

Caitlin Mackie:

Thanks, Chloe.

Chloe Hall:

Yeah. Sharing your team's experience with retrospectives and new cross functional team. It's been really nice hearing from you, and there's so much that our audience can take away from what you've shared with us today. And I hope that we've truly inspired everybody listening to get out there and implement the team retrospective on a regular basis. So, yeah, thank you.

Caitlin Mackie:

Thank you so much, Chloe. Thanks for having me. It was fun, fun to be on this side. And I hope everyone enjoys this episode.

Chloe Hall:

Thanks, Caitlin.

Caitlin Mackie:

Thanks. Bye.

"Great convo with Dave & Eric! Key takeaway: revamp Easy Agile's org structure representation. Exciting stuff!"

Nick Muldoon, Co-Founder and Co-CEO of Easy Agile, is joined by Dave West, CEO, and Eric Naiburg, COO, from Scrum.org.

In this episode, Nick, Dave, and Eric unpack the current agile landscape, discussing the role of the agile native and emphasizing the importance of building connected teams by flipping the hierarchy and putting leaders in supporting roles.

They emphasise the importance of empowering the people closest to the problem to make the call, and ultimately creating an environment for success to happen.

We hope you enjoy the episode!

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

Transcript:

Nick Muldoon:

Hi folks. Welcome to the Easy Agile Podcast. My name's Nick Muldoon. I'm the co-founder and co CEO at Easy Agile, and today I'm joined with two wonderful guests, Eric Naiburg, the Chief operating officer at scrum.org, and Dave West, the chief executive officer at scrum.org. Before we begin, I'd just like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging, and extend the same respect to all Aboriginal, Torres Strait Islander and First Nations people that are joining us today. So gentlemen, thank you so much for making some time. We really appreciate it.

Eric Naiburg:

Thank you.

Nick Muldoon:

I guess I'd love to just jump in and, Dave, I've got a question for you first and a follow on for you, Eric. I'd love to just get a quick assessment, Dave, of the Agile landscape today and I guess the shifts that you may have seen now that we're out of these COVID lockdowns, these back and forth, COVID lockdowns.

Dave West:

Yeah, it's interesting. So I've been the CEO almost eight years here at scrum.org, and it has changed a bit during those eight years. I think what we're seeing and is a, dare I say, the deployment phase, mass deployment of these Agile ways of working and this Agile mindset throughout industries and throughout all organizations. It's more than an IT software development thing. And I think that that was accelerated during COVID. What's interesting though is many of the characteristics of Agile that became so important during COVID, particularly around empowered teams, particularly around trust, particularly around the hierarchy and the reduction of hierarchy, some of those things are being challenged as we return to the new normal, which some people would rather was just the normal. So I am seeing some of that. However, generally Agile is here, it's here to stay. I think the reality is that most knowledge workers, particularly those knowledge workers dealing in complex work are going to be using some kind of Agile approach for the foreseeable future.

Nick Muldoon:

And last week you... Was it last week? I believe you were in Paris for the first face to face?

Dave West:

[foreign language 00:02:37] I was and it rained the entire time actually, Nick. So yeah, I spent a lot of time inside in Paris.

Nick Muldoon:

Well, what was the sentiment from the Scrum trainers there, from the conversations they're having?

Dave West:

Yeah, it was interesting. We talked a lot about at scale, enterprise adoption, the challenges. It is funny that the challenges are challenges that you expect, and most of them are about people, legacy systems, people status, power position. We talked a lot about the challenges that teams are getting in these large complicated organizations. That continues to be the conversation. There is, obviously, this is Europe, they're very close to Ukraine and the conflict there. So there's definitely some conversations about that. We have six Ukrainian trainers and also about the same number of Russian trainers as well. So that's always a conversation. And then there's a general downturn of the economy that was also being talked about.

Layoffs are happening throughout Europe, and particularly in the technology sector, but I think that's growing to some extent. Vodafone just announced today that they were laying off, it's about 6,000 employees, and they're one of the biggest telecommunication companies in Germany, for instance. So there was definitely some of that, but so if you add enterprise, you add conflict uncertainty, you add economic uncertainty, those three things will come together. But what was funny in it is that throughout all of this, they were incredibly upbeat and excited. And I think because they're talking to people that they've never spoken to before, they're talking to people about how Scrum is a natural way of working, talking about the challenges of empowered teams, empiricism, continuous improvement.

And I had some really exciting conversations with trainers who were like, Yeah, well we're doing this in this aerospace company or this electric car supplier in Germany or whatever, or this financial services startup that's using blockchain for the first time. And of course they're using Agile. And so it was funny. It was almost as though all of those things, though there were the backdrop, it was still incredibly positive.

Nick Muldoon:

So this is interesting, and I guess if I reflect on the background for both of you, Eric, I'm looking at, you two have worked together from rational days-

Eric Naiburg:

A few times.

Nick Muldoon:

... a few times, but the prevalence of the Agile... I would describe you two as Agile natives and it sounds like, Dave, you've got your tribe there in Paris last week that are Agile natives. And I guess Eric, for you, what's the sense around the people that you are interacting with from a leadership perspective in these companies? Can you identify the Agile natives? Yeah, I guess is it an easier conversation if you've got Agile natives in leadership levels?

Eric Naiburg:

It's definitely an easier conversation if they're there. Sometimes they're in hiding, sometimes they're not Agile natives masquerading as Agile natives as well, which always makes it a little bit difficult because you have to peel back that onion and peel through who are they and what's their real agenda. I was talking to a CIO last week, and he was talking about the typical CIO lasts two to three years. So what is their real agenda? What are they trying to achieve? And Dave mentioned the people part of this, and people often become the hardest part of any Agile transformation or working in an Agile way. People want to protect themselves, they want to protect their turf, they want to do the things that they need to do to be successful as well. So you see that as talking to leaders within organizations, and they want to do better, they want to improve, they want to deliver faster, but they've still got that pressure. Organizations, at least large organizations, haven't changed. They still have boards, and they still report to those boards, and those boards still have their agendas as well.

Nick Muldoon:

You're making me recall a conversation that I had, this is several years ago, but on a trip through Europe, and it was with the Agile native, that was the Agile practice lead and probably wasn't masking, probably was legitimately an Agile native, yet they were talking about the mixed incentives for their, maybe not their direct leader, but the VP further up. And it was actually a, I don't want to say a zero-sum game, but there was some kind of fiefdom thing going where the various VPs would fight for resources, people, whatever, because that would unlock further bonus. But at the end of the day, it was not optimizing the entire financial services company. Are we still seeing that today?

Dave West:

Oh, very much so. In fact, a colleague of ours says, "Science used to have a saying, science progresses one funeral at a time." And I think Agile definitely has some of that, not funerals hopefully, but retirements.

Nick Muldoon:

Retirements

Dave West:

Retirement.

Nick Muldoon:

Yeah.

Dave West:

Yeah. The reality is that when you don't have incentives aligned, where you don't have teams aligned to those incentives and leadership aligned to those consistent incentives, then you're going to always be dealing with some challenges. What's so frustrating is we all know the industrial revolution, and particularly the recent revolution of mass production and oil, which just happened in the deployment phase just after the second World War, was enabled by changing working practices created by people like Ford and Deming and all of these people. We all know that. The digital revolution is happening around us. It may even pass us if you believe the AI buzz that's happening. We may be put to the side and computers may just take over, but this digital is happening, and you are in with leaders and they're like, "Yeah, totally respect that. We are going to be a hundred percent digital. We are an airline, but really we are a digital company with wings."

They describe themselves in this way, and then they don't want to challenge the fundamentals of how authority, how value is managed, how risk is made transparent, how governance is, it happens, how funding is made and planning, et cetera. They don't want to challenge any of those assumptions. They like that the way it is. But we are going digital. It is ironic that it still is happening. However, that isn't totally hundred percent. The organizations that get it, the organizations that have leaders that are either insightful, either motivated, or maybe they want to write a book or something. Maybe their reasons aren't always as clear, but those leaders are dragging these organizations into the 21st century.

Great example. Proctor and Gamble, Gillette. Gillette, the latest exfoliating razor. I can see you haven't used it, unfortunately, Nick, with your rather handsome beard. So yeah. Anyway, I use it a lot, as you can tell. The exfo... Was built using Scrum and Agile. This is Proctor and Gamble, an ancient, okay not ancient, an older organization, but really has got it. They realize that if they want to keep up with their customers, their partners, their suppliers, they need to work in quite different ways. And so it isn't roses, but there are roses in the garden as it were.

Eric Naiburg:

And it goes beyond, when you think of that organization, you think of what Gillette has done, is it goes beyond traditional Agile thinking. Traditional Agile thinking, we think software, and this is engineering, this is manufacturing, this is bringing together marketing because in those types of organizations, marketing drives what the product's going to be, and then engineering figures out how to deliver that product and so on. So it's really bringing together the whole organization into how do we deliver something, and deliver it together. I think that's one of the big things that we're seeing. And one of the big changes that Agile helps to drive is that team. So you talked about incentives and team incentives, that's a piece of it, but it's team ownership. It's team togetherness.

It is that ultimately they all feel accountable, and bringing that accountability together as a team versus, and I think even... So my wife's in manufacturing and it's always... She's on the R and D side of it, and complaining about the marketing people. You have those conversations of, "Well, they don't realize what it takes to actually build this thing. They just have the dream." And by bringing them together in that team, and really they're having their daily scrums, they're planning together and they're having those hard conversations respectfully, that starts to build that team and build them in a way that they're able to actually deliver faster and more what the customer wants.

Dave West:

Can I just lean in, I'm sorry, we just taken over here a little Nick, but I just want to lean into something that Eric said around it is all about the teams. One of the fundamental problems we see in many organizations is hierarchy. Because if you get these massive hierarchies, obviously there's, "I've got to be in control of something. I need to take ownership of things. I need to be off irresponsible for certain things." That's how hierarchies work. And so that often undermines the ability of a team to effectively function. We need to flip that so that these hierarchies become, instead of being on top of the teams, they need to be underneath the teams supporting them. Think of them as those support trusses on bridges or whatever. You have some fabulous bridges in Australia and in Melbourne and in places like that and in Sydney.

So think of it upside down, holding up the teams. But that means, going back all again to incentives again, that those leaders need to understand what they're responsible for in this new world. And they're doing it for very good reason. They're doing it because the teams need to be, they're closer to the problem, they need to be empowered to make the decisions in real time based on the data, the information they have, they need to have clean line of sight to the customer. All of those things are the reason why a hierarchy is just too slow to respond and too bureaucratic. So we need to flip it and enable those teams. And that's a huge challenge.

Nick Muldoon:

I Love this. You two have given me something to ponder. So for the first six years of the company's life, of Easy Agile's life, we did have a very simple team page, and Dave and I as co-CEOs were at the bottom of the page. And then you had the leaders of the pillars. So you had, at the time, Tegan was the head of product, the leader, and they sat on top of Dave and I, and then the team sat on top of that. And it's interesting, I'm actually trying to reflect now, it's probably only in the last 12 or 18 months as we went through 40 people, that that page or that visualization has flipped. I've got an action item obviously to come out of this, thank you gentlemen, to actually go and flip it back because it's a communications mechanism, but if we actually put ourselves at the foundation in this supporting role for supporting the folks, that sets the tone, I imagine, for the team members in how they think of themselves and maybe that accountability piece as well, Eric.

Eric Naiburg:

Yeah. Yeah. That's interesting because sometimes it's those little things that change how people think and feel. I use a lot of sports analogies when I talk and meet with people, and especially with where Dave was talking of empowering the people closest to the problem. We have to do the same in sport. If we have to wait for the manager to tell us to pass the ball, it's never going to happen. We've got to allow the people to make decisions and make those decisions on the field. We need to apply that to business as well. Allow the people who are closest to the problem, closest to what's happening, make those decisions within the business as well.

Nick Muldoon:

So if we come back to Proctor and Gamble, and we don't have to rabbit hole on it, but they're one of the large, long-lived companies, and I don't know about their approach, in particular, but I think about GE, and GE had their internal training university program, and they were training their leaders, training their managers how to manage, training their leaders how to lead. How does a Proctor and Gamble go about shifting that conversation internally, and what's that timeframe? Because presumably you've start with someone that's on a team. Do you have to elevate them over time through the hierarchy of the company?

Dave West:

It is interesting. I'm fortunate to spend maybe because we're both British people living in Boston, I'm fortunate to spend quite a lot of time with, and there's videos on our site with this, by the way, interviews with Dave Ingram who runs R and D for male grooming, it's called, in the Gillette part of P and G. And the case study is out there. So I talked to him a lot about how you drive it in a huge organization where they've got everything to lose. They've got products that are amazing, they've innovated, those products are the products that you put into your shopping cart as you walk down the aisle. They don't want to muck that up. Let's be frank. If suddenly, because of some innovation, there's no razors on the shelves, then I, as a board man need a razor. So I will buy an alternate product, and it's possible that then I'll always buy that product.

So they've got to be very, very careful. They've got more to lose. So we talk a lot about how you manage change and it's all of the above. What he's done very smartly is he's empowered the product owner role or the person, the glue role, whether it's using Scrum or something else, and he's really invested in these change agents in his organization, and he's definitely led by doing, he's been very honest and open about that, and very clear that he doesn't have all the answers and he's looking for them to help him during this, which isn't perhaps what you'd expect from a traditional organization where-

Nick Muldoon:

The leader might need to feel that they have the answer to all of these questions.

Dave West:

Exactly. And he's done a really, really good job of doing that. And primarily because he says, "Well, my success is ultimately their success, so if I can make them be a little bit more successful, there's more of them than me, so let's make it work." Which I think is an unusually honest and very insightful view of it. So he's driven it predominantly through product management ownership areas. He's then provided a support environment around that. He's then definitely advertised the successes. He's spent a lot of time building cross-functional teams. The thing that Eric was talking about. And really been very careful working with their leadership. If you're material science, there's a whole department, if there's marketing, there's this whole channel thing that they have. Basically working with their leaders to create the environment for success to happen. And I don't think it's easy. I think there's many surprising roadblocks along the way, and I can't speak for him on this, but he's taken that divide and conquer approach, focusing on that catalyst role.

Nick Muldoon:

Because you, obviously, you're providing a lot of training for various, well, I guess people at various levels in these companies. And obviously it's a far cry from having a CST and a CSM and a CSPO certification going back a decade, decade and a half. What's the uptake around the leadership training? And what does that look like, Eric? Is there renewed interest in that at the moment or are people demanding more of that leadership training? Is it fit for purpose for today's leader?

Eric Naiburg:

So I think to a point it is. We're certainly seeing growth in the leadership training. Matter of fact, Dave and I were just looking at those numbers earlier this week or yesterday, I guess. Today's [inaudible 00:21:29]

Nick Muldoon:

Are there are any numbers you can share with us?

Eric Naiburg:

It's hard to share the exact numbers, but we're seeing double-digit growth in number of students taking our leadership classes. Both how do you measure, so our evidence-based management classes, as well as our leadership training, but that also only goes so far because a lot of those folks, depending on how high up, especially in the organization you go, aren't willing to take lots of time out to take such training. So a lot of it happens in that coaching. They're hiring the executive coaches or the Agile coaches that are in there. The scrum masters that are in there are actually working to help coach those folks. And a lot of it's less about the training and more about the mindset shifts. So if you look at our Agile leadership course, a large part of it is spent on getting people to think differently. And really some of it's hit you over the head type of activities, where it really helps to drive those points across of, "Wow, I need to think differently. I need to work differently. I need to treat people differently."

Nick Muldoon:

Differently.

Eric Naiburg:

It's that, and we're seeing good success with that because especially when that light bulb goes off for folks, and that light bulb that goes off saying, "Wow, this is different." We have some exercises in our classes that really get you thinking and get you... There's one, for example, where you're thinking you're doing the right thing for the customer, and you're thinking you're doing exactly right until it kills the customer, because you didn't necessarily think through the whole. It's, "Well, this is what the customer wanted, so we need to do it, but maybe I should have got together with the team and let the team make decisions." I'm going a little extreme, but-

Nick Muldoon:

No, I appreciate it.

Eric Naiburg:

... it's those sorts of things that we have to change. And a lot of what we do in the course is educate leaders on what those teams are going through, and what the individuals on those teams need, and the type of support that they need, not how do you manage those teams, not how do you manage those people. But how do you empower and enable those people to be successful?

Nick Muldoon:

I want to just rewind for a second, sorry.

Eric Naiburg:

Killing people.

Nick Muldoon:

It sounded like there's a friction point in actually getting these leaders to take the time out of the office to go and get some education.

Eric Naiburg:

There is, yes.

Nick Muldoon:

Is that correct?

Eric Naiburg:

Yeah.

Dave West:

It's incredibly hard if you're at a large organization, in particular, when your schedule is overlapping meetings continuously eight to nine hours a day for them to take that moment to step back. Everybody, I believe very strongly, Nick, that everybody needs to take time to invest in their own personal and professional development. And that time is not a waste. Ultimately it is an incredibly good investment.

Nick Muldoon:

Yes.

Dave West:

We know-

Nick Muldoon:

It's great ROI.

Dave West:

Totally. Even if it just resets you, even if you have that moment of clarity because of it. it's not a surprise that people like Bill Gates go on retreat every three to six months and he takes his big bag of books-

Nick Muldoon:

Books.

Dave West:

And he goes off grid for a few days just to reset. I think that that time is incredibly effective. But what's interesting is, we are under, in America in particular, and I'm sure it's true in Australia, it's certainly true in England, where I'm from, motion is more important than outcomes. It's all about the motions. If you look busy, you're not going to get fired. And I think to some extent we learned that in school. I don't know if your parents said to you or maybe you got your first job. I was working on a delicatessen counter at the co-op supermarket, and I remember there was an old worker there, turned to me, he goes, "Whatever you do, when the manager walks by," Mr. Short-

Nick Muldoon:

Look busy.

Dave West:

... was his name. And he was everything that name implies. "Mr. Short walks by, look like you're doing something, start cleaning something, otherwise he'll take you off and make you do provisions, and you don't want to dealing with that milk, it's rancid." And I remember that. Look busy. And I think we've got a lot in our culture. I try to take time every week. I book, for instance, my lunch hour, I book it and I always try to do something in it. I try to watch a TED talk, read something, just to clear your mind to think about something different. I think that time is incredibly important. However-

Nick Muldoon:

Get exposed to some new perspective, right?

Dave West:

Exactly. Even if it means, even if the stuff you're watching or whatever isn't that relevant necessarily. Sometimes that lack of relevance is exactly what you need because your mind does something.

Nick Muldoon:

A mental break.

Dave West:

Exactly. And however in corporate America, and I think that's corporate in general, that doesn't happen. People are overly leveraged, they're incredibly busy. They have to attend these meetings, otherwise their profile is diminished. And I think that's at the detriment of the organization and the company. Here's a question, Nick.

Nick Muldoon:

Yeah.

Dave West:

Who have you helped recently?

Nick Muldoon:

Who have I helped recently? I spend most of my time, and I get most of my energy out of coaching conversations with individuals. So on my [inaudible 00:27:35] profile, I've got futurist very high up, and so I love exploring what is your life and your career going to look like in five years time? They're the conversations that I really get jazzed by.

Dave West:

And that's what everybody... Who have you helped is more important than what have you done.

Nick Muldoon:

Yeah.

Dave West:

And I think you need to balance that.

Nick Muldoon:

I pulled up these stats because I thought you might find them interesting. We did a survey last year of a subset of our customers. And we had 423 teams. So it's not a huge sample size, but 423 teams. And the reason I think about it is because there's a lot of, what was the statistic here? So just to give you a sense, most common sprint duration is 14 or two week sprints. Most teams have six people that are involved. Fibonacci for story pointing, an estimation. 10% of these teams achieved what they set out to achieve at the start of the sprint. And so the teams, this 10% of teams, the subset, they did add work into their sprints, but teams that were unsuccessful, rolled work from sprint to sprint.

And so perhaps what it indicated to us is that there are teams that over commit and under deliver, and in fact 90% of them, 90% of the survey teams, it would appear that they over commit and under deliver. And then there are teams that are, maybe, leaving time, Dave, maybe for some education or some spare time in their two-week sprint. And they actually happen to pull on more work and they achieve that. And I'm just thinking about that from a sense of, are 90% of these teams trying to be busy or are they trying to be perceived to be busy? Even if it's at the expense of actually delivering?

Eric Naiburg:

Or are they even pushed into it? It's interesting, there's a question on our professional scrum master one, our PSM one test that often people get wrong. And I think it's a great question, which is, I'm paraphrasing because I don't remember it exactly, but it's essentially how much of the sprint backlog needs to be filled coming out of sprint planning. And a significant number of people say it needs to be complete coming out of sprint planning. Which goes in the face of Agile and Scrum.

Dave West:

Exactly.

Eric Naiburg:

Because we don't know there. There's that uncertainty. All we need is enough to get started, and once we get started, but I think people are fearful of, "Well, we've got two weeks, we need to be able to plan those two weeks and we better be able," and this is some of that top-down pressure that we talked about. "Well, we need to show that we've got two weeks worth of work here and that we're not sitting around, so let's fill it up." And those are some of the misnomers about Agile and Scrum. "Well, it's a two-week sprint, we need to plan two weeks." Well, no, we don't. We need to have a goal. Where are we going to get to? How we achieve it is going to take time because we're going to learn as we go. As a matter of fact, the scrum team that I'm on right now, we were running a three-week sprint, and two weeks in we've actually achieved our goal. And now we're able to build upon that goal. And we already delivered on that goal a week early, which is great.

Nick Muldoon:

Do you think, Eric, that there's a fear from leadership that if people haven't got two weeks worth of work teed up, that they're just going to be twiddling their thumbs?

Eric Naiburg:

I don't know that it's a fear from leadership. I think it's a perception that the workers have of what leadership is thinking. I think it's more that. And I think it's the, "Well, we said we've got two weeks," and they are going to ask us, management's going to say, "When will you deliver?" I don't know that we'll ever get away from that when will we deliver question, even though we continually try to get away from that answer. But they're going to ask it. So if they're going to ask it, I better be prepared, which means I better have a whole bunch of work laid out. And that just breaks everything that we teach. It breaks everything that we think in Agile.

And all I need in planning is I need a goal, and some idea of how I'm going to get there. And over time let's revisit it and let's continue to revisit it and go to it. But it amazes me how often that some of the answers to that question are, you have a full sprint backlog go coming out of sprint planning, you have enough to get started. I forget what some of the others are. But it amazes me how many times when I review tests people put the full back sprint backlog where it even says, right in the scrum guide, "You're going to inspect and adapt throughout the sprint." Well, how do I inspect and adapt if I've already decided what I'm going to do?

Nick Muldoon:

Who's the onus on? If it's not actually the leadership's wish that you fill up all your time and you operate at a hundred percent capacity, then is the onus on the leader to make it known or is the onus on the team to engage in the conversation?

Dave West:

It's the leader.

Eric Naiburg:

Yes.

Nick Muldoon:

Yeah. Yes, both. Yeah.

Dave West:

I think it's more the leader because I think they have to create the environment where the team actually can challenge it, and actually have that very clear conversation. What worries me about your stan is the fact that I don't... The first few sprints. Yes, maybe you get overly excited, maybe you fill the sprint, which you don't need to. Maybe you're just keen. That's okay. The thing is, what happens on sprint three or four or five, when the same pattern is manifesting itself over and over again. That's worrying. And I think that speaks really clearly to the lack of help the team's having. Whether you call it an Agile coach, and in Australia, I think the Agile manager is a phrase that's used, or whether it's an Agile, or whether it's a scrum master, whatever. Scrum.org has a scrum master.

And the reason why we have a scrum master isn't because we don't know scrum, though there's some days it might be questionable. But cobbler's children, all that stuff. But the reality is, we do know Scrum, we talk it, we breathe it, we love it. But having somebody that steps back and says, "Hang on, Westy, what have you done there? Have you forced encouraged the team to fill the sprint? Have you set them an unrealistic goal? Have you listened to them and asked them the questions? Or have you told them what you want? And what do you think that's going to do?" I know that I have, because Eric and I fund the sprints, as it were. When we go to a sprint review and we say stuff, because a sprint review is ultimately there to provide feedback to the team, to allow them to inspect and adapt for the next sprint.

You can't change the past, but you can change the future based on feedback. If I go in with, "Oh, well that's rubbish and you should do this, and what about that?" Yeah, it's going to have an impact. So ultimately we have to think about, as leaders, what we bring, and also have somebody often helping us to be the leader that we need to be because we get excited and we get enthusiastic and we get, "Oh, you can do this and that? Let's do it. That sounds awesome." And sometimes that can...

Eric Naiburg:

And that's part of why I say it's both. That's why I said the yes. It's on the leader, but the leader needs to be reminded of that. The leader needs to be supported by that, especially by the product owner and the scrum master. The product owner has to be able to say no. The product owner has to... I talk about happy ears and most CEOs and senior leaders are-

Nick Muldoon:

Happy ears?

Eric Naiburg:

Yeas. Most CEOs and senior leaders I've worked with have what I call happy ears. They come from one customer or they talk to one person and heard something that-

Dave West:

Do this.

Eric Naiburg:

... that one person might have thought was great. And next thing you know, they're putting all these new requirements on the team. And I've worked in many startups and big companies where, even at IBM, that happened. And the product owner needs to be able to say, "Whoa, hold on. That's a great idea. Let's think about it. And we'll put it on the backlog, we'll think about it later. But let's not distract the team right now from what we're trying to do and what we're trying to achieve." And that's why I say it's both. It's not just on the leader. You're not going to fully change the leader. You're not going to fully change them to not have those exciting moments. And that's what makes them entrepreneurs. That's what makes them who they are.

But the team needs to be able to push back. The leader needs to be accepting of that pushback and the scrum master and the product owner, as well as others on the team, need to be able to have that pushback. I remember very, very early in my career, I worked for a company called Logicworks. We had a data model, a little data modeling tool called Irwin. And I remember sitting in my cube, and the CEO had just come back from a meeting with one client, and comes over, and I was a product manager-

Nick Muldoon:

Eric, do this.

Eric Naiburg:

And starts talking about, we need to go do this now, and blah, blah, blah, blah, blah. It's like, well, hold on. It's like, but blah, blah, blah said they'd buy it. Well one, did you actually talk to the people using it? Or did you talk to somebody way up here who has no idea how they're actually using the tool? Which the answer was talking to CEO to CEO conversation. And just because they'll buy it, will anybody? But you have to be able to have those conversations. You have to build that trust with the leader from the team, and from the team to the leader, to be able to have those pushbacks and be able to say, "That's an interesting idea. We'll take it under consideration for the future, but right now we have a focus. We've got a sprint goal and we're not going to destroy our sprint goal because you got excited about something."

Dave West:

As you can see, Nick, I have a really hard time getting any of my ideas into our organization because they ask things like this. So annoying, Nick. They say, "Okay, that's great. Is that more important than these five things that are currently driving our product goal?" I'm like, "Ugh, what do you mean? I can't have dessert and main course and an appetizer? I have to pick one that's just so not fair." And they said, "Well, we could spin up another team and then that requires investment. It's going to take time." And I'm like, "Oh gosh, don't you hate it when you have intelligent, smart teammates?" It's just hard.

Nick Muldoon:

Dave and I have definitely, so Dave Elkin, my co-founder, he comes from an engineering background and I come from a product background. And we've definitely noticed in the last, again, probably in this timeframe, in the last 18 months, as the team's grown or through a certain inflection point, in the past, we would quite come comfortably have conversations about what about this idea and how about that? And we'd try and tease things out, and we'd tease them out with the team, but there was no expectation that that stuff would get picked up. And then we had few examples where teams would go and take on and think that they needed to look at this stuff and we're like, "Oh, no, no, no, sorry, we should clarify that we just wanted to get a brainstorm or we wanted to get a thought out of our head, and we wanted some perspective on it, but this should absolutely not mean that you should chase it down." And so the language and how we've had to approach things like that, or activities like that, has certainly changed.

Eric Naiburg:

I've seen that a lot lately-

Nick Muldoon:

[inaudible 00:39:50] Inflection point.

Eric Naiburg:

... probably in the last two or so years. And I think maybe because of remote, it's made it even worse, because you don't get all the emotion and things. But I've definitely seen a lot more of that, of, "Well, I'm just," I've been told this doesn't translate, "but I'm just spit balling and I'm just throwing an idea out there just to have a conversation." And because the leader said it, people think it's fact and that they want to do it. And all they were doing is, "Hey, I heard this thing. What do you think?"

Nick Muldoon:

What's your perspective?

Eric Naiburg:

Yeah, exactly. And I think as leaders, we have to be very careful to understand the impact of what we're saying, because we may be thinking of it as, "I'm just throwing it out there for some conversation." Somebody sitting at the desk just heard, "Oh, they want us to go do that." And I've seen that a lot in companies recently, including in ours, where the way something's said or what is said is taken on as we must do this versus, "Hey, here's an idea, something to noodle on it." So you're not alone, Nick.

Nick Muldoon:

I love it. Hey, Eric, Oregon, that's a great place to call it. That is, and you have given me, you've both given me a lot to noodle on, so I'd like to say thank you so much from our listeners and from the crew at Easy Agile for joining us today. I really appreciate it. It's been wonderful having you on the podcast.

Dave West:

Well, thank you for inviting us. We're really grateful to be here, and hopefully some of this has made sense, and yeah, let's continue to grow as a community and as a world working in this way, because I think we've got a lot of problems to solve. I think the way we do that is people working effectively in empowered ways. So let's change the world, man.

Nick Muldoon:

I love it. Okay, that's great. Thank you.

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