Easy Agile Podcast Ep.21 LIVE from Agile2022!

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

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

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

‍

‍

‍

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

Be sure to subscribe, enjoy the episode 🎧

‍

‍

‍

Transcript

Jared Kells:

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

Jared Kells:

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

Jess Belliveau:

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

Jordan Simonovski:

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

Angad Sethi:

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

Jared Kells:

Nothing fancy!

Jess Belliveau:

Don't sell yourself short.

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

Podcast over! Tell us about observability.

Jess Belliveau:

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

Jess Belliveau:

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

Jordan Simonovski:

Okay!

Jess Belliveau:

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

Jared Kells:

Yep.

Jordan Simonovski:

Yep.

Jess Belliveau:

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

Jared Kells:

Sounds good.

Jess Belliveau:

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

Jordan Simonovski:

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

Jordan Simonovski:

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

Jared Kells:

I was going to say that!

Jordan Simonovski:

I'll try not to get too much into-

Jared Kells:

Runs out of memory!

Jordan Simonovski:

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

Jared Kells:

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

Jordan Simonovski:

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

Jordan Simonovski:

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

Angad Sethi:

Would it be fair to say-

Jared Kells:

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

Angad Sethi:

Oh, sorry Jared.

Jared Kells:

No you can-

Angad Sethi:

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

Jordan Simonovski:

Yeah.

Angad Sethi:

Oh.

Jess Belliveau:

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

Jess Belliveau:

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

Jordan Simonovski:

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

Jess Belliveau:

Oh, I didn't sign up for that!

Jordan Simonovski:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

Yeah, sorry, sorry, yeah! Go on.

Jordan Simonovski:

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

Jordan Simonovski:

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

Jared Kells:

What's an SLO?

Jordan Simonovski:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

That's what I really care about.

Jess Belliveau:

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

Angad Sethi:

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

Jordan Simonovski:

Yeah. I think that would come with good instrumenting-

Angad Sethi:

Good question?

Jordan Simonovski:

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

Jared Kells:

I think that we have to build-

Jordan Simonovski:

Yeah?

Jared Kells:

Oh, sorry Jordan.

Jordan Simonovski:

No, you go.

Jared Kells:

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

Jess Belliveau:

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

Jess Belliveau:

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

Jordan Simonovski:

I think NorthX.

Jess Belliveau:

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

Jordan Simonovski:

Your data structures remain the same.

Jess Belliveau:

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

Jared Kells:

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

Jess Belliveau:

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

Jordan Simonovski:

Observability suggests dashboards, right?

Jess Belliveau:

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

Jess Belliveau:

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

Jordan Simonovski:

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

Jess Belliveau:

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

Jordan Simonovski:

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

Jess Belliveau:

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

Angad Sethi:

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

Jordan Simonovski:

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

Jess Belliveau:

What does SLO stand for, Jordan?

Jordan Simonovski:

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

Jordan Simonovski:

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

Jordan Simonovski:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

Yeah sure.

Jess Belliveau:

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

Jordan Simonovski:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

In that state.

Jess Belliveau:

In that state, yeah.

Jordan Simonovski:

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

Jared Kells:

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

Jordan Simonovski:

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

Jess Belliveau:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

Maybe! Yeah.

Jess Belliveau:

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

Angad Sethi:

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

Jess Belliveau:

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

Jared Kells:

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

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

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

Jess Belliveau:

Yeah

Jared Kells:

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

Jess Belliveau:

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

Jared Kells:

All thanks!

Jess Belliveau:

Thanks for having us, yeah.

Jared Kells:

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

Jordan Simonovski:

Thanks everyone.

Angad Sethi:

That was [inaudible 00:41:55].

Jess Belliveau:

Tune in next week!

TL;DR

Henrik Kniberg, the agile coach behind Spotify's model, discusses how AI is fundamentally transforming software development. Key takeaways: AI tools like Cursor and Claude are enabling 10x productivity gains; teams should give developers access to paid AI tools and encourage experimentation; coding will largely disappear as a manual task within 3–4 years; teams will shrink to 2 people plus AI; sprints will become obsolete in favour of continuous delivery; product owners can now write code via AI, creating pull requests instead of user stories; the key is treating AI like a brilliant intern – when it fails, the problem is usually your prompt or code structure, not the AI. Bottom line: Learn to use AI now, or risk being left behind in a rapidly changing landscape.

Introduction

Artificial intelligence is fundamentally reshaping how software teams work, collaborate, and deliver value. But with this transformation comes questions: How do we maintain team morale when people fear being replaced? What happens to code quality when AI writes most of the code? Do traditional agile practices like sprints still make sense?

In this episode, I sit down with Henrik Kniberg to tackle these questions head-on. Henrik is uniquely positioned to guide us through this transition – he's the agile coach and entrepreneur who pioneered the famous Spotify model and helped transform how Lego approached agile development. Now, as co-founder of Abundly AI, he's at the forefront of helping teams integrate AI into their product development workflows.

This conversation goes deep into the practical realities of AI-powered development: from maintaining code review processes when productivity increases 10x, to ethical considerations around AI usage, to what cross-functional teams will look like in just a few years. Henrik doesn't just theorise – he shares real examples from his own team, where their CEO (a non-coder) regularly submits pull requests, and where features that once took a sprint can now be built during a 7-minute subway ride.

Whether you're a developer wondering if AI will replace you, a product owner looking to leverage these tools, or a leader trying to navigate this transformation, this episode offers concrete, actionable insights for thriving in the AI era.

About Our Guest

Henrik Kniberg is an agile coach, author, and entrepreneur whose work has shaped how thousands of organisations approach software development. He's best known for creating the Spotify model – the squad-based organisational structure that revolutionised how large tech companies scale agile practices. His work at Spotify and later at Lego helped demonstrate how agile methodologies could work at enterprise scale whilst maintaining team autonomy and innovation.

Henrik's educational videos have become legendary in the agile community. His "Agile Product Ownership in a Nutshell" video, created over a decade ago, remains one of the most-watched and shared resources for understanding product ownership, with millions of views. His ability to distil complex concepts into simple, visual explanations has made him one of the most accessible voices in agile education.

More recently, Henrik has turned his attention to the intersection of AI and product development. As co-founder of Abundly AI, he's moved from teaching about agile transformation to leading AI transformation – helping companies and teams understand how to effectively integrate generative AI tools into their development workflows. His approach combines his deep understanding of team dynamics and agile principles with hands-on experience using cutting-edge AI tools like Claude, Cursor, and GitHub Copilot.

Henrik codes daily using AI and has been doing so for over two and a half years, giving him practical, lived experience with these tools that goes beyond theoretical understanding. He creates educational content about AI, trains teams on effective AI usage, and consults with organisations navigating their own AI transformations. His perspective is particularly valuable because he views AI through the lens of organisational change management – recognising that successful AI adoption isn't just about the technology, it's about people, culture, and process.

Based in Stockholm, Sweden, Henrik continues to push the boundaries of what's possible when human creativity and AI capabilities combine, whilst maintaining a pragmatic, human-centred approach to technological change.

Transcript

Note: This transcript has been lightly edited for clarity and readability.

Maintaining Team Morale and Motivation in the AI Era

Tenille Hoppo: Hi there, team, and welcome to this new episode of the Easy Agile Podcast. My name is Tenille Hoppo, and I'm feeling really quite lucky to have an opportunity to chat today with our guest, Henrik Kniberg.

Henrik is an agile coach, author, and entrepreneur known for pioneering agile practices at companies like Spotify and Lego, and more recently for his thought leadership in applying AI to product development. Henrik co-founded Abundly AI, and when he isn't making excellent videos to help us all understand AI, he is focused on the practical application of generative AI in product development and training teams to use these technologies effectively.

Drawing on his extensive experience in agile methodologies and team coaching, Henrik seems the perfect person to learn from when thinking about the intersection of AI, product development, and effective team dynamics. So a very warm welcome to you, Henrik.

Henrik Kniberg: Thank you very much. It's good to be here.

Tenille: I think most people would agree that motivated people do better work. So I'd like to start today by touching on the very human element of this discussion and helping people maintain momentum and motivation when they may be feeling some concern or uncertainty about the upheaval that AI might represent for them in their role.

What would you suggest that leaders do to encourage the use of AI in ways that increase team morale and creativity rather than risking people feeling quite concerned or even potentially replaced?

Henrik: There are kind of two sides to the coin. There's one side that says, "Oh, AI is gonna take my job, and I'm gonna get fired." And the other side says, "Oh, AI is going to give me superpowers and give us all superpowers, and thereby give us better job security than we had before."

I think it's important to press on the second point from a leader's perspective. Pitch it as this is a tool, and we are entering a world where this tool is a crucial tool to understand how to use – in a similar way that everyone uses the Internet. We consider it obvious that you need to know how to use the Internet. If you don't know how to use the Internet, it's going to be hard.

"I encourage people to experiment, give them access to the tools to do so, and encourage sharing. And don't start firing people because they get productive."

I also find that people tend to get a little bit less scared once they learn to use it. It becomes less scary. It's like if you're worried there's a monster under your bed, maybe look under your bed and turn on the lights. Maybe there wasn't a monster there, or maybe it was there but it was kind of cute and just wanted a hug.

Creating a Culture of Safe Experimentation

Tenille: I've read that you encourage experimentation with AI through learning – I agree it's the best way to learn. What would you encourage leaders and team leaders to do to create a strong culture where teams feel safe to experiment?

Henrik: There are some things. One is pretty basic: just give people access to good AI tools. And that's quite hard in some large organisations because there are all kinds of resistance – compliance issues, data security issues. Are we allowed to use ChatGPT or Claude? Where is our data going? There are all these scary things that make companies either hesitate or outright try to stop people.

Start at that hygiene level. Address those impediments and solve them. When the Internet came, it was really scary to connect your computer to the Internet. But now we all do it, and you kind of have to, or you don't get any work done. We're at this similar moment now.

"Ironically, when companies are too strict about restricting people, then what people tend to do is just use shadow AI – they use it on their own in private or in secret, and then you have no control at all."

Start there. Once people have access to really good AI tools, then it's just a matter of encouraging and creating forums. Encourage people to experiment, create knowledge-sharing forums, share your own experiments. Try to role-model this yourself. Say, "I tried using AI for these different things, and here's what I learned." Also provide paths for support, like training courses.

The Right Mindset for Working with AI

Tenille: What would you encourage in team members as far as their mindset or skills go? Certainly a nature of curiosity and a willingness to learn and experiment. Is there anything beyond that that you think would be really key?

Henrik: It is a bit of a weird technology that's never really existed before. We're used to humans and code. Humans are intelligent and kind of unpredictable. We hallucinate sometimes, but we can do amazing things. Code is dumb – it executes exactly what you told it to do, and it does so every time exactly the same way. But it can't reason, it can't think.

Now we have AI and AI agents which are somewhere in the middle. They're not quite as predictable as code, but they're a lot more predictable than humans typically. They're a lot smarter than code, but maybe not quite as smart as humans – except for some tasks when they're a million times smarter than humans. So it's weird.

You need a kind of humble attitude where you come at it with a mindset of curiosity. Part of it is also to realise that a lot of the limitation is in you as a user. If you try to use AI for coding and it wrote something that didn't work, it's probably not the model itself. It's probably your skills or lack of skills because you have to learn how to use these tools. You need to have this attitude of "Oh, it failed. What can I do differently next time?" until you really learn how to use it.

"There can be some aspect of pride with developers. Like, 'I've been coding for 30 years. Of course this machine can't code better than me.' But if you think of it like 'I want this thing to be good, I want to bring out the best in this tool' – not because it's going to replace me, but because it's going to save me a tonne of time by doing all the boring parts of the coding so I can do the more interesting parts – that kind of mindset really helps."

Maintaining Code Quality and Shared Understanding

Tenille: Our team at Easy Agile is taking our steps and trying to figure out how AI is gonna work best for us. I put the question out to some of our teams, and there were various questions around people taking their first steps in using AI as a co-pilot and producing code. There are question marks around consistency of code, maintaining code quality and clean architecture, and even things like maintaining that shared understanding of the code base. What advice do you have for people in that situation?

Henrik: My first piece of advice when it comes to coding – and this is something I do every day with AI, I've been doing for about two and a half years now – is that the models now, especially Claude, have gotten to the level where it's basically never the AI's fault anymore. If it does anything wrong, it's on you.

You need to think about: okay, am I using the wrong tool maybe? Or am I not using the tool correctly?

For example, the current market leader in terms of productivity tools with AI is Cursor. There are other tools that are getting close like GitHub Copilot, but Cursor is way ahead of anything else I've seen. With Cursor, it basically digs through your code base and looks for what it needs.

But if it fails to find what it needs, you need to think about why. It probably failed for the same reason a human might have failed. Maybe your code structure was very unstructured. Maybe you need to explain to the AI what the high-level structure of your code is.

"Think of it kind of like a really smart intern who just joined your team. They're brilliant at coding, but now they got confused about something, and it's probably your code – something in it that made it confused. And now you need to clarify that."

There are ways to do that. In Cursor, for example, you can create something called cursor rules, which are like standing documents that describe certain aspects of your system. In my team, we're always tweaking those rules. Whenever we find that the AI model did something wrong, we're always analysing why. Usually it's our prompt – I just phrased it badly – or I just need to add a cursor rule, or I need to break the problem down a little bit.

It's exactly the same thing as if you go to a team and give them this massive user story that includes all these assumptions – they'll probably get some things wrong. But if you take that big problem and sit down together and analyse it and split it into smaller steps where each step is verifiable and testable, now your team can do really good work. It's exactly the same thing with AI.

Addressing the Code Review Bottleneck

Tenille: One of our senior developers found that he was outputting code at a much greater volume and faster speed, but the handbrake he found was actually their code review processes. They were keeping the same processes they had previously, and that was a bit of a handbrake for them. What kind of advice would you have there?

Henrik: This reminds me of the general issue with any kind of productivity improvement. If you have a value stream, a process where you do different parts – you do some development, some testing, you have some design – whenever you take one part of the process and make it super optimised, the bottleneck moves to somewhere else.

If testing is no longer the bottleneck, maybe coding is. And when coding is instant, then maybe customer feedback – or lack of customer feedback – is the bottleneck. The bottleneck just keeps moving. In that particular case, the bottleneck became code review. So I would just start optimising that. That's not an AI problem. It's a process problem.

Look at it: what exactly are we trying to do when we review? Maybe we could think about changing the way we review things. For example, does all code need to be reviewed? Would it be enough that the human who wrote it and the AI, together with the human, agree that this is fine? Or maybe depending on the criticality of that change, in some cases you might just let it pass or use AI to help in the reviewing process also.

"I think there's value in code review in terms of knowledge sharing in a large organisation. But maybe the review doesn't necessarily need to be a blocking process either. It could be something you go back and look at – don't let it stop you from shipping, but maybe go back once per week and say, 'Let's look at some highlights of some changes we've made.'"

We produce 10 times more code than in the past, so reviewing every line is not feasible. But maybe we can at least identify which code is most interesting to look at.

Ethical Considerations: Balancing Innovation with Responsibility

Tenille: Agile emphasises people over process and delivering value to customers. Now with AI in the mix, there's potential for raising some ethical considerations. I'm interested in your thoughts on how teams should approach these ethical considerations that come along with AI – things like balancing rapid experimentation against concerns around bias, potential data privacy concerns.

Henrik: I would treat each ethical question on its own merits. Let me give you an example. When you use AI – let's say facial recognition technology that can process and recognise faces a lot better than any human – I kind of put that in the bucket of: any tool that is really useful can also be used for bad things. A hammer, fire, electricity.

That doesn't have so much to do with the tool itself. It has much more to do with the rules and regulations and processes around the tool. I can't really separate AI in that sense. Treat it like any other system. Whenever you install a camera somewhere, with or without AI, that camera is going to see stuff. What are you allowed to do with that information? That's an important question. But I don't think it's different for AI really, in that sense, other than that AI is extremely powerful. So you need to really take that seriously, especially when it comes to things like autonomous weapons and the risk of fraud and fake news.

"An important part of it is just to make it part of the agenda. Let's say you're a recruitment company and you're now going to add some AI help in screening. At least raise the question: we could do this. Do we want to do this? What is the responsible way to do it?"

It's not that hard to come up with reasonable guidelines. Obviously, we shouldn't let the AI decide who we're going to hire or not. That's a bad idea. But maybe it can look at the pile of candidates that we plan to reject and identify some that we should take a second look at. There's nothing to lose from that because that AI did some extra research and found that this person who had a pretty weak CV actually has done amazing things before.

We're actually working with a company now where we're helping them build some AI agents. Our AI agents help them classify CVs – not by "should we hire them or not," but more like which region in Sweden is this, which type of job are we talking about here. Just classifying to make it more likely that this job application reaches the right person. That's work that humans did before with pretty bad accuracy.

The conclusion was that AI, despite having biases like we humans do, seemed to have less biases than the human. Mainly things like it's never going to be in a bad mood because it hasn't had its coffee today. It'll process everybody on the same merits.

I think of it like a peer-to-peer thing. Imagine going to a doctor – ideally, I want to have both a human doctor and an AI doctor side by side, just because they both have biases, but now they can complement each other. It's like having a second opinion. If the AI says we should do this and the doctor says, "No, wait a second," or vice versa, having those two different opinions is super useful.

Parallels Between Agile and AI Transformations

Tenille: You're recognised as one of the leading voices in agile software development. I can see, and I'm interested if you do see, some parallels between the agile transformations that you led at Spotify and Lego with the AI transformations that many businesses are looking at now.

Henrik: I agree. I find that when we help companies transition towards becoming AI native, a lot of the thinking is similar to agile. But I think we can generalise that agile transformations are not really very special either – it's organisational change.

There are some patterns involved regardless of whether you're transitioning towards an agile way of working or towards AI. Some general patterns such as: you've got to get buy-in, it's useful to do the change in an incremental way, balance bottom-up with top-down. There are all these techniques that are useful regardless. But as an agilist, if you have some skills and competence in leading and supporting a change process, then that's going to be really useful also when helping companies understand how to use AI.

Tenille: Are you seeing more top-down or bottom-up when it comes to AI transformations?

Henrik: So far it's quite new still. The jury's not in yet. But so far it looks very familiar to me. I'm seeing both. I'm seeing situations where it's pure top-down where managers are like "we got to go full-out AI," and they push it out with mixed results. And sometimes just completely bottom-up, also with mixed results.

Sometimes something can start completely organically and then totally take hold, or it starts organically and then gets squashed because there was no buy-in higher up. I saw all of that with agile as well. My guess is in most cases the most successful will be when you have a bit of both – support and guidance from the top, but maybe driven from the bottom.

"I think the bottom-up is maybe more important than ever because this technology is so weird and so fast-moving. As a leader, you don't really have a chance if you try to control it – you're going to slow things down to an unacceptable level. People will be learning things that you can't keep up with yourself. So it's better to just enable people to experiment a lot, but then of course provide guidance."

AI for Product Owners: From Ideation to Pull Requests

Tenille: You're very well known for your guidance and for your ability to explain quite complex concepts very simply and clearly. I was looking at your video on YouTube today, the Agile Product Ownership in a Nutshell video, which was uploaded about 12 years ago now. Thinking about product owners, there's a big opportunity now with AI for generating ideas, analysing data, and even suggesting new features. What's your advice for product owners and product managers in using AI most effectively?

Henrik: Use it for everything. Overuse it so you can find the limits. The second thing is: make sure you have access to a good AI model. Don't use the free ones. The difference is really large – like 10x, 100x difference – just in paying like $20 per month or something. At the moment, I can particularly strongly recommend Claude. It's in its own category of awesomeness right now. But that of course changes as they leapfrog each other. But mainly: pay up, use a paid model, and then experiment.

For product owners, typical things are what you already mentioned – ideation, creating good backlog items, splitting a story – but also writing code. I would say as a PO, there is this traditional view, for example in Scrum, that POs should not be coding. There's a reason for that: because coding takes time, and then as PO you get stuck in details and you lose the big picture.

Well, that's not true anymore. There are very many things that used to be time-consuming coding that is basically a five-minute job with a good prompt.

"Instead of wasting the team's time by trying to phrase that as a story, just phrase it as a pull request instead and go to the team and demonstrate your running feature."

That happened actually today. Just now, our CEO, who's not a coder, came to me with a pull request. In fact, quite often he just pushes directly to a branch because it's small changes. He wants to add some new visualisation for a graph or something in our platform – typically admin stuff that users won't see, so it's quite harmless if he gets it wrong.

He's vibe coding, just making little changes to the admin, which means he never goes to my team and says, "Hey, can you guys generate this report or this graph for how users use our product?" No, he just puts it in himself if it's simple.

Today we wanted to make a change with how we handle payments for enterprise customers. Getting that wrong is a little more serious, and the change wasn't that hard, but he just didn't feel completely comfortable pushing it himself. So he just made a PR instead, and then we spent 15 minutes reviewing it. I said it was fine, so we pushed it.

It's so refreshing that now anybody can code. You just need to learn the basic prompting and these tools. And then that saves time for the developers to do the more heavyweight coding.

Tenille: It's an interesting world where we can have things set up where anyone could just jump in and with the right guardrails create something. It makes Friday demos quite probably a lot more interesting than maybe they used to be in the past.

Henrik: I would like to challenge any development team to let their stakeholders push code, and then find out whatever's stopping you from doing that and fix that. Then you get to a very interesting space.

Closing the Gap Between Makers and Users

Tenille: A key insight from your work with agile teams in the past has been to really focus on minimising that gap between maker and user. Do you think that AI helps to close that gap, or do you think it potentially risks widening it if teams are focusing too much on AI predictions and stop talking to their customers effectively?

Henrik: I think that of course depends a lot on the team. But from what I've seen so far, it massively reduces the gap. Because if I don't have to spend a week getting a feature to work, I can spend an hour instead. Then I have so much more time to talk to my users and my customers.

If the time to make a clickable prototype or something is a few seconds, then I can do it live in real time with my customers, and we can co-create. There are all these opportunities.

I find that – myself, my teams, and the people I work with – we work a lot more closely with our users and customers because of this fast turnaround time.

"Just yesterday I was teaching a course, and I was going home sitting on the subway. It was a 15-minute subway ride. I finally got a seat, so I had only 7 minutes left. There's this feature that I wanted to build that involved both front-end and back-end and a database schema change. Well, 5 minutes later it was done and I got off the subway and just pushed it. That's crazy."

Of course, our system is set up optimised to enable it to be that fast. And of course not everything will work that well. But every time it does, I've been coding for 30 years, and I feel like I wake up in some weird fantasy every day, wondering, "Can I really be this productive?" I never would have thought that was possible.

Looking Ahead: The Future of Agile Teams

Tenille: I'd like you to put your futurist hat on for a moment. How do you see the future of agile teamwork in, say, 10 to 15 years time? If we would have this conversation again in 2035, given the exponential growth of AI and improvements over the last two to three years, what do you think would be the biggest change for software development teams in how they operate?

Henrik: I can't even imagine 10 years. Even 5 years is just beyond imagination. That's like asking someone in the 1920s to imagine smartphones and the Internet. I think that's the level of change we're looking at.

I would shorten the time a little bit and say maybe 3 or 4 years. My guess there – and I'm already seeing this transfer happen – is that coding will just go away. It just won't be stuff that we humans do because we're too slow and we hallucinate way too much.

But I think engineering and the developer role will still be there, just that we don't type lines of code – in the same way that we no longer make punch cards or we no longer write machine code and poke values into registers using assembly language. That used to be a big part of it, but no longer.

"In the future, as developers, a lot of the work will still be the same. You're still designing stuff, you're thinking about architecture, you're interacting with customers, and you're doing all the other stuff. But typing lines of code is something that we're gonna be telling our kids about, and they're not gonna believe that we used to do that."

The other thing is smaller teams, which I'm already seeing now. I think the idea of a cross-functional team of 5 to 7 people – traditionally that was considered quite necessary in order to have all the different skills needed to deliver a feature in a product. But that's not the case anymore. If you skip ahead 2 or 3 years when this knowledge has spread, I think most teams will be 2 people and an AI, because then you have all the domain knowledge you need, probably.

As a consequence of that, we'll just have more teams. More and smaller teams. Of course, then you need to collaborate between the teams, so cross-team synchronisation is still going to be an issue.

Also, I'm already seeing this now, but this concept of sprints – the whole point is to give a team some peace of mind to build something complex, because typically you would need a week or two to build something complex. But now, when it takes a day and some good prompting to do the same thing that would have taken a whole sprint, then the sprint is a day instead. If the sprint is a day, is there any difference between a sprint planning meeting and a daily standup? Not really.

I think sprints will just kind of shrink into oblivion. What's going to be left instead is something a little bit similar – some kind of synchronisation point or follow-up point. Instead of a sprint where every 2 weeks we sit down and try to make a plan, I think it'll be very much continuous delivery on a day-to-day basis. But then maybe every week or two we take a step back and just reflect a little bit and say, "Okay, what have we been delivering the past couple of weeks? What have we been learning? What's our high-level focus for the next couple of weeks?" A very, very lightweight equivalent of a sprint.

I feel pretty confident about that guess because personally, we are already there with my team, and I think it'll become a bit of a norm.

Final Thoughts: Preparing for the Future

Henrik: No one knows what's gonna happen in the future, and those who say they do are kidding themselves. But there's one fairly safe bet though: no matter what happens in the future with AI, if you understand how to use it, you'll be in a better position to deal with whatever that is. That's why I encourage people to get comfortable with it, get used to using it.

Tenille: I have a teenage daughter who I'm actually trying to encourage to learn how to use AI, because I feel like when I was her age, the Internet was the thing that was sort of coming mainstream. It completely changed the way we live. Everything is online now. And I feel like AI is that piece for her.

Henrik: Isn't it weird that the generation of small children growing up now are going to consider this to be normal and obvious? They'll be the AI natives. They'll be like, "Of course I have my AI agent buddy. There's nothing weird about that at all."

Tenille: I'll still keep being nice to my coffee machine.

Henrik: Yeah, that's good. Just in case, you know.

---

Thank you to Henrik Kniberg for joining us on this episode of the Easy Agile Podcast. To learn more about Henrik's work, visit Abundly AI or check out his educational videos on AI and agile practices.

Subscribe to the Easy Agile Podcast on your favourite platform, and join us for more conversations about agile, product development, and the future of work.

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

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

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

We hope you enjoy the episode!

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

Transcript:

Hayley Rodd:

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

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

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

Tony Camacho:

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

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

Hayley Rodd:

Wow.

Tony Camacho:

And teams.

Hayley Rodd:

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

Tony Camacho:

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

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

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

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

Hayley Rodd:

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

Tony Camacho:

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

Hayley Rodd:

Yeah, okay.

Tony Camacho:

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

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

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

Hayley Rodd:

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

Tony Camacho:

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

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

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

Hayley Rodd:

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

Tony Camacho:

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

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

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

Hayley Rodd:

Wow.

Tony Camacho:

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

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

Hayley Rodd:

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

Tony Camacho:

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

Hayley Rodd:

Looking off camera, avoiding me. Yeah.

Tony Camacho:

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

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

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

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

Hayley Rodd:

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

Tony Camacho:

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

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

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

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

Hayley Rodd:

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

Tony Camacho:

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

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

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

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

Hayley Rodd:

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

Tony Camacho:

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

Hayley Rodd:

Please

Tony Camacho:

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

Hayley Rodd:

Never.

Tony Camacho:

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

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

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

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

Hayley Rodd:

Beautiful.

Tony Camacho:

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

Hayley Rodd:

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