Easy Agile Podcast Ep.8 Gerald Cadden Strategic Advisor & SAFe Program Consultant at Scaled Agile Inc.

"We spoke in detail about scaling agile, being a SAFe fellow, discipline, the traits of effective leaders and how to trust your people."

Transcript

Nick Muldoon:

Good day, folks. Thanks for joining us for another Easy Agile Podcast. This morning, I'm joined by Em Campbell-Pretty of Pretty Agile. Em is one of 22 SAFe fellows globally and she's been doing agile transformations at scale for over a decade now. She's also the author of two books, The Art of Avoiding a Train Wreck and Tribal Unity. So, all about culture and psychological safety here, and all about obviously scaling agile release trains, tips and tricks.

Nick Muldoon:

My key takeaways that I was really jazzed about, the traits of effective leaders for scaling agile transformations and being an effective organization, trust, as in trusting their people, an openness to learning and a willingness to learn, the ability to experiment and treat things as failures if they are failures, and discipline. Em and I talked a bit about discipline today as a trait of leaders. It's a really great episode and I took a lot from it, and you'll hear my takeaways at the end and what I need to go and learn after some time with Em this morning. So, let's get started. How many weeks a year are you typically on the road?

Em Campbell-Pretty:

How many weeks a year am I typically on the road? A lot, most. It would be unusual for me to spend four weeks without going somewhere. That would be unusual. I don't travel every week, but I travel most weeks, and I travel in big blocks. Right? So, I'll go and do ... Like I said, just before the lockdown, we did three weeks in Auckland, so that was in February-March.

Em Campbell-Pretty:

We went to Auckland, we had a client in Auckland, we just stayed there. So, three weeks in Auckland, came back here, and did not return to Auckland. Returned to support that client virtually over Teams and Zoom was how that one went. But yeah. Normally between running around Australia, Southeast Asia, Hong Kong, Singapore, Manila, the US, New Zealand, yeah, not home that often, normally. This has been truly bizarre.

Nick Muldoon:

So, this is a very unusual year for someone like yourself that's flying around visiting clients all over the world.

Em Campbell-Pretty:

Absolutely. Absolutely. It's been a very strange year. It's an interesting difference on energy as well. Not flying all the time I think is good for my body. I feel the difference. I also feel the difference sitting in a chair all the time. So, I was traveling a lot, but I was on my feet most days when I was working. Now if I'm working, I'm sitting a lot.

Nick Muldoon:

You're sitting down. Yeah.

Em Campbell-Pretty:

So, that's interesting. But I don't miss the jet lag at all. I don't miss the amount of time the travel consumes at all. In fact, it's been nice. I've had a little bit of head space. I've probably blogged more this year than I have in a few years because I've just had some head space and being able to think. But I don't get to see the world either, and all my holidays got canceled. So, nevermind work. I had trips to Europe. Four weeks from now, I was supposed to be in Canada seeing polar bears.

Nick Muldoon:

Aw.

Em Campbell-Pretty:

Tell me about it!

Nick Muldoon:

I would love to see polar bears. They look so cuddly on TV. I'm not sure that that would actually be the circumstance if I was to try to approach one and give one a cuddle.

Em Campbell-Pretty:

Yeah. I don't think cuddling was involved. I was told I could bring a camera and a tripod, which means obviously I'm going to stand some distance away from this polar bear and take photos. But that will not be happening either. So, no holidays and no travel for work, and of course, being in Melbourne, not even any, let's just go to [crosstalk 00:04:15].

Nick Muldoon:

Coffee or anything like that.

Em Campbell-Pretty:

Just nothing.

Nick Muldoon:

Nothing.

Em Campbell-Pretty:

Nothing.

Nick Muldoon:

Yeah, because you've been on legit lockdown.

Em Campbell-Pretty:

Yep.

Nick Muldoon:

So, tell me then about the shift over the last 10 or 15 years in these scaled, agile transformations. Obviously today, like you described with this client in Auckland, everything's got to be remote. Presumably, not as effective. But I'd love to get a sense of what the evolution is from the transformations 10 years ago, banking, telcos, that sort of environment to the clients that you're working with today. Describe what it was like 10 years ago.

Em Campbell-Pretty:

So, 10 years ago, and it's so interesting to reflect on this now, I read Scaling Software Agility, which is a book that Dean published in 2007. Then I discovered that wasn't the latest book, so then I read Agile Software Requirements. This was 2011. I'm this crazy, angry business sponsor with this program of work I'd been sponsoring for five years that's never delivered anything, and in this cra-

Nick Muldoon:

You were the crazy, angry business sponsor?

Em Campbell-Pretty:

Yeah. Yeah, yeah. I was the crazy [inaudible 00:05:26]. I was very angry. You would be angry too if you were me. I refer to it now as the money fire. So, basically, here's my job. Right? Go to the CFO, ask for money. Give the money to IT. IT lights a match, sets it on fire. Comes back, asks me for money. I get to go back to the CFO and say I need more money. Five years. Five years. That's all I did. Ask for money and try to explain where the other money went.

Em Campbell-Pretty:

Anyway, in the strangest restructure ever, I end up the technology GM for the same group I had been the business sponsor of for the past five years. Apparently, they couldn't find anybody appropriately qualified. So, you can do it, Em. Sure. So, I'm a bit of a geek, so I read books, and I'm reading these books by Leffingwell because I'd been doing some agile ... So, I'd been doing something I'd been calling agile. Let's just go with that.

Em Campbell-Pretty:

It was interesting to me because I could see little rays of light. But it still wasn't really making anything happen, so hence the reading. These books talk about this agile release train [inaudible 00:06:46] that sounds cool. We should so do this thing. So, I set about launching this train at a Telstra in early 2012. It wasn't called SAFe, right? It was just the books and these things called an agile release train.

Em Campbell-Pretty:

Now, to look back 10 years ago, it wasn't called SAFe. People weren't running around doing this. I was not actually really qualified for the job I was in. Well, I wasn't a technology leader by any stretch of the imagination, and I decide that I'm just going to launch an agile release train. So, there were rare and unusual beasts, and I'm not sure I really understood that when I went down the path of doing it.

Em Campbell-Pretty:

I'm big on the, I read it in a book, I read it in a blog, I heard it at a conference, I'll just try it. That's very much always been my mental model. So, I read it in a book and I just tried it. Then we discover that actually, literally nobody is doing this, so it becomes Australia's first agile release train and Australia's first SAFe implementation. Oh, boy, have I learned a lot since then.

Nick Muldoon:

Well, yeah. I was reflecting on that because I dug out The Art of Avoiding a Train Wreck, right? This is one of the ones that you signed for Tegan. But obviously, you've learned a ton since then because you've managed to put together a tome of tips and tricks and things to avoid as you are pursuing these transformations. As an industry, though, well, as an industry, I guess this spans many industries, but as a practice these days, are we actually getting better at these transformations? Are there companies out there today, Em, that are still taking piles of money and setting it on fire?

Em Campbell-Pretty:

So, I think I meet people every day who hear my story and go, "Oh, my god. You used to work here?" So, I think there's still many, many organizations that have an experience that is like the experience I had back in 2010 and what have you. So, it seems to be something that really resonates with people. I guess so many of the businesses we go into now either are not agile at all or, I guess like my world was, doing something they call agile. What we find is the something that they call agile, I wouldn't say it's not agile. But it leaves a lot to be desired.

Nick Muldoon:

They're on a journey, right?

Em Campbell-Pretty:

Yeah. Yeah. Well, I guess so because they end up having a conversation with us. So, they understand that what they're doing is not enough. They understand that what they're doing isn't getting them the results that they want. I don't know that they understand why. It's interesting to me sometimes that they look to SAFe because you asked me about how's the client base changed? One of the things that's really interesting in Australia is we get far more of the small to medium sized companies now than the big ones.

Em Campbell-Pretty:

So, they're companies that consider themselves agile. But what we're calling them, the startups that are no longer startups, right? These are organizations that they're generally old 10, 20 year old startups and they're scaling and they see their problem as a scaling problem. So, that's what leads them to a conversation around the scaled agile framework.

Em Campbell-Pretty:

When we look at them through a SAFe lens, we go, "Gee, you're tiny. But okay. I can see that you can have an agile release train and it won't do you any harm. In fact, it would probably help you a lot in terms of mid-range planning," because mid-range planning just seems to be nonexistent for a lot of these organizations. Prioritization. A lot of these small organizations, very knee-jerky in terms of how they prioritize, bouncing from one thing to the other.

Nick Muldoon:

Are they reacting to the market, or are they reacting to the leaders, maybe the lack of discipline in the leadership?

Em Campbell-Pretty:

You know what? They would say they're reacting to the market. I would say they've got a discipline issue.

Nick Muldoon:

Yeah. [crosstalk 00:11:23].

Em Campbell-Pretty:

So, I read, obviously, big reader, last summer, obviously Australian summer, US winter, I read Melissa Perry's The Build Trap. Interesting book and your well respected thought leader in product management. Not a big fan of SAFe. Probably not a big fan of agile either was the takeaway I had from her book. But the thing that she does talk about that I really thought was valuable was the lunacy in chasing your competitors. So, building features because your competitors-

Nick Muldoon:

Your competitors [crosstalk 00:12:06].

Em Campbell-Pretty:

... build them, or building features to land a contract or retain a customer. So, I thought she sees all of that as lunacy, and I tend to agree. So, that was my ... I think that's quite interesting. Her perspective is you don't know if the competitor's actually having any luck with that thing that they've built. So, if you build it because they built it, you don't know. You have no idea. So, don't just build it because they've built it. It might not be doing them any favors either.

Em Campbell-Pretty:

Of course, once you start just doing random stuff for this big customer or this big client, you start to lose your way as an organization. People end up with completely different versions of their products, branches that they can't integrate anymore. It's interesting. So, when I look at that, I go, "I feel like there's a discipline issue in some of these organizations at the leadership level."

Em Campbell-Pretty:

What is it we're trying to do? What is our vision? What is our mission? What is our market? What are we doing to test and learn in that market, as opposed to just get a gun, let's do everything, grab everything? Oh, my goodness. They were doing that over there. Stop this, start this, stop this. Of course, if you're stopping and starting all the time, you're not delivering anything, and that seems to be something that we see a lot with these organizations. They're not delivering.

Em Campbell-Pretty:

I'm not saying their delivery mechanism is perfect. There's challenges there too. But some part of the problem is the inability to stay a course. Pick a course and stay a course. I'm not saying don't pivot, because that's stupid too. But being more deliberate in your choices to pivot, perhaps. Yeah.

Nick Muldoon:

Do you get a sense, Em, that there are leadership teams in various geographic regions that are more effective at this and more effective at that longterm planning and having that discipline and that methodical approach to delivery over an extended time period?

Em Campbell-Pretty:

I think regions and cultures and nationalities certainly play a role in the leadership, I don't know, persona, personality. I don't know that I could say when I've worked in this country or this part of the world that their leaders are better at forethought. I think some cultures lend themselves to lean and agile more than others. Hierarchical cultures are really, really challenging.

Em Campbell-Pretty:

That can be both a geographic thing, but it can also just be an industry thing, right? So, government can be very hierarchical. The banks can be very hierarchical. Some of the Asian cultures are very hierarchical. But some companies are just very hierarchical as well. So, who owns the company, who leads the company, all of that can play a big role in what's acceptable because so much of success in this scaled agile journey comes down to a leadership that is willing to trust the teams, a leadership that is willing to learn, a leadership that's willing to experiment, and a leadership that's prepared to be disciplined.

Nick Muldoon:

So, leadership with trusting the teams, willing to learn, willing to experiment, and with discipline. They're those four things that you-

Em Campbell-Pretty:

Yep.

Nick Muldoon:

Yeah, okay. I'll make a note of those, Em. I'll come back to those. Trust, learn, experiment, and discipline. I'm interested, I guess, this year being a very interesting, a very unique year for doing remote transformation work and coaching and consulting, 10 years ago, what was the percentage of remote team members distributed teams? Now, you've basically, I think the big banks in Australia aren't even going back to the office until 2021. Atlassian is not going back to the office until 2021. Twitter, Jack Dorsey, my old CEO, said, "Work from home forever," sort of thing. What's the takeaway for this year and what do you expect for 2021 and beyond?

Em Campbell-Pretty:

So, look. This year has been eyeopening, and look, some things are, as I would have anticipated, some things have been different. So, obviously, we're seeing entire organizations going online. We're seeing the teams are online, the PI planning's online, everything's online. That's actually in some ways opened up opportunity. So, where we've had clients who have had the most odd setups in terms of distribution, and you can make a train work where you've got teams across two locations. But we're big fans of the entire team is in Sydney or the entire team is in India. We don't have half the team in Sydney and half the team in India.

Em Campbell-Pretty:

But organizations really struggle with that because perhaps all the testers are in India and then you want a tester on every team and now you've got a problem. How do you create a complete team and not cross the time zones? So, the opportunity becomes if I can find teams that are not physically co-located but time zone friendly, I have a little bit more option. So, I can have a train that operates between, I don't know, Sydney and India. Or I can find a four hour overlap in their day, and I can insist that that team works 100% online.

Em Campbell-Pretty:

So, the big thing that we'd advise against is I don't want that team hybrid. Right? I don't want three people sitting in the office in Sydney and three people sitting in their homes in India. I want everybody online. I want an even playing field, and I think we can do that now in a way that is more acceptable than before. Because the same advice I was giving, gee, back when I wrote Tribal Unity, same advice. Right?

Em Campbell-Pretty:

So, 2016, everybody, equal playing field. If you're going to be distributed, everyone has to be online, as opposed to some people online and some people in a room. So, that's a more acceptable answer now than it was prior to this year. So, that's good. I think that's good.

Nick Muldoon:

In 2021, then, Em, you mean this is just going to play forward. I guess there's going to be a reversion of some of these companies back to the office because they've got huge real estate and workplace infrastructure already.

Em Campbell-Pretty:

Yeah. So, look. We're seeing clients closing offices the same way that you see some of the companies in the US doing that. We're also seeing parts of Australia and New Zealand with no particular COVID impact at this point actually going back into the office, and having created that example of teams that are crossing time zones, and then going back into the office and going back to that hybrid space. So, that's interesting and [crosstalk 00:20:08].

Nick Muldoon:

So, where you're back into that environment where you might have some people working together in an office that can get a cup of coffee together and then some that are stuck still at home. I guess there's not just even regional differences, right? If you've got a team member that's got a particular health situation, they're not going to feel comfortable necessarily coming back into the office, regardless of the situation, until there's a vaccine or something.

Em Campbell-Pretty:

Absolutely.

Nick Muldoon:

Yeah, okay.

Em Campbell-Pretty:

So, yeah. Look, I think it's going to be interesting. I would strongly advocate that organizations have teams that are either in person teams or online teams, and the team just either operates 100% online or the team operates 100%-

Nick Muldoon:

In the office.

Em Campbell-Pretty:

... in person and in the office, and if you have a train that has both in any train level ceremony, everybody goes to a desk and-

Nick Muldoon:

And do it online.

Em Campbell-Pretty:

... a video camera and we do it that way. I think the thing that seems to be most sticky about the physical environment and SAFe is PI planning. Nobody needs to beat. Right? That was cool. Nobody needs to beat, no one's PI planning slipped, everybody just went. They were all online. So, we'll just PI plan online. It'll be fine. We saw people use whatever infrastructure they had available to them.

Nick Muldoon:

Yeah. [crosstalk 00:21:30].

Em Campbell-Pretty:

So, I'm sure a number of people called you folks and said, "We need a tool." But some just went, "We have Google Suite, we have Microsoft whatever it is, we have this, we have that. We're just going to make it work," and no matter what they used, they made it work and they ran the events and their events were effective and they got the outcomes. The big thing that is missing is that energy. You can't get the energy of 100, 200 people in a room from an online event. But mechanically-

Nick Muldoon:

We can achieve it.

Em Campbell-Pretty:

... we can achieve it. So, we hear everybody wants to go back to PI planning in person because of the social, because of the energy, which I think is awesome. I absolutely think that is awesome, and I can see this world in which people do a lot more work from home, work remote, whatever that looks like, and then the PI planning events are the things that we do to bring ourselves together and reconnect on that eight, 10, 12 week basis. That's my feeling. Could be wrong.

Nick Muldoon:

I guess I'll be really interested to see how it plays out, and I think we should return to this conversation in 12 months, Em.

Em Campbell-Pretty:

Yeah. Oh, no.

Nick Muldoon:

I'm just thinking, what's going through my mind is one of our customers in New York, financial services company, and for one of their arts, it was 150,000 US exercised to bring their people together once a quarter.

Em Campbell-Pretty:

Yeah. Wow.

Nick Muldoon:

I'm now going, I'm like, "Okay, yes, they're doing it digitally now." That's fine. They're going to miss out on things. But if they lose the budget, do they have to fight to get the budget back? Or does the budget sit there? There's these other unknown ramifications of this shift over the course of 2020 that we're yet to see play out, I guess.

Em Campbell-Pretty:

I think you're right, and I think it would be particularly interesting for the trains that have been launched remotely. So, if the train has been launched remotely, do you ev-

Nick Muldoon:

So, not existing trains that have been working together for six to 12, 18 months. But you want to get a brand new train started. Have you done that remotely this year with some of your clients?

Em Campbell-Pretty:

Oh, we're in the process of doing it now.

Nick Muldoon:

Cool. Tell me.

Em Campbell-Pretty:

We had one, though, literally just before the lockdown. So, they did their first PI planning face to face and then immediately moved to remote working and, yeah, now working on remotely launching a train. For us, we have a playbook. It's a bunch of workshops. It's a bunch of classes. We just use online collaboration tools. We've found things that replicate the sort of tools that we would have in a physical room, and the joy of being able to read people's Post-it notes, right? This has been the absolute highlight for me, the joy of being able to read people's Post-it notes.

Nick Muldoon:

No more hieroglyphics.

Em Campbell-Pretty:

Yeah. Absolutely.

Nick Muldoon:

What is that that you wrote, Sally? Yeah.

Em Campbell-Pretty:

Everyone can say everything at once, right? So, you think about the classroom and the workshop where there's a group of people huddled around Post-its and a flip chart paper and they're still huddled in a way in their virtual huddle, but everybody can read, right? It's not that I'm not close enough, I can't read, I can't read your handwriting. There's this great equalizer is the online world. So, I think that's great. I think the challenge for the trains launched remotely is going to be do you ever get the face to face experience?

Em Campbell-Pretty:

Because if I go back over the years, one of the things we know is your first PI planning event sets the standard. So, people get this imprint in their heads of what is possible. For example, if you skip something in your first PI planning event, you just decide to, I don't know, skip the confidence vote or something weird like that, you don't do the roam of the risks or you just skip something, you never do it because you're successful without it.

Nick Muldoon:

It never gets picked up. Yeah, okay.

Em Campbell-Pretty:

You're successful without it. So, every compromise you make, and you make a series of compromises, and then you're successful despite those compromises, and that becomes a false positive feasibility. It tells you, yes, I was right. I was right.

Nick Muldoon:

I don't need to do that.

Em Campbell-Pretty:

I didn't need to do those things because I was awesomely successful and I didn't do these things. So, it's the learning [crosstalk 00:26:15]-

Nick Muldoon:

That's confirmation bias, is it?

Em Campbell-Pretty:

Yeah, that's it. That's the one. Confirmation bias. That's exactly it. Yep. Yeah, and I think there's going to be a bunch of confirmation bias in these remotely launched trains, and unless they're inside organizations where there's enough knowledge of SAFe and the physical PI planning to know that there's going to be value in bringing them together, but I can see that being a real challenge. I think trains that are launched online may never go into a physical PI planning event because of that confirmation bias.

Nick Muldoon:

All right.

Em Campbell-Pretty:

That makes me really sad.

Nick Muldoon:

I want to come back to something you said before about the leaders, and you mentioned the trust, the openness to learning and experimentation, and the discipline. I was going back over your SAFe Global 2018 talk about the seven traits of highly effective servant leaders.

Em Campbell-Pretty:

Yep.

Nick Muldoon:

Yeah?

Em Campbell-Pretty:

Yep.

Nick Muldoon:

I guess I had some questions about this, and obviously, these are four of the traits. What are the other three traits that I'm missing? Then I've got a followup question about some of the actual things that you talked about that you picked up in your trip.

Em Campbell-Pretty:

[inaudible 00:27:29] one of those four on the list I had in 2018.

Nick Muldoon:

I'll quiz you on it.

Em Campbell-Pretty:

How awkward. So, in 2018, the answer was people first, a respect for people, that sort of lens, lean thinking, manager, teacher, learner. So, we had that one. Yeah. Learner. [inaudible 00:28:00] crazy. What else did I have? [inaudible 00:28:10].

Nick Muldoon:

Yeah. Okay. I wanted to talk about that one, actually. I made a note about that. What is that, and are there examples of that in the West?

Em Campbell-Pretty:

A lot of people talk about true north.

Nick Muldoon:

[inaudible 00:28:28]. True north.

Em Campbell-Pretty:

Yeah. True north. The translation I got, which I got from Mr. [inaudible 00:28:39], who partnered with Katie Anderson for the lean study tour I did in, I don't know, '18, '17, '18, 2018, I think, so the translation he gave was direction and management sort of things. So, it's mission, right? It's strategic mission. It's that sort of thing.

Nick Muldoon:

So, just a sidebar here for anyone that hasn't seen Em's talk on this, there's a woman by the name of Katie Anderson. She runs an annual, I think, I guess not this year, but she runs an annual-

Em Campbell-Pretty:

No, not this year. She did not go this year.

Nick Muldoon:

... not this year, runs an annual lean, Kanban, kaizen study tour to Japan and visits ... Who did you visit, Em? You visited with Katie. How many were in the crew that you went over there with?

Em Campbell-Pretty:

So, I think it was a group of about 20 from memory. Katie lived in Japan for two years and then went back to the US. She lives in San Francisco, I think. While she was there, she really liked the idea of putting together these lean study tours. She was already a lean practitioner more in the healthcare side of things. So, she got the opportunity to ... We actually were on a test run tour.

Nick Muldoon:

Oh, cool.

Em Campbell-Pretty:

So, this was her experiment. She had a relationship with Ohio State University and they brought some people to the table and she brought some people to the table and they made it happen. She also had an existing relationship with Mr. [inaudible 00:30:24], who was John [inaudible 00:30:26] first manager at Toyota. So, he's a 40 year Toyota veteran.

Nick Muldoon:

Veteran.

Em Campbell-Pretty:

He came with us for the week. So, we of course went to Toyota, but we went to a bunch of Toyota suppliers as well. Isuzu, [inaudible 00:30:43]. Then we also went to Japan Post, which was fascinating. We went to a city which name escapes me right now, but they called it 5S City because all the companies in that city practice the 5S, the manufacturing 5S.

Nick Muldoon:

Tell me about it. It's not coming to mind. I don't feel comfortable or familiar.

Em Campbell-Pretty:

You don't feel good about 5S?

Nick Muldoon:

No.

Em Campbell-Pretty:

No. That's not good. So, how would I ... The 5S is five Japanese words, which I'm going to go ... Yeah. My Japanese, nothing. But it's about standardized work. So, for example, when you go into the 5S factories, you'll see the floors marked up where you need to stand to do a particular job.

Nick Muldoon:

[crosstalk 00:31:41] This is what Paul Aikas picked up for his-

Em Campbell-Pretty:

Oh, no.

Nick Muldoon:

I feel like I've seen Paul Aikas' videos of their manufacturing in the US that everything's marked up.

Em Campbell-Pretty:

Yeah.

Nick Muldoon:

Okay.

Em Campbell-Pretty:

Probably. That would be my guess. We should ask Teddy.

Nick Muldoon:

We can ask Paul, and we can ask all these people. There's time.

Em Campbell-Pretty:

Well, yeah.

Nick Muldoon:

Okay.

Em Campbell-Pretty:

Okay.

Nick Muldoon:

So, that lean tour, the Japan study tour, that was a super effective and motivating thing for you?

Em Campbell-Pretty:

Yeah. For me, it was very reinforcing. So, I had I guess my own lens on what lean leadership meant, and I found that particular tour to be very reinforcing around the value set that I believe is part of that. Katie [inaudible 00:32:43] created [inaudible 00:32:44] that is designed to show you that. So, she's often very clear that says this is not Japan, right? This is not a reorganization into Japan. This is not every leader in Japan.

Em Campbell-Pretty:

This is, I've hand picked a series of lean leaders to show you it being practiced. But it was certainly very reinforcing for me. So, very similar messages I picked up in terms of how I like to head, how I coach others to lead was built into the messages that she delivered. So, it was very cool. It was very cool. Some of those leaders, just so inspiring, particular kaizen. I think the thing that just really hits you in the face as you're talking to these folks is kaizen, this drive to get better.

Nick Muldoon:

All the time.

Em Campbell-Pretty:

All the time. Absolutely. It's these folks looking for, they're looking for the one second, right?

Nick Muldoon:

Yeah.

Em Campbell-Pretty:

The one second improvements. There's a video that floats around. Have you seen the Formula 1 video-

Nick Muldoon:

Yeah.

Em Campbell-Pretty:

... where they do, yeah, the changeover in 63 and it takes them over a minute and they do the changeover in 90-something in Melbourne and it takes them six seconds or whatever it is. It's like that, right? It's that how do I find one more second, half a second? They're just so driven. If I can remove a step that someone has to take, can I move something closer to somebody?

Nick Muldoon:

Yeah. There was some comment in the presentation that you gave. There was some comment about if I have to take another five steps, that's an extra 10 seconds. Then that's an extra 10 seconds every time I do this activity every day, and that all adds up. So, how do we shave these seconds off and be more effective and deliberate about how we do this?

Em Campbell-Pretty:

That was just huge, right? I called it kaizen crazy in the presentation. I'm just so, so driven to improve, and just tiny, small improvements every day.

Nick Muldoon:

So, one of the other practices that I didn't grok out of that talk was about the Bus Stop. What was the Bus Stop about?

Em Campbell-Pretty:

Was that in that talk? Really?

Nick Muldoon:

I'm forcing you to stretch your mind [crosstalk 00:34:57].

Em Campbell-Pretty:

You are. You are. You are. You are quite right. It really was [inaudible 00:35:01]. Okay. Oh, you're awful.

Nick Muldoon:

Yes.

Em Campbell-Pretty:

Yes. Yes, you are. Okay. So, effective leaders are human was the tagline on that one. It was really about leaders being down to Earth and being one with the teams. So, things I saw in Japan, this factory run by a woman, [inaudible 00:35:42], I think it was, so very unusual. Not a lot of women leaders in Japan. Her husband took her name because [inaudible 00:35:52]. It's a really interesting character.

Em Campbell-Pretty:

But her company has a bunch of morning rituals. You always say good morning and thank you and how they talk every day and everybody talks and everyone interacts. Then one of the other places we went to, they all had their uniforms they wore in the factory. But everybody wore the uniform, right? The CEO, the office workers, and everybody wore the uniform. Everyone was one.

Em Campbell-Pretty:

Then I was thinking about my experience leading teams, and a lifetime ago, I was working with a team that decided to enter a corporate competition. This competition was about showing your colors and showing the corporate values, which were things like better together and courage, and then [inaudible 00:36:49] a rainbow thing. So, this team decides what they're going to do, is it an address up in the rainbow colors, and they're going to be better together and show their courage and they're going to do the Macarena and they're going to video it and that's going to be how they're going to win this competition.

Em Campbell-Pretty:

I did not participate in this Macarena because someone has to take photos and stuff, right? How else are they going to enter the competition? So, had to do my bit. Anyway, we also had this ritual, which was about teams bringing challenges to leadership to resolve, and they did at the end of every spring. So, they do this Macarena and they film it and they enter the competition and at the end of the spring, they bring their challenges to leadership.

Em Campbell-Pretty:

Their challenge is Em did not do the Macarena. You are our leader, you did not do the Macarena. We are feeling very challenged by that, and we're bringing this to you to resolve. So, I went and spoke to the team that raised and said, "Look. I got to tell you. I don't know the Macarena. So, sorry." I still remember this so clearly. One of the guys said to me, "I read this blog about the importance of leaders being vulnerable." You know who wrote that blog post, don't you?

Nick Muldoon:

Oh, Em. Oh. You have it.

Em Campbell-Pretty:

So, we negotiated. I said, "Look. I think I can manage the Bus Stop." For those not from Australia, we grow up doing this in high school dances. In my part of the world, anyway. So, I grabbed my leadership team and we did do the Bus Stop and it was part of proving that we too were the same as everybody else and doing our bit and responding to the team's feedback. So, yes. That is where the Bus Stop fits in. Thanks so much for that, Nick.

Nick Muldoon:

Okay. No, I appreciate that. Now, I'm glad that I got that context. I try and do similar things. Typically, it's a karaoke or something, or that we haven't done that in a while. Yeah, okay. So, I guess the thrust of that talk was really about to leaders to serve, and it was all about being in service of. It sounds like what you took from the Japan study tour was these leaders there were very much in service of their people.

Em Campbell-Pretty:

Absolutely.

Nick Muldoon:

Do you see that as a trait that is prevalent in the best performing companies that you deal with, and how likely are they over a five, 10 year horizon, whatever that happens to be, to outperform their competitors or to be more successful in their market? Or I guess however they define success?

Em Campbell-Pretty:

I certainly see a correlation between leaders that like to serve and/or choose to serve and success with scaled agile, and business, because I guess we have seen over, it's close to 10 years, is those who practice together, your framework with discipline get results, and they get significant results. They improve their ability to deliver products and services, their cost base goes down, their quality goes up, their people are happier, their attrition goes down. We see it every single time.

Em Campbell-Pretty:

What we also see is when the leaders don't walk the talk, when the leaders are paying lip service to the transformation, it doesn't stick. They don't get the results. People don't find it a better place to work. People aren't bought into the change. So, there is definitely a correlation there. You can get pockets of wonderfulness inside an organization.

Em Campbell-Pretty:

We often observe that the organization that's transformation is as successful is the most bought in leader. Most senior bought in leader. So, if you're the leader of a train and you show the right behaviors, your train will be really great.

Nick Muldoon:

Successful.

Em Campbell-Pretty:

But that means nothing for the broader organization, solution train, the business unit, what have you. You see this thing that goes from the leader. If the leader's showing the right behaviors, you get within that space, you get the behaviors, you get the change, you get the results. But leaders who say one thing and do another, people don't buy it, right?

Nick Muldoon:

I guess this is true of any organizational change, isn't it?

Em Campbell-Pretty:

Yeah.

Nick Muldoon:

You hit the boundaries of your pocket, as you said, within the organization and then you meet the real world, the rest of the organization. People, maybe they don't have enough energy or they don't feel that they can influence and change that, and so they just live within their bubble because they don't feel that they can exert the pressure outside of that.

Em Campbell-Pretty:

Yeah. Look. I've certainly, I've seen successful bubble influence organizations. Successful bubbles can become interesting. Chip and Dan Heath's book, which one was it, Switch.

Nick Muldoon:

Oh, yeah. Switch. Yeah.

Em Campbell-Pretty:

[inaudible 00:42:02]. Shine a light on bright spot or something like that. So, bright spots inspire, and if you can create a bubble in an organization that outperforms the rest of the organization, or even if it performs better than it has previously, then everybody looks. Right? How did the organization that goes from poor delivery to great deliveries is what is going on here? That inspires others to get interested. One of the really interesting things we've seen in Australia, we can trace pretty much every SAFe implementation in Australia back to the one at Telstra.

Nick Muldoon:

Yeah, right. They all spun off from that, from the people that were part of it.

Em Campbell-Pretty:

Well, no. People who came and saw it. People who were inspired by it.

Nick Muldoon:

They're not necessarily directly involved in it.

Em Campbell-Pretty:

No. People came and got inspired by it, and then they went, did their thing, and then they inspired someone else. I haven't tried to do it recently, but there was a point in time we just could web together all of them because we could count them when we could see them. But we can web together most of them still. It says you saw someone who saw someone who saw someone who actually was someone who went to visit us at Telstra back in 2012, 2013 and got inspired.

Em Campbell-Pretty:

So, that bright spot can be really, really powerful, and that's what it takes, right? You get to add a little bit of noise, a little bit of difference, and people start to ask what's going on. I wouldn't say it's foolproof. I think it still requires, so someone's got to come, they've got to see, and then they've got to have the courage to do it for their part of the organization.

Em Campbell-Pretty:

That's the hard bit, right? I can come, I can see, I can get inspired. But am I prepared to put myself out there? There's a lot to be said for leaders who are prepared to take risks. That was one of the-

Nick Muldoon:

This was your lesson about the Bus Stop, right? You have to put yourself out there and be vulnerable.

Em Campbell-Pretty:

Yeah. Absolutely. Absolutely. This was actually, I was thinking, was the thing I was talking about at last year's SAFe Summit was be safe or be SAFe.

Nick Muldoon:

Be safe or be SAFe. Tell me about that.

Em Campbell-Pretty:

So, be safe, don't take a risk, or be SAFe, as in the scaled agile framework, and take that leap of faith. It comes back to, we started talking today about when I did this at Telstra, I didn't really understand that this wasn't a normal everyday, this is what everybody did sort of thing. It was a very new thing. So, I took a risk from a perspective that I was a business leader in a technology space and I really felt I had nothing to lose.

Em Campbell-Pretty:

So, I look back and that and go, "What on Earth possessed me?" And I go, "Well, I'm this business person leading this technology team. I wasn't supposed to succeed anyway."

Nick Muldoon:

Put it all on the line, right?

Em Campbell-Pretty:

I found out later they actually had a plan for when I did not succeed. I was supposed to fail.

Nick Muldoon:

Wait. How much waste is that? Why did they plan for something before it was ... Okay.

Em Campbell-Pretty:

Organizational policies. What can I tell you? Anyway, I did not fail. I did succeed, and because I took some crazy, calculated risks, and I've seen it time and time again, right? So many of these leaders in these companies that make this change are taking a leap of faith. I'm always saying I can't tell you exactly what's going to happen. I don't know whether you're going to get 10% cost out or 50% cost out. I don't know if your people are going to be 10% happier or 50% happier. I don't know that.

Em Campbell-Pretty:

What I do know is if you listen to what we're telling you and you follow the guidance and you behave in line with those lean and agile values, you will get results. You'll get results every single time. But you've got to be brave enough to buy in and take it on holistically and not do this thing where you manage to customize your way out of actually doing the thing-

Nick Muldoon:

Doing anything.

Em Campbell-Pretty:

... that you wanted to do.

Nick Muldoon:

Yeah. Okay. Em, this was awesome. Before we finish up, I want to take two minutes. You've mentioned books a lot today and you reminded me of this quote, Verne Harnish, "Those who read and don't are only marginally better off than those who can't." So, today so far, you've mentioned Chip and Dan Heath with Switch, you've mentioned the Leffingwell series from the late noughties. There might have been a few others. But tell me, what are you reading today? You've been in lockdown. What are the two or three top books that you've read since you've been in lockdown in Melbourne?

Em Campbell-Pretty:

Oh, my goodness. It's very awkward. Every time someone asks me, "What did you just read?" I go, "I don't know."

Nick Muldoon:

I don't think I remember.

Em Campbell-Pretty:

Can't remember. It's terrible. What am I reading? I need to open my Kindle. I don't know what I'm reading. Geoffrey Moore, Zone to Win.

Nick Muldoon:

Zone to Win.

Em Campbell-Pretty:

Zone to Win. I think that's what it's called. It's a newer book. I know this year, because obviously, I've read The Build Trap this year-

Nick Muldoon:

Yep. Melissa Perry. You mentioned that one. Yeah.

Em Campbell-Pretty:

Yep. I've read the Project to Product, Mik Kersten.

Nick Muldoon:

What was that one, Project to Product?

Em Campbell-Pretty:

Yeah. Project to Product, Mik Kersten. One of the IT Revolution press books. So, released just over a year ago. Very tied up in the SAFe 5.0 [crosstalk 00:48:21]. The other book tied up in the SAFe 5.0 release is John Kotter's Accelerate. So, I picked that back up. I read it a number of years ago when it first came out. But I like to revisit stuff when SAFe puts it front and center. Seems to make some sense to do that at that point in time.

Nick Muldoon:

Yeah, okay. It's interesting that, thinking about Verne Harnish, the scaling up framework, no relation to-

Em Campbell-Pretty:

No.

Nick Muldoon:

... scaled agile, for anyone that's not familiar. But so much of the scaling up framework about scaling businesses, they draw on so much content from existing offers, existing tomes, points of reference and experience, and it's super valuable, and I guess SAFe is no different, right? It draws on this wisdom of the collective wisdom.

Em Campbell-Pretty:

Absolutely. Absolutely. [inaudible 00:49:14] It was very fun to say in the early days, we stand on the shoulders of giants, a quote from somebody else whose name escapes me.

Nick Muldoon:

Yeah, okay. Well, Em, look. I wanted to thank you so much for your time this morning. This has been fantastic.

Em Campbell-Pretty:

No worries. It's great to catch up with you.

Nick Muldoon:

Yeah. I guess my takeaways from this, I like the be safe or be SAFe, like either be safe and don't take any risks, or be SAFe and actually put yourself out there and step into scaled agile. I definitely have to go and do a bit of research on the five S's as well and learn a bit more about that. But thank you so much for your time. I really appreciate it.

Em Campbell-Pretty:

No worries, Nick. Great to see you.

"Thoroughly enjoyed my conversation with Jon, he shared some great perspectives on the impact of the Agile manifesto" - Amaar Iftikhar

Amaar Iftikhar, Product Manager at Easy Agile is joined by Jon Kern, Co-author of the Agile Manifesto for Software Development and a senior transformation consultant at Adaptavist.

Amaar and Jon took some time to speak about the Agile Manifesto. Covering everything from the early days, ideation, process, and first reactions, right through to what it means for the world of agile working today.

They touch on the ideal state of an agile team, and what the manifesto means for distributed, hybrid and co-located teams.

We hope you enjoy the episode!

Transcript

Amaar Iftikhar:

Hi everyone. Welcome to the Easy Agile Podcast. My name is Amaar Iftikhar. I'm a product manager here at Easy Agile. And before we begin, Easy Agile would 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 that same respect to all Aboriginal, Torres Strait Islander, and First Nations peoples joining us today.

Today, we have on the podcast Jon Kern, who is the co-author of the Agile Manifesto for Software Development and an Agile consultant. If you're wondering, you're correct. I did mention the Agile Manifesto for Software Development. The Agile Manifesto. So Jon, welcome for being here and thank you for joining us.

Jon Kern:

Oh, my pleasure, Amaar. Thank you.

Amaar Iftikhar:

Yeah, very excited to have you on. Let's just get started with the absolute basic. Tell the audience about, what is the Agile manifesto?

Jon Kern:

Well, it's something that if you weren't around, and I know you're young, so you weren't around 21 years ago, I guess now, to maybe understand the landscape of what software development process and tooling and what most of us were facing back then, it might seem like a really obvious set of really simple values. Who could think that there's anything wrong with what we put into the manifesto? But back in the day, there were, what I practiced under as a... I'm an aerospace engineer, so I was in defense department work doing things like fighter simulation, F-14 flat spins and working with a centrifuge and cool stuff like that. And subject to a mill standard specification, which makes sense for probably weapons systems, and aircraft manufacturing, and all sorts of other things. But they had one, lo and behold, for software development. And so there was a very large, what I would call heavy handedness around software development process. We call it heavyweight process. Waterfall was the common term back then, and probably still used today.

And there were plenty of, I would say the marketing juggernaut of the day, IBM and Rational unified process, these large, very much like Safe. Where it's a really large body of work, awesome amount of information in it, but very heavy process even though everything would, say you tailor it, it could be whatever you wanted. I mapped my own lightweight process into REP for example. Sure. But the reality was we were facing kind of the marketplace leader being heavyweight process that was just soul crushing, and from my perspective, wasting taxpayers' money. That was kind of my angle was, well, I'm a taxpayer, I'm not going to just do this stupid process for process sake. That has to have some value, has to be pragmatic. So lo and behold, there were a handful of us, 17 that ended up there, but there are a handful of us that practiced more lightweight methods. So the manifesto was really an opportunity for coming together and discovering some of the, what you might think of as the commonality between many different lightweight practices. There was the XP contingent. I first learned about Scrum there, for example. Arie van Bennekum, a good friend, he taught us about DSDM. I don't even remember what it stands for anymore. It was a European thing.

Alistair and Jim Highsmith, they had, I forget, like crystal methodologies. So there was a fair amount of other processes that did not have the marketing arm that erupted, or didn't have the mill standard. So it was really all about what could we find amongst ourselves that was some sort of common theme about all these lightweight processes. So it was all about discovering that, really.

Amaar Iftikhar:

You all get together, the principles kind of come to fruition, and let's fast forward a little bit. What was the initial reaction to the original manifesto?

Jon Kern:

Yeah, it was even kind of funny that the four values, the four bullets is as simple as it was. The principles came a bit later. I want to say we collaborated over awards wiki, but the original... If you go to Agile uprising, you can see I uploaded some artifacts, because apparently I'm a pack rat. And I had the original documents that Alistair probably printed out, because he was the one... He and Jim lived there near Salt Lake City. So it was like, "Hey, let's come here." And we like to go skiing, so let's do it here. So he arranged the room and everything. And so there's some funny artifacts that you can find. And the way that it actually came about was an initial introduction of each of us about our methods. And really I think a key, we left our egos at the door. I mean I was a younger one. Uncle Bob, some of these, he was at Luminar, I know I have magazines still in the barn that he was either the editor of, or authors of for people who don't remember what magazines are. Small little booklets that came out. So Uncle Bob was like, Ooh, wow, this is pretty cool.

And I wasn't shy because I had a lot of experience with heavyweight methods. So I really wanted to weigh in on... Because I had published my own lightweight method a few years earlier. So I had a lot of opinions on how to avoid the challenges of big heavyweight process. So the culmination as we were going out the door and after we had come up with the four values was I think Ward said, "Sir, want me to put this on the web?" And again, this is 2001 so dot com and the web's still kind of new so to speak. And we're all like, yeah, sure, why not? What the hell, can't hurt. We got something, might as well publish it. I don't think to a person, anybody said, "Oh yeah, this is going to set the world on fire because we're so awesome." And we were going to anoint the world with all of this wonderful wisdom. So I don't think anybody was thinking that that much would happen.

Amaar Iftikhar:

Yeah. So what were you thinking at that time? So how would the principles that you had come up with together, was that maybe just for the team to take away? Everyone who was there? What was the plan at that time?

Jon Kern:

I think it was a common practice. Like I said, there were other groups that would often meet and have little consortiums or little gatherings and then publish something. So I think it was just, oh yeah, that's a normal thing to do is you spent some time together and you wrote things down, you might as well publish it. So I think it wasn't any deeper than that other than Bob, I think Bob might say that he wanted to come up with some kind of a manifesto of sorts or some kind of a document because that's I think what those sort of... I was never at one of those gatherings, but you know, you could see that they did publish things. I have a feeling it was just something as innocent as, well we talked, wrote some things down, might as well share it.

And then the principles, there were a lot of different practices in the room. So some of what I would say the beauty of even the values page is the humility at the top is it's still active voice. We are uncovering not, hey all peasants, we figured it all out. No, we're still uncovering it. And the other thing is by doing it, because I'm still an active coder. And plus we value this more on the left, more than on the right. Some people might say it's a little ambiguous or a little fuzzy, but that's also a sign of humility and that it's not A or B. And it really is fuzzy, and you need to understand your context enough to apply these things. So from a defense department contracting point of view, certainly three of the four bullets were really important to me because I learned... Sure, we did defense department contracting. But it's way more important to develop a rapport with the customer than it is... Because by the time you get to the contract you've already lost, which goes along with developing a rapport with the customer, the individual.

And one of Peter Codes, when we worked with customers and whatnot, one of our mantras was frequent tangible working results, AKA working software. You can draw a lot and you can do use cases for nine months, but if you don't have anything running, it's pretty, I would guess risky that you don't have anything, no working software yet. So it really was I think an opportunity to share the fact that some people thought two weeks and other people thought a month. Even some of the print principles had a pretty good wide ranging flexibility so to speak. That I think is really important to note.

Amaar Iftikhar:

Yeah, no, absolutely. And it makes sense. Did you or anyone else in the room at that time ever imagine what the impact downstream would be of the work that was being done there?

Jon Kern:

Not that I'm aware of. I certainly did not. I remember a couple times in my career walking in and seeing some diagrams when I worked with the company Together Soft, and we'd build some cool stuff and I'd see people having some of the... Oh yeah, there's a diagram I remember making on their wall. That's kind of cool. But nothing near how humbling and sort of satisfying it is. Especially I would say when I'm in India or Columbia or Greece, it almost seems maybe they're more willing to be emotional about it. But people are, it's almost like they were freed by this document. And in some sense this is a really, really tiny saying it with the most humility possible. A little bit like the Declaration of Independence, and the fact that a handful of people... And the constitution of the United States. A handful of people met in a moment of time, never to be repeated again and created something that was dropped on the world so to speak, that unleashed, unleashed a tremendous amount of individual freedom and confidence to do things. And I think in a very small, similar fashion, that's what the manifesto did.

Amaar Iftikhar:

As you mentioned, there was a point in time when the manifesto was developed and that was almost over 20 years ago. So now the way of working, and the world of working has drastically changed. So what are your thoughts on that? Do you see another version coming? Do you think there are certain updates that need to be made? Do you think it's kind of a timeless document? I'd love to hear your thoughts on that.

Jon Kern:

Yeah, that's a good question. I personally think it's timeless and I welcome other people to create different documents. And they have. Alistair has The Heart of Agile, Josh Kerievsky's got Modern Agile.

There's a few variations of a theme and different things to reflect upon, which I think is great. Because I do believe, unlike the US Constitution, which built in a mechanism to amend itself, we didn't need that. And I believe it captured the essence of how humans work together to produce something of value. Mostly software, because that's what we came to practice from, is the software experience. But it doesn't take a lot of imagination to replace the word software with product or something like that and still apply much of the values that are there with very, very minor maybe adjustments because frequent tangible working results.

There might have to be models, because you're not going to build a skyscraper and tear it down and say, "Oh, that wasn't quite right," and build it again. But nonetheless, there are variations of how you can show some frequent results. So I think by and large it's timeless. And I would challenge anybody. What's wrong with it? Point out something that's somehow not true 20 years later. And I think that's the genius behind it was we stumbled on... And probably because most of us were object modelers, that's one of the things we're really good at, is distilling the essence of a system into the most critical pieces. That's kind of what modeling is all about. And so I think somehow innately, we got down to the core bits that make up what it is to produce software with people, process and tools. And we wrote it down. That's why I think it's timeless.

Amaar Iftikhar:

Yeah, no absolutely. I think that was a really good explanation about why it's timeless. I think one of the principles that comes to mind in a kind of modern hybrid or flexible working arrangement is one of the principles talks about the importance of face to face conversations. And in a world now where a lot of conversations aren't happening physically face to face, they might be happening on Zoom. Do you think that still applies?

Jon Kern:

Yeah, I think what we're finding out with... Remote was literally remote, so to speak, back 20 years ago. I was working with a team of developers in Russia and we had established enough trust and physical... I would travel there every month. So kind of established enough of a team, and enough trust in the communication that we could do ultimately some asynchronous work because different time zones. And me being in the east coast. 7:00 AM in the US was maybe 3:00 PM in Russia if I recall. St. Petersburg. So we were able to overcome the distance, but it's hard to beat real life. And I would often sometimes even spar a little bit with Ron Jeffries that on the one hand you could say the best that you can do is in person. But on the other hand, I could argue a little bit of some of the remoteness makes things... You have to be a little more verbose, possibly a little more precise, but also a little more verbose. A little more relaxed with... You might take a couple of passes to get something just because, I mean there are two time zones passing in the night. But that was based off of some often initial face to face meetings, and then you could go remote and still be successful and highly effective.

So I think it's important that teams don't just say that they can still do everything. And zoom is way better than 20 years ago, admittedly. Zoom gets, at least you can see a face. But nothing replaces the human contact. And I think also for wellbeing, I think human contact is important. So I would still say that the interaction aspect in the manifesto is still best served with a healthy dose of in-person. And that's kind of the key about most things in Agile. It's to me it's about pragmatism, and not just being dogmatic but rather, what might work better for us? And even experimenting with try something a little bit and see how that works. So even how you treat the manifesto, you should treat it in an Agile manner so to speak.

Amaar Iftikhar:

Yeah, no absolutely. That's a great point. On that note, as an Agile consultant or the Agile guy, what have you seen are the best practices or what works, what doesn't work for distributed teams?

Jon Kern:

Well I think the things that are most challenging that I've run across big companies and even smaller ones is that... I don't know if it's natural, God forbid if it's natural, but tendencies that I've seen in some companies to set up silos where you're the quality control, you're the UX, you're the front end, you're the back end, makes my headwater explode. Because that's building in a lag and building in communication roadblocks and building in cooperation which is handed offs from silo to silo, versus collaboration. So I've seen more of that. And I get it, you might want to have a specialty, but customer doesn't care. Customer wants something out the door. If I showed up and I'm going to pull a feature off the stack, what do you mean I can only do part of it? I don't get that. And yeah, I know I'm not an expert in everything but we probably have an expert that we can figure out what the pattern is. So I find that sort of trend, I don't know if it's a trend, but I find that's a step backwards in my opinion. And it's better to try to be more cross-functional, collaborative, everybody trying to work to get the feature out the door, not just trying to do your little part.

Amaar Iftikhar:

Yeah, a hundred percent. I think knocking on silos is a big part of being agile, or even being digital for that matter. And often the remedies for it too are there at hand, but it's a lot harder to actually be practical with it, to actually implement it in an organization, a living, breathing business where there's real people and there's dynamics to deal with, and there's policies and processes to follow. So I guess as generic as you can be, what is your thought as an Agile consultant to a business that's kind of facing that issue?

Jon Kern:

One of the things that... Adaptive is what my colleague John Turley has really opened my eyes to. I tend to call it the secret sauce, or the missing piece to my practice. And it has to do with individual's mindset and what we call vertical development. So it might sound like weird wishy-washy fluffy stuff, but it's actually super critical. And I've always said people, process, and tools for, I want to say since late nineties probably, I mean a long time. And the first I've been able to realize why sometimes I would have just spectacular super high performing teams and other times it'd be just really, really well performing but not always that spark and sometimes kind of like, eh, that was a little meh. And a lot of it comes down to where people lie on in terms of how they make their meaning and what their motivational orientation is, command and control versus autonomy.

So what we do is we've learned that we can help people first off recognize this exists, and help people with what we call developmental practices. Something that, even the phrase, you probably heard it, like safe experiments. Failure, or trying something and failing. Well if you chop someone's head off for it, guess what? They're just going to probably stay pretty still and only do what they're told, not try to... I have a super high dose of autonomy in me, so I've long lived by the, better to beg forgiveness than ask permission, and always felt as long as I'm trying to do the right thing to succeed and do the best for the company, they probably won't fire me if I make a mistake. But not everybody has that amount of freedom in the way they work. So you have to help establish that as management, and that's a big thing that we work with, with teams.

And then we also start with the class. If you've ever watched office space, and if you haven't you should, but the, what is it that you do here? So there's a great, the consultants Bob and Bob coming in, the efficiency consultants, "So Amaar, what is it that you do here?" But literally that's something, whether we're helping teams build a new product, is okay, what's the purpose? What's the business purpose of this product? What is it that you do here? What do you want to do with this product? What value does it provide? Same thing with anything you're working with as a team. And that's why whether it's software, producing some feature that has an outcome that provides value to the customer, or some product. But the point is if you don't understand that, now it's making, the team is going to have a real hard time being able to make decisions which are helping us move forward.

So if you help everybody understand what it is we're here to do, and then try to get the folks that might reflect all the different silos if you're siloed, but all the different elements. How do we go from an idea to cash, so to speak, or idea to value in the customer's hand? And have a good look at that. Because there are so many things that just sort of... Technical data often creeps into software code bases. And the same thing, we sort of say the organizational debt, the same thing can happen. Your process debt. You can just end up with, all right, we want the development team to go faster, John and company, can you come in and help coach us? We want to go agile. Sure, okay yeah. All right. We roll up our sleeves, we look around and after an initial kind of value stream look, like, wait I'm sorry but there's a little tiny wedge, it's about 15%, that's the development. And then you spent the 85% thinking about it.

Let's pretend we could double the speed of development. Which was initially the... Yeah, we need the developers to code faster or something. That's a classic. And no you don't, you need to stop doing all this bullshit up front that's just crazy ass big waterfall project-y stuff with multiple sign-offs. And matter of fact, one of the sign-offs, oh my gosh it only meets once a week, and then if you have a typo in it, you get rejected. You don't come back for another... Are you insane? You spent eight months deciding to do eight weeks worth of work. Sorry, it's not the eight weeks. So things like that, what I recommend anybody self inspect is try to... If you're worried about your team, how you can do better is just start trying to write down what does your process step look like and what is a typical time frame?

How much time are you putting value into the... Because a lot of times people batch things up in sprints. That's a batch, why are you putting things in a batch? Or they have giant issues. Well that's the big batch. So there's lots of often low hanging fruit. But to your point, it's often encrusted in, this is the way we work and nobody feels the ability to change or even to stop and look to see how are we working. So I think that's where we usually start is let's see how you actually work today. And then while we're doing that you can spill your guts, you can tell us all the things that hurt and that are painful and then we'll try to design a better way that we can move towards, in terms of working more effectively. Because our goal is to help teams be able to develop ways to do more meaningful and joyous work, really. Because it's a lot of fun when it's clicking and when you're on a good team and you're putting smiles on the customers' faces, it's hard to almost stay away from work because it's so much fun. But if it's not that, if it's drudgery and you're just a cog in the machine and stuff takes months to get out the door, it's a job. It's not that much fun.

Amaar Iftikhar:

Yeah. A lot of the points that you mentioned there strongly resonated with me, and the common pain points. It sounds like you've kind of seen it all. And by the way if you haven't seen office space, definitely need to watch it. It's a really good one. You've mentioned now a lot about of the element of the challenges that a distributed team faces. Now I want to flip it over and ask you what does the perfect distributed team look like today that lives and breathes agile values?

Jon Kern:

Yeah. I don't know if you can ever have such a thing, a perfect of any kind of team. So I would say harking back to the types of distributed teams that I've worked with, and this goes back to the late nineties. So I've been doing this for a long, long time. Only really done remote, whether it was with developers in Russia or down in North Carolina, or places like that. And I think that the secret was having a combination of in-person... If you want to go somewhere as a group, there are things you can do to break the ice, to establish some, what you might call team building type activities.

And not just, hey let's go do a high ropes course and be scared out of our wits together. But rather also things that are regarding why are we here, what are we trying to achieve? And let's talk about whether it's the product we're trying to build, and take that as an opportunity to coalesce around something and get enough meat on the bone, enough skeletons of what it might look like. Because there's good ways to start up and have a good foundation. And that's part of what I've been practicing for decades. If you get things set up properly with understanding that just enough requirements, understanding... And I do a lot of domain modeling with UML and things like that, just understanding what the problem domain is that we're trying to solve to achieve the goals we're looking for, have a sense of the architecture that we want. So all those things are collaborative efforts.

And so if you have enough of a starting point where you've worked together, you come in and, let's say you even had to go rent someplace, because nobody lived near office, so you all flew somewhere. I mean that's money well spent in my opinion. Because that starts the foundation. If you've broken bread so to speak, or drank some beers, or coded together and did stuff, and then you go back to your remote offices to take the next steps and then realize when you might need to meet again. So that's really important to understand that the value of establishing those relationships early on so that you can talk bluntly. And I have some good folks that I run a production app for firefighters since like 2006.

Amaar Iftikhar:

Yeah, very cool.

Jon Kern:

And that friend that I've worked with, we are so tight that we can... It makes our conversations, we don't have to beat around the bush, we don't have to worry about offending any, we just, boom, cut to the chase. Because we know we're not calling each other's kids ugly. We're just trying to get something done fast.

And building that kind of rapport takes time and effort and working together. And that's what I think a good successful distributed team, you need to come together every so often and build those relationships and know when you might need to come together again if something is a problem. But that I think is a key to success is it shortens the time. Because you may have heard of things like the group forms, if this is performance on the Y axis they form and they're at some performance level, then they need to storm before they get back to normal, and before they start high performing. So it's this form, storm. You get worse when you're storming. And storming means really understanding where we're at. When we argue about, I don't think that should be inheritance, Amaar. And then you're like, "Oh bull crap, it really..."

And again, we're not personal, but we're learning each other's sort of perspectives and we're learning how to have respectful debates and have some arguments, so to speak, to get to the better place. And I've worked in some companies that are afraid to storm, and it feels like you're never high performing.

Everyone's too polite. It's like, come on. And I love when I worked with my Russian colleagues. They didn't give a crap if I was one of the founders. And I'm glad, because I don't want any privilege, I don't want anything like that. No let's duke it out. May the best ideas win. That's where you want to get to. And if you can't get there because you don't have enough of a relationship, and you tend not to say the things that needed to be said because you're being polite, well it's going to take you really long to succeed. And that's a lot of money, and that's a lot of success, and people might leave.

So I think the important thing is if you're remote, that's okay, but sheer remote is a real challenge. And you have to somehow figure out, if you can't get together to learn how to form and storm, and build those bonds face to face, then you need to figure out how to do it over Zoom. Because you need to do it, because if you don't, if you never have words, then trust me, you're still not high performing.

Amaar Iftikhar:

Yeah, I kind of feel like being fully remote now is being offered as almost a competitive advantage to candidates in the marketplace now, because it's a fight for talent. But if I'm understanding correctly, what you are saying is that in-person element is so important to truly be high performing and those ideas kind of contradict each other, I feel.

Jon Kern:

Yeah. And again, having been remote since the late nineties, I've been doing this a long time. And commuting to Russia is the longest commute I ever did, for three years. I mean that's a hell of a long flight to commute there over seven times, or whatever the hell it was. Anyway, I used to say that that being remote is not for everyone, because it really isn't. I mean you have to know how to work without anybody around, and work. I mean it has its own challenges. And yeah, it might be a perk, but I think what you need to do is look at potentially what the perks are and figure out too, can I fold them into... It doesn't have to be all or nothing. And I think that can be a easy mistake to make maybe is to, all right cool, we don't have to have office space. That's a lot of savings for the company. Yeah, but maybe that means you need to have some remote workspaces for occasional gatherings, or figure it out.

But yeah, I think even... And certain businesses might work differently. In the beginning of building a product, I want to have heavy collaboration and I want to get to a point where it's almost, I feel like the product goes like this where once you get things rolling and you kind of get up, get some momentum going, now the hardest thing to do is be in front of an agile team, whether they're in-person or remote. Once things are rolling and rocking and kicking and it's like everything's clicking, you can just bang out features left, like boom, boom, boom. Yeah, okay then we probably need to be...

Unless we've got ways that we're pairing or things like that. I will say when we're together, mobbing is easier. I'm sure there's ways to do it remote, but being in a room, I don't know, it's a lot easier than coordinating over Zoom. You just, hey there's this problem, let's all hang out here after standup because we're just going to mob on this. So it doesn't take a whole lot versus anything remote, there's a little extra, okay, we've got to coordinate, and even different times zones, gets even worse. So yeah, don't get carried away with remote being the end all be all. Because I have a feeling there's going to be a... I would wager there will be a backlash.

Amaar Iftikhar:

And I'll take that back coming from the Agile, the person who does this day to day who helps teams become agile, I'll definitely kind of take your word for it. Plus with my experience too, I've seen nothing really beats a good white-boarding session. That is really hard to replicate online. I mean we have these amazing tools, but nothing quite mimics the real life experience of just having a plain whiteboard and a marker in your hand. That communication is so powerful.

Jon Kern:

Great point. You're so, right, because I had just with the one company that I was with for five years, we were doing high level engineered to order pump manufacturing sales type tool for... So it was my favorite world because it blended my fluid dynamics as an aerospace engineer, plus my love for building SaaS products, and building new software and things like that. And even having a young, we would interview at Lehigh University and we'd have some young graduates that would be working with us, and being able to bring them into the fold, and there was a room behind where my treadmill was and we'd go in there, we'd have jam sessions on modeling and building out new features. And man, you're right. Just that visceral three dimensional experience. Yeah, Miro's great. Or any other kind of tool, but yeah, it's not the same. You're absolutely right. That's a great point. You're almost making me pine for the good old days. [inaudible 00:42:04]

Amaar Iftikhar:

I think the good old days very much still exist. I think even now, it's kind of been a refreshing time for me to be with Easy Agile. I've only been here for just under two months now. And there's a strong in-person dynamic. And again, it's optional, where if people are remote or they're hybrid or they need to commute once in a while, it's a very understanding environment. But once you're in the office or you're in person, you kind of feel the effect you were describing, you're motivated to deliver for the end customer. You just want to come back. It's an addictive feeling of, I want to be back in person and I want to collaborate in real time in person.

Jon Kern:

That's beautifully said, because that's... One of the companies that we're beginning to engage with in South Africa, they're at this very crossroad of struggling with, everybody's been remote, but boy, the couple times we were together, got so much done. And you're describing the flame of, the warmth of delivering and let the moths come to the flame. I mean nurture it and then fan the flames of the good and let people opt in and enjoy it. And still sometimes, yeah, I got to say home, I got the kids or the dog, that's okay too. But giving the option I think is where we're going to head. And I believe the companies that are able to build that hybrid culture of accepting both, and neither mandating one nor the other, but building such a high performing team that basically encourages people to opt into the things that make the most sense at that time. And I think that those companies will rule the day, so to speak.

Amaar Iftikhar:

Yeah, absolutely. It's been so nice to chat with you John, and I've really enjoyed this. I want to leave the audience off with one piece of advice for distributed agile teams from you. We've talked a lot about the importance of in-person collaboration. We've talked about the principles of the agile manifesto. Now, what would the one piece of advice be when you're thinking of both? When you want the agile manifestos to be something that's living and breathing in distributed agile teams, what one piece of advice can you give businesses today right now who are going through the common struggles? What can you tell them as that last piece of advice?

Jon Kern:

Well, I think kind of a one phrase that I like to use to capture the manifesto is, "Mind the gap." In my sort of play on words, what I mean is the gap in time between taking an action and getting a response. Whether it's what do we do about the office, what do we do about remote, what do we do about this feature, what do we do about this line of code? The gap in time is, it's sort of a metaphor about being humble enough to treat things as a hypothesis. So don't be so damn sure of yourself one way or the other about the office or remote or distributed. But instead, treat things as a hypothesis. Be curious and experiment safely with different ways and see what works. And don't be afraid of change. It's not a life sentence to, you got to run your business or your project or your team one way for the rest of your life. No. Don't tell the boss, but work is subsidized learning. I never understood people who just keep doing the same thing because they weren't given permission. Just try it. So that's what my departing phrase would be regarding making those decisions. Mind the gap and really be humble about making assumptions, and test your hypotheses, and shorten the gap in time between taking actions and seeing a reaction.

Amaar Iftikhar:

Oh, that's awesome. Thank you. I really wish we could let the tape roll and just keep talking about this for a couple more hours, but we'll end it right there on that really good piece of advice that you've left the audience off with. Jon, thank you again for being on the podcast. And we've really, really enjoyed hearing you and learning from your experiences.

Jon Kern:

Oh, my pleasure. Any time. Happy to talk another couple hours, but maybe after some beers.

Amaar Iftikhar:

Yeah.

Jon Kern:

Except it's your morning, my evening. I'm going to have to work on that.

Amaar Iftikhar:

Yeah.

Jon Kern:

My pleasure, Amaar.

On this episode of The Easy Agile Podcast, tune in to hear developers Angad, Jared, Jess and Jordan, as they share their thoughts on observability.  

Wollongong has a thriving and supportive tech community and in this episode we have brought together some of our locally based Developers from Siligong Valley for a round table chat on all things observability.

💥 What is observability?
💥 How can you improve observability?
💥 What's the end goal?

‍

‍

‍

"This was a great episode to be a part of! Jess and Jordan shared some really interesting points on the newest tech buzzword - observability""

Be sure to subscribe, enjoy the episode 🎧

‍

‍

‍

Transcript

Jared Kells:

Welcome everybody to the Easy Agile podcast. My name's Jared Kells, and I'm a developer here at Easy Agile. Before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the Wodiwodi people of the Dharawal nation, and pay our respects to elders past, present and emerging, and extend that same respect to any aboriginal people listening with us today.

Jared Kells:

So today's podcast is a bit of a technical one. It says on my run sheet here that we're here to talk about some hot topics for engineers in the IT sector. How exciting that we've got a couple of primarily front end engineers and Angad and I are going to share some front end technical stuff and Jess and Jordan are going to be talking a bit about observability. So we'll start by introductions. So I'll pass it over to Jess.

Jess Belliveau:

Cool. Thanks Jared. Thanks for having me one as well. So yeah, my name's Jess Belliveau. I work for Apptio as an infrastructure engineer. Yeah, Jordan?

Jordan Simonovski:

I'm Jordan Simonovski. I work as a systems engineer in the observability team at Atlassian. I'm a bit of a jack of all trades, tech wise. But yeah, working on building out some pretty beefy systems to handle all of our data at Atlassian at the moment. So, that's fun.

Angad Sethi:

Hello everyone. I'm Angad. I'm working for Easy Agile as a software dev. Nothing fancy like you guys.

Jared Kells:

Nothing fancy!

Jess Belliveau:

Don't sell yourself short.

Jared Kells:

Yeah, I'll say. Yeah, so my name's Jared, and yeah, senior developer at Easy Agile, working on our apps. So mainly, I work on programs and road maps. And yeah, they're front end JavaScript heavy apps. So that's where our experience is. I've heard about this thing called observability, which I think is just logs and stuff, right?

Jess Belliveau:

Yeah, yeah. That's it, we'll wrap up!

Jared Kells:

Podcast over! Tell us about observability.

Jess Belliveau:

Yeah okay, I'll, yeah. Well, I thought first I'd do a little thing of why observability, why we talk about this and sort of for people listening, how we got here. We had a little chat before we started recording to try and feel out something that might interest a broader audience that maybe people don't know a lot about. And there's a lot of movements in the broad IT scope, I guess, that you could talk about. There's so many different things now that are just blowing up. Observability is something that's been a hot topic for a couple of years now. And it's something that's a core part of my job and Jordan's job as well. So it's something easy for us to talk about and it's something that you can give an introduction to without getting too technical. So we don't want to get down. This is something that you can go really deep into the weeds, so we picked it as something that hopefully we can explain to you both at a level that might interest the people at home listening as well.

Jess Belliveau:

Jordan and I figured out these four bullet points that we wanted to cover, and maybe I can do the little overview of that, and then I can make Jordan cover the first bullet point, just throw him straight under the bus.

Jordan Simonovski:

Okay!

Jess Belliveau:

So we thought we'd try and describe to you, first of all, what is observability. Because that's a pretty, the term doesn't give you much of what it is. It gives you a little hint, but it'll be good to base line set what are we talking about when we say what is observability. And then why would a development team want observability? Why would a company want observability? Sort of high level, what sort of benefits you get out of it and who may need it, which is a big thing. You can get caught up in these industry hot buzz words and commit to stuff that you might not need, or that sort of stuff.

Jared Kells:

Yep.

Jordan Simonovski:

Yep.

Jess Belliveau:

We thought we'd talk about some easy wins that you get with observability. So some of the real basic stuff you can try and get, and what advantages you get from it. And then we just thought because we're no going to try and get too deep, we could just give a few pointers to some websites and some YouTube talks for further reading that people want to do, and go from there. So yeah, Jordan you want to-

Jared Kells:

Sounds good.

Jess Belliveau:

Yeah. I hopefully, hopefully. We'll see how this goes! And I guess if you guys have questions as well, that's something we should, if there's stuff that you think we don't cover or that you want to know more, ask away.

Jordan Simonovski:

I guess to start with observability, it's a topic I get really excited about, because as someone that's been involved in the dev ops and SRE space for so long, observability's come along and promises to close the loop or close a feedback loop on software delivery. And it feels like it's something we don't really have at the moment. And I get that observability maybe sounds new and shiny, but I think the term itself exists to maybe differentiate itself from what's currently out there. A lot of us working in tech know about monitoring and the loading and things like that. And I think they serve their own purpose and they're not in any way obsolete either. Things like traditional monitoring tools. But observability's come along as a way to understand, I think, the overwhelmingly complex systems that we're building at the moment. A lot of companies are probably moving towards some kind of complicated distributed systems architecture, microservices, other buzz words.

Jordan Simonovski:

But even for things like a traditional kind of monolith. Observability really serves to help us ask new questions from our systems. So the way it tends to get explained is monitoring exits for our known unknowns. With seniority comes the ability to predict, almost, in what way your systems will fail. So you'll know. The longer you're in the industry, you know this, like a Java server fails in x, y, z amount of ways, so we should probably monitor our JVM heap, or whatever it is.

Jared Kells:

I was going to say that!

Jordan Simonovski:

I'll try not to get too much into-

Jared Kells:

Runs out of memory!

Jordan Simonovski:

Yeah. So that's something that you're expecting to fail at some point. And that's something that you can consider a known unknown. But then, the promise of observability is that we should be shipping enough data to be able to ask new questions. So the way it tends to get talked about, you see, it's an unknown unknown of our system, that we want to find out about and ask new questions from. And that's where I think observability gets introduced, to answer these questions. Is that a good enough answer? You want me to go any further into detail about this stuff? I can talk all day about this.

Jared Kells:

Is it like a [crosstalk 00:08:05]. So just to repeat it back to you, see if I've understood. Is it kind of like if I've got a, traditionally with a Java app, I might log memories. It's because I know JVM's run out of memory and that's a thing that I monitor, but observability is more broad, like going almost over the top with what you monitor and log so that you can-

Jordan Simonovski:

Yeah. And I wouldn't necessarily say it's going over the top. I think it's maybe adding a bit more context to your data. So if any of you have worked with traces before, observability is very similar to the way traces work and just builds on top of the premise of traces, I guess. So you're creating these events, and these events are different transactions that could be happening in your applications, usually submitting some kind of request. And with that request, you can add a whole bunch of context to it. You can add which server this might be running on, which time zone. All of these additional and all the exciters. You can throw in user agency into there if you want to. The idea of observability is that you're not necessarily constrained by high cardinality data. High cardinality data being data sets that can change quite largely, in terms of the kinds of data they represent, or the combinations of data sets that you could have.

Jordan Simonovski:

So if you want shipping metrics on something, on a per user basis and you want to look at how different users are affected by things, that would be considered a high cardinality metric. And a lot of the time it's not something that traditional monitoring companies or metric providers can really give you as a service. That's where you'll start paying insanely huge bills on things like Datadog or whatever it is, because they're now being considered new metrics. Whereas observability, we try and store our data and query it in a way that we can store pretty vast data sets and say, "Cool. We have errors coming from these kinds of users." And you can start to build up correlations on certain things there. You can find out that users from a particular time zone or a particular device would only be experiencing that error. And from there, you can start building up, I think, better ways of understanding how a particular change might have broken things. Or some particular edge cases that you otherwise couldn't pick up on with something like CPU or memory monitoring.

Angad Sethi:

Would it be fair to say-

Jared Kells:

Yeah. It's [crosstalk 00:11:02].

Angad Sethi:

Oh, sorry Jared.

Jared Kells:

No you can-

Angad Sethi:

Would it be fair to say that, so, observability is basically a set of principles or a way to find the unknown unknowns?

Jordan Simonovski:

Yeah.

Angad Sethi:

Oh.

Jess Belliveau:

And better equip you to find, one of the things I find is a lot of people think, you get caught up in thinking observability is a thing that you can deploy and have and tick a box, but I like your choice of word of it being a set of principles or best practices. It's sort of giving you some guidance around these, having good logging coming out of your application. So structured logs. So you're always getting the same log format that you can look at. Tracing, which Jordan talked a little bit about. So giving you that ability to follow how a user is interacting with all the different microservices and possibly seeing where things are going wrong, and metrics as well. So the good thing with metrics is we're turning things a bit around and trying to make an application, instead of doing, and I don't want to get too technical, black box monitoring, where we're on the outside, trying to peer in with probes and checks like that. But the idea with metrics is the application is actually emitting these metrics to inform us what state it is in, thereby making it more observable.

Jess Belliveau:

Yeah, I like your choice of words there, Angad, that it's like these practices, this sort of guide of where to go, which probably leads into this next point of why would a team want to implement it. If you want to start again, Jordan?

Jordan Simonovski:

Yeah, I can start. And I'll give you a bit more time to speak as well, Jess in this one. I won't rant as much.

Jess Belliveau:

Oh, I didn't sign up for that!

Jordan Simonovski:

I think why teams would want it is because, it really depends on your organization and, I guess, the size of the teams you're working in. Most of the time, I would probably say you don't want to build observability yourself in house. It is something that you can, observability capabilities themselves, you won't achieve it just by buying a thing, like you can't buy dev ops, you can't buy Agile, you can't buy observability either.

Jared Kells:

Hang on, hang on. It says on my run sheet to promote Easy Agile, so that sounds like a good segue-

Jess Belliveau:

Unless you want to buy it. If you do want to buy Agile, the [crosstalk 00:13:55] in the marketplace.

Jared Kells:

Yeah, sorry, sorry, yeah! Go on.

Jordan Simonovski:

You can buy tools that make your life a lot easier, and there are a lot of things out there already which do stuff for people and do surface really interesting data that people might want to look at. I think there are a couple of start ups like LightStep and Honeycomb, which give you a really intuitive way of understanding your data in production. But why you would need this kind of stuff is that you want to know the state of your systems at any given point in time, and to build, I guess, good operational hygiene and good production excellence, I guess as Liz Fong-Jones would put it, is you need to be able to close that feedback loop. We have a whole bunch of tools already. So we have CICD systems in place. We have feature flags now, which help us, I guess, decouple deployments from releases. You can deploy code without actually releasing code, and you can actually give that power to your PM's now if you want to, with feature flags, which is great.

Jordan Simonovski:

But what you can also do now is completely close this loop, and as you're deploying an application, you can say, "I want to canary this deployment. I want to deploy this to 10% of my users, maybe users who are opted in for Beta releases or something of our application, and you can actually look at how that's performing before you release it to a wider audience. So it does make deployments a lot safer. It does give you a better understanding of how you're affecting users as well. And there are a whole bunch of tools that you can use to determine this stuff as well. So if you're looking at how a lot of companies are doing SRE at the moment, or understanding what reliable looks like for their applications, you have things like SLO's in place as well. And SLO's-

Jared Kells:

What's an SLO?

Jordan Simonovski:

They're all tied to user experiences. So you're saying, "Can my user perform this particular interaction?" And if you can effectively measure that and know how users are being affected by the changes you're making, you can easily make decisions around whether or not you continue shipping features or if you drop everything and work on reliability to make sure your users aren't affected. So it's this very user centric approach to doing things. I think in terms of closing the loop, observability gives us that data to say, "Yes, this is how users are being affected. This is how, I guess the 99th percentile of our users are fine, but we have 1% who are having adverse issues with our application." And you can really pinpoint stuff from there and say, "Cool. Users with this particular browser or this particular, or where we've deployed this app to," let's say if you have a global deployment of some kind, you've deployed to an island first, because you don't really care what happens to them. You can say, "Oh, we've actually broken stuff for them." And you can roll it back before you impact 100% of your users.

Jared Kells:

Yeah. I liked what you said about the test. I forgot the acronym, but actually testing the end user behavior. That's kind of exciting to me, because we have all these metrics that are a bit useless. They're cool, "Oh, it's using 1% CPU like it always is, now I don't really care," but can a user open up the app and drag an issue around? It's like-

Jess Belliveau:

Yeah, that's a really great example, right?

Jared Kells:

That's what I really care about.

Jess Belliveau:

The 1% CPU thing, you could look at a CPU usage graph and see a deployment, and the CPU usage doesn't change. Is everything healthy or not? You don't know, whereas if you're getting that deeper level info of the user interactions, you could be using 1% CPU to serve HTTP500 errors to the 80% of the customer base, sort of thing.

Angad Sethi:

How do you do that? The SLO's bit, how do you know a user can log in and drag an issue?

Jordan Simonovski:

Yeah. I think that would come with good instrumenting-

Angad Sethi:

Good question?

Jordan Simonovski:

Yeah, it comes down to actually keeping observability in mind when you are developing new features, the same way you would think about logging a particular thing in your code as you're writing, or writing test for your code, as you're writing code as well. You want to think about how you can instrument something and how you can understand how this particular feature is working in production. Because I think as a lot of Agile and dev ops principles are telling us now is that we do want our applications in production. And as developers, our responsibilities don't end when we deploy something. Our responsibility as a developer ends when we've provided value to the business. And you need a way of understanding that you're actually doing that. And that's where, I guess, you do nee do think about observability with a lot of this stuff, and actually measuring your success metrics. So if you do know that your application is successful if your user can log in and drag stuff around, then that's exactly what you want to measure.

Jared Kells:

I think that we have to build-

Jordan Simonovski:

Yeah?

Jared Kells:

Oh, sorry Jordan.

Jordan Simonovski:

No, you go.

Jared Kells:

I was just going to say we have to build our apps with integration testing in mind already. So doing browser based tests around new features. So it would be about building features with that and the same thing in mind but for testing and production.

Jess Belliveau:

Yeah and the actual how, the actual writing code part, there's this really great project, the open telemetry project, which provides all these sort of API's and SDK's that developers can consume, and it's vendor agnostic. So when you talk about the how, like, "How do I do this? How do I instrument things?" Or, "How do I emit metrics?" They provide all these helpful libraries and includes that you can have, because the last thing you want to do is have to roll this custom solution, because you're then just adding to your technical debt. You're trying to make things easier, but you're then relying on, "Well I need to keep Jared Kells employed, because he wrote our log in engine and no one else knows how it works.

Jess Belliveau:

And then the other thing that comes to mind with something like open telemetry as well, and we talked a bit about Datadog. So Datadog is a SaaS vendor that specializes in observability. And you would push your metrics and your logs and your traces to them and they give you a UI to display. If you choose something that's vendor agnostic, let's just use the example of Easy Agile. Let's say they start Datadog and then in six months time, we don't want to use Datadog anymore, we want to use SignalFx or whatever the Splunk one is now.

Jordan Simonovski:

I think NorthX.

Jess Belliveau:

Yeah. You can change your end point, push your same metrics and all that sort of stuff, maybe with a few little tweaks, but the idea is you don't want to tie in to a single thing.

Jordan Simonovski:

Your data structures remain the same.

Jess Belliveau:

Yeah. So that you could almost do it seamlessly without the developers knowing. There's even companies in the past that I think have pushed to multiple vendors. So you could be consuming vendor A and then you want to do a proof of concept with vendor B to see what the experience is like and you just push your data there as well.

Jared Kells:

Yeah. I think our coupling to Datadog will be I all the dashboards and stuff that we've made. It's not so much the data.

Jess Belliveau:

Yeah. That's sort of the big up sell, right. It's how you interact. That's where they want to get their hooks in, is making it easier for you to interpret that data and manipulate it to meet your needs and that sort of stuff.

Jordan Simonovski:

Observability suggests dashboards, right?

Jess Belliveau:

Yeah, perhaps. You used this term as well, Jordan, "production excellence." And when we talk about who needs observability, I was thinking a bit about that while you were talking. And for me, production excellence, or in Apptio we call it production readiness, operational readiness and that sort of stuff is like we want to deploy something to production like what sort of best practices do we want to have in place before we do that? And I think observability is a real great idea, because it's helping you in the future. You don't know what problems you're going to have down the line, but you're equipping your teams to be able to respond to those problems easily. Whereas, we've all probably been there, we've deployed code of production and we have no observability, we have a huge outage. What went wrong? Well, no one knows, but we know this is the fix, and it's hard to learn from that, or you have to learn from that I guess, and protect the user against future stuff, yeah.

Jess Belliveau:

When I think easy wins for observability, the first thing that really comes to mind is this whole idea of structured logging, which is really this idea that your application is you're logging, first of all. Quite important as a baseline starting point, but then you have a structured log format which lets you programmatically pass the logs as well. If you go back in time, maybe logging just looked like plain text with a line, with a timestamp, an error message. Whatever the developer decided to write to the standard out, or to the error file or something like that. Now I think there's a general move to having JSON, an actual formatted blob with that known structure so you can look into it. Tracing's probably not an easy win. That's a little bit harder. You can implement it with open telemetry and libraries and stuff. Requires a bit more understanding of your code base, I guess, and where you want tracing to fire, and that sort of stuff, parsing context through, things like that.

Jordan Simonovski:

I think Atlassian, when you probably just want to know that everything is okay. At a fairly superficial level. Maybe you just want to do some kind of up time on a trend. And then as, I guess, your code might get more complex or your product gets a bit more complex, you can start adding things in there. But I think actually knowing or surfacing the things you know might break. Those would probably be your quickest wins.

Jess Belliveau:

Well, let's mention some things for further reading. If you want to go get the whole picture of the whole, real observability started to get a lot of movement out of the Google SRE book from a few years ago. The Google SRE stuff covers the whole gamut of their soak reliability engineering practice, and observability is a portion of that, there's some great chapters on that. O'Reilly has an observability book, I think, just dedicated to observability now.

Jordan Simonovski:

I think that's still in early release, if people want to google chapters.

Jess Belliveau:

The open telemetry stuff, we'll drop a link to that I think that's really handy to know.

Angad Sethi:

From [inaudible 00:26:12], which is my perspective, as a developer, say I wanted to introduce cornflake use Datadog at Easy Agile. Not very familiar, I'm not very comfortable with it. I know how to navigate, but what's a quick way for me to get started on introducing observability? Sorry to lock my direct job or at my workplace.

Jordan Simonovski:

I would lean, I could be biased here. Jess correct me or give your opinion on this, I would lean heavily towards SLO's for this. And you can have a quick read in the SRE-

Jess Belliveau:

What does SLO stand for, Jordan?

Jordan Simonovski:

Okay, sorry. Buzz words! SLO is a service level objective, not to be confused with service level agreement. An agreement itself is contractual and you can pay people money if you do breach those. An SLO is something you set in your team and you have a target of reliability, because we are getting to the point where we understand that all systems at any point in time are in some kind of degraded state. And yeah, reliability isn't necessarily binary, it's not unreliable or reliable. Most of the time, it's mostly reliable and this gives us a better shared language, I guess. And you can have a read in the SRE handbook by Google, which is free online, which gives you a pretty good understanding of Datadog.

Jordan Simonovski:

I think the last time I used it had a SLO offering. But I think like I was mentioning earlier, you set an SLO on particular functionalities or features of your application. You're saying, "My user can do this 99% of the time," or whatever other reliability target you might want to set. I wouldn't recommend five nines of reliability. You'll probably burn yourself out trying to get there. And you have this target set for yourself. And you know exactly what you're measuring, you're measuring particular types of functionality. And you know when you do breach these, users are being affected. And that's where you can actually start thinking about observability. You can think about, "What other features are we implementing that we can start to measure?" Or, "What user facing things are we implementing that we can start to measure?"

Jordan Simonovski:

Other things you could probably look at are, I think they're all covered in the book anyway, data freshness in a way. You want to make sure the data users are being displayed is relatively fresh. You don't want them looking at stale data, so you can look at measuring things like that as well. But you can pretty much break it down into most functionalities of a website. It's no longer like a ping check, that you're just saying, "Yes, HTTP, okay. My application is fine." You're saying, "My users are actually being affected by things not working." And you can start measuring things from there. And that should give you a better understanding, or a better idea, at least, of where to start with what you want to measure and ow you want to measure it. That would be my opinion on where to get started with this if you do want to introduce it.

Jared Kells:

We're going to talk a little bit about state and how with some of these, like our very front end heavy applications that we're building, so the applications we build just basically run inside the browser and the traditional state as you would think about it, is just pulling a very simple API that writes some things into the database with some authentication, and that sort of stuff. So in terms of reliability of the services, it's really reliable. Those tiny API's just never have problems, because it's just so simple. And well, they've got plenty of monitoring around it. But all our state is actually, when you say, "Observe the state of the system," for the most part, that's state in a browser. And how do we get observability into that?

Jess Belliveau:

A big thing is really, there's not one thing fits all as well. When we talk about the SLO stuff as well, it's understanding what is important to not so much maybe your company but your team as well. If you're delivering this product, what's important to you specifically? So one SLO that might work for me at Apptio probably isn't going to work for Easy Agile. This is really pushing my knowledge, as well, of front end stuff, but when we say we want to observe the state as well, we don't necessarily mean specifically just the state. You could want to understand with each one of those API's when it's firing, what the request response time is for that API firing. So that might be an important metric. So you can start to see if one of those APIs is introducing latency, and so your user experience is degraded. Like, "Hey when we were on release three, when users were interacting with our service here, it would respond in this percentile latency. We've done a release and since then, now we're seeing it's now in this percentile. Have we degraded performance performance?" Users might not be complaining, but that could be something that the team then can look into, add to a sprint. Hey, I'm using Agile terms now. Watch out!

Jared Kells:

That's a really good example, Jess. Performance issues for us are typically not an API that's performing poorly. It's something in this very complicated front end application is not running in the same order as it used to, or there's some complex interaction we didn't think of, so it's requesting more data than expected. The APIs are returning. They're never slow, for the most part, but we have performance regressions that we may not know about without seeing them or investigating them. The observability is really at the individual user's browser level. That makes sense? I want to know how long did it take for this particular interaction to happen.

Jess Belliveau:

Yeah. I've never done that sort of side of things. As well, the other thing I guess, you could potentially be impacted in as well as then, you're dealing with end user manifestations as well. You could perceive-

Jared Kells:

Yeah sure.

Jess Belliveau:

... Greater performance on their laptop or something, or their ISP or that sort of stuff. It'd be really hard to make sure you're not getting noise from that sort of thing as well.

Jordan Simonovski:

Yeah. There are tools like Sentry, I guess, which do exist to give you a bit more of an understanding what's happening on your front end. The way Sentry tends to work with JavaScript, is you'll upload a minified map of your JS to Sentry, deploy your code and then if something does break or work in a fairly unexpected way, that tends to get surfaced with Sentry will tell you exactly which line this kind of stuff is happening on, and it's a really cool tool for that company stuff. I don't know if it'd give you the right type of insights, I think, in terms of performance or-

Jared Kells:

Yeah, we use a similar tool and it does work for crashes and that sort of thing. And on the observability front, we log actions like state mutations in side the front end, not the actual state change, but just labels that represent that you updated an issue summary or you clicked this button, that sort of thing, and we send those with our crash reports. And it's super helpful having that sort of observability. So I think I know what you guys are talking about. But I'm just [crosstalk 00:35:25], yeah.

Jess Belliveau:

Yeah, that's almost like, I guess, a form of tracing. For me and Jordan, when we talk about tracing, we might be thinking about 12 different microservices sitting in AWS that are all interacting, whereas you're more shifting that. That's sort of all stuff in the browser interacting and just having that history of this is what the user did and how they've ended up-

Jared Kells:

In that state.

Jess Belliveau:

In that state, yeah.

Jordan Simonovski:

I guess even if you don't have a lot of microservices, if you're talking about particular, like you're saying for the most part your API requests are fine but sometimes you have particularly large payloads-

Jared Kells:

We actually have to monitor, I don't know, maybe you can help with this, we actually should be monitoring maybe who we're integrating with. It's actually much more likely that we'll have a performance issue on a Xero API rather than... We don't see it, the browser sees it as well, which is-

Jordan Simonovski:

Yeah, and tracing does solve all of those regressions for you. Most tracing libraries, like if you're running Node apps or whatever on your backend. I can just tell you about Node, because I probably have the most experience writing Node stuff. You pretty much just drop in Didi trace, which is a Datadog library for tracing into your backend and your hook itself into all of, I think, the common libraries that you'll tend to work with, I think. Like if you're working for express or for a lot of just HADP libraries, as well as a few AWS services, it will kind of hook itself into that. And you can actually pinpoint. It will kind of show you on this pretty cool service map exactly which services you're interacting with and where you might be experiencing a regression. And I think traces do serve to surface that information, which is cool. So that could be something worth investigating.

Jess Belliveau:

It's funny. This is a little bit unrelated to observability, but you've just made me think a bit more about how you're saying you're reliant on third party providers as well. And something I think that's really important that sometimes gets missed is so many of us today are relying on third party providers, like AWS is a huge thing. A lot of people writing apps that require AWS services. And I think a lot of the time, people just assume AWS or Jira or whatever, is 100% up time, always available. And they don't write their code in such a way that deals with failures. And I think it's super important. So many times now I've seen people using the AWS API and they don't implement exponential back off. And so they're basically trying to hit the AWS API, it fails or they might get throttled, for example, and then they just go into a fail state and throw an error to the user. But you could potentially improve that user experience, have a retry mechanism automatically built in and that sort of stuff. It doesn't really tie into the observability thing, but it's something.

Jared Kells:

And the users don't care, right? No one cares if it's an AWS problem. It's your problem, right, your app is too slow.

Jess Belliveau:

Well, they're using your app. Exactly right. It reflects on you sort of thing, so it's in your interest to guard against an upstream failure, or at least inform the user when it's that case. Yeah.

Jared Kells:

Well, I think we're going to have to call it, this podcast, because it was an hour ago. We had instructed max 45 minutes.

Jess Belliveau:

We could just keep going. We might need a part two! Maybe we can request [cross talk 00:39:21].

Jared Kells:

Maybe! Yeah.

Jess Belliveau:

Or we'll just start our own podcast! Yeah.

Angad Sethi:

So what were your biggest learnings today, given it's been Angad and I are just learning about observability, Angad what was your biggest learning today about observability? My biggest learning was that observability does not equal Datadog. No, sorry! It was just very fascinating to learn about quantifying the known unknowns. I don't know if that's a good takeaway, but...

Jess Belliveau:

Any takeaway is a good takeaway! What about you, Jared?

Jared Kells:

I think, because I we were going to talk about state management, and part of it was how we have this ability, at the moment to, the way our front ends are architected, we can capture the state of the app and get a customer to send us their state, basically. And we can load it into our app and just see exactly how it was, just the way our state's designed. But what might be even cooler is to build maybe some observability into that front end for support. I'm thinking instead of just having, we have this button to send us out your support information that sends us a bunch of the state, but instead of console logging to the browser log, we could be console logging, logging in our front end somewhere that when they click, "send support information," our customers should be sending us the actions that they performed.

Jared Kells:

Like, "Hey there's a bug, send us your support information." It doesn't have to be a third party service collecting this observability stuff. We could just build into our... So that's what I'm thinking about.

Jess Belliveau:

Yeah, for sure. It'll probably be a lot less intrusive, as well, as some of the third party stuff that I've seen around.

Jared Kells:

Yeah. It's pretty hard with some of these integrations, especially if you're developing apps that get run behind a firewall.

Jess Belliveau:

Yeah

Jared Kells:

You can't just talk to some of these third parties. So yeah, it's cool though. It's really interesting.

Jess Belliveau:

Well, I hope someone out there listening has learned something, and Jordan and I will send some links through, and we can add them, hopefully, to the show notes or something so people can do some more reading and...

Jared Kells:

All thanks!

Jess Belliveau:

Thanks for having us, yeah.

Jared Kells:

Thanks all for your time, and thanks everybody for listening.

Jordan Simonovski:

Thanks everyone.

Angad Sethi:

That was [inaudible 00:41:55].

Jess Belliveau:

Tune in next week!