Easy Agile Podcast Ep.12 Observations on Observability

Listen on
Subscribe to our newsletter
  • website.easyagile.com/blog/rss.xml

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?

‍

Angad Sethi

‍

‍

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

Related Episodes

  • Podcast

    Easy Agile Podcast Ep.5 Andrew Malak, Chief Product Officer at Spaceship

    Teagan Harbridge

    "I really enjoyed my conversation with Andrew Malak. We talk integrating agile techniques and tips on how to achieve a culture of accountability"

    Andrew is a firm believer that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes.

    Enjoy the episode!

    ‍

    ‍

    ‍

    ‍

    Transcript

    Teagan Harbridge:

    Welcome to another episode of the Easy Agile Podcast. I'm Teagan, head of product here at Easy Agile. And we've got a really exciting guest on the show today, Andrew Malak from Spaceship. He's the chief product officer. Andrew is a true believer in creating products and experiences that solve customer problems. He believes that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes. In his current role, Andrew aims to help people take control of their wealth from a young age, educating good money habits and helping people invest where the world is going. Andrew is a family man who loves his time with his wife and children. And believe it or not, he uses agile techniques in his personal and professional life. Andrew is an economics geek. He plays and coaches soccer, football. He's a big Liverpool supporter, loves to travel, loves amazing architecture, and loves working with children.

    Teagan Harbridge:

    There were so many takeaways from my chat with Andrew that I really struggled to pair it down to three. But if you say tuned, here are some of the things that you're going to learn from our chat with Andrew. Why we should stop using the term agile transformation and start calling it an agile evolution. Why it's important to be open-minded to our own limitations so to break the old mindset of protecting original scope. And tips on how to achieve a culture of accountability. So I hope you enjoy. Andrew, can you tell me a little bit about Spaceship?

    Andrew Malak:

    Oh, fantastic. Well, thank you very much for, first of all, having me, Teagan. Spaceship is a business that's on a journey to make good money habits and investing accessible to all people. So what we look for is trends to do with industries or companies who are building the future of both industry or economies. We invest in them for the longterm, we break down barriers of entry for people, we give them a fee-free product under $5,000, no minimum investments. It's really easy to sign up. You simply download an app and you sign up and make one product selection decision, and you're done. You can start investing on autopilot. We allow you to also invest your superannuation in a not too dissimilar way.

    Teagan Harbridge:

    So tell me a little bit about who your target customer is, then. Because it seems like you're trying to make something quite complicated accessible for maybe first time investors.

    Andrew Malak:

    Well, you're absolutely right. There's a niche segment of people out there at the moment, millennials or even gen Zs, that we just don't think have been well serviced by the incumbents. And what we're trying to do is resonate with these young people as much as possible. We're trying to reduce industry jargon and really make things simple to them, because investing doesn't have to be complex. It's really about a lot of discipline around, if I can manage my personal P&L, or money in, money out, then I can create a cash buffer that can go into my assets column on my balance sheet. That's really what we're trying to do. And that kind of language, if we can get it right, can really simplify things that have typically been in the hands of financial advisors and accountants and give it back to everyday Australians who are starting out in their investment journey.

    Teagan Harbridge:

    Yeah, awesome. And you've been on quite a journey before landing in the FinTech space as the Spaceship CPO. So can you tell me and our audience a little bit about what that journey has looked like?

    Andrew Malak:

    Oh, where do I start? If you asked a graduate Andrew Malak what he'd be doing now, I don't think I would've been speaking about this because at that point in time in my career I didn't know this space would actually be around, if that makes sense. So I'll go back to my younger years, and I always thought I was going to be an architect. I had this fascination with bridges and I wanted to design things and see them come to life. And let's just say that I do that in different ways right now, but I started out working in CommSec on the trading floor. I moved on to work as a business analyst, and that's where I started my critical thinking into how businesses work and how things can be made more efficient.

    Andrew Malak:

    I dabbled in teaching for a little bit, I taught high school economics and religion for a little bit. And then I eventually landed in a product role at St. George Bank prior to the merger with Westpac. At that point in time, the light bulb really came on. I realized, "Hey, I like creating things. I like to change things. I don't like to just do things," if that makes sense. And that wondering mind that doesn't like the conform was finally let loose, if that makes sense. And I haven't stopped enjoying it. I loved my time at Westpac, made lots of friends, worked on really cool, successful projects, and implemented lots of things that had great results. Worked on lots of things that have failed miserably and learnt a lot out of that. And when the opportunity at Spaceship started to surface late last year, it was just too good an opportunity to not really come in and have a go. So yeah, it's been quite the journey.

    Teagan Harbridge:

    Yeah, wow. And I love a good failure story. And you said you've had lots. Can you think, just off the top of your head, what one of those big failures has been?

    Andrew Malak:

    Where do I start? I think our first attempt at taking a digital experience to allow customers to acquire a product online was quite a failure that taught us a lot. We basically took the systems that our back office staff used and just made it available to customers. And the real good learning out of that is there was a lot of traffic and a lot of demand, but not enough completion ever. And the best learning that came out of that... This is back in 2006, so internet speeds were just starting to pick up. Broadband was starting to go mainstream and customers' trust around doing more transactions that used personally identifiable data was starting to normalize at that point in time. Up until then, people quite reserved thinking, "I'm going to lose my personal data," et cetera. So when we decided to do that, we saw that there was a lot of demand but we quickly came to the realization that we used to train staff for four to six weeks on how to use the systems before they knew how to service customers using them.

    Andrew Malak:

    But then we've deployed it into production for customers to self-service and realized quite quickly that the experience for customers had to be much more guided than the experience for a staff member. This is where the evolution of usability or design thinking started to come in. We started thinking of, "Well, how do we make these things so easy that a first-time user can go end to end and not encounter friction?" And this is where our understanding of design principles, customer testing using verbatim and anguage that can resonate with a first-time user becomes critical to the execution. It's not just good systems but it's good user experience sitting on top of systems.

    Andrew Malak:

    That's probably the one that resonates with me the most because I've held that to a very high regard throughout my whole career. Now everything I do I think of, "Where's the friction? How do we make sure there's no friction? What's the customer going to feel throughout this experience? How are we creating unnecessary anxiety in that experience for the customer, and how do we move that away? How do we become more transparent but still be simple?" And yeah, that's probably the one that resonates the most.

    Teagan Harbridge:

    Seems like a tremendous learning opportunity early enough in that project and something that's stuck with you since, so great learning opportunity.

    Andrew Malak:

    Absolutely.

    Teagan Harbridge:

    We've got a ton of customers who are at all stages of their agile transformations, and I know that this is something that you've had experience with if we go back to your St. George, Westpac days. Can you give our audience any tips or stories that you encountered when you were going through those agile transformations? What lessons can you share with our audience?

    Andrew Malak:

    Oh, I have lots of lessons to share, actually.

    Teagan Harbridge:

    This is what I love.

    Andrew Malak:

    Look, I like to position it more as agile evolution more than agile transformation because no matter what you try to do, you're not just going to drop waterfall and become agile next morning. Honestly, I've seen so many attempts and every single time I see that the graduality of the change is a better predictability of the final outcome that you're going to land. So ultimately the Holy Grail that everyone's aspiring to is that, as a leader, you can rock up to a team stand up unexpected and then, without being told who is in what role, who the product owner is, who the engineer is, who the QC is, who the designer is, it becomes hard for you as the leader to work out who's who because at that point in time the team is so well converged on customer outcomes that they will self-organize themselves around what each person needs to do.

    Andrew Malak:

    And most of the language being used is really around, what are we trying to define the customer? What's the best thing to do within the capacity that we have to deliver this feature to market as quickly as possible, capture value for the customer and the business as much as possible? This takes a long time to get to, where you can start normalizing to a standardized, common set of goals, common cadence, and common ways of working. And I think it's ultimately about how much empowerment you can give people and how much as a leader you can relegate yourself in the background to allow them to work it out themselves as long as you're coming in and nudging things along the way and helping people course correct along the way. So the good news is that I actually think at Spaceship, we're pretty close to getting there.

    Andrew Malak:

    We have been running scrum and we have been running sprints for a long time, but it has been largely ceremonials. But over the last quarter, we've done a really good job at embedding more cross-functional people into these teams. But the goal for us is that now we feel like our throughput has actually increased and that the constant flow of information between the teams is becoming more natural and there is actually less ambiguity between the teams around, "All right, we built it this way. The API is no longer consumable. It doesn't fit what we're trying to do from our front-end and there's less back and forth." So we can really see that the amount of friction between persons in the team is really starting to reduce dramatically and we're starting to see that throughput really increase. Having said that, the best way to go about an agile transformation is just get started.

    Andrew Malak:

    You can sit and plan out things and plan towards utopia as much as you want or you can actually just get going. So when I say by get going, I say you have to start by getting buy-in from all the leaders of the different cross-functional teams, because if you don't have that buy-in at the leadership level, it's just not going to work because there's going to be blockers, there's going to be escalations. And if all these things result in conversations around, "Should we keep doing this?" Or, "Hey, maybe this is not the right thing to do." That needs to be off the table really early on and it needs to be a total commitment at the leadership level that we're going to make this work and whatever we encounter we're just going to fix forward. Once you have that commitment at the leadership level, you need to very clearly define the values that the team is going to be handed to work with, because agile itself, it's not a process, it's a set of values that the team needs to just take and start working with.

    Andrew Malak:

    So we could go and rattle individuals and interactions over processes and tools or working software over comprehensive documentation. Well, give these to the team and they're going to say to you at day one, "We can't go to all of that straight away." So they might actually say that day one, "We're still going to need some documentation because we're not comfortable yet. We don't understand the language of the other people in the scrum team well enough to be able to go and actually code off the back of a conversation." But by the 10th sprint, the 20th sprint, that misunderstanding of what the product owner wants or what the designer is trying to achieve in an experience starts to become embedded in the mind of the engineer.

    Andrew Malak:

    The engineer understands the customer a lot more, and then you can make do with less process and less documentation and less negotiated outcomes and more commonality across the team. The other thing that then starts to kick in at that stage is that ability of the team to pivot in response to a change and not see that as a threat to what they're trying to achieve. The old ways of working was, define that scope, protect that scope, and not let things disturb that scope, whereas if you're halfway through a project and you get some really good information that tells you that maybe you are not on track to achieve a good outcome, you should be welcoming that. And the team itself in the beginning is going to find that an irritation, but over time they'll become more comfortable with pivoting off the back of new information.

    Teagan Harbridge:

    Yeah. It's a big mindset shift. I was just having a discussion today about, where does being agile and being reactive, where's that line in the middle. And when does taking information and pivoting because you think something will be better, when can we break that mindset of, "Oh, we're just being reactive?" No, we're being responsive.

    Andrew Malak:

    Yeah, yeah. And look, I think the word reactive itself naturally has a negative connotation to it, but agility in mindset allows you to flip that on its head and say that no one can work things out in totality to 100% of what's possible, so being open-minded to our own limitations first and foremost allows us to acknowledge that when new information comes in, it is because we didn't think through the solution 100%, but let's also be okay with that because no one can. So I think it's flipping on its head and acknowledging it upfront and saying that this is going to happen, but when it comes we will assess the information we have with the capacity we have with how far progressive we are and make a decision that's right for us, for the customer, and for what's possible.

    Andrew Malak:

    So I take it as the more information you get along the way, the more reinforcement of, are you doing what's right or should you pivot and change at that point in time? The other thing that happens really early on is that if you as a leader can create a really clear vision around customer outcomes and establish your first cross-functional team and hand over that vision to the team, it becomes theirs. Don't hand over the backlog to the team. Don't give them a ready backlog, just give them the vision and then tell them, "You guys work out what your backlog looks like." When they come up with their own backlog, as long as you as a leader don't see that it's just a list of Hail Marys in it and there is a fair bit in there that is well spread out between hygiene things, strategic things, and a few moonshots and the balance is right, if the team has come up with their own backlog, the motivation they have to build their own ideas just goes through the roof.

    Andrew Malak:

    And that's what you want to achieve. You want to achieve clarity that the work fits with the vision and the motivation that you get out of the backlog being created by the team itself gets you that throughput enhancement. The other thing that you're going to struggle with really early on is chunking things down to fitting within the sprint cadence. I think that's one that's often been my biggest challenge when moving towards agile practices early on. Typically in the first few sprints, you always have overruns and things don't complete in the sprint because we end up thinking we can do more than we can and it takes us a while to work out, in wrapping up something that becomes shippable in a sprint, you probably take a little bit less in that sprint because you've got to test it or you've got to do a release in that sprint, or you're going to do a PIR in that sprint, or you're going to do a lot of retros in that sprint. Start to sort of formulate what you're going to take through the next planning cycle.

    Andrew Malak:

    So you've got to budget to that capacity, and I'll find that teams underestimate the magnitude of that work. So be okay with that. Overruns in the first few sprints don't mean you've failed, it means you're learning how to plan better. And then make sure your retros and your pivot off the back of that into your next planning sessions is taking information that is now new to you, and making sure you're working with it. I think as the leader, though, you have to set the expectations that teams can make mistakes and that it's a safe environment.

    Andrew Malak:

    And I've seen many agile... I was about to use the word transformation, even though I've just said I don't believe in transformation. Any teams that are adopting agile principles expecting that in their first few sprints they don't have any hiccups, and that if throughput falls in the first few sprints, then there's a bit of a, "Oh, well you told me this thing was going to increase our throughput." Yeah, but not straight away. So I think just being realistic with yourself and what's possible, and that shift in itself, until it normalizes, takes a bit of getting used to. The teams need to know it's a safe environment, that if their productivity suffers, if they make mistakes or if they break things, it's going to be okay. We'll fix forward.

    Andrew Malak:

    But then also there comes a point in time where we have to be very clear about the culture of accountability around using that capacity really well. So what I've found, that the best use of that is the showcase. And what we've done at Spaceship, because we're trying to reduce the amount of ceremonies, we've combined both the planning playback in a sprint as well as the showcase into the same ceremony. So what we do is we play back what we built last session using a demonstration of working software and comparing the amount of work we've executed versus what was planned in the previous sprint. We're saying we've got 80%, 90% through the work and this is what it looks and feels like, and this is what we're deploying to the customer. Then we actually showcase what we plan to do in the next sprint.

    Andrew Malak:

    And that's part of the showcase, is our hand on heart commitment to, "This is what we as a team are committed to doing in the next sprint." And then that accountability to the organization becomes something that keeps us on track throughout the sprint. As distractors or things that are not committed in the sprint come our way, we quickly think about, all right, can we accommodate these things? Do they need to be done? Are they going to take us off track with what is planned? Are they important enough? Is it a major defect of production, and can customers no longer access our app? Well, drop what you're doing and attend to that. Otherwise, if it's not material, keep focused on the work that you've committed to in front of the organization.

    Andrew Malak:

    After this you're going to start to experience some growing pain, and the growing pain is good because it means that agile is working and more teams or more feature opportunities become possible for the business. There's going to be a lot more hype around moving to agile. Other teams are going to come across and say, "Oh, how do we piggyback off what you're doing?" Et cetera. This is good. This is good, but what it means now is that some new risks are going to actually start to be introduced. Working with common code, common dependencies, or even common people being needed to be doing multiple things just means that you now need more coordination. I'd say to anyone who reaches this point in time, this is where people feel compelled to start introducing some new roles, coordination roles. And I'd just say, be careful because that can start add to your overhead really quickly.

    Andrew Malak:

    I find the best way to ensure that teams continue to be in sync is with the right dialogue at the right level with the right rhythm. And this is where I think keeping it simple to just the scrum of scrums works really well. I like the scrum of scrums to be balanced between both product owner and tech lead from each team being present, and a cadence of one to two times per week works really well. And as long as the product owners across the teams and the tech leads across the teams know what the other teams are working on, know what could impact their own work from a release perspective or scheduling perspective or an environment perspective, I think that tends to work really well as well.

    Teagan Harbridge:

    Yeah, wow. Lots of nuggets in there and certainly things that resonate with our experience here at Easy Agile, being a small company that's grown really quickly. So I can definitely relate. We've had conversations about, do we introduce new roles into this company? We've introduced a new cadence of meeting rhythms only the last couple of months, so we're going through these things too.

    Andrew Malak:

    Absolutely. Absolutely. What have been your biggest learnings so far?

    Teagan Harbridge:

    I think that you cannot underestimate communication, and it really does come back to that cadence and that rhythm with the team. And we're experimenting at the moment with a daily huddle where we're talking about, how do we embed showcases more regularly in our cycles? We've got a big demo at the end of the cycle. How can we make that a more ingrained part of our culture? And it really does come back to that culture of accountability as well. So yep, it's all resonating.

    Andrew Malak:

    Yeah, absolutely. Look, you can go to whatever industry you want but the problems are usually similar. And the great thing is that having these conversations is very important to fast-tracking your way forward, because your problem is not unique to you. Someone else has seen it in someone else has figured out a way. And I think what I like about the FinTech industry is that we compete on products and services, but there's a lot to learn from each other. And even if you just go outside of FinTech, there's a lot to learn from other industries who have adopted agile practices.

    Teagan Harbridge:

    If we take a bit of a flip, we've gone from your professional career and your experience into a more personal level. You mentioned that you use agile techniques outside of work. So I'm not sure if many others are in the same boat, but can you elaborate on this? What does that mean? What does that look like?

    Andrew Malak:

    Okay, I hope you don't think I'm extremely weird. We actually have a family campaign. So I guess if I go back to how we've come to actually doing this. Becoming parents, we would look at our children and see so many things that we want them to be better at. And in trying to give them constant feedback, which felt like the feedback was so much that it's all being drowned out because there's so much of it. In fact, my oldest son actually gave me that feedback. He goes, "Dad, why don't we focus on one thing at a time?"

    Andrew Malak:

    And I was like, "Wow, okay." For a ten-year-old to tell me that, that was amazing. So we came to realize that we needed to narrow and focus on one improvement area at a time, and we don't move on to the next one until we've actually closed out the first one. For example, my oldest son, very clever boy. We're trying to focus with him on the discipline of process over just getting the answer right, because he is clever and nine times out of 10, ask him a question, he's got the answer and he just wants to say it.

    Andrew Malak:

    But we've started to try to break down the question and work more on the process with him so that in following the process, coupled with his natural ability, we will get more answers right more often. And that's what we're working through at the moment. So our family's scrum wall at the moment has a mix of things on it. Everyone has their own swim lane, and in each swim lane there are a few tasks, some related work or study, some relating to household chores, some related to health or exercise, and some related to acts of kindness. And what we aim to do is make sure that we're moving things across in all four categories every single day. So yeah, you can use agility wherever you'd like but I think that mindset in general, that if I wake up every day and do things that make me better than I was yesterday, then I'll get to keep moving forward in my personal life as well as my professional life.

    Teagan Harbridge:

    And do you have WIP limits?

    Andrew Malak:

    We don't at the moment, and we're not doing showcases at the moment. We'll see how we can introduce them in the future.

    Teagan Harbridge:

    And how was the introduction of a Kanban board at home? How was that received by the family? Have they enjoyed it, has there been any feedback?

    Andrew Malak:

    Well, it wasn't actually planned. It started by just sticking some Post-its up on the fridge to remind us of stuff. And then one day I said to my wife, "You know what? This reminds me of what we do at work. Why don't we formalize it?" She had a bit of a chuckle but then one day she came back and then she found it there. So yeah, it wasn't really planned.

    Teagan Harbridge:

    Awesome. And you've already been super generous with your time so I'll close it out with one final question. What advice do you wish someone would have given you when you took the leap from product management into product leadership?

    Andrew Malak:

    Yeah, that's a really good question. I think first and foremost, that you've got to make sure that you drop your need for perfectionism, because first and foremost, you might have been the best product manager yourself. You might have been amazing. And I'm not saying I was, but if you were and you step up in leadership role, you're going to have people of different abilities working for you. And what you need to understand is that they're going to need some time learning their role and learning their trade. And just don't get in the way of them learn. So for example, you might see someone doing something that may not be the best or most optimal use of that capacity in that sprint. You might feel the urge to jump in and course correct. But if you let them go and just hear their feedback post the retro, they might've had that learning themselves, and a learning that they get for themselves rather than being told by their leader is going to be much more useful for them.

    Andrew Malak:

    You have to drop your need to make decisions and be in control because, again, the more you can relegate yourself to a servant leadership role and let the team make decisions, when they make decisions and now have to go back up that decision with execution, they're more likely to put their heart and soul into it. The more they feel like you are going to make the decisions, the less inclined they are to think through problems themselves, and then they'll keep bringing the problems back to you. So every time someone asks you a question that has a black and white answer, throw it back to them and ask them what they think, because that way you're coaching them to work it out themselves. And then the last thing that's really important is, I feel like it's really important to think through how your organization allows you to be different and take advantage of that differentiation.

    Andrew Malak:

    So for example, at Spaceship here, because we're small, we're not a large corporate, our customers are a little bit more forgiving. So you have a limited capacity to build experiences and you can't do all things at the same time. Understand that and take advantage of it, and get your team to also learn that. Because if you're trying to how the all edge cases, it will take a lot longer to get something to market and you might use a lot of the team's capacity to build edge cases. And you can't really afford that when you're in a start-up.

    Andrew Malak:

    So for example, we launched a new investment portfolio yesterday. We launched the Spaceship Earth portfolio, our first sustainable investment portfolio and it's a sign of more things to come hopefully in the sustainability space. But in launching that, we knew that we have a limitation in our experience or our product set today where each customer can only have one portfolio. We knew that existing customers would want to invest in sustainable investing, but our commitment to them is that it's in our backlog and it's actually the next feature that we're actually going to take to market.

    Andrew Malak:

    And in explaining that to our customers, they've been very understanding, that they know our throughput is limited but they also know that their voice is being heard and we are building the things that they're telling us about. So I would say that the best piece of advice to tell my young self is to make sure that you get the balance right between the voice of the customer. That's going to tell you all the hygiene things that your product lacks in terms of experience or gaps. And then get the balance between new strategic things that you can go after and new things that you can take to market, as well as a few Hail Marys every now and again. We call them moonshots. They may or may not work, but it's exciting, and if it works, can 10X your volume. And they are the things that are likely to go viral. So getting the balance right is very important.

    Teagan Harbridge:

    It's been wonderful, Andrew. I've definitely taken a lot away from our chat today, and I'm sure our audience will too. So thank you again so much for your time, and good luck.

    Andrew Malak:

    No Teagan, look, thank you very much. And it's been a pleasure speaking to yourself and Easy Agile, and I wish you guys all the best too.

    Teagan Harbridge:

    Awesome. Thanks Andrew.

    Andrew Malak:

    Have a good afternoon.

  • Podcast

    Easy Agile Podcast Ep.6 Chris Stone, The Virtual Agile Coach

    Sean Blake

    What a great conversation this was with Chris Stone, The Virtual Agile Coach!

    Chris shared some insights into the importance of sharing and de-stigmatising failures, looking after your own mental health, and why work shouldn't be stale.

    Some other areas we discussed were, why you should spend time in self reflection - consider a solospective? and asking "how did that feel?" when working as a team.

    "I really enjoyed our chat. Plenty to ponder over the silly season, and set yourself up with a fresh perspective for 2021. Enjoy and Merry Christmas!"

    ‍

    ‍

    ‍

    Transcript

    Sean Blake:

    Hello, and welcome to another episode of the Easy Agile Podcast. It's Sean Blake here, your host today, and we're joined by Chris stone. Chris is going to be a really interesting guest. I really enjoyed recording this episode. Chris is the Virtual Agile Coach. He's an agility lead. People First champion blogger, speaker and trainer, who always seeks to gamify content and create immersive Agile experiences. An Agile convert all the way from back in 2012, Chris has since sought to broaden his experiences, escape his echo chamber and to fearlessly challenge dysfunction and ask the difficult questions. My key takeaways from this episode were; it's okay to share your failures, the importance of recognizing our mental health, why it's important that work doesn't become stale, how to de-stigmatize failure, the importance of selfreflection and holding many self retrospectives, and the origins of the word deadline. You'll be really interested to find out where that word came from and why it's a little bit troubling. So here we go. We're about to jump in. Here's the episode with Chris stone on the Easy Agile Podcast. Chris, thanks so much for joining us and spending some time with us.

    Chris Stone:

    Hey there Sean, thank you for having me. It's a pleasure.

    Sean Blake:

    I have to mention you've got a really funky Christmas sweater on today. And for those people listening on the audio, they might have to jump over to YouTube just for a section to check out this sweater. Can you tell us a bit about where that came from?

    Chris Stone:

    So this sweater was a gift. It's a Green Bay Packers, Chris, Ugly Christmas Jumpers, what they call it. And I'm a fan of the Green Bay Packers, I've been out there a few times to Wisconsin, Green Bay, Wisconsin. It's so cold out there in fact. When you're holding a beer and minus 13 degrees, the beer starts turning to slush just from being outside in the cold air. It's a great place, very friendly, and the jumper was just a gift one Christmas from someone.

    Sean Blake:

    Love it. There's nothing better than warm beer is there? Okay. So Chris, I first came across you because of the content that you put out on LinkedIn. And the way that you go about it, it's so much fun and so different to really anything else I've seen in the corporate space, in the enterprise space, in the Agile space even, why have you decided to go down this track of calling yourself the virtual Agile coach, building a personal brand and really putting yourself out there?

    Chris Stone:

    Well, for me, it was an interesting one because COVID, this year has forced a lot of people to convert to being virtual workers, remote workers, virtual coaches themselves. Now, what I realized this year is that, the aspiration for many is those co-located teams, it's always what people desired. They say, "Oh, you have to work harder, Katie, that's the best way." And I realized that in my whole Agile working life, I'd never really had that co-located team. There was always some element of distributed working and the past two years prior to where I'm currently, my current company, I was doing distributed scaled Agile with time zones, including Trinidad and Tobago, Alaska, Houston, the UK, India, and it was all remote.

    Chris Stone:

    And I thought, all right, this is an opportunity to recognize the fact that I was a virtual Agile coach already, but to share with others, my learnings, my experiences, the challenges I've faced, the failures I've had with the wider community so they can benefit from it because obviously, everyone, or more many have had to make that transition very quickly. And there's lots of learnings there that I'm sure people would benefit from. And this year in particular, I guess the honest answer, the reason for me being, I guess out there and working more on that side of things, being creative is because it's an outlet for my mental health.

    Chris Stone:

    I suffer from depression and one of my ways of coping with that is being creative and creating new content and sharing it. So I guess it's a reason of... it's linked to that also, but also the stories that people tell me afterwards, they motivate me to keep doing it. So when someone comes to me and says, "Hey, I did the Queen retrospective, the Queen Rock Band retrospective, and this program manager who never smiles connected to the content and admitted he liked Queen and smiled." And this was a first and when people come to me and say, "Hey, we did the Home Alone retrospective, the one of your Christmas themed ones and people loved it. It was great." It was the most engaging retrospective we've had so far because the problem is work can become stale if you let it be so.

    Chris Stone:

    Retrospectives can become this, what did we do last time? What are we going to do next time? What actions can we do? Et cetera, et cetera. And unless you refresh it and try new things, people will get bored and they'll disconnect and they'll disengage, and you're less likely to get a good outcome that way. So for me, there's no reason you can't make work a little bit fun, with a little bit of creativity and a little bit of energy and passionate about it.

    Sean Blake:

    I love that. And do you think a lot of people come to work even when they're working in Agile co-located teams and it's just not fun, I mean what do you think the key reasons are that work isn't fun?

    Chris Stone:

    I think because it can become stale. All right. So let's reflect on where we are today. Today, we're in a situation where we're not face-to-face with one another. We don't have time for those water cooler chats. We don't connect over a coffee or a lunch. We don't have a chat about idle banter and things of that on the way to a meeting room, we didn't have any of that. And that forces people to look at each other and see themselves as an avatar behind a screen, just a name. Often in particular, people aren't even on video camera.

    Chris Stone:

    It forces them to think of people as a name on a screen, rather than a beating heart on a laptop. And it can abstract people into just these entities, these names you talk to each day and day out, and that can force it to be this professional non-personal interaction. And I'm a firm believer that we need to change that. We need to make things more fun because it can, and in my experience, does result in much better outcomes. I'm very, very people first. We need to focus on people being people. People aren't resources. This is a common phrase I like to refer to you.

    Sean Blake:

    I love that, people aren't resources. You spoke a little bit about mental health and your struggle with depression. Something that I hear come up time and time again, is people that talk about imposter syndrome. And I wonder, firstly, if you think that might be exasperated through working remotely now. People are not so sure how they fit in, where their role is still the same role that it was 12 months ago. And do you have any tips for people when they're dealing with imposter syndrome, especially in a virtual environment?

    Chris Stone:

    Well, yeah I think this current environment, this virtual environment, the pandemic in particular, has led to a number of unhelpful behaviors. That there's a lot more challenges with people's mental health and negativity, and that can only lead to, I guess, less desire, less confidence in doing things, maybe doubting yourself. There's some great visuals I've shared on this recently, and it's all about reframing those imposter thoughts you have, the unhelpful thinking, that thing that goes through your mind that says, Oh, they're all going to think I'm a total fraud because maybe I don't have enough years of experience, or I should already know this. I must get more training. There's lots of “shoulding” and “musting” in that. There's lots of jumping to conclusions in this.

    Chris Stone:

    And a couple of ways of getting around that is, so if you're thinking of the scenario where I'm a fraud think, "Oh, well I'm doing my best, but I can't predict what they might think." When you're trying to think about the scenario of do I need to get more training? Well, understand and acknowledge the reality that you can't possibly know everything. You continue to learn every single day and that's great, but it's unrealistic to know it all. There's a great quote I often refer to and it's, true knowledge is knowing that you know nothing. I believe it's a quote from Socrates.

    Chris Stone:

    And it's something that very much resonates with me. Over the years I've gone through this learning journey where, when I first finished university, for example, I thought I knew everything. I thought I've got it all. And I'd go out to clients and speak and I'm like, "Oh yeah, I know this. I've got this guys." And then the more involved I've become and the more deeper I've gone into the topic, the more I realized, actually there's so much that I don't know. And to me, true knowledge is knowing that you know nothing tells me there's so much out there that I must continuously learn, I must continuously seek to challenge myself each and every day.

    Chris Stone:

    Other people who approach me and say, "How do you, or you produce a lot of content. How would you put yourself out there?" And I say, "Well, I just do it." Let's de-stigmatize failure. If you put a post out there and it bombs, it doesn't matter, put another one out there. It's as simple as that, learn from failure, Chuck something out there, try it, if it doesn't work, try something else. We coach Agile teams to do this all the time, to experiment. Have a hypothesis to test against that. Verify the outcomes and do retrospectives. I do weekly solospectives. I reflect on my week, what works, what hasn't worked, what I'm going to try differently. And there's no reason you can't do that also.

    Sean Blake:

    Okay. So weekly solospectives. What does that look like? And how do you be honest with yourself about what's working, what's not working and areas for yourself to improve? How do you actually start to have that time for self-reflection?

    Chris Stone:

    Unfortunately you got to make time for some reflection. One thing I've learned with mental health is you have to make time for your health before you have to make time for your illness or before you're forced to make time for your illness. And it can become all too easy in this busy working world to not make time for your health, to not make time and focus on you. So you do just have to carve out that time, whether that's blocking some time in the diary on a Friday afternoon, just to sit down and reflect, whether that's making time to go out for a walk, setting up a time on your Alexa to have a five minute stretching break, whatever it is, there's things you can do, and you have things you have to do to make time for yourself.

    Chris Stone:

    With regards to a solospective, the way I tend to do things is I tend to journal on a daily basis. That's almost like my own daily standard with myself, it's like, what have I observed? What have I... what challenges do I face in the past day? And then that sums up in the weekly solospective, which is basically a retro for one, where I reflect on, what did I try it? What do I want to achieve this week? What's gone well? What hasn't gone well. It's the same as a retrospective just one and allows me to aggregate my thoughts across the week, rather than them being single events. So that I'm focusing more on the trajectory as opposed to any single outlier. Does that make sense?

    Sean Blake:

    It does. It does. So you've got this trajectory with your career. You're checking in each week to see whether you're heading in the right direction. I assume that you set personal goals as well along the way. I also noticed that you have personal values that you've published and you've actually published those publicly for other people to look at and to see. How important are those personal values in informing your life and personal and career goals?

    Chris Stone:

    So I'd say that are hugely important, for me, what I thought was we see companies sharing their values all the time. You look on company websites and you can see their values quite prominently. And you could probably think do they often live up to their values? You have so many companies have customer centricity as their value, but how many of them actually focus on engaging with their customers regularly? How many have a metric where they track, how often they engage with customers? Most of them are focusing on velocity and lead time. So I always challenge, are you really customer centric or is that lip service? But moving aside, I digress. I thought companies have values, and obviously we do as well, but why don't we share them? So I created this visual, showing what mine were and challenged a few others to share it also. And I had some good feedback from others which was great.

    Chris Stone:

    But they hugely influence who I am and how I interact on a day-to-day basis. And I'll give you an example, one of my values is being open source always. And what that means is nothing I create, no content I create, nothing I produce would ever be behind a payroll. And that's me being community driven. That's me sharing what I've learned with others. And how that's come to fruition, how I've lived that is I've had lots of people come to me say, "Hey, we love the things you do. You gave me flying things. Would you mind, or would you like to collaborate and create this course that people would pay for?" So often I've said, "If it's free, yes. But if it's going to be monetized, then no."

    Chris Stone:

    And I've had multiple people reach out to me for that purpose. And I've had to decline respectfully and say, "Look, I think what you're doing is great. You've got a great app and I can see how having this Agile coaching gamification course on that would be of great value. But if it's behind the payroll, then I'm not interested because it's in direct conflict with my own values, and therefore, I wouldn't be interested in proceeding with it. But keep doing what you're doing, being people first, #people first." This is about me embodying the focus on people being beating hearts behind a laptop, rather than just this avatar on a screen. And I have this little... the audio listeners, won't be able to see this, but I'm holding up a baby Groot here. And he's like my people first totem.

    Chris Stone:

    And the reason for that is I have a group called the Guardians of Agility, and we are people first. That's our emblem. And these are my transformation champions in my current company. I like to have Guardians of Agility, and I've got this totem reminding me to be people first in every interaction I have. So when, for example, I hear the term resources and I'm saying, well... As soon as I hear it, it almost triggers me. I almost hear like, "Oh, what do they mean by that?" And I'll wait a little moment and I'll say, "Hey, can you tell me what you mean by that?" And you tease it out a little bit. And often they meant, "Oh, it's people, isn't it?" If you're talking about people, can we refer to them as people?

    Chris Stone:

    Because people aren't resources. They're not objects or things you mine out the ground. They're not pens, paper or desks. They're not chairs in an office. They are people. And every time you refer to them as a resource, you abstract them. You make it easier to dehumanize them and think of them as lesser, you make it easier to make those decisions like, oh, we can just get rid of those resources or we can just move that resource from here to there and to this team and that team, whether they want to or not. So I don't personally like the language.

    Chris Stone:

    And the problem is it goes all the way back to how it's trained. You go to university and you take a business degree and you learn about human resources. You take a course, Agile HR, Agile human resources, right, and it's so prevalent out there. And unless we challenge it, it won't change. So I will happily sit there and a meeting with a CTO and he'll start talking about resource and I'll say, "Hey, what do you mean by that?" And I'll challenge it and he'll go, "Yeah, I've done it again, have I not?" "Yes. Yes, you have." And it's gotten to the point now where I'll be on this big group call for example, and someone will say it, and I'll just start doing this on a screen waving, and they'll go, "Did it again, didn't I?" "Yes, you did."

    Sean Blake:

    So some of these habits are so ingrained from our past experiences our education, and when you're working with teams for the first time, who's never worked in Agile before, they're using phrases like resources, they're doing things that sometimes we call anti-patents, how do you start to even have that conversation and introduce them to some of these concepts that are totally foreign to people who've never thought the way that you or I might think about our teams and our work?

    Chris Stone:

    Sure. So I guess that the first response to that is with empathy. I'm not going to blame someone or make out that they're a bad person for using words that are ingrained, that are normal. And this is part of the problem that that term, resource is so ingrained in that working language nowadays, same as deadlines. Deadlines is so ingrained, even though deadlines came from a civil war scenario where it referred to, if you went past the line, you were shot. How did that land in the business language? I don't know. But resources, it's so ingrained, it's so entrenched into this language, so people do it without intending to. They often do it without meaning it in a negative way. And to be honest, the word itself isn't the issue, it's how people actually behave and how they treat people.

    Chris Stone:

    I said my first approach is empathy. Let's talk about this. Let's understand, "Hey, why did you use term?" "Oh, I use it to mean this." "Okay. Well." Yeah, and not to do it or call them out publicly or things like that. It's doing things with empathy. Now, I also often use obviously gamification and training approaches, and Agile games to introduce concepts. If someone's unfamiliar to a certain way of working, I'll often gamify. I'll create something, a virtual Agile game to demonstrate. The way I do say, is I'm always looking to help people understand how it feels, not just to talk theory. And I'll give you an example. I'm a big fan of a game called the Virtual Name Game. It's a game about multitasking and context switching.

    Chris Stone:

    And I always begin, I'll ask group of people, "Hey guys, can you multitask?" And often they go, "Yeah, we can do that." And there'll be those stereotypical things like, "Oh yeah, I'm a woman. I can do that." It happens. Trust me. But one of the first things I do, if I'm face-to-face with them, I'll say, "Hey, hold your hands out like this. And in your left hand..." And people on the audio can't see me, I'm holding out like my hands in front of me. In my left hand, we're going to play an endless game of rock, paper, scissors. And in my right hand, we're going to play a game of, we have a thumb war with each other. And you can try, you can challenge them, can they do those concurrently? No, they can't. They will fail because you just can't focus on both at the same time.

    Chris Stone:

    Now the Virtual Name Game, the way it works is you divide a group of people up into primarily customers and one developer. And I love to make the most senior person in the room, that developer. I want them to see how it feels to be constantly context switching. So if you were the developer, you're the senior person to review the hippo in this scenario, the highest paid person. I would say Sean, in this game, these customers, they are trying to get their name written first on this virtual whiteboard. And we're going to time how long it takes for you to write everyone's name in totality. The problem is that they're all going to shouting at you continuously, endlessly trying to get your attention. So it's going to be Sean, Sean, write my name, write my...

    Chris Stone:

    And it's just going to be wow, wow, wow, who do I focus on? You won't know. And this replicates a scenario that I'm sure many people have experienced. He who shouts loudest gets what they want. Prioritization is often done by he who's... or the person who shouts loudest not necessarily he. We then go into another rounds where you say, I'm this round, Sean, people are to be shouting their name at you. But in this round, you're going to pay a little bit attention to everyone. So the way you're going to do that is you're going to read the first letter of one person's name, then you move on to the first letter of the next person's name, and you're going to keep going around. The consequence of that is everyone gets a little bit of attention, but the result is it's really slow.

    Chris Stone:

    You're starting lots of things but not finishing them. And again, in each round, we're exploring how it feels. How did it feel to be in that round? Sean, you were being shouted at, how did that feel? Everyone else, you were shouting to get your attention. You had to shout louder than other people, how did that feel? And it's frustrating, it's demotivating, it's not enjoyable. In the final around, I would say, "Hey, Sean, in this round, I'm going to empower you to decide whose name you write first. And you can write the whole thing in order. And the guys actually they're going to help you this time, there are no shouts over each other, they are going to help you." And in this scenario, as I'm sure you can imagine, it feels far better. The result is people finish things, and you can measure the output, the number of brand names written on a timeframe.

    Chris Stone:

    It's a very quick and easy way of demonstrating how it feels to be constantly context switching and the damage you can have, if, for example, you've prioritized things into a sprint and you got lots of trying to reorder things and so on and so forth, and lots of pressure from external people that ideally should be shielded from influencing this and that, and how that feels and what the result is, because you may start something, get changed into something else. You got to take your mindset of this, back into something else, and then the person who picks up the original thing might not have even been the same person, they've got to learn that over again. There's just lots of waste and efficiency costs through that. And that's just an example of a game I use, to bring that sort of things to life.

    Sean Blake:

    That's great. That's fantastic. I love that. And I think we need to, at Easy Agile, start playing some of those games because there's a lot of lessons to be learned from going through those exercises. And then when you see it play out in real life, in the work that you're doing, it's easier to recognize it then. If you've done the training, you've done the exercise, that all seems like fun and games at the time, but when it actually rears its head in the work that you're doing, it's much easier to call it out and say, "Oh wait, we're doing that thing that we had fun playing, but now we realize it's occurring in real life and let's go a different direction." So I can see how that would be really powerful for teams to go through that so Chris [crosstalk 00:22:26].

    Chris Stone:

    I'd also add that every game that I do, I construct it using the four Cs approach. So I'm looking to connect people... firstly, connect people to each other, and then to the subject matter. So in this game is about multitasking. To contextualize why that matters, why does context switching and multitasking matter in the world of work? Because it causes inefficiencies, because it causes frustration, de-motivation, et cetera. Then we do some concrete practice. We play a game that emphasizes how it feels. And at the end we draw conclusions, and the idea is that with the conclusion side of things, it's almost like a retrospective on the game. We say, "Hey, what did we learn? What challenges we face? And what can we do differently in our working world?" And that hopefully leaves people with actionable takeaways. A lot of the content I share is aiming to leave it with actionable takeaways, not just talking about something, but reflecting on what you could do differently, what you could try, what experiment you might like to employ with your working life, your team that might help improve a situation you're facing.

    Sean Blake:

    Okay. Yeah, that's really helpful. And you've spoken about this concept of Agile sins, and we know that a lot of companies have these values, they might've committed to an Agile transformation. They might've even gone and trained hundreds or thousands of people at accompany using similar tactics and coaching and educational experiences that you provide. But we still see sometimes things go terribly wrong. And I wonder, what's this concept of Agile sins that you talk about and how can we start to identify some of these sins that pop up in our day-to-day work with each other?

    Chris Stone:

    I guess, so the first thing I would emphasize about this is that using sin, it's a very dogmatic religious language and it's more being used satirically than with any real intent. So I just like to get that across. I'm not a dogmatic person, I don't believe there is any utopian solution. I certainly don't believe there's any one size fit to all situation for anyone. So the idea that there's really any actual sins is... yeah, take that with a pinch of salt. The reason the Agile sins came up is because I was part of... I'd done a podcast recently with a guy called Charles Lindsey, and he does this Agile confessional. And it's about one coach confessing to another, their mistakes, their sins, the things they've done wrong.

    Chris Stone:

    And I loved it because I'm all about de-stigmatizing failure. I'm all about sharing with one another, these war stories from one coach to another, because I've been a proponent of this in the past. I've shouted, "Hey there, I failed on this. I made this mistake. I learned from it." And I challenge others to do so as well and there's still this reluctance by many to share what went wrong. And it's because failure is this dirty word. It's got this stigma attached to it. No one wants to fail, leaders in particular. So the podcast was a great experience.

    Chris Stone:

    And it was interesting for me because that was the first time I'd given a confession, because I'll be honest with you, I'm someone who is used to taking confession myself. I go to this hockey festival every year and I got given years ago, this Archbishop outfit, and I kind of made that role my own way. I was drunk, and I said, "You're going to confess your sins to me." And if they haven't sinned enough, I tell them to go and do more. And I give them penicillin with alcohol shots and things like that. And I've actually baptized people in this paddling pool whilst drunk. Anyway, again, I digress, but I wasn't used to confessing myself, usually, I was taking confession, but I did so and it was a good experience to share some of my failures and my patterns was to create... and it was my own idea, to create my videos, seven videos of my seven Agile sins. And again, this was just me sharing my mistakes, what I've learned from that, with the intent of benefiting others to avoid those similar sins.

    Sean Blake:

    So you've spoken to a lot of other Agile coaches, you've heard about their failures, you confessed your own failures, is it possible for you to summarize down what are those ingredients that make someone a great coach?

    Chris Stone: And that is a question, what makes someone a great coach? I think it's going to be entirely subjective, to be honest. And my personal view is that a great coach listens more than they speak. I guess that would be a huge starting point. When they listen more than they speak, because I've... and this is one of the things I've been guilty of in the past, is I've allowed my own biases to influence the team's direction. An approach I'd taken in the past was, "Hey, I'm working with this team and this has worked well in the past. We're going to do that." Rather than, "So guys, what have you done so far? What have you tried? What's worked well? What hasn't worked well? What can we create or what can we try next? That works for you guys. Let's have you make that decision and I'm here to guide you through that process to facilitate it, rather than to direct it myself."

    Chris Stone:

    Again, I find ... it's an approach that resonates more with people. They like feel that they own that decision as opposed to it being forced upon them. And there's far less, I guess, cognitive dissonance as a consequence. So listening more than speaking is a huge for me, a point an Agile coach should do. Another thing I think for me nowadays, is that there's too much copying and pasting. And what I mean by that is, the Spotify, the Spotify model came out years ago and everyone went, "Oh, this is amazing. We're going to adopt it. We're going to have tribes and chapters and guilds and squads, and it's going to work for us. That's that's our culture now."

    Chris Stone:

    I was like, "Well, let's just take a moment here. Spotify never intended for that to happen. They don't even follow that model themselves anymore. What you've done there is you've just tried to copy and paste another model." And people do it with SAFe as well. They just say, "Hey, we're going to take the whole SAFe framework and Chuck it into our system in this blueprint style cookie cutter." And the problem is that it doesn't take into account for me, the most important variable in any sort of transformation initiative, the people, what they want, and the culture there. So this is where another one of my values is, innovate, don't replicate. Work with people to experiment and find that Agile, what works for them rather than just copying and pasting things.

    Chris Stone:

    So tailor it to their needs rather than just coming in with some or seen dancing framework, and then the way I do it is I say, "Hey, well, SAFe is great. Well, it's got lots of values, and lots of great things about it. Lots of benefits to it, but maybe not all of it works for us. Let's borrow a few tenent of that." Same with LeSS, same with Scrum At Scale, same with Scrum, similar to Kanban. There's lots of little things you can borrow from various frameworks, but there's also lots of things you can inject yourself, lot's of things you can try that work for you guys, and ultimately come up with your own tailor-made solutions. So innovate, don't replicate would be another one for me.

    Chris Stone:

    Learning, learning fast and learning often, and living and breathing that yourself. Another mistake I and other coaches I think have made is not making time for your own personal development to allowing, day in, day out to just be busy, busy, busy, but at the same time you're going out there, coaching teams, "Hey, you've got to learn all the time. You got to try new things." But not making that time for yourself. So I always carve out time to do that, to attend conferences, to read books, to challenge myself and escape my echo chamber. Not just to speak to the same people I do all the time, but perhaps to go on a podcast with people I've never spoken to. To a different audience, maybe to connect with people that actually disagree with me, because I want that.

    Chris Stone:

    I don't want that homophilous thinking where everyone thinks exactly like I do, because then I don't get exposed to the perspectives that make me think differently. So I'm often doing that. How can I tend to conference that I know nothing about, maybe it's a project management focus one. Project management and waterfall isn't a dirty word either. There is no utopian system, project management and... sure traditional project management and waterfall has its benefits in certain environments. Environments with less footing, less flexible scope or less frequently changing requirements works very well.

    Chris Stone:

    I always say GDPR, which is an EU legislation around data protection, that was a two year thing in the making and everyone knew exactly what was happening and when they had to do it by. That was a great example of something that can be done very well with a waterfall style, because the requirements weren't changing. But if you are trying to develop something for a customer base that changes all the time, and you've got lots of new things and lots of competitors and things like that, then it varies, and probably the ability to iterate frequently and learn from it is going to be more beneficial and this is where Agile comes in. So I guess to sum up there, there's a few things, learning fast learning often. I can't even remember the ones I've mentioned now, I've gone off on many tangents and this is what I do.

    Sean Blake:

    I love it. It's great advice, Chris. It's really important and timely. And you mentioned, earlier on that the customer base that's always changing and we know that technology is always changing and things are only going to change more quickly, and disruptions are only going to be more severe going forward. Can you look into the future, or do you ever look into the future and say, what are those trends that are emerging in the Agile space or even in work places that are going to disrupt us in the way that we do our work? What does Agile look like in five or 10 years?

    Chris Stone:

    Now that again is a very big question. I can sit here and postulate and talk about what it might look like. I'm going to draw upon what I think is a great example of what will shape the next five or 10 years. In February, 2021, there's a festival called Agile 20 Reflect, I'm not sure if you've heard of it, and it's built as a festival, not conference, it's really important. So it's modeled on the Edinburgh festival and what it intends to be is a celebration of the past, the present and the future of Agile. Now what it is, it's a month long series of events on Agile, and anyone can create an event and speak and share, and it will create this huge community driven load of content that will be freely accessible and available.

    Chris Stone:

    Now, there are three of the original Agile manifestor signatories that are involved in this. Lisa Adkins is involved in this as is lots of big name speakers that are attached to this festival. And I myself, I'm running a series of retrospectives on the Agile manifesto. I've interviewed Arie van Bennekum, one of the original Agile manifesto signatories. They're going to be lots of events out there. And I think that festival will begin to shape in some way, what Agile might look like because there's lots of events, lots of speakers, lots of panel discussions that are coming up, coming together with lots of professionals out there, lots of practitioners out there that will begin to shape what that looks like. So whilst I could sit here and postulate on it, I'm not the expert to be honest, and there are far greater minds than I. And actually I'd rather leverage the power of the wider community and come into that than suggesting mine at this time.

    Sean Blake:

    Nice. I like it. And what you've done there, you've made it impossible for us to click this video and prove you wrong in the future when you predict something that doesn't end up happening. So that's very wise if you.

    Chris Stone: Future proof myself.

    Sean Blake: Exactly. Chris, I think we're coming almost to the end now, but I wanted to ask, given the quality of your Christmas sweater, do you have any tips for teams who are working over the holiday period, they're most likely burnt out after a really difficult 2020? What are some of the things you'd say to coaches on Agile teams as they come into this time where hopefully people are able to take some time off, spend some time with their family. Do you have any tips or recommendations for how people can look after their mental health look after their peers and spend that time in self-reflection?

    Chris Stone:

    Sure. So a number of things that I definitely would recommend. I'm currently producing and sharing this Agile advent calendar. And the idea is that every day you get a new bite-size piece of Agile knowledge or a template or something working in zany or a video, whatever it may be. There's lots of little things getting in there. And there's been retro templates, Christmas and festive themes. So there's a Home Alone one, a Diehard one, an elf movie one, there's all sorts. Perhaps try one of those as a fun immersive way with your team to just reflect on the recent times as a squad and perhaps come up with some things in the next year.

    Chris Stone:

    And there's for example, the Diehard one, it's based on the quotes from the movie Diehard so it's what you'd be doing in there, celebrate your... to send them to your team. Or there's one in there about, if this is how you celebrate Christmas, I can't wait for new year. And that question was saying, what do we want to try next year? Like this year has been great, what do we want to try differently next year? So there's opportunities through those templates to reflect in a fun way so give one of those a go. I shared some Christmas eve festive Zoom backgrounds, or Team backgrounds, give those a go and make a bit fun, make it a bit immersive. There's Christmas or festive icebreakers that you can use. What I tend to do is any meeting I facilitate, the first five minutes is just unadulterated chat about non-work things, and I often use icebreakers to do so. And whether that's a question, like if you could have the legs of any animal, what would you have and why, Sean, what would that be?

    Sean Blake:

    Probably a giraffe, because just thought the height advantage, it's got to be something that's useful in everyday life.

    Chris Stone: Hard to take you on the ground maybe.

    Sean Blake:

    Yes. Yes, you would definitely need that. Although, I don't think I would fit in the lift on the way to work, so that would be a problem.

    Chris Stone:

    Yeah. That's just how I start. But yeah, that's just a question, because it's interesting to see what could people come up with, but there's some festive ones too, what's your favorite Christmas flick? What would put you on the naughty list this year? Yeah, does your family have any weird or quirky Christmas traditions? Because I love hearing about this. Everyone's got their own little thing, whether it's we have one Christmas present on Christmas Eve or every Christmas day we get a pizza together. There's some really random ones that come out. I love hearing about those and making time for that person interaction, but in a festive way can help as well.

    Chris Stone:

    And then on the mental health side of things, I very much subscribed to the Pomodoro effect from a productivity side of things. So I will use that. I'll set myself a timer, I'll focus without distractions, do something. And then in that five minute break, I'll just get up and move away from my desk and stretch and get a coffee or whatever it may be. But then I'll also block out time, and I know some companies in this remote working world at the moment are saying, "Hey, every one to 2:00 PM is blocked out time for you guys to go and have a walk." Some companies are doing that. I always make time to get out and away from my desk because that... and a little bit more productive and it breaks up my day a little bit. So I definitely recommend that. Getting some fresh air can do wonders for your mental health.

    Sean Blake:

    Awesome. Well, Chris, I've learnt so much from this episode and I really appreciate you spending some time with us today. We've talked about a lot of things from around the importance of sharing your failures, the importance of looking after your mental health, checking in on yourself and your own development, but also how you tracking, how you feeling. I love that quote that you shared from, we think it Socrates, that true knowledge is knowing that you know nothing. I think that's really important, every day is starting from day one, isn't it? De-stigmatizing failure. The origins of the word deadline. I did not know that. That's really interesting. And just asking that simple question, how did that feel? How did that feel working in this way? People were screaming your name, walk up work, when work's too busy, how does that feel? And is that a healthy feeling that everyone should have? So that's really important questions for me to reflect on and I know our audience will really appreciate those questions as well. So thanks so much Chris, for joining us on the Easy Agile Podcast.

    Chris Stone:

    Not a problem. Thank you for listening and a Merry Christmas, everyone.

    Sean Blake:

    Merry Christmas.

  • Podcast

    Easy Agile Podcast Ep.26 Challenging the status quo: Women in engineering

    "It was great to be able to have this conversation with Maysa and have her share her story. So many great takeaways." - Nick Muldoon

    Join Nick Muldoon, Co-founder and Co-CEO of Easy Agile as he chats with Maysa Safadi, Engineering Manager at Easy Agile.

    As a woman, growing up in the middle east and being passionate about pursuing a career in the world of tech, don’t exactly go hand in hand. Navigating her way through a very patriarchal society, Maysa talks about her career journey and how she got to where she is today.

    Having the odds stacked against her, Maysa talks about challenging the status quo, the constant pressure to prove herself in a male-dominated industry, the importance of charting your own course and her hopes for the future of women in tech.

    This is such an inspiring episode, we hope you enjoy it as much as we did.

    Transcript

    Nick Muldoon:

    Hi, team. Nick Muldoon, co-founder co-CEO at Easy Agile, and I'm joined today by Maysa Safadi, who's an engineering manager here at Easy Agile. We'll get into Maysa's story and journey in just a little bit, but before we do, I just wanted to say a quick acknowledgement to the traditional custodians of the land from which we are recording and indeed broadcasting today, and they are the people of the Dharawal speaking country just south of Sydney and Australia. We pay our respects to elders past, present, and emerging, and extend that same respect to all Aboriginal Torres Strait Islander and First Nations people that are joining us and listening in today. Maysa, welcome. Thanks for joining us.

    Maysa Safadi:

    Thank you, Nick. Thank you for inviting me.

    Nick Muldoon:

    So, Maysa's on today. We're going to explore Maysa's journey on her career to this point, and I think one of the things that interests me in Maysa's journey is she's come from a fairly patriarchal society in the Middle East, and has overcome a lot of odds that some of her peers didn't overcome, and she's managed to come to Australia, start a family in Australia, has three beautiful children and is an engineering manager after spending so many years as a software engineer. So, Maysa, I'd love to learn a little bit about the early stages of your life and how you got into university.

    Maysa Safadi:

    I was born and raised in United Arab Emirates. I am one of nine. I have three brothers and five sisters. I'm the middle child actually. Dad and mom, they were very focused on really raising good healthy kids and more important is to educate all of their kids regardless if they are boys or girls. Started my education at schools there. When I graduated from high school, I end up getting enrolled in a college like what you call it here in Australia, TAFE.

    Education in United Arab Emirates, it's not free. Being one of nine and having that aim and goal for my father to educate all of us. When it comes to education, it was two factors that play big part of it. Can dad afford sending me to that college or university? and then after I finish, will I be able to find a job in that field? One of my dream jobs, I remember growing up I wanted to be a civil engineer, and I remember my older brother, he's the second, was telling me it's good that you want to study civil engineering. Remember, you will not be able to find a job.

    Nick Muldoon:

    Tell me why.

    Maysa Safadi:

    United Arab Emirates, it's male dominated country. Civil engineering is a male dominated industry. If you are going to look for a job after a graduation, it is pretty much given to males and Emirati males first. So, kind of it needs to go very down in the queue before it gets to me, and to be realistic, sometimes you give up your dreams because you know that you are not going to have a chance later in life.

    Nick Muldoon:

    Oh, my gosh, this is demoralizing.

    Maysa Safadi:

    Unfortunately.

    Nick Muldoon:

    Okay,

    Maysa Safadi:

    So, the decision for me to get to engineering, it was, again, I couldn't really go to university because it was too expensive. My older sister had a friend who told her about this institute that they are teaching computers. When it came to mom and dad, they really told us, "Do whatever you want, study whatever you want, it is you who is going to basically study that field and you need to like it and you need to make sure that you can make the most of it." So, with that institute, it was reasonably okay for my dad to pay for my fees and they were teaching computers. I thought, "Yeah, all right, computers, it is in science field, right? I can't maybe study civil engineering, but I'm really very interested to know more about computers."

    Nick Muldoon:

    Similar, close enough.

    Maysa Safadi:

    Close enough. I end up getting enrolled and I remember the very first subject was fundamentals of computers or computer fundamentals, something like this, and I thought, "Yeah, all right, that is interesting," and I did really finish my education from there. After two years I ended up getting a diploma in computer science.

    Nick Muldoon:

    So, was this a unique situation for you or were most of your girlfriends from high school also going on to college?

    Maysa Safadi:

    It's unique actually, unique to my family. I'm not saying it's rare, you will find other families doing it, but it's not common. It is unique because, yes, most of the girls, if not all they go to school, it's compulsory in United Arab Emirate, but very small number of them pursue higher education. Pretty much girls, they end up finishing school and the very first chance to get married, they end up getting married and starting their own family. I remember-

    Nick Muldoon:

    And you've chosen a different path because-

    Maysa Safadi:

    Oh, yeah.

    Nick Muldoon:

    ... yes, you have a family today obviously, but you established your career, you didn't finish school and get married.

    Maysa Safadi:

    I think I really give so much credit to mom and dad in that sense. They told us education is more important than starting a family or getting married. They said, "Finish your degree, finish your education, then get married." The other thing they said, "Do not even get married while you are studying because for sure you won't be able to finish it. Maybe because your husband wouldn't want you to finish it. Maybe you will become so busy with the kids and you will put it back." I remember actually so many times with my older sisters when someone, it's traditional marriage there, when some people come and propose to marry or to propose for their hands, my dad always used to say, "No, finish your education first."

    Nick Muldoon:

    So, this is interesting because I think your eldest was born when you went and actually continued education and got your master's, is that correct?

    Maysa Safadi:

    Yes. I got diploma in computer science. However, I always wanted a bachelor degree. I knew that there is more to it. I fell in love with computing but I wanted more, and always I had that perception in mind, "If I'm going to get a better opportunity, then I have to have a better certificate or education." So, I thought getting a bachelor degree is going to give me better chances. I was working in United Arab Emirates and saving money, and Wollongong University had a branch there in Dubai. So, I had my eyes on finishing my degree there. Eventually I end up enrolling at Wollongong University, Dubai campus, to get my bachelor degree in computer science.

    Nick Muldoon:

    So, just for folks that are listening along, Wollongong is the regional area of Australia where Maysa and I and many of our team live. So, University of Wollongong is the local Wollongong University that has a branch in Dubai.

    Nick Muldoon:

    So you were with University of Wollongong doing this bachelor degree, and how did you make the transition and move to Australia?

    Maysa Safadi:

    When I was studying at Wollongong University, Dubai campus, and was working at the same time to be able to pay the fees, I met my husband at work, and happened that he has a skilled migrant visa to come to Australia, coincident. So, I was thinking, "All right, he is going to go to Australia, he is a person that I do really see spending the rest of my life with. So, how about if I transfer my papers to Wollongong University here in Australia, finish my degree from here, while he gets the chance to live in the country, and then we can make our minds. 'Is it a place for us to continue our life here?' If not, it was a good experience. If good, that is another new experience and journey that we are going to take." So, we end up coming to Australia. I finished my degree from here.

    Nick Muldoon:

    What did you find when you arrived at Australia? How was it different from United Arab Emirates? How was it different for women? How was it different for women in engineering given what your brother had said about civil engineering in Dubai?

    Maysa Safadi:

    I had a culture shock when I came to Australia. Yes, I was in a country that.... male-dominated country, third world country, no opportunities for females, to a country where everything is so different. The way of living, the communication, the culture, everything was so different. When it comes to engineering, because I didn't really finish my degree in United Arab Emirate, so I didn't even get the chance to work in engineering though. However, knowing about the country and knowing about the way they take talents in, I knew I had slim chances. Now, coming to Australia and to finish my degree at the university, it was challenging. Someone from the Middle East, english is second language, being in computer degree where looking around me, "My god, where are the girls? I don't really see many of them around." And then, yeah, getting into that stereotype of industry or of a field where it is just only for males.

    Nick Muldoon:

    Yeah, so a bit of a culture shock coming across. I guess fast forward, you've spent a decade in software engineering and then progressing into engineering leadership. What was the change and how did you perceive the change going from a team member to a people leader?

    Maysa Safadi:

    I graduated from Wollongong University and I end up getting a job at Motorola as a graduate software engineer. In the whole team there was three females.

    Nick Muldoon:

    How big was the team?

    Maysa Safadi:

    How big was the team? It was around 20.

    Nick Muldoon:

    Okay.

    Maysa Safadi:

    Yep. There was the network team which had, I can't remember how many, but it was a different team. The team I was in, it is development team, and there was three girls in there, one of them another graduate that end up coming to the program and one that started a year before. Interesting, these two females, they are not in IT anymore. I really loved the problem solving, I really loved seeing the outcome of my work in people's hands because I was developing features for mobile phones. So, all was in mind then as an IC, how to become better at my work, how to learn more, how to prove myself to everyone that I'm capable as much as any other male in the team.

    Nick Muldoon:

    Do you think, Maysa, that that's something that you've had to do throughout your career to prove yourself?

    Maysa Safadi:

    Yes, yes. It's a tough industry. Really not seeing so many females it makes it hard because you look for role models that makes you think, "Oh, she made it. I can make it. If she's still in there, then I can learn from her." I missed all of that. I never had another mentor in my career or having even a female manager in all of the jobs I had before. So, always I was dealing with males, always I was trying to navigate my way to show them the different perspective I can bring. Even the subtle interactions I used to have with them giving me that, "You are not capable enough. You are not there yet. This is our territory. Why are you here?" All of these things, it does really, without you think about it, it does really sink your self-esteem and the self-worth when you are in industries like this. Yeah.

    Nick Muldoon:

    So, I'm conscious, you know are in this position now, you've kind of talked about you can't be what you can't see. If you can't see a woman that's a people leader and you're not reporting to one, then it's hard to see how you can become that. But, here you are, you have become that, and for our team here, you are one of the women leaders in the company, which is fantastic. So, I guess, what are the sorts of activities that you are undertaking to try and be present and be visible that you can be a woman people leader in the engineering field. I think it was earlier last month perhaps that you were at WomenHack in Sydney.

    Maysa Safadi:

    Yes, I've been-

    Nick Muldoon:

    What's WomenHack?

    Maysa Safadi:

    Okay. WomenHack, it is organization to bring diverse talented women intake together, to support them, to educate them, and not just only that, to try to connect them with other companies that they appreciate diversity and inclusion, and basically try to recruit... Pretty much, it is finding opportunities for women in tech, in companies that they do value the diversity.

    Nick Muldoon:

    Okay. So, I think it's interesting, I see these parallels here between your mom and dad that kind of went out on a limb and extended themselves financially to get six girls through a college and university education in the Middle East, and they were doing something that was perhaps fairly progressive at the time. You said it wasn't common. It sounds like WomenHack is bringing together more progressive companies these days, that are creating opportunities for women to get into leadership or even to accelerate their careers.

    Maysa Safadi:

    Yes, it is so pleasing to see the change that has happened over the years. When I reflect back in 2000, when I graduated and end up working in IT, and all of the behaviors, there was no knowledge or there was no awareness how much diversity is important, and they were not even aware that really females are really quitting the field or not that many females enrolls in the first place in degrees like computing or engineering. Even education through the school, no awareness was there. Then you see now the progress that is happening, more awareness is during school. Universities, they are trying to make the degrees or the fields more inviting for females and diversity. They are trying to bridge the gaps. So, many companies that are taking action to make it easier for females to be in the field and to progress in the field.

    So, WomenHack, there are so many other groups like Women in Tech, there are so many companies that are allies to females in tech as well, where they are trying to really support and make their voice heard by other companies. Is as well all of the research and the science, are really proving that having diversity in teams, it is going to be more beneficial for the companies, for the teams, to have more engaging teams having these differences. So, yeah, there is a lot of awareness happening at the moment, and so many companies are trying to do something about it. I wish if that was early on.

    Nick Muldoon:

    Earlier in your career.

    Maysa Safadi:

    Earlier in my career, yes. So, many times I felt so isolated. So many times I was sitting back and saying, "Is it worth the fight?" Why do I have to work always twice as hard, to just only prove that I'm capable? Why does it have to be this way? Why I'm not equal?" That what actually made me change my career from IC to people leader. I didn't want to put other females... Being people leader wasn't just only for females, it was for me to voice, to be able to help pretty much. People leader to be able to help anyone in the field regardless if they are males or females. Moreso is to lead by example, is to be a role model for others, is to show others that if I can make it, then definitely you can as well, is to provide the support, it's to build that trust.

    Nick Muldoon:

    So, how can we, as an industry, I guess, how do we change... I'm reflecting on Iran at the moment, and the activities that have taken place over the last 60 days in particular, but really just more media coverage for hundreds of years of oppression of women. What do you hope, you being a people leader, a woman that's come from the Middle East, what do you hope for these young women and girls in our Iran over their trajectory? If we're still making a journey here in Australia, in a male dominated industry, what sort of hope do you have over the 20 years from here to 2040, for these women that are in the Middle East today and still haven't found a progressive society?

    Maysa Safadi:

    Politics. It's the game of power. Really hoping is the awareness to get there for these females in locked countries to know that there are better opportunities for them. They need to be stronger, they need to support each other, they need to empower each other. As much as it is easy said, it's not that easy done. However, all of that frustration that is built in them, it is surfacing from time to time. I'm really hoping for Iranian women, not just only Iranians, I'm really hoping for every woman in the world, regardless if it is a third world country or even if it is advanced country like Australia, is to always feel that they are worthy, is always to feel that they can have a voice, they can be part of life, and they are doing meaningful things.

    Now, if they are raised in a way that always being told you are second, always being told you role only to get married and raise family, they will believe it themselves. So, it needs to come from women like us, leading by example, being role models, sending the awareness. Really media, we need to use the media very well so we can get to these people who are really locked in their countries now thinking that this is normal. It a lot of work needs to happen.

    Nick Muldoon:

    Well, that's an interesting observation. It is normalized for them, isn't it? So, look, reflecting on my own upbringing, I remember that my parents would always say you can achieve anything you put your mind to, but I could open up the newspaper, I could look on TV and I could see a host of people that were people that look like me, that is white males that were Australian, that were successful in business, and so I believed that I could do and be whatever I wanted to do and be. So, I guess, how do we get this message out? How do we tell your story more broadly to get this message out? That you can do whatever you put your mind to, you can achieve whatever you hope to achieve. There's something interesting for me to reflect on about the media piece that you're talking about.

    Maysa Safadi:

    Yeah, and I think the countries that they are advanced, the countries that they are really recognizing women more and more, they are more responsible in sending that awareness. They have to do more. It is basically, yeah, media, it is such an important thing. This is what people read everyday or watch everyday.

    Nick Muldoon:

    I guess, I'm conscious, like we're talking about half a world away in the Middle East, but you're actually involved in a community group here at home. What's that group that you're involved in and how's that helping women?

    Maysa Safadi:

    Yeah, I'm a board member for organization called Women Illawarra. It is run by women, for women. Basically this organization is to help women in domestic violence, it's basically to set them in the right path. It gives them services and it does educate them and even help them with the counseling, with legal support so they can get out of these situations. Make them believe that they can be part of this society, that they are important voice in the society, in the community, and they can really contribute and make an impact. So, by providing this education and this support, it is empowering these women to take matters their hand, and again, to really set the path for their own life and their own success. They need to take control back again, and yeah, even help their kids see their moms that they are really doing the right thing.

    Nick Muldoon:

    It's this interesting thread that comes through in your entire life story and your journey, that mom and dad wanted you to have an education so that you were empowered to chart your own course in life-

    Maysa Safadi:

    Yes.

    Nick Muldoon:

    ... and here you are today, giving back to other women, trying to help them get an education and feel empowered so that they can chart their own course in life. I think that's fantastic. Thank you, Maysa.

    Maysa Safadi:

    Thank you.

    Nick Muldoon:

    What is your hope for women over the next 10 years? Because it sounds like we're on a trajectory, we're making progress in some countries, we're not making as much progress in other countries. What's your hope for 2030? What does it look like?

    Maysa Safadi:

    My hope for 2030, or my hope for... I really hope it is even five years, less than 10 years. My hope for 10 years is not to have conversations about how to reduce the gap between males and females, because by the 10 years time, that should be the way everyone operates. My hope in 10 years time is to have equal opportunities for anyone regardless what's their gender, background, language they speak, physical abilities, it needs to be equal, it needs to.... Equity, it is such an important thing. Giving exposure to the same opportunity, it is so important regardless what's your abilities. Stereotyping, I need that to get totally erased from the world.

    We are all a human, we did not really choose where we born, who our parents are, what our upbringing, what our financial situation, it wasn't our choice, why do we have to get penalized for it? We have responsibility toward the world to help everyone. We are social people, we really thrive when we have good connections and good bonds, we really need to tap into the things that makes us better. So, we have so many talents that we can use it to the benefits of the world. I know countries always going to have fights and politics, that everyone is looking for the power, that's not going to disappear. But us, as people part of this world, we really need to try to uplift and upskill everyone around us. I really hope for the females in all of the other countries to know that they are worth it, to know that they are as good as anyone else. They have the power, they don't realize how much strength and power they have. So, it comes from self-belief. Believe in yourself, and you will be surprised how much you will be able to achieve.

    Nick Muldoon:

    There you go. Believe in yourself and you'll be surprised with how much you are able to achieve. Maysa Safadi thank you so much for your time. Really appreciate it.

    Maysa Safadi:

    Thank you so much Nick. Thank you everyone.