Easy Agile Podcast Ep.27 Inclusive leadership

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!

"From beer analogies, to scrum in restaurants and neurodiverse teams, it's always a pleasure chatting with Kit"

Kit talks to agile methodology beyond the usual use case, like working with geologists & restaurant owners to apply scrum.

Kit also highlights the need to focus on a bottom-up approach, providing a safe space for leaders to learn & ask questions, and whether neurodiverse teams are key to effectiveness.

This was a really interesting conversation!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Nick Muldoon:

G'day folks. My name's Nick Muldoon. I'm the Co Founder and Co CEO of Easy Agile, and I'm delighted to be joined today by Kit Friend from Accenture. Kit is an agile coach at Accenture and he's also the Atlassian Practice Lead there. Kit, good morning.

Kit Friend:

Morning, Nick. Sadly only the Practice Lead for a bit of things, but I try my best. It's a pleasure to be with you, for the second time we've tried this week as well, in the lovely world of broadband dependent remote working and things. But here's hoping, eh?

Nick Muldoon:

It's beautiful, isn't it? Now, for those of you at home listening in just so you've got a bit of context, Kit is a father to two, he lives in London, and he's been at Accenture now for a little over 10 years, right?

Kit Friend:

Yeah, September, 2010. Fortunately I met my wife in pretty much the same summer, so I only have to remember one year, and I can remember one by the other. So it helps when I'm trying to remember dates, and sort things through because I'm not very good with my memory, to be honest with you.

Nick Muldoon:

Oh well. So for me, the reason to get you on today, I'm super excited to hear about the journey that you've been on in Accenture, and I guess the journey that you're on with your clients, and on these various engagements. Before we dive into that though, I wanted to know, can you just tell me what is one of your favorite bands from the '90s, from the early '90s?

Kit Friend:

Yeah, and I really enjoy that we had a delay between things, because it's like one of those questions, because I'm like, "Hmm." And I think I'm a victim of playlist culture, where it's like naming an entire band feels like a real commitment. It's all about tracks now with things, right? But I have narrowed it down to two for my favorite 90s band and I think I'm going to commit afterwards. So my undisputed favorite 90s track, Common People by Pulp, right? Hands down, yeah, it's right up there. For me, I studied at St Martins, the Art College, so for me Common People is the karaoke track of my university days with things there. So Common People by Pulp, favorite track.

Kit Friend:

For bands wise though, I was split between... Initially I went Britpop, I was like, "Cool, that feels like a happy place for me." Particularly at the moment in our weird dystopian society, I listen to Britpop and it's kind of happy. So Blur was right at the top for me for band commit of the 90s thing then. But then I remembered that Placebo is actually technically a 90s band, even though I did not listen to them as a 13 year old Kit and things. So I think Placebo edges it for me on favorite 90s band of things, just about. But I do have to admit, even though it's not my favorite 90s track, I do think Wonderwall is perhaps the best song ever written.

Nick Muldoon:

Oasis? Love it.

Kit Friend:

Yeah, for track wise. But for me particularly I was at Oktoberfest with some colleagues a couple of years ago and I don't think any other track could get 600 drunken Germans up on benches together with everyone else, all the way around from the world, with a rock polka band singing at the top of your voices at 11 o'clock at night or something. So yeah, that smorgasbord, but I'll commit to Placebo for favorite band in that weird caveated sentence.

Nick Muldoon:

I love it, thanks for that, Kit. And so it's interesting because you touched on then that you went to St Martins, which was an art college. So I'm interested to know, what did you study? What are your formal qualifications and then what led you into this world of Agile delivery and continuous improvement?

Kit Friend:

Yeah. I mean to do the Twitter bio caveat that all the opinions are my own and not Accenture's before we go down the journey of things. Although it must be said I am trying to convert as many of my colleagues and clients to my way of thinking as possible. But so I studied St Martin or studied at St Martins College, so in the UK certainly, I don't know what it's like in Australia, but when you go and do an art and design degree they basically distrust your high school education. They're like, "Nah, everything you've done before is..."

Kit Friend:

So they make you take what's called, or they advise you to take what's called a foundation year where you try a bunch of stuff. So you come in thinking you're going to be a painter or a product designer or something, and they're like, "No, no, no. You haven't experienced the breadth of the creative industries and things." So I did one of those, which was amazing, and I came in thinking I was going to be a product designer. Ended up specializing in jewelry and silversmithing and things, so I made like... Yeah, sort of wearing long black trench coats and things, I was making gothy spiky armor and all sorts of things, and [inaudible 00:04:24] work with silver. So I do have a Professional Development Award in Welding from that year, so that was my first formal qualification on that. I'm a really bad welder though.

Kit Friend:

Then at the end of it I was like, "I don't really know what I want to do still." As you do as you go through university, so my formal degree title, adding to my trend of very long unpronounceable things, is, Ba Hons Art And Design And The Environment, Artifact Pathway, and what it was was... Your face is-

Nick Muldoon:

Yeah, I'm trying to process that.

Kit Friend:

Yeah. I think the course only existed for three years, it felt like a bit of an experiment, or it only existed in that format. So we had architecture students doing the first part of their architectural qualification, we had what were called spatial design students who were, I think, designing spaces. They weren't interior designers, they were a bit more engineery and then we had this weird pathway called Artifact, which was the rest of us and we weren't quite as strict as product designers, we weren't artists. We were making objects and experiences and things.

Kit Friend:

Yeah, it was a really interesting experience. I mean towards the end of it I began specializing more and more in designing ways for communities to come and build things and do stuff together, and it's a bit weird when you look backwards on things. You're like, "I can directly trace the path of the things I've done since to that sort of tendency [crosstalk 00:05:54] liking bringing people together."

Nick Muldoon:

So yeah, do you think that community building aspect was kind of a genesis for what you've been trying, the community around Agile transformation you've been developing over the past decade, or?

Kit Friend:

I don't know. It's easy to trace back to these things, isn't it? But I guess I've always-

Nick Muldoon:

You don't see it at the time.

Kit Friend:

... liked bringing people together to do things. No. It's a theory anyway, isn't it? An origin story theory as we go. So I did that and then I complained lots about my course, I was like, "This is rubbish. This is all really random and things." So I got elected as a Student Union Officer, so I don't know how it works in Australia but in the UK you can be elected as a full time student politician effectively, and you can do it... You take sabbatical either during your course or at the end of your course where it's not really a sabbatical. So I was the Student Union, served full time for two years after I finished my degree, which is a bizarre but educational experience.

Kit Friend:

Again, it's about organizing people, like helping fix problems and having to be very nimble with... You don't know what's happening the next week, you're going to protest against unfair pay or you're going to have someone who's got their degree in trouble because of their personal circumstances and things, so it's a really interesting mix. So yeah, that's where I started my journey into things.

Nick Muldoon:

So it's interesting for me, because you talk about this, the early piece of that is, "We don't trust anything that you've learnt prior to this and we're going to give you a bit of a smorgasbord and a taste of many different aspects." How does that relate to an Agile transformation? Because I feel like we went through a decade there where an Agile transformation was literally, "Here's Scrum, do two weeks Scrum, story point estimates, no rollover. If you rollover we slap you on the wrists."

Nick Muldoon:

There probably, 10 years ago, there wasn't a lot of experimentation with different approaches to delivery. It was just, "We're going from this Waterfall approach to this Agile approach." Which back then was very commonly Scrum. Why don't we give people the smorgasbord and why don't we give them three month rotations where they can try a bit of Scrum and a bit of Kanban and different approaches?

Kit Friend:

Well, I guess it's practicality, isn't it? These things. It's a challenge, and it's a challenge, it works within a contained place. I teach a lot of our product container courses for our clients and we always use the David Marquet video of Greatness Summary. What's great about the David Marquet situation, he's got this Petri dish, right? Literally a submarine, aint no one interfering with his submarine crew. So he can do that, he can go, "Well, let's try this thing." I vastly oversimplify because it's an amazing story, right?

Kit Friend:

But you've got that space to do something and try something out, and actually when we do talk to clients and colleagues alike about Agile transformations, I think one of the things that I say consistently in terms of the role of leadership is they do need to create a safe space, a little place where they protect and they're like, "In this space we're doing Agile, we can experiment, we can do these things. Leave my guys alone. Trust me within that."

Kit Friend:

I think where I see Agile going well, it is where there is a bit of that safe space protected to do things. I've got colleagues who work in companies where they go like, "Okay, we're going to try now and all we're going to ask you to do is forecast your next week's volume of stories. Everything else is up to you, you can choose to apply Scrum, you can use Crystal, DSDM, whatever it is. All you have to do for us as a company is give us a high level view of these metrics or something." So there's flexibility. I think when I think about your journey as an Agilist and trying to do things though, people saying try a bit of everything, it's lovely advice but it's a bit difficult to actually do because it's like we still need to make things, we still need to do stuff practically.

Kit Friend:

So when I talk to people who are starting off their journey or both clients and colleagues who are wanting to move through things like that, like what do they do first, I still say Scrum is a really good place to start because I think there's that quote from somewhere, it's probably in the Scrum Guide, about, "It's simple to understand but complex to get right." And you would think with complex and chaotic situations, right? But I think that-

Nick Muldoon:

And the discipline required is-

Kit Friend:

Yeah, yeah. But discipline's a good thing, right?

Nick Muldoon:

Mm-hmm (affirmative). But not everyone has it.

Kit Friend:

No. But one of my colleagues, Nick Wheeler, he uses the phrase, "Too many beanbags, not enough work done to talk about Chaotic Agile." I think you've got to have that focus on getting things done, right? Value delivery has got to be there, as well as it being a pleasant working atmosphere and balance. So it's about somewhere between the two, and I like Scrum because it gives people something too... It's a framework, right? It gives people something to hang off to start their journey, otherwise I feel like you could spend months debating whether you have an Agile master and what do they do? Where do we go? Do we have a person who holds the vision and things?

Kit Friend:

I think when people are starting off I always say, like, "Why not try Scrum? Why not see? Try it for a couple of sprints and see what works for you and then see what comes out in the wash." I mean if they're in an area where there's some fundamental contradictions, like, "Yeah, I'm not going to force sprints on a call center, right? It doesn't make sense." I was talking to someone yesterday who works on a fraud team, and it's like I'm not going to ask her how much fraud is going to be committed in two weeks time, or as part of MPI, right? It's absurd.

Kit Friend:

So in those circumstances, yeah, you start with Kanban methods and processes and practices instead. But for people who are building products, building things, I think the Scrum is a pretty good fit at the beginning. So yeah, that's my answer, so both. Why not have both is the answer to that, I guess, on the way. Yeah. It'd be interesting to see what other frameworks rear their heads. I mean I found the other day a scaled Agile framework called Camelot that involved lots of castles and things in the YouTube video. I thought that was marvelous. But there's room for a lot of planning and thinking.

Nick Muldoon:

As soon as you saw Camelot, for some reason my mind goes to Monty Python. I don't know quite why. But what's this flavor of scaled Agile called Camelot? Can you tell me about it? Because I'm not familiar with it.

Kit Friend:

I've seen one YouTube video on it, Nick. For anyone Googling it, you can find it related to the X Scale Alliance. I think it's a picture of the Monty Python Camelot on the front page.

Nick Muldoon:

Is it actually?

Kit Friend:

Yeah, yeah. I'm pretty sure weird things. And you know what it's like with techy geeks, right? There's a lot of embedded Hitchhikers' Guide To The Galaxy and Monty Python references in component names and things. So I'd be unsurprised. What I like about something like the Camelot model, other than me thinking Monty Python and castles and things, is it does evoke something in people. I think when we're talking to people about Agile we do need to evoke a feeling with them. We need to get people going, "Oh yeah, I kind of get where you're going."

Kit Friend:

So I always like to do the cheesy uncapitalize the A, what does agile mean to you? Yeah, is it about being nimble? Is it about being flexible and that kind of thing?

Nick Muldoon:

I mean I'm conscious you've obviously done Lean Kanban in university, you've done Scrum Alliance Training and Certification, Prince2, Scaled Agile of course. Why do you do all these things? I mean is it curiosity? I mean is it there's an expectation from clients that you have these certifications? And would you go and get a certification in Camelot? Or even one that I was introduced to recently was Flight Level Agile, Flight Level Agility. Which is a different way of-

Kit Friend:

Ooh, another one?

Nick Muldoon:

Yeah, another one. A different way of describing. Actually I remember, bit of a sidebar sorry, but Craig Smith from... who was at the time I believe was working at Suncorp, an Australian bank. He did 46 Agile methods in 40 minutes or something like that, and he spent a minute and he introduced people to all of these different approaches.

Kit Friend:

Yeah, and methods versus frameworks and things is a fun one to draw the lines between. I mean I've been surprised actually how few times I've been asked for certifications around things. It's changing a bit more, and I've seen definitely more enthusiasm from our clients, and in fact I'm seeing new people within Accenture which is really nice, to require and encourage certification. I don't think it's necessary that the safe course then guarantees that you're going to scale Agile successfully, right? But it's a good way of demarking whether people have done their homework and have put some effort into [crosstalk 00:14:50] knowledge.

Nick Muldoon:

And they got the foundational baseline stuff.

Kit Friend:

Yeah. Now in terms of your question around Brett, so my view is that if we try and attach the word coach to ourselves... I think I've seen country by country different trends, so when I look at my colleagues in the States there's a bit more codifying on the term Agile Coach. There's an attachment to ICA Agile and Lisa Adkins work and all sorts of different things over there which is good. Certainly in the UK and Europe, I see it as a lot more varied at the moment and it's a term that's attached to a lot of people.

Kit Friend:

If you look at people, just anyone on LinkedIn with a CV title or little bio title Agile Coach, you can see a big variety of people who've been doing different Agile frameworks for like 20 years doing things, and you can see someone who's been a Scrum Master for three months and then switched jobs, and they'll have like Agile Enterprise Coach as their title. And you're like, "Hmm, how many people have you ever done Scrum with? And have you done anything but Scrum?" And my view is if 40-

Nick Muldoon:

But I mean Enterprise Agile Coach because I've done Scrum with my team of six people in a-

Kit Friend:

In an Enterprise, right?

Nick Muldoon:

In Enterprise.

Kit Friend:

But my feeling is if all you can do to a team that you're coaching is offer one way of thinking and one approach to doing stuff, how are you coaching them then? There's no breadth to what you're able to offer. But if all you've experienced is Scrum and then you get landed with a team doing fraud investigation, how are you going to guide them on a path which doesn't include sprints and those things? I mean you might do, because you're going to take things from Scrum that become sensible, but you need that spectrum.

Nick Muldoon:

Give us a sense, Kit, what is the most quirky, or unusual perhaps is a better way to frame it, what is the most unusual team that you have introduced to Agile practices and Lean principles?

Kit Friend:

So I've got to embarrass my colleague Giles, because mine is not the most interesting. So Giles was looking at introducing Scrum to geologists for site surveying and things, which I love as an example to talk about because it's so-

Nick Muldoon:

Wow. Yeah.

Kit Friend:

When you unpack it's so interesting to think about what that would mean, and I need to catch up with him to see how far through they got actually applying it. But because it's like, "Why would you do that?" And then it's like, "Ooh, actually, they probably have a really big area to survey. Wouldn't it better to introduce some feedback loops and look at how you slice down that problem to get some value and learning delivery out of things?"

Nick Muldoon:

That's interesting.

Kit Friend:

So I really, really like that. Yeah. Then I always reference when we're teaching, there's a restaurant called Ricardo's in London that I have to make sure it's not gone out of business. I think it's still in business, but-

Nick Muldoon:

Well, I thought it-

Kit Friend:

Well, COVID, right? I think he's their owner, Ricardo. At least he's the person that's inspired their name. He applied Scrum and it's beautiful, looking at the exercises they went through when they put it in place. And on his website, which I'll ping you the URL for the show notes, but they do this cross functional teaming thing where they got all the staff at the restaurant to look at the role types that they needed, and then their availability and things. They were like, "Only this one guy can do the bar. Maybe we should up skill some other people to be able to work on the bar?" And I love that thinking of applying those elements of stuff.

Kit Friend:

So back to your question though of where have I applied unusual things to my teams, I haven't done any really quirky ones, to be honest with you. I mean I think having a background in art and design I find it... When I talk about iteration and all those areas, my mind immediately goes back to projects where we made things and did stuff and have it there, and particularly when people get panicked in a business situation I think back to... I used to freelance doing special effects with my dad whilst I was at university, because it's a great way to make cash for things. My dad worked for the BBC and freelance. I think about that immediacy and panic when I'm talking about Kanban and handling ops and incidents and things, and I'm like, "You guys don't need to panic, it's not like you're on live TV." And they have a countdown of three, two, one, right?

Kit Friend:

No one has that in our business. We panic sometimes when something falls over, but there's never that second by second delay. So I think the quirkiest places that I've applied Agile thinking are probably before my career in technology. They were in that kind of place where we're making creative things and doing stuff, and it's there where you're like, "You would never do a 400 line requirements document for a piece of product design or jewelry, right?" You would produce something rough and see what people think about it, and build things in so there's a balance there.

Kit Friend:

I mean when you're launching live products though, you do some strange things, right? And you have some fun memories from that. So I remember when we launched YouView in the UK, which is a public credential because it was for Accenture. Fine. But during launch day a colleague of mine, Ed Dannon and me, we became shop display people for the day so we were at the top of John Lewis in Oxford Street in London demonstrating the product, and that was a part of our Agile working for that week because that's what they needed. That was how we delivered value was physically being the people going like, "Hello, Mrs Goggins. Would you like to try this YouView box at the top of things?" So I remember those days fondly.

Nick Muldoon:

And so was that capture on a backlog somewhere, or?

Kit Friend:

Do you know what? YouView is where I was introduced to my love of dura, so I suspect, yeah, I don't think we did formally add a backlog somewhere. It would've been nice too, wouldn't it? I'd like to claim that my entire Accenture career could be constructed out of Dura tickets if I piled them one on top of each other for 10 years. Certainly about a 60%-

Nick Muldoon:

How many Dura tickets do you reckon you've resolved over the years?

Kit Friend:

God. How many have I duplicated is probably the question, right? Which is like 8,000. There's always duplicate of things. It's got to be in the thousands, hasn't it?

Nick Muldoon:

Tell me, you've, okay, over thousands of duplicates resolved. But you've been doing this for a while in the Atlassian space, and obviously with the Agile transformations at scale. How have these engagements at scale evolved over the past seven or eight years? And what do they look like in 2021 with this completely remote mode of operation?

Kit Friend:

Yeah. Starting at the end of that, I see light, I see goodness in things. But I guess similar to how you expressed 15 years ago, 10 years ago everyone was like, "Do Scrum and have some story points and things." I think during that period, if we go back like 10 years ago, so we're like the early 2010s or whatever we call the teens in the decades, I think we see a lot of people experimenting with early versions of SAFE. They'll do wheel reinvention and people simultaneously going, "Let's have a big meeting where everyone plans together. How do we normalize story points? You shouldn't, maybe we should. How do we do metrics there?" And that kind of stuff.

Kit Friend:

So I think certainly what I've seen is a lot of people trying out those things as we go through, and then trying to weave together concepts like design thinking and customer centricity, and there are all these bits of stuff which feel good, but they weren't very connected in any way that was repeatable or methodical or codified. Then what I quite enjoy, and linking back to your last question, is then the branching of the approaches to things. You've got SAFE, which is laudably to everyone who works on that, right? They try and write down everything.

Kit Friend:

I always say this to everyone, you're like, "Thank goodness someone decided to go on that website and make everything clickable and everything." Because when you do need to reference one of those elements, it's a godsend being able to go and go, "Yes, here is the page that talks about Lean budgets. I might not agree with everything on it, but it's a really good starting point. It's a really good point of reference to have."

Kit Friend:

Then you've got the others, and I do use SAFE at one end of detail, and even if you're doing SAFE correctly you don't do it by the book and copy and paste, right? And that kind of thing. But there is a lot of detail and a lot of options there. At the other end of the scale you've got things like Less, where it's intentionally about descaling and it intentionally focused on simplicity. Look at the front pages of the website, and on the SAFE website you've got everything. On the Less website it looks like we've done it on a whiteboard, right? And that's intentional, both of them are intentional at the end of the scale. Then we've got Scrum on the scale, which seems to be the new, rising, kind of darling of things at the moment, and that was the other thing. So what I see now-

Nick Muldoon:

And they all have a place, don't they?

Kit Friend:

Yeah.

Nick Muldoon:

It's interesting that there's a large enough audience and market for all of these to succeed, and there's a lot of overlap between them in the various ideals and practices that they suggest that you experiment with.

Kit Friend:

Yeah. I mean what I've seen in the past few years is that I think people often get laudably enthusiastic about the scaling bit. So they take a look at a word like Lean Portfolio Management or a business problem they have of how can I capacity manage? And they go straight to the scaling frameworks without stopping at the teams on the way, and that's definitely a tendency I hear more and more from friends, colleagues, geeky friends, colleagues, clients, right? They don't make that initial investment in getting the teams going well, whether it's Scrum or whether they're running in anything else.

Nick Muldoon:

Sorry. But hang on, are you saying then, Kit, that people are actually coming into a scaled Agile transformation and they haven't got the team maturity? Sorry, forgive me, but I felt I guess my belief and my understanding was that these scaled Agile transformations, for the most part, are building on top of existing successful team transformations.

Kit Friend:

I think that is how it should work right. We should be going bottom up, or at least to a certain extent. In the SAFE implementation roadmap it talks about reaching a tipping point and having... I mean you can start with Waterfall and the SAFE implementation roadmap, but it talks about ad hoc Agile and those things there. I think when people in large businesses and organizations come with a problem though, they're coming with a big problem and they want to fix that, and yeah, it's a difficult message to land, the, "Hi, you've got one to two to five years worth of getting your teams working before you can deploy the fancy portfolio management Kanban and see a flow of things right." Because people are nice. Most people are nice, most people are enthusiastic, most people want to fix things, and so they want to fix that big scaley thing.

Kit Friend:

But it's difficult to land, the, "No, you've got to fix these things at the bottom." I was describing to a colleague, Lucy, last week, and I said, "If you want an answer a question of how do I capacity manage and how do I balance demand across a large organization, you should imagine each of your..." Let's pretend they're Scrum teams without debasing it for a moment. Let's pretend your Scrum team is like a bar with a row of different glassware on it, and each time box is a different sized pint glass or a schooner or whatever you have. Now, my capacity management for a single team is me with a big jug of beer and I've got all the work that I want to do in that beer. My whole backlog of things. My capacity management for a team is pouring it in and hopefully I guess it right. I probably don't and I spill some beer in the first ones as we go through. But over time I'm trying to guess how much beer I can pour into each time box of things and we go through.

Kit Friend:

Now, the only way that I can know how much I can fit in in the future is if I see what I've got in the past, like how it went and can I predict the size of the glass, and over time I can, and we stabilize. So everything's a pint glass after a while, after we've experimented with everything there. Now, if we don't have that ability to forecast and measure, get the actual data back via some tooling at a team level, how can we manage across multiple teams? Right? You can't. You can't have a big top down roadmap where you're like, "Yeah, we want to launch the easy Agile bank across all these areas and go into the teams." Unless you have that team level maths that you can rely on.

Kit Friend:

It doesn't matter whether that's story points or whether you're doing no estimates stuff and you're just measuring flow or you're using Monte Carlo, whatever it is. You need some mathematical way of helping people understand the flow of work and what's happening there, and ideally tying it back to value with some data. Workout whether is your easy Agile bank actually a good idea or should we pivot and do something else? Yeah, is it delivering the thing that customers want when we've given them easy Agile bank beta at the beginning of things.

Nick Muldoon:

How good do you think clients are these days? So here's the thing, I guess, you talk about early transformations and it was, "Hey, we're going to go Scrum." But now there's the design thinking, I mean there's devops, there's DevSecOps, there's so many different aspects now that people are exploring and they're exploring at the same time. How do you help the client navigate this? Because they get it from every different angle from different aspects of the business, and in fact it's just got to be overwhelming, quite frankly.

Kit Friend:

Well, it's overwhelming for us trying to help right, right? People like yourselves, I mean you're like, "How do we cope with this weird specific configuration that they want to feed into easy Agile programs?" So I think that the light at the end of the tunnel that I referenced before is I see a lot more people coming with an ask of helping them get the bottom up things right, so they understand there's a pincer. We can't ignore-

Nick Muldoon:

Get the foundation.

Kit Friend:

Yeah. But we can't ignore that there's the big business, right? There's the people expecting big things and they've drunk the Agile Kool-Aid, they've read the article and they want to be there. So there is that top down pressure, but I am seeing more and more asking for advice and help to do things at the bottom. On a couple of areas recently, my current theory of the day, and I have a favorite theory every six months or so so this won't be the same later in the year, but I really, really like training the product owners first to help with that transformation. My current theory is that it's because they're like the battering ram to help the business understand what's happening with these delivery teams, and build the bridge and link between things and form that.

Kit Friend:

Because if you don't have the product owners being the conduit and the voice of the business and the customer and the voice of the team back to the business in doing things, I think the rest of it falls down. So my theory at the moment is that if you start by training the product owners that's the best way to begin things and it helps with the scaling body scaling, the focus on the team level to help do things.

Kit Friend:

To be honest, even if they're not doing Scrum, I think that the role of a product owner, relatively close to what the Scrum guy says, if we take out the sprint references and things, I think that's a sensible thing to have in every cross functional Agile team, regardless of what you're doing. And it's a distinct personality type, right?

Kit Friend:

I often talk when people are doing our Agile Foundations course, where we're like, "Here's everything. Find your place." I think that most people, or certainly most people I train, fall quite clearly into a product owner or a Scrum Master style personality type. I'd say about 80% you can tell, like, "You're a producty person. You're a Scrum Mastery type person. Or if you're not doing Scrum, a coach, a facilitator, a team builder." Maybe about 20% can flit between the two, and they're special people. The Unicorns as we have in every industry and type, but most people fit into one of those. I think it's good to think about how those personality types work in your business.

Kit Friend:

The other thing I love about training the product owners first, it really unveils upon them that, let's say, we're now at... "Hi, Nick. Yesterday you were the business owner for this process and doing things. You're now a product owner, go. And you can only have till Monday." If we train you, you're like, "Oh my God, I didn't realize I was now accountable for the value of this whole team delivering. It's my problem to make sure they're delivering good things? I didn't know that." So if we do that training right at the beginning I think it sets a baseline of expectations of what we're asking of those people, and the responsibility that's placed on them. Yeah.

Nick Muldoon:

When you're doing this Agile Foundations course that you run for folks through, are you doing a DISK profile as part of that? Again to assess their personality type.

Kit Friend:

No, no. That would be really good. What a great suggestion. I can include that.

Nick Muldoon:

Well, I'm merely inquiring because I wonder. I'm just thinking about it now, I'm wondering, are there personality types that are more likely to be the product owner? Is a product owner more of a CS and is a... Yeah, I don't know.

Kit Friend:

I don't know. I mean it's one of those things, isn't it? I forget the number of personality types and roles I've been assigned in various bits of my career. I can't remember. Back when I was a Student Union Officer, I'll have to look up the name of it, but we had the ones where, "Are you a completer finisher or a shaper?" And all sorts of those things there, and then DISk was relatively popular. We've got a Gallup Strengths Test within the Accenture Performance Management Tool, which is actually really interesting.

Kit Friend:

The bit I like about the Accenture one is when you join a new team you can bunch yourself together in the tool and see what people's different strengths and personality traits are, so you can be like, "This team's very heavy on the woo. Or you're a team that's full of energy or ideas with things, and it's quite interesting too." I mean it's nice to see the strength, but it's also interesting to notice where you might have gaps and you're like, "I need to make sure that someone's keeping an eye on quality because we all get very excited and run fast."

Nick Muldoon:

Do you remember, this would have to be a decade ago now, I'm sure, but I think his name with Larry Macaroni or Larry Macayoni, and he was working for Rally Software at the time, and he did a very wide ranging study of the effectiveness of Agile teams? And I'm just thinking back on that now, because he was looking at things like defect rates, escaped bugs versus captured bugs and all sorts of other bits and pieces. But I don't think he touched on the personality traits of these teams and whether even Dave the Cofounder here at Easy Agile, my business partner, he was talking. He shared a blog article this morning about neurodiverse teams and I'm just trying to think, do we know is there a pattern of DISK profile distribution, neurodiversity distribution, that leads to a more effective team?

Kit Friend:

I don't know. I haven't read. Yeah, it's Larry Maccherone, but it's not spelt the way I suspected originally. I put in Macaroni, based on your pasta based pronunciation of things. So it looks like it's the quantifying the... What's it called? Quantifying the Impact of Agile on Teams, which is really interesting.

Nick Muldoon:

But I don't know if that sort of study has been done since he did it back then.

Kit Friend:

Particularly the personality types is interesting, and neurodiversity is another interesting element. So I've got dyslexia and dyscalculia, and one of the bits I've found-

Nick Muldoon:

What's dyscalculia?

Kit Friend:

Well, just like dyslexia, there's quite a spectrum covered by one term of these, so it's large. But effectively my particular diagnosis, I have problems processing sequences of numbers. So you can read me out a sequence of numbers and if it's exactly that, I can cope with it normally because I can do visual processing, because that's my creative industries background, it's what we do, right? We visually process. But I can't repeat them back to you backwards, I can't reprocess them as units of stuff with things. My wife says-

Nick Muldoon:

How did you even come across that?

Kit Friend:

So a retrospective again, so my sister was diagnosed with dyslexia at school, and she's got a more traditional dyslexic diagnosis. So when you hear dyslexia, people normally associate it with not being able to read and spelling and grammar and that kind of stuff. Dyslexia, as you might know from [inaudible 00:35:00] is actually... I'm waiting for them to split it, to be honest with you, because it's so broad. But my diagnosis of dyslexia is more about my short term memory processing, so it's the ability to process. I can read and write fine.

Kit Friend:

My sister got diagnosed at school, had blue glasses, all the conventional grammar and spelling related elements of dyslexia. My dad got diagnosed then in his mid 50s, I think at the time. So he started working at the University Arts London, my art college, my dad still runs the woodwork shop in central St Martins in their beautiful new campus in King's Cross in London. He got diagnosed with things, and I was like, "Hmm. I know it's hereditary, I should probably get checked." So I think I was 25 or 26, and one of the lovely bit... I mean there's many lovely bits about working at Accenture, but a large corporation has really, really good support networks and things.

Kit Friend:

So I pinged the right people around, and they were like, "Yes, of course we can support you getting an assessment. We'd love to make sure that you're able to function." So I got an assessment done and they were like, "Yeah, you're dyslexic and dyscalculic on this kind of area." But the more interesting thing was that they were like, "Here's the coping mechanisms that you've developed." And the coping mechanisms was a list of my career and choices and education. It was like, "You will choose things where you can do abstract thinking and drawing." It was really funny because I never felt like it blocked me at school, I quite enjoyed exams and things.

Kit Friend:

But I was terrible at revising, right? I can't go through notes and do things there. Looking at my diagnosis I was like, "It's because I don't process things that way." I have to process things visually, I have to draw, I have to chunk things. Now I look at the way that I work with Agile teams and I coach teams, and I create abstract references to things, right? I'm teaching product owner and Scrum Master courses on Mural where we move things around and create objects.

Nick Muldoon:

Or the example that you used before, Kit, with the beer glasses at the bar.

Kit Friend:

Yeah. I can't deal with numbers in abstract, right? I have to deal with them in an analogy or I have to be able to visual them. I'm hopeless at coding, I can't store concepts like variables in my head. They just fall apart, it's like building with sand in front of me and it's all dry and crumbly. And I think in fact when I looked at that diagnosis and I was still, what? I'd be like three or four years into my career at Accenture. I looked at the way that I'd begun to get slowly addicted to tools like Atlassian and Dura, and I was like, "Ah, I'm compensating for the fact that I have basically no ability to memorize things in the short term." I'm helping visualize stuff in the way that I help teams and build tasks and things, in a way that means I'm outsourcing my short term memory to this lovely tool where we do things there.

Kit Friend:

Yeah. I've grown to love it, I think you have to work with it right. I speak to some of my colleagues, I teach at the moment with an Agile coach called Lucy Sudderby and another one called Charlotte Blake, and I'm like, "Thank you, guys, for compensating for my dyslexia. I appreciate that you kind of balance out my inability to memorize anything." Yeah, hopefully they feel they benefit from some of the quirky strengths of it when we go through, but it's a balancing act, right?

Nick Muldoon:

That's very cool. Thanks for sharing that.

Kit Friend:

No worries.

Nick Muldoon:

I'm just thinking about it now, as you mentioned coaching with Lucy and Charlotte, and going back to something that you said earlier, Kit, with respect to... I don't know if you said the leaders, but basically the folks at the top drinking the Kool-Aid. I'm interested to know, how do you create, going back to this other thought that you had, I'm trying to connect dots, going back to this other thought that you had right up at the top about the psychological safety, right? And that feeling safe. How do you provide a safe space for these leaders that could be CEOs of business units or execs, GMs, whatever they happen to be, provide a safe space for them to actually ask questions and do Q&A and learn without feeling?

Kit Friend:

Yeah. Because we forget that they're people too, right?

Nick Muldoon:

Yeah.

Kit Friend:

There's this idea that these leaders are somehow insurmountable, they have no fear. But we need to build a safe space for everyone around things, I think you're right. I think we get the same sort of question when people talk to me about how they can convert people to Agile or make the case for things in an organization but not sure about it. I think that the answer, relatively saying, in that we need to give them some data, some facts. So my view is that it's not good to come to people and talk about...

Kit Friend:

I somewhat cynically criticize when people talk about Agile ways of working, and they'll often abbreviate it to WAW or something as well. I think when we talk about agility too abstractedly, and I say the phrase wavy hands too much, but when we talk about it within specifics too much, it encourages a sense of anxiety and it's a nebulous, wishy washy kind of thing so I like to bring some data to people. My favorite ones to use, and I need to get updated stats, but the Sandish Chaos Reports are an amazing project management journal, where they talk about success and failure of Waterfall versus Agile projects.

Kit Friend:

Now, there's a bunch of questions it leads you to about how do they classify Agile and all sorts of things. But indisputably, what it tells you is that the traditional way of doing things that we are told is secure and safe, if I go to a procurement team or a finance team and I go, "I'd like to build this thing, guys." They're like, "Great, give me the milestones, give me the plan." And there's this inbuilt assumption that that's a safe and responsible and proven way to do things.

Kit Friend:

The Sandish Chaos Reports tell you it's a terrible way to do things, right? They're like, "Statistically, doesn't matter what you're building, what industry, what you're doing, it's a terrible idea to fix scope at the beginning, trust your plan and have a system which fails when you have any change." And when you unpack it, like when we talk about agility overall, what are we saying? We're saying it's not a good idea to begin something and for it only to be able to succeed within fairly tight boundaries, where no one changes their mind for the duration of the thing, everything goes exactly as you plan and when does that ever happen with technology? And the world doesn't change for the duration of your thing.

Kit Friend:

Most of the time when we're talking about these project things, like how long are they? Three months to three years is the window I usually give. Three months, I see rarely in any industry these days, right? These big efforts where people are trying to do these things at scale, you're talking multiyear. What are the chances that the scope can be frozen for that period? Pretty low, and also what's the chance that the people that you asked for the requirements at the beginning really knew them all? Everyone's normally really nice, they try their best.

Nick Muldoon:

The chance that the people you ask at the beginning are going to be there when you actually get to the next-

Kit Friend:

Yeah. There's a whole set of fundamental problems with that. So I like to bring that kind of data to our leaders when they're asking about the case for agility, so it's not about, "Do you want to sign up to use a framework?"

Nick Muldoon:

But let's say, Kit, that they've made the case for agility, they're there, they're doing it. What's the space that you provide for them? Do you have a CEO round table where they can go and they've got a shoulder to cry on and go, "This Agile transformation is going harder than I thought it was going to be"?

Kit Friend:

Agilists Anonymous, [crosstalk 00:42:19] company. Yeah. I think it is a good idea to pair them up, so I get a lot of requests at the moment for us to provide coaches directly to support leaders. I've also seen a trend in reverse mentoring, separately big companies. But that kind of idea of, okay, you've got these people who are really experienced, and their experience is relevant, right? We're not saying that the CEO's 30, 40, 50 year career in something is invalid now and we know better than them. But they're trying to match that up with these, not even emerging, right? Because the Agile Manifest is 20 years old now. But they're trying to match these up with these foreign, new practices and things they've got, and that requires a bit of hand holding. So yes, there's a personal angle there. I don't think necessarily a round table is the way to do it per se, but giving them someone that they can chat too and, yeah, an ability to relate and go like, "What is this thing?" And decode the jog, I think is really useful.

Kit Friend:

So data about success rates is important, right? But the other data that's really important I think to help provide that sense of safety is about value delivery, and this is where I think most people are still having trouble. We've just about got to the point where people can start to attach a concept of benefits and value at the start of things. Now, often that's still too big. We talk about the value of the entire project, can you assign a notion of value to every epic and story in your backlog or whatever units of stuff you're doing?" Probably not, right? Can you do it in a pound or dollar or euro or whatever your local currency is figure? Probably not. But can you even rank them one to 10? Maybe with things.

Kit Friend:

So I think the evolution of OKRs and KPIs coming in, and people starting to internalize that more, offers some hope. It's still relatively immature in most organizations and you're still kind of getting there. I feel like every sort of practice and things, it's probably going to have some misinterpretation, enthusiastic and well meaning interpretation, but you're going to get some people using it somehow to Waterfall things probably in some areas. But bringing that data that gives them some sort of feedback loop that makes sense to those people in those senior positions I think is really powerful. The opposite of this is where they expect to see RAG statuses and milestones and that's the only data they get from their teams, right?

Kit Friend:

I sat down with an executive of an organization a few years ago and I was like, "Please invest in your tooling. Please do it." And he's like, "Why would I need to? I have these slides where they tell me green and the dates are there." And I was like, "I love that you're trusting, and I like to trust." The trust in the teams was really, really good. But I knew the teams and I knew they didn't have any tools. It was project managers getting stressed and running around, and then I knew that all the RAG statuses were going to go, "Green, green, green, green. Red." It was the Watermelon Effect that was going to happen, right?

Kit Friend:

So when I see conversations like that happening, I want to empower them. I want to empower them with data and bring those things together. I think that data about why doing Agile is really important, the data about how it's really going on your teams, and the ability to make decisions based on it is really important. There's the Scrumming case study on the Saab Gripen is lovely because they, in one of the articulations, they do the sequence of morning standups and allegedly, according to the case study, I'm pretty sure it's true, they do 7:30 in the morning, which is insane. I don't know why they start at 7:30 in the morning in Sweden, but apparently they start at 7:30 in the morning. But they do a sequence of standups and the idea is by the end of the hour the cascade of standups means that any impediment can reach the executives within the hour and they can fix it.

Kit Friend:

That feeling of connection, that trust in teams and that show of progress, real working things being the way that we communicate that we're making progress, I think that's how we build some safety in and help our leaders do things. Not RAG statuses and milestones and Gantt Charts. They have to have that realness with things, hopefully.

Nick Muldoon:

It's interesting. It makes me think, we did a factory tour recently and it's a factory that makes air conditioning manifolds for commercial buildings, and they actually-

Kit Friend:

What? Why were you touring an air conditioning factory? Were you buying some air conditioning?

Nick Muldoon:

No, no, no. Lean principles, right? You want to see the application of the principle.

Kit Friend:

Wow, you're living it, you're living it. It's wonderful.

Nick Muldoon:

Yeah. So they do breakfast from 6:15 to 6:45 or 6:30, something like that, and then they get going. I think they do their standup at 7:45 after they're actually in the flow, they come together, "Okay, where are we at for today? What are we working on?" Then that rolls up to the ops team and then that rolls up to the leadership team, and then at the end of the day they do their closing huddle for the day, "Hey, have we got all of our tools? Are we back? What are we going on with tomorrow morning?" So it was like the start and the finish of the day and it's really interesting.

Nick Muldoon:

Just thinking about, we introduced an end of day huddle in COVID, when we were all on Zoom all the time, and I think it was very useful. But then of course as we get back into the office, it drops away. It's interesting how things evolved, right?

Kit Friend:

Yeah. And you're the big Head Honcho, right, Nick? I have a worry niggle with end of day meetings, about whether they're for the team they're for people to feel they're across stuff, and I find it interesting because I'm having to take people through practicing for Scrum Master exams and things, lots at the moment, and I really like talking about how standups are for the team. They're for the developers, they're not for the product owner even, they're certainly not for the stakeholders. Now, I consistently see with a lot of these Agile ceremonies, I'm like, "Who's getting the benefit from that meeting? Is it someone getting a status check in or is the team getting it?"

Kit Friend:

And if the team enjoys it, if the team gets something from the end of day huddle and things, I'm cool with it. But sometimes I see things, and the two anti patterns I see with leaders joining, of any level, joining the meeting, so the first is that they use it as like their aeration platform. The team's ready to go with their standup and then the leader of whatever level pops in and he's like, "Team, I've got this update for you." And then it's like 10 minutes of their amazing update and mini vision for the day, and then at the end it's like people are going, "Yeah, now do your standup. Now do the Scrum kind of thing." And then the other thing is that where it becomes like a status check in for stuff, and I'm like, "It's not what it's for, guys. We should be focused on [crosstalk 00:48:57]-"

Nick Muldoon:

We do. So we can get done with 22 people in six to eight minutes.

Kit Friend:

That's slick.

Nick Muldoon:

It's taken time to get here, but what we actually started out asking for was one good thing, and that's typically a family, community thing, what are you going on with today, do you have any blockers? And it's interesting now that we're having this chat, Kit, I do not see blockers come up very often, so I wonder why that is.

Nick Muldoon:

Yeah, anyway. Hey, Kit, I'm conscious of time. I've got one last question for you.

Kit Friend:

Yeah, go for it.

Nick Muldoon:

What are you reading at the moment? What books are you reading or have read recently that you'd recommend for the audience to read?

Kit Friend:

Yeah, I'm between businessy books. I need to find a next one. One attribute, and it's probably not my dyslexia, I think it's just because I'm lazy, I'm really bad at reading business books, like serious books with things. So I rely on audiobooks lots to consume meaningful data. I really, really enjoyed listening to Lisa Adkins Coaching Agile Teams audiobook when she released it, because I knew I wasn't going to get through the book and so-

Nick Muldoon:

Did she narrate it?

Kit Friend:

Yeah, which is even better, right?

Nick Muldoon:

Cool, yeah.

Kit Friend:

So lovely to hear from the authors' voices when they're doing things. So I'd really recommend that, and then accompanying it after... I mean either way round, listen to the Women In Agile podcast series on coaching Agile teams, because they talk about each other and there's a whole episode on language, and she talks about how between writing the book and narrating the book, reading it, there was bits of language where she just cringed and she was like, "I can't believe I wrote that." And it really resonates it with me, thinking about my Agile journey and how I would cringe at what I did with teams five, six years ago. As we all do, right? You look back with hindsight.

Kit Friend:

So Coaching Agile Teams is really, really good, and I'd recommend. When [crosstalk 00:50:54]-

Nick Muldoon:

Isn't that beautiful, right? Because if you look back and you cringe, it shows that you've evolved and adapted and you've learned, and you've improved?

Kit Friend:

Oh yeah, if you look back and don't cringe, either you were perfect which is unlikely, right?

Nick Muldoon:

Unlikely. Unlikely.

Kit Friend:

[crosstalk 00:51:07] things, or you're oblivious which is more likely. I don't mean you personally, Nick. So Coaching Agile Teams is really good, I still recommend the Whole Time if people are trying to get their head round what it's like to work in Agile, what's there. I used to recommend The Phoenix Project, and then I really enjoyed The Unicorn Project more for filling in a team. Your talking about the air conditioning factory just reminded me because of all the Lean kind of things. I really like that, and I struggle when I explain to people because I'm like, "It's not dry, it's a novel about an Agile transformation, but it's not [crosstalk 00:51:42]

Nick Muldoon:

It's not. I love it. I get up and I read the newspaper, right?

Kit Friend:

Yeah.

Nick Muldoon:

That's my thing in the morning, and I would never read a business book at night. But The Phoenix Project and The Unicorn Project, I've read them several times as bedtime books.

Kit Friend:

Yeah. To your kids, Nick? Do you sit there [crosstalk 00:52:01]

Nick Muldoon:

I will. I'll get there. I'm starting to teach them about Lean principles, build quality in. Yeah.

Kit Friend:

Yeah. If you haven't done it already, getting your kids to story point Lego is really amusing and I've enjoyed a lot. I know it's just like time gym, but I enjoy doing it with my son, Ethan, because you know how difficult it is to get adults to get relative sizing in units, and kids just get it. It's wonderful how they just don't get distracted by the fact that you've got an abstract unit, and they're like, "I get that idea." I got Ethan story pointing in five minutes, I've struggled to get some adults story pointing in like five days and they argue about, "Do you mean it's days, ideal days, hours?" Things.

Kit Friend:

So yeah, Unicorn Project I think are really good. I haven't actually read it all yet, but I do want to read and I recommend the whole time because of a really good podcast, 99 [inaudible 00:52:51] Invisible Women by Caroline Criado Perez. So when we talk about being customer centric and about really knowing who we're providing our products for, I think there's a really powerful story around making sure we understand the data and when we're going through, and Invisible Women has some amazing, horrifying, but amazing stories and bits of data and narrative around it. So I think those would be my three at the moment, three's a good number to ask people to start with, isn't it?

Nick Muldoon:

Okay, cool. Kit, this has been wonderful. My takeaway is I've got to read The Invisible Woman, because I haven't heard that book.

Kit Friend:

Invisible Women, there's lots of them is the problem, Nick.

Nick Muldoon:

Invisible Women, okay. Thank you. That's my takeaway that I've got to read. Kit, this has been beautiful, I really enjoyed our chat this morning.

Kit Friend:

It was a pleasure as well. Thank you so much for having me, Nick.

Nick Muldoon:

I hope you have a wonderful day, and I look forward to talking about this journey again. I want to come back and revisit this.

Kit Friend:

Yeah. Let's do a check in. We should do our DISK profiles for the next one maybe, and we can find out maybe I'm meant to be a product owner and you should be, I don't know, you'll be like test lead or something it'll say. I don't know. We'll find out.

Nick Muldoon:

It's beautiful. All right, thanks so much, Kit. Have a wonderful day.

Kit Friend:

And you. Bye now.

‍

"It was great to chat with Alana and learn from her experience" - Sean Blake

In this episode, I was joined by Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day.

She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.

We covered a lot of ground in today's episode. We talked about:

• The importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities.
• Building trust with your team and disclosing some vulnerabilities about yourself.
• Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community.
• Servant leadership and being a generous leader.
• The importance of authenticity and direct communication.

I hope you enjoyed today's episode as much as I did.

Transcript

Sean Blake:

Hello, welcome to the Easy Agile Podcast. My name's Sean Blake and I'll be your host today. Today, we have a really interesting guest and a fantastic episode ahead for you. Our guest today is Alana Mai Mitchell. Alana is a results coach, author, podcast host, and Senior Product Development Manager at one of Australia's largest banks where she works with Agile teams every day. She has over 13 years experience in digital financial services and coaching. She's spoken live on Channel 10 here in the Australian media and has had her mental health story featured in publications, like The Daily Mail and Mamma Mia. She's the author of a book, Being Brave, and she's the host of the Eastern Influenced Corporate Leader Podcast.

Sean Blake:

We covered a lot of ground in today's episode. We talked about communication styles. We talked about the importance of putting your hand up and telling your manager when you want to be challenged more and to be exposed to new opportunities. We talked about the importance of building trust with your team and disclosing some vulnerabilities about yourself. We covered Alana's mental health journey over the course of six years, and that journey continues today. What she's learned and what we can learn from her experience to better look after our teams and people in our community. We talked about going first in servant leadership and being a generous leader. The importance of authenticity and direct communication. I hope you enjoyed today's episode as much as I did. Let's get started. Alana, thanks so much for joining us on the Easy Agile Podcast today. It's great to have you here.

Alana Mai Mitchell:

Thanks so much, Sean.

Sean Blake:

Before we jump into our conversation, Alana, I'm just going to do an acknowledgement to country. We'd like to acknowledge the traditional custodians of the land from which we're recording today, the Watiwati people of the Tharawal speaking nation, and pay our respects to elders past, present and emerging. We extend that same respect to all Aboriginal and Torres Strait Island peoples who are tuning in today.

Sean Blake:

Well, Alana, there's so much to talk about today. The background is, we used to be colleagues in the financial services industry. We bumped into each other again out of the blue at Agile Australia '21 Conference, just at the end of last year, which was a great conference. We thought we'd have you on the podcast because you've got so many different stories to tell, but I thought maybe we could start this episode by talking about your career journey and how working with Agile Teams has weaved into your career trajectory.

Alana Mai Mitchell:

Yeah, sure. Agile really came into the forefront right back in 2013. I always remember my first Agile training. We had a team day, where I was working at the time. We had an external facilitator come in because the Agile framework was something totally new to financial services at that time. We played Lego. We had each of our wider team was divided into smaller teams, like scrum teams, all this new terminology. Then we were building island and we had an island each and the product owner was feeding user stories in from the customer. Partway through we were building, I think, a rocket launcher and then no, we didn't want to rocket launcher anymore.

Alana Mai Mitchell:

We wanted to tweak it. We had to adapt to things on the fly. I always remember that experience because it was so transformative, just having such a direct and collaborative way of working with people on a project. To this day, of all the Agile trainings and experiences that I've gone through, it's always the ones that are really interactive that I've remembered the most and gained the most and taught them, like learnt them myself as a participant and then taught them to other people as well.

Sean Blake:

Along the way, do you think, you've been through all these training sessions and you've been working with teams on the ground. What have you found from Agile, which is a big topic, but what have you found to be the most transformative and the most helpful from the way that these teams used to do things to the way that they do them now?

Alana Mai Mitchell:

I would say communication. What I found was, because I had the contrast with both, I've worked in Water Force style projects and Agile projects as well. I think the biggest part is the amount of effort and rigor that we would go through reviewing requirements and have those be delivered into technology. Then it go quiet and you not hear from technology until they come back with something and they're like, "I've got a baby." You're like, "What kind?" The difference with Agile is that you are able to co-create them.

Alana Mai Mitchell:

You're creating with your customer or your end user, if you're working with an internal user, and then you are also working with technology and finding out what kind of constraints technology has or what kind of ideas they have as well. You have that ability to communicate with the dev. Sometimes your devs are on-shore, often cases they're offshore. We're all remote now, so it doesn't make as much difference as it did when we were in the office. You can really just pull away a lot of the process that gets in between people and have conversations. That's what I really think is the most transformative part.

Sean Blake:

Great. Yeah, so that communication. Do you feel like the communication throughout COVID and working remotely has been more challenging? Are you one of those people that find those face-to-face communication skills, you really prefer the face-to-face or has remote been okay for you? Because I know some people have struggled. Some people have found it easier to be on Zoom all the time.

Alana Mai Mitchell:

Well, I mean, when I go in the office and we have that brief time where we were back in the office, I had a smile on my face the whole time. Because I just love seeing people and I'd go around and walk over to my team and say, "Hey, how are you going?" Just catch up with them. I think the one piece that's missing for me in the remote working whilst there's greater flexibility, you can do multiple things at the same time. You focus a lot of your work. You can get a lot more done quicker. I do find that informal relationship building, you need to actually schedule in time or pick up the phone out of the blue and connect with someone.

Alana Mai Mitchell:

Whereas in the office, I would just find that because people were there and I don't know, you might be having lunch at the same time or going downstairs for something at the same time or even the corridor conversations that happen after the meeting where you can just chase someone or ask someone a question or they chase you and you just get things done. It's just different. I'd say it's more, the catch ups are more scheduled and formal, I find in a remote work setting.

Sean Blake:

I feel the same way. I feel the small talk and the talk about the weekend on Zoom is much harder for me and much more tiring to try and sustain that than in person. It becomes more naturally. I really have to make a big effort, especially on one-to-ones with people in the team when I'm trying to check in on their health and wellbeing and how they're going at work. I just find that much more exhausting than what I do in person. I think it's just those nonverbal communication skills and you can see people's body language easier when you're in the office.

Sean Blake:

Someone's slumped at their chair for six hours out of a seven-hour work day. Then you're like, "Oh, something's wrong." If you know that you've got to get on Zoom and try and pretend to be happy and that everything's okay, then you can fake it a little bit easier. Of course, there's loads of benefits to remote work, as you say. That human element personally, I find it's much more challenging to replicate using digital tools. Maybe there'll be more innovation that comes, but the time will tell on that.

Alana Mai Mitchell:

Yeah. On that, I wanted to add some of my friends in the technology space. Talking about the metaverse and how at the moment you and I are having this conversation through screens. I'm in my space, in my house, and you can see my painting in the background and I can see that you've got a podcast set up. One of my friends was talking about how, he's an architect, and so he was thinking about how we create digital spaces. When we meet digitally, if we were meeting as our avatar, what kind of space would facilitate better conversation? That blew my mind when he was talking about that. I was like, "Oh, I hadn't even thought of that." Absolutely, you could meet in a virtual space because we're doing what we've got with the tools that we have today, but the tools can change.

Sean Blake:

I guess it's almost certain they will change. I can't see that Zoom will be the market leader forever. I'm sure there'll be things that come along very soon that will try and replicate some of those physical experiences that we miss so much of being in the office and having those social experiences together. Alana, I'm wondering about the teams that you work with now or in the past, those Agile teams, do you have any tips for people who are new to Agile teams or maybe they're coming in?

Sean Blake:

They want to improve their communication, whether they're remote or in office, and improve their organization's Agile maturity, but they're just finding it a bit of a struggle. Do you have any tips for people who are just, they're butting their heads up against the wall and they can't seem to make progress with some of those patterns and habits that you talked about, like taking requirements away and not knowing what's happening for so many months or years before you hear something back from technology? How do you actually start to influence that culture and behavior, if you're new to Agile?

Alana Mai Mitchell:

I'm going to take a slightly different approach on that to answer your question. Because the thing that came to mind for me was when I in Outward Bound, which is a remote wilderness organization in 2012 in the US. I was instructing there. One of the frameworks that they use is William Glass' Choice Theory. Choice Theory talks about that we have five needs, and I'll put myself on the spot. Well, I'll mention some of them, because I can't remember all of them. There's like need for fun. Some people have a high fun need. Then there's like need for power, like feeling powerful. There's like, love and belonging, is another important need. There's two others, which I can't recall right now. I think when you are coming out of a situation, from a perspective, you've tried a couple of times when you're approaching it, and not getting anywhere, I would have a look at what needs am I, myself looking to get met out of this communication.

Alana Mai Mitchell:

Then on the flip-side, what needs is my communication partner or the team that I'm working with? What is the most important need for them? As we were talking about remote working, like the fun need. People love to have fun and you can actually have fun at work. It doesn't need to be separate. Thinking about like, if you have a high fun need, and you also notice your team has that as well. How can you address that in your communication style or bring out some kind of activities that can bring that to life? I would always go back to what are my needs and what are the needs of other people that I'm working with? Because when you're working with different teams, they have different agendas, they have different goals. If you can figure out what you have in common, it's a lot easier to bring another team or people in those team on the journey, once you figured out what the common ground is.

Sean Blake:

That's great advice. Think about it from their point of view, rather than just what you need and your own agenda and try and adapt to your approach to them. That's really good. I saw this quote recently, Alana, which reminded me a little bit about your mental health journey, which we'll talk about more in a moment. The quote was about, when you're looking for a new role or a new job, you shouldn't just look for a great company to work for. You should look for a great manager to work for, because the influence and your experience as an employee, working for a manager, is often so much more important than and influential than just picking a great or a well-known company to work for. Have you found that to be true in your own career?

Alana Mai Mitchell:

Oh, yeah. I have found that some really phenomenal leaders. In a previous organization that I was working in, I like to keep learning and growing all the time. In previous roles, sometimes I get bored. It happens. That's really valuable to organizations because I'm constantly looking at where to improve things. I had a time where my manager was focused on other things and learning and development wasn't as important. Then I had a lady named Christina come in and Christina was like fire. She was just, "This is what we got to do." Open to change, really clear communicator, she's from the US. She's really direct in a compassionate way and she's really progressive as well. I found because of her influence in the organization.

Alana Mai Mitchell:

Also, through my willingness to put my hand up and say, "I'm willing to participate." Which is, for the people who are tuning in, it's not just about the leader creating the opportunities for you and saying, "Hey, present to this general manager forum or executive general manager forum." Or whatever it is. It's also about you saying, "Hey, I'm willing and I'd love to." And communicating what you are after. We met on that path and I had some of the most, stronger success working with Christina. I was fortunate at that the culture was also really great. The immediate team culture needed to shift as well, which is part of why Christina came on board, and the company culture is really good.

Alana Mai Mitchell:

I would say on the point on like manager over culture is that when you are someone who is progressive and you're wanting to shape the culture for the better, you're going to find cultures that need a little attention or need a little work or things that aren't quite as performing as well as they are. With the sales perspective, opportunity plus. If you go to a culture and everything's amazing, you're sure you can make it a little bit more amazing. Really, when you have the support of your manager, who's, you see these initiatives and they're going to say, "Okay, go for it. I've got this GM forum coming up that you can present at, or let's find your sponsor. Let's find your mentor." That the two of you working as a team can be at the forefront of the new culture, which impacts the rest of the culture.

Sean Blake:

Interesting. I don't know if I've ever been in a culture that's perfect and overachieving and too good, but absolutely you can get too comfortable and complacent in roles and you can almost just be a little bit shy from putting your hand up for those opportunities. Do you think there's many cultures out there that are too good? How do you assess the quality of a culture before you accept the role and start working in that team?

Alana Mai Mitchell:

Oh, good question. I always asked, what's the vision and how does it relate to this role? I want to hear it from the hiring manager before I join a company. What I'm looking for is I'm asking that question to multiple people. I'm looking for a congruence, about the hiring manager sees a similar story as to what their peer, who's maybe interviewing in the second interview or their leader in the third interview. I'm looking for those things to match up, because that's telling me there's consistency. It's just, I'm getting the same story. That they're also communicating well. That would be a sign to me. Yeah, that's about what I do.

Sean Blake:

That's good. Good tip. Alana, you have a quote on your website, which talks about your mental health journey. It says, "I have totally recovered from five mental health breakdowns across six years, where doctors once talk would me, I would be homeless." That sounds like a lot of hardship and a lot of sweat and tears and pain over many years. Do you want to walk us through a little bit of that journey and what you've learned about yourself through those experiences?

Alana Mai Mitchell:

Oh, yeah. Thanks for pulling that out from the site, Sean. In 2013, I started to notice that things weren't right. I wasn't feeling myself. I sought help from a counselor, career counselor. Because I thought, "Is it my career?" I said, "Am I not in the right job?" I spoke to a psychiatrist and a psychologist and they did a little bit of an investigation, but no one really got to what was going on. Then I made some quick decisions in my career, which I look back on and I think, "Wow, I really was in the throes of it and not thinking clearly at all when I made those choices." I found myself, about November 2014, in between roles. As someone who was previously really ambitious, like high-achiever, chronic high-achiever without having a role and a career prospect at the moment back then was a big deal.

Alana Mai Mitchell:

I had what was called a psychotic episode. Essentially, that was like me, believing deluded thoughts and not having a really strong grip on reality, having some story going on in my head that wasn't true at all. It ended up because I was taken by ambulance to hospital. Then still at that point, people didn't really know what was going on. I was a in mental health ward and came out from that, started on medication, which improved things. I thought, and this is part of why I had the multiple psychotic episodes, is that I thought that the stress of being in between jobs or stressful situations at work, I thought they were the triggers for the psychotic episodes.

Alana Mai Mitchell:

I would take the medication for a while, get better temporarily, think everything was normal, stop the medication. Then six months later I would have another breakdown. Then that happened over six years and I realized towards the fifth and final, so that was when I was running a coaching business that had a few clients at the start and then we didn't have any clients at all. I essentially ran out of money and got into debt. Then when the doctor learned about my financial situation, he said, "You're going to be homeless." I was so offended. I was like, "How dare you." I was like, "No, I will not. I will not." I look back now and I'm so thankful for him sharing that with me, because he provided me with a choice. Something to push against and choose another way. He activated my will, from me going from being offended to being thankful, where I'm at today.

Alana Mai Mitchell:

I charted my way out of that. Now, I have well-managed schizophrenia and I take medication. I'll be taking medication for the rest of my life. It's part of who I am. I don't experience like, some people have a lot of appreciation for, because I know that they're in their mental health journey. It's not all smooth sailing, even after they have an answer of a diagnosis. It still can be challenging in there's up days and down days. For me, I'm consistent. It's been now coming up to four years since the doctor and I had that conversation in the hospital. Life is just incredible since then.

Sean Blake:

That's great. I'm so happy to hear that. Thank you for sharing your story with our audience. I think it's really important, isn't it? To be vulnerable and to share the truth about things that have happened in the past. Do you think that there's something that we can learn? With the people that you work with now, do you have a clearer understanding or are you looking for signs of people in your life who might be struggling with some of the similar issues and what can we do as people in our own communities and working with teams to look out for each other and to better support each other with some of these mental health issues front of mind so that we can be more supportive?

Alana Mai Mitchell:

I always listen for and check in with how the team is doing and it's not just, you ask how are you, and you're listening for more than what they say. If they say they're good, how are they saying it? We had that conversation before about the remote working and it's different. To come to the, are you okay, and we have the, are you okay days. Someone asked me in the office where we were actually working together. They're like, "Are you okay, Alana?" I couldn't answer her. It's not always as simple as getting a no, sometimes it's, you don't get a response. Then the alarm does go off. I really think taking in all the points of interaction that you have with someone and aligning to, is that consistent with how do they were, is there something different, check in with them, how is it going? If you're having a conversation, great. If they're sharing with you, even better.

Alana Mai Mitchell:

If they're not, you can always just check in with yourself and being like, "Is it something you need?" As to, why are they not sharing or is that something that's going on with them as well? The other piece I wanted to tie it, bring it back to the Agile leadership piece and from the conference that Agile Australia that we were at. I really see that building trust with teams is so key. We're in this remote working environment or hybrid working environment, depending on what office you're in. It really is important to build trust with your team. One of the quickest ways you can do that is by sharing vulnerably with what you have to share. I don't mean going for exposure and putting yourself in vulnerable situations where you are uncomfortable with what you share.

Alana Mai Mitchell:

It's disclosure, so it's something that you're 100% comfortable within yourself, and you've accepted it within yourself and you share that with your team in openness. When you do that, you see that your team also, they hear it and they mirror it as well. You go first and they share. The mental health example, I shared that on LinkedIn. I've shared it in situations with my team. Then I've been invited to talks and I've had people approach me. It really builds without having to go through a lot of, I ask this thing of this person, do they deliver it above and beyond expectations when I ask for it? How many times do you need to go through that process before you trust someone versus you, coming out and creating an environment of trust through of vulnerability? I do caveat that it's like not oversharing, it's sharing what you're comfortable with at that point in time, and that might change as you go on.

Sean Blake:

Interesting. Does this apply to leaders as well? I know that you've spoken about being a generous leader in the past, and that reminds me of servant leadership, which is another kind of Agile phrase that you hear come up quite a lot. This idea of going first, disclosing what you're comfortable with to your team, even as a leader, showing vulnerability is really important. I know in my experience, if you can share some of the honest and harsh realities of what it's like to be in your position, then your team are more empathetic with the challenges that you have.

Sean Blake:

Because a lot of people assume that when you are in a position of leadership and responsibility, then things are easier because you can just delegate or you've got budget to solve some of these problems, but it's not actually the reality of it. The reality of it is you struggle with things just like anyone else. By sharing and disclosing things with people at all levels of the organization, then that helps to build empathy and a bit more care and support no matter what level you're at. Are there other things or habits or qualities of a generous leader or a servant leader that you've seen or that you try and model or encourage?

Alana Mai Mitchell:

The big one that stands out for me is authenticity. Really knowing yourself, knowing what your leadership style is, knowing what your challenges are, what your strengths are, what you're working on and being authentic about that. When you feel something, sharing what you feel, not having to feel like you need to say it a different way or sugarcoat it, being able to speak your mind in a way that's direct and compassionate. We're not going for like arrogance, and we're not going for wishy washy. We're going for direct and compassionate, then share what's in your heart, so authenticity. Those are the leaders that you, I'm so glad you brought up empathy because when you're vulnerable, empathetic, and authentic, those are the leaders that really stand out for you and me.

Sean Blake:

That's great advice. Authenticity, direct communication, build empathy. All right, thanks for sharing that.

Alana Mai Mitchell:

You're welcome.

Sean Blake:

Alana, how did you decide that you wanted to write a book about some of your experiences and can you tell us about how your book, Being Brave, has changed your life and how you think about sharing your story?

Alana Mai Mitchell:

I naturally have a lot of things going on. I love projects. I love it, that's why I'm in projects. Because I love setting a goal and reaching it. The company I was working at had done a number of workshops and I got to a point where I didn't have as many activities going on. I was like, "Oh, that's really interesting. I don't have as much stuff going on." This was just at the start of the pandemic in 2020. A friend, a really dear friend of mine said, "Try meditation. Try meditation daily." I meditated each day and I had been surrounded, my network is very much of a coaching network. I know a lot of coaches and they had written their own books as well. I was on the radar and I was meditating and I got the idea to write a personal memoir about my story.

Alana Mai Mitchell:

It's really interesting that even in through that process of doing a lot of personal development work and going through the process of writing the story, there were still some things in that, that I wasn't quite comfortable owning yet. It's been, since I wrote the book that I've accepted that. In a book, if people read it, I talk about psychotic episodes. I don't talk about schizophrenia because it was all later when I was asked to do a media thing about schizophrenia, that I was like, "Okay, yep. Time to own that." I feel like the book at a point in time had me accept all that had happened with unconditional love and then to still, modeling that piece of going for disclosure and not exposure. Still, I had my fragility on what I wasn't ready to disclose yet. Since then, that had progressed further.

Sean Blake:

That's awesome. That therapy you're sitting down to write the story actually helped flesh out the story itself and you came to terms with some of those things that happened. What has been the reception to the book?

Alana Mai Mitchell:

Most people, when they pick up the book, it's a short book, so some people even call it a booklet, because it's 11,000 words. It's short. They say, "Wow, I read that in an hour and a half, in one sitting. I couldn't put it down." someone had said, "It's the story of the famous rising from the ashes." They can take a lot of inspiration from it. The point of the book and a lot of what we're talking about vulnerability is going first as the leader. You set an example that others can follow in, so that will flow into their lives as well. The book is set out with a story and a few questions at the end that people can go through for their own insight.

Sean Blake:

Great, awesome. Alana, is there anything else you'd like to share with our audience before we start wrapping up the episode today?

Alana Mai Mitchell:

I did, because I know this is about Agile more so, and that's a really important topic to your audience. I did write and have a think about after that conference we went to, Agile Australia, about what is beyond the Spotify model? Because the Spotify model is very, word is spoken about it at the moment with the crews and the tribes and squads of course, and the chapter lead models and all that they have, which I'm sure everyone tuned in would be really familiar with. I started to think about, what are the things that are relevant beyond the Spotify model? What's next? If your organization is at a point where you've already at your job at some of that, and you're looking for what's next. I did write an article about that. It's on LinkedIn, and I'll give it to you. If you want to, you can put it in the show notes.

Sean Blake:

That's awesome. We will definitely do that. Where can people go to find out more about you? Where can they buy your book or visit your website?

Alana Mai Mitchell:

My site is www.alanamaimitchell.com. On there is more about my story. There's a few things about coaching, which may be relevant. I'm not coaching at the moment, I'm more focused on my career in financial services. Then the book is on Amazon and it's in English and also in Spanish. There's the audio book and also the print book and the eBook.

Sean Blake:

Awesome. Well, Alana, thanks for disclosing what you've disclosed today and sharing your story with us. I've learned a lot about your experiences, and I've got a lot to think about, to reflect on, how to be a more generous leader. Thanks for spending time with us and being part of the Easy Agile Podcast.

Alana Mai Mitchell:

You're so welcome. Thanks for having me on the show, Sean.

Sean Blake:

Thanks, Alana.