Here's Why "Agile" Isn't Working For You with Jon Fazzaro

Unlock the true potential of Agile with Jon Fazzaro, a veteran full-stack software coach, who joins me to dissect the reasons behind its faltering effectiveness in today's corporate world. Together, we challenge the rigidity that Agile methodologies have acquired over time, urging a return to its experimental roots. By listening to our exchange, you'll gain insights into revitalizing the adaptable, learning-centric spirit of Agile, and understand why agility in software development is less about following a plan and more about evolving through continuous learning and adaptation.

Through the lens of personal experiences and discussions on modern work systems, we tackle the tough questions around the value of knowledge work and the counterproductive nature of traditional success metrics. Hear how embracing a culture of small, iterative progress and learning from failures, rather than banking on large, uncertain gambles, can pave the way for more meaningful achievements in the realm of software development. This conversation is a clarion call to foster environments that value psychological safety, where making and learning from mistakes is not only accepted but celebrated, setting the stage for genuine innovation.

Connect with Jon on LinkedIn:
https://www.linkedin.com/in/jonfazzaro/

Connect with Jon at Industrial Logic:
https://www.industriallogic.com/people/fazzaro/

Join the Alliance using the link below!

Transcript

Mark Metze: 0:06

Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Welcome back to the Agile Within. This is Mark Metz. I want to welcome our guest, a full-stacked software coach from Fort Wayne, indiana, john Fazzaro. Welcome, john Howdy. Mark, how are you, hey? Great Thanks for joining us. John, if I'm coming to Fort Wayne, indiana, for a day, what are you telling me I've got to do?

Jon Fazzaro: 1:02

It's a little cliche, I think, for Fort Wayne, but that's kind of the point of the question. But you'd have to go to Coney Island and this is an old hole-in-the-wall hot dog place down on Main Street. But the trick is, don't order a hot dog. You got to get the hamburger. The hamburger Because they have this Coney sauce, this chili sauce that they put on top of the dogs, but they actually marinate the burger meat in the sauce. Wow, and it's like the worst thing. You will have a heart attack, it'll be a heart attack right.

Jon Fazzaro: 1:44

Yeah, yeah, yeah, exactly, it's worth it. You go to Coney Island get the burgers. We'll walk in Promenade Park because it's beautiful now.

Mark Metze: 1:51

Oh, neat, cool, All right. So our title for our episode today is here's why Agile Isn't Working For you. So, john, tell us, why isn't Agile working for us?

Jon Fazzaro: 2:05

Well, of course, mark, it's because Agile is dead? I don't think so. Oh, of course it's been dead, right? Yeah, well, I'm going to qualify that a little bit. I have to say that I've been seeing the Agile is dead flavor of blog posts and podcast episode and conference talk Since I think it was like 2014, 2015,. I started hearing that I've been doing the nerd thing professional nerd thing for about 20 years and the Agile thing really got on my radar about 15 years ago. But Agile is.

Jon Fazzaro: 2:44

It would be more proper to say Agile is still dead, agile's been dead, and when you look at that, I'm going to go grammar nerd on you for a second. But when you look at a sentence like that, agile is dead or Agile is still dead, agile, in that case, is a noun and this I feel like there's sort of there's a grammar nerd thing here, but I think it's sort of the key of the whole problem is is trying to take an idea like agility, like the adjective Agile, and distilling it into a thing, a noun, that holds still. That's sort of an oxymoron, and I would say also that words, as much as grammar nerds like me want, want there to be a proper. You know this is a word and this isn't. Let's take the case of irregardless right. You know it's classic case of that's not a real word, but people say it all the time.

Jon Fazzaro: 3:49

Well, language is what people say, right? So? And words take on the meaning that people use them for as much as as much as the Oxford English nerds want to not have that happen. So what you and I, as as Agilists, might want Agile to mean is not what it means most of the time. When people in our industry say it and I think that's where I come at this, in terms of Agile being dead and Agile not working for you it's that what people call Agile is a thing that doesn't work.

Mark Metze: 4:31

Question for you when we say Agilists, who makes up that group of Agilists?

Jon Fazzaro: 4:38

If we're making agility the focus of our work and our conversation, it's likely because we have seen what it was intended to mean from the manifesto days, from the lightweight process days. I guess what I'm trying to draw a contrast between is that it's anything like what it means these days, especially in larger corporations, is anything but a lightweight process. Agile means that we use Jira and we have it configured by this consultant in a certain way. The Scrum Master is somebody who runs around and bangs on everybody's desks to keep their tickets up to date. That's a fun job.

Mark Metze: 5:23

I don't believe you. You caught the sarcasm. I'm asking a rhetorical question Is it possible, when you have teams, and specifically software teams that I'm referring to here is it possible to have teams where you have some members, or Agilists and other members, or not?

Jon Fazzaro: 5:41

Yeah, I'm sure it happens all the time. This is fundamentally software agility. It's a point of view, it's a mindset. There's another cliche the mindset. Really we can't just say it's a mindset. And here are these 12 principles and four values. It comes down to something smaller than that. If you think about what's in the Agile Manifesto, that's a document with a point of view. It's got even in those things that they call principles. They aren't first principles. You can ask why about them a number of times. To steal the five-wise technique from Lean, you can ask why about each of those principles and get to a first principle that's behind all of them. The essence of it is that the thing you're working on doesn't have any value. That's because you're working on it. In present tense, what defines knowledge work is that we don't know what's going to work. We don't know that we're right, we're trying something and we don't know if it's valuable until it's done and in use by the person or people that we're doing it for.

Mark Metze: 7:12

In the spirit of agility, we think about experimentation and not doing big upfront planning and wasting time with planning that we could actually be doing. I'd be very interested to hear some stories from you on some teams that were very apprehensive to experiment and maybe how they evolved over time to be able to be comfortable with experimenting and what had to be in place. What environment qualities were there to make them comfortable with experimenting with they weren't comfortable before?

Jon Fazzaro: 7:52

Sure, yeah, I think there's that comfort factor. It comes from the shared belief. I think that it's baked into our organizations that we need to have faith in the work that's given to us, like if your boss or your project manager hands you something and says do this. There's not a strong, there's not a strong Instinct to question. So I was with. I ended up sort of sitting in with a team I wasn't coaching them, but this was a mobile development team and they had their. Their manager was beside himself because there was, they were, they were slow it Bluntly, he was having a lot of that's what agility is about is about Moving faster.

Mark Metze: 8:41

Right, that's what. That's why we do agile stuff to get things done and, yes, we're not at risk.

Jon Fazzaro: 8:47

Yeah, you know, I always want to. I always want to be careful about Straying into the territory of what Jeff Jeff Sutherland's book you know, twice the work in half the time.

Mark Metze: 8:59

No, I saw work in half the time.

Jon Fazzaro: 9:00

That's right, yeah, it's. And especially the use of the word work there. You know, to my point, work is not inherently valuable. We don't know if it's valuable until so. Why do we want to do twice the amount of it in half the time? Well, we, I mean maybe twice the value in half the time, but I don't know. I Don't know. I'm just picking on Jeff, so.

Jon Fazzaro: 9:23

So, anyway, there's a mobile development team that just couldn't go fast enough, and it wasn't. These people were not lazy, you might imagine. They were. You know, they were working hard, they were putting extra hours, but the business was not like. They were like you know where the hell's it? This feature was supposed to be in the app like three months ago and it would just drag out. And this manager was just, he was a good dude, he was beside himself because he had been kind of called onto the carpet by his, by the you know Executives and saying you know you can't turn this team around. We're gonna have to outsource that whole function because this is costing us too much and you know that's a very down the gauntlet.

Jon Fazzaro: 10:05

Yeah, yeah, really, that's a different threat, right, exactly, and we've been a very real like this would not only be, you know, a black mark on him, but it's you know, obviously, several people's careers that he was close to and cared about. So it was very real and you know this, this new. Yet another feature that they needed came through, and it was that they had to add the subscription sign up to To the to their mobile apps. They already had a subscription sign up on the on their web app, but so he brings the Stories to them in a meeting and, to their credit, they they swarmed on it and and estimated like on the spot.

Jon Fazzaro: 10:48

It was a really, really great exhibit of self-organizing behavior. It was really cool To watch them sort it all out. But they came back and said this is like a month and a half of work and he puts his head in his hands. He's like that's not gonna work. They need it live within the week. And so I'm kind of sitting over there in the corner and he's always he's always kind of Helped me at arm's length, this guy, because he wasn't he wasn't into the whole agile thing. He's misinterpreted some things that I've said as and, in fact, one time, you know, confided in me that he saw me as a zealot, but I wasn't in contact with the real world, but he was. You know he was desperate, so he had me in in the meeting. I saw a waiter.

Mark Metze: 11:31

To help out with it.

Jon Fazzaro: 11:32

But desperate times call right yeah, it's okay, we got a call Geez, calling fissaro in. But so I there's like this thick silence after he's, after he said this, because, like what do you say to that? It's a month and a half of work, they wanted in a week. And so they start going down the path of like well, we're gonna have to come in on the weekends. And and I'm like, okay, wait a second, why? And he's like, why what? He's our? I could tell he's already irritated with me and I was like why did they need it live within the week? And he's like because that's, that's our SLA, that's because you know that this is what we have to do for the business, that's, this is what we do. And I'm like that doesn't, that doesn't make any sense. They have a reason for demanding that they're not just being, you know, arbitrary about that. If this, the, if it's that important.

Jon Fazzaro: 12:22

There's a story here, you know. So, roger, the manager didn't know, but a there was a younger product product manager who had heard that basically our partnership with, let's say, acme, who's with a company we're fronting this, you know, subscription sale or our partnership was in trouble because our numbers weren't what they had promised them to be and that the play was that most of our users were on Android, not web users or even iPhone users. So they handed this off to the mobile team, which does both iOS and Android, and it said you know, okay, if we put this in front of our Android users, our subscription Numbers are gonna jump right. So right there, I hear the hypothesis. Right, this is a thing we don't know, it's gonna happen, but here's the play, here's the experiment, mm-hmm. So I rephrased it like that and I could see, I could see lights going on around the room and one of the iOS engineers, of course, piped up and said well, this doesn't have to. If Android is really the thing, then that saves us like two weeks of two weeks off of that estimate.

Jon Fazzaro: 13:27

And, of course, they had Roger's attention. Like now, we're talking right. So, yeah, yeah, a fellow you know an Android developer who was it was a creative guy, but he said hey, you know, we already have the form on the web. We don't have to go through all the work to build the form in Android. What if we just had a button in the Android app that opened a browser to the web form? Of course, they had that live within like two or three days, pretty good. They and and turns out they were right. The numbers started coming back up and you know they did the anything but twice the work they did. They did a lot less. They cut out all the work because now you know, as soon as they understood the full story of what was needed, they could target that much more directly.

Mark Metze: 14:12

So that is a great example of maximizing the work not done.

Jon Fazzaro: 14:17

And, mark, I think that's the whole game. Honestly, the whole system of work that we grew up in came from a time when we really needed people to put down their farming tools, come to the city and get in line at a factory and help build the 20th century, which that was the right problem to solve at that time. But it required teaching everybody that what was valuable, what work looked like, was showing up on time and following instruction. Right, you had to build this gigantic machine out of people. That was the problem to solve in the 20th century and, you know, prior to that, the industrial era, yeah, but with knowledge work, our work isn't necessarily valuable. We don't know it's going to be valuable until and after it's delivered. And yet we still have this tremendous faith in the work that we're handed because we were taught through the structures of work that were built up before that work is inherently valued. Right, we're taught to adhere to documented requirements. We end up in process separating knowledge from work.

Mark Metze: 15:22

Okay.

Jon Fazzaro: 15:23

I'm with you the biggest waste in all of knowledge work, I think, is you need to keep that knowledge, you need to keep the story with the user story, john.

Mark Metze: 15:32

I was a developer from the mid 90s through the later 2000s. This was before the days of being able to work remotely. You came into the office and you had your work computer at the office and that's where you did your work. Honestly, there were times that I would almost literally spend the night at the office. You know I would leave at two, three, four o'clock in the morning and that was rewarded. Was it really what I was able to accomplish? Or was it the amount of hours and how hard I worked?

Mark Metze: 16:05

And admittedly, this was a time when, as a consultant, your company was paid based on the hours that you charged towards the project, right. And so the running joke was, when you came into the office, there was a little marquee board there and it had an employee of the month there and it's like oh, employee of the month, ah, that person. So they work the most hours in the month. That's what that means. They make the most money for the company just due to the sheer number of hours and dollars. That they're nothing about outcomes, nothing about how they're making the customers or the user's life better. It was just a billing exercise.

Jon Fazzaro: 16:46

Yeah Well, and I think it's just on the topic of consulting that the sooner you and your consulting firm whoever that is can get away from billing hourly, the better off you are. I mean, I guess my question is which of those is easier to measure the amount of hours you put in or the value you delivered, the results? And that's the problem is, we just go for the easy thing to measure and then that gets gained. So you've got violating good hearts law all over the place. That's the one where, if you create a target out of a measure, it ceases to be a good measure. You no longer measure. It's like if we're targeting a certain number of hours, then that's what's going to happen. If we're targeting a certain amount of code coverage, people will fall all over themselves to make that happen at the expense of other important things.

Mark Metze: 17:45

Yep, there's a question I want to ask you and see if this resonates with you, john, regarding to why Agile isn't working for us, and it's related to making small bets instead of making large bets, meaning, when we have these large systems like the situation you explained before, we could consider that maybe a medium-sized bed or possibly a large bet, but you said it was going to take them a month, a month and a half, to be able to deliver. I would consider that a medium or a large-sized bet. The team was able to come up with a small bet that if you didn't win that bet, then it's not like okay, I don't have any more money to work with game over. How do we promote that with our organizations? That mindset?

Jon Fazzaro: 18:37

We have to talk about this faith that we have in the work Instead of having faith in the people that you work with, but stop having faith in whatever idea somebody with a higher salary wrote down as the thing we have to do we have to talk about the problem that we're solving, not about the solution.

Jon Fazzaro: 18:55

I think there's a lot of talk and work around well, shaving off all of the rough edges on a proposed solution to something that's not been tested and trying to get it right the first time, then believing that the work you're doing is inherently valuable. The mindset, I guess, behind that so the traditional work mindset is we know we're right and therefore versus. If we recognize what's going on in knowledge, work and software development specifically, we might be wrong. We have to embrace that we might be wrong and ask the question how long do we want to be wrong? For that's going to lead to, well, obviously we don't want to be wrong for very long. How soon can we find out whether we're wrong or not so we can take the next step? That's the natural, that's the non. It's not agile coded that conversation. It's about business, it's about a market, it's about real things that we're doing with software and our work, and so you can have that conversation with anybody, at any level, I would think.

Mark Metze: 19:59

So it reminds me of a story, one of the tougher classes that I took in college and I was a math, I had a math minor, but linear algebra was one of the tougher classes that I took and I still remember because the professor that day, first day of class, he came in and said that all of the tests, all of the quizzes, are all optional. So you can take them or not, but when you get to the final exam that's not optional. So if you want to forego all the quizzes and all the exams, you can and come to one day of class and take the final exam and let your whole class score reside right on that. So obviously nobody did that right. Nobody was willing to say you know, it takes too much time to study for a test, to study for a quiz. I'm just going to take that final exam and be right, and that way I'm saving time right, because I'm not having to do all these. No, I mean, you'd be ludicrous to do that.

Mark Metze: 21:00

And so I sometimes surface that story when talking about carving out large pieces of work and when you hear the rhetoric of and again. So I've used this same thing before, because when I was a developer, it's like well, it's just easier for me to do the work while I'm in there. Yeah, it takes longer for me to break this out into separate, discrete tasks and deliver it separately. Just let me go ahead and just do the work while I'm in there, and or the work's just got to get done. How many times have you heard that? Yeah.

Jon Fazzaro: 21:29

This is well, what are you talking about? Why we have to do this, Because they said so, because the customer wants it, because, yeah, because everything, but why the problem is? Yeah, I think that's a really interesting story about the classroom, because it actually what people, what you described, that people actually did, it actually surprised me Because of that behavior that I've seen so much in especially corporate quote unquote agile settings, and what I've learned is that, well, we're putting tons and tons of effort into trying to get it right the first time and it results in this giant, this big bang release that's got a tremendous amount of risk baked into it, and that's, of course, the analogous to the just take the final exam and skip everything before that.

Mark Metze: 22:20

Yeah, you don't know what you don't know.

Jon Fazzaro: 22:22

Right, but the students took the teacher up on all the tests and quizzes in the meantime and I wonder why did that? Why did people go that way in a classroom, but in general do not in a work setting? And it makes me think about what keeps people from shipping their work, what keeps people from saying this is ready for you to see, this is ready to review, this is ready to deploy. There's a wonderful book that kind of changed the way I saw work Back in 2010,. It was Seth Godin's Lynch Pin.

Jon Fazzaro: 22:52

I don't know if you've read that I haven't but he had a crucial idea there about our lizard brain, the brain stem part of us that we don't even really think with. We don't think of it, but it's sort of. You know, it's what pulls your hand back from a fire when you get too close, but it's also what makes you start breaking out in a sweat and want to run away when you're going to a job interview. But you know so it doesn't know the difference between your boss and a tiger. It just knows you want to get out of there, and I think that's at play quite a lot when it comes to trying to make smaller bets. But the you know, yeah, it's, it's less work, but and you'll find out you're wrong sooner if you're thinking about that straight. But most people are thinking how do I not get caught, how do I not get found out? Because you know, there's the element of imposter syndrome, there's the feeling of having eyes on your work, especially if you release it soon enough to find out whether something's wrong with it. You're being vulnerable in that way and are you and of course this comes back to psychological safety Are you in an environment where it's safe to be wrong about something? Because if you're not, why would you ever place a small bet and release something sooner? Why would you ever create the opportunity to find out if you're wrong, if it's not safe to be wrong, whether that safety is actually in the organization or just in your head, in your brainstem, I think.

Jon Fazzaro: 24:16

I think the people in the classroom in your example, like they took the test because there's there's not really a you know it's not really putting yourself out there, I think to take a test or a quiz. That's a normal thing in the classroom and so it was a free opportunity. It didn't come with a cost, an emotional cost. It was a free opportunity to find out early if they were on the right track or not. But maybe that's not the case where we work. Maybe you show it to your colleagues and they're like no, we have to. You know, the project manager is tremendously. You know this is a tremendously important feature. We have to get it right the first time. We have to shave off the edges and get the design just right. It gets pixel perfect before we show it to the director levels or, you know, even to QA.

Mark Metze: 24:59

Thinking too, John, just about maybe you can help me with terminology here Sure, and being able to put this into the proper words from a psychological aspect. There are people that just don't like to deliver bad news, Sure, and so I guess that will be part of your lizard brain that you would. You would have that response of well, I'd rather not share this bad news that things aren't progressing the way that I thought they were, or this might be bad. So it's easier for me to withhold that now and not make you bad now in hopes that something magical is going to change in the future and it's just going to work out so that you're not mad.

Mark Metze: 25:37

And the example I'm thinking of is for a company that I was working with. We were, we were replacing a legacy application with a new application, total rewrite from scratch. And so many of the customers were like this old feature that I had, when are you going to bake that into the new one? And the response of some of the some of the customer facing people in the professional services area was well, we're putting it on our backlog. So what the customers here is oh, you're putting it on the backlog. That means I should expect it in like a week, a month, maybe three months, yeah, but what the reality was? You're making them happy in the moment by saying you put it on the backlog. Which you're not telling them is there's no way that's ever going to see the light of day. Yep Checks in the mail. So how much of that do we just? Maybe, psychologically, as people, we just don't like that uncomfortable feeling, so we just kind of swallow it and hope that it changes later.

Jon Fazzaro: 26:29

Yeah, Well, I absolutely. It takes a certain amount of courage, empathy and generosity to be direct with a person and give them bad news. I think, yes, it's terribly easy to give good news or to hand wave and say it's in the backlog, checks in the mail, because that makes the person feel good right away, makes both people feel good. Yeah, Speaking of psychology, there's a tremendous tendency to discount the suffering of future you that's that guy's problem. Six months from now, when we do the big debt, when we take the final exam, it's that guy's problem. It's not my problem today. I'm a different person than that person and that sounds ridiculous, of course, when you say it out loud, but that happens all day long and I'm probably even doing some of it right now and I don't even know it. But you need to be courageous to take that step, to say the thing. That's uncomfortable and if you're in the right environment you get rewarded for that.

Jon Fazzaro: 27:28

But you have to take that first step.

Mark Metze: 27:30

So I'm leaning on you as a full stack software coach. Yeah, when we're trying to make these small bets, we can get tempted in doing the easy work first to see a lot of progress and leave the risky parts until later. And so you're again you're showing lots of progress. People are getting the idea that things are progressing really well. Yeah, boy, we're at the home stretch. Now we just have to wrap it up and you've got this big piece that you were like.

Mark Metze: 27:59

Yeah, you seen the movie the Money Pit by Tom Hanks and Shelly Long. It's a movie from the 80s and you know this old house that needs renovations and it's would like be a multimillion dollar house, but in the current condition it was awful. And the contracting group that they had, they would always come to the basket of how much longer? Two weeks, right, six months later, how much longer do you think? Two weeks? So that's that last bit that can be. Why do, as developers, why do we do that? And how do you help your teams to make sure you're breaking that risk early and not late?

Jon Fazzaro: 28:37

in the game. So when you say, why do we do that You're talking about? Why do we put off the things that are?

Mark Metze: 28:42

riskier Okay.

Jon Fazzaro: 28:43

Huh, I well, maybe not all teams do.

Mark Metze: 28:46

Maybe some teams are just. You know, they like challenges, like solving problems, and that's really what drives them is being able to solve this problem. But I've experienced other teams that just like to do the easy work first and it's like that's going to be a Pandora's box.

Jon Fazzaro: 29:01

I would, honestly, I would look less to the people on the team in those situations to explain their behavior and more to the system around them. What is it set up to reward? Do you get a compensated or promoted or, you know, evaluated HR wise based on the, I guess, the number of tickets you complete or the number of commits you make or God forbid the lines of code you write? But I think I think we've moved beyond that as an industry. But you know some such measure like look at the measurements, look at what's rewarded and you talked earlier about being rewarded for putting in extra hours. What are those developers? What does that team think they're being rewarded for? It may not even be what they're actually being rewarded for. So what is the? What do they think? What's the story their heads about what they're being rewarded for and that determining one way or the other.

Jon Fazzaro: 29:53

The other aspect of this, I think, is that the nature of the work causes that problem, that hope. You know it's going to be two weeks or we're 95% complete on this task for six months. It's that's not a failing of that person doing that work, not even, not even in the slightest. It's a maybe a failure of clarity, communication, but it's also a general failure to think of the work correctly, because this work expands when you touch it. That is the nature of the work. It's like Woody Zool has a fantastic quote on this it's it's in the doing of the work that we discover the work that we need to do.

Jon Fazzaro: 30:29

First time I saw that it was a tweet and I was like, yeah, that's right. Oh, my God, I would be scared to tell my boss that I would be scared to say to that, to the person that I'm doing this work for, because they would think I'm just being mushy, I'm being, I'm being wishy washy about the work. They're like, no, they would be. Yeah, no, of course not.

Jon Fazzaro: 30:47

The work is the work you know this is. You know this is an eight hour task, it's going to take you eight hours and that's. This is not linear. And so, as you do and you know, if you, speaking of estimates, if you have a larger task, you're more likely to the range of how off you are on how much you estimated to be is greater than if you have, like a, you know, one or two hour task. It's much more accurate because, as you do the work, the work grows, right, right, right, and so that's kind of an exponential curve. But anyway, yeah, I think, I think there's there's definitely a lack of acknowledgement of the fact that the work grows as you touch it.

Mark Metze: 31:24

Yeah. So, John, as we're coming to the end here, I think a good place to land was. Could you share that quote with us one more time?

Jon Fazzaro: 31:31

Yeah, yeah, it was. It's in the doing of the work that we discover the work that we need to do.

Mark Metze: 31:36

So that is very profound and very deep as I think about that. So I'll leave that for our listeners to ponder about. We'd love for you to comment on our LinkedIn page about what that means to you and and how that's applied to you about work, and I just want to say thank you to John for agreeing to be a guest here. We'll have to have you back again on a follow up episode because I've got like 10 million questions running around in my head, amazing.

Jon Fazzaro: 32:04

You mean the work expanded when we touched it. Oh, I see what you did there. We might have been. We might have been wrong about what we talked about today. So let's try again.

Mark Metze: 32:13

We might have we might have. Well, everyone thanks for joining us for this episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues Until next time. This has been your host, mark Nats.