Accelerate Your Delivery with FAST Agile: Tips and Tricks from FAST Founder Ron Quartel and Agile Coach Todd Hallowell

S2 E5 FAST w/ Ron and Todd

[00:00:00] Brad Nelson: Welcome to this episode of the Agile for Agilists podcast. I’m your host, Brad Nelson, and with me as always, is my partner in crime, Drew Podwal. Hello everybody. How you doing? And today we have a super exciting episode. We’re gonna talk about FAST and what it is, what the acronym stands for, all of that.

Today I’m joined by my colleague Todd Hollowell. And, uh, I Do you consider yourself like the author, creator, founder of, of Fast Ron

[00:00:28] Todd Hallowell: Cortel? Uh,

[00:00:29] Ron Quartel: yes. Founder I think is, uh, the nearest thing I’ve been using, which doesn’t feel quite right, but until I can think of something better. Sure.

[00:00:39] Brad Nelson: Well, welcome. We’re excited, we’re excited to learn all about this.

I mean, I’ve, I’ve read it, I’ve heard about it as well. From, from Todd, who’s, uh, a colleague of mine at Insight for about four years now. He predates me and has been a, a joy to work with. So, Todd, why don’t we start with having you introduce what it is

[00:00:59] Todd Hallowell: you do. Sure. Yeah. So, uh, Todd Hall. Well, thanks for having us on.

Brad and Drew. Appreciate that. So I work with Brad. Best description is, is an Agilists or Agile coach with insight, working with various different levels of individuals, teams and organizations. Kind of trying to help them find better ways of getting back to principal driven collaboration and kind of just finding the most effective, efficient ways to get to value for their users, despite any specific type of a or specific set of tools.

So not going with, uh, Agile Chameleon today? No. It’s usually purple, fluffy bunny is what I go with. So people have to go, what does that mean? And that’s really to me the better question. So, so what do you do at Insight? Well, I’m pur what’s your role is usually the question I get. Right And it’s purple, fluffy bunny.

And then they have to ask what that means. Too many assumptions. If you give somebody a, a role that they know what it means, they kind of jump to those right away and you lose some value. ,

[00:01:49] Brad Nelson: one of the things that I appreciate about Todd is he definitely finds creative ways of engaging people. That I don’t see anyone else do.

So it, for any of our listeners in Columbus, if you went to Path to Agility, you saw a Sea of pink shirts for insight. That was the ingenuity of Todd. Very, very creative, fun, Agilists. I get to work with . So, so Ron, I, I assume you, you’ve done more with your life than found fast. So why don’t you tell us a little bit about

[00:02:17] Ron Quartel: yourself?

Yeah, hi, uh, I, I really like Todd’s answer of the pink, fluffy rabbit, whatever it is. , I can really relate to that cause I, uh, I have troubles describing what I do, uh, as well. So, um, my career started as a developer and from there it’s kind of weaved through dev manager, Agile coach, technical coach, technical sales, and.

Yeah, just keep weaving through those, but always in the field of, of Agile in one way or another. Actually, right now I’m doing dev work. I guess my real passion is for org design and I do that when I can, but when I can’t, I’ll do other things.

[00:03:02] Brad Nelson: And uh, you live in Detroit now, correct? I

[00:03:04] Ron Quartel: do. As of last week.

Yeah.

[00:03:08] Brad Nelson: So I am also from Michigan originally, not Detroit. So Ron gets points there from me. Uh, but where are you

[00:03:15] Ron Quartel: from originally? I’m from Sydney, Australia. You can probably hear a bit of the accent coming through.

[00:03:20] Todd Hallowell: Yes, it’s,

[00:03:21] Drew Podwal: it’s lovely. I was, uh, I was in the Navy from 96 to 2001 and I was on an aircraft car.

I never made it to Sydney, but we reported for a little more than a week in Perth. And then we dipped down below the southern tip of Australia and, uh, got to go visit Tasmania, which was probably the coolest place I’ve ever been. I felt like I was in Maine, but in the southern hemisphere. It just had this very similar vibe to it.

But I haven’t been back yet.

[00:03:50] Todd Hallowell: Yeah, I don’t know if Ron knows this about me or not yet, so I’ll keep, I’d like to keep him guessing. Uh, my mom lives in, uh, cardigan Village in Victoria, so she is down there living in Australia now as well. So she keeps begging me to go down and visit. So I’ll have to remember to ask you for sites to go see Ron when I finally get around to taking three weeks off and traveling down there.

Yeah,

[00:04:08] Ron Quartel: for sure. That is something I did not know about you.

[00:04:11] Brad Nelson: So Ron, why don’t you tell us, tell, tell the audience what does Fast Stand for and where did it come from? Yeah.

[00:04:18] Ron Quartel: FAST is an acronym for Fluid Scaling Technology. The A is silent, uh, in a bit of a joke, , because, uh, turns out Agile scaling methods need to have a, a fourth lowercase letter somewhere.

So I squeeze one in , but it is essentially, uh, fluid scaling technology. Uh, I did, I don’t make it lowercase, I’ve just called it fast. And, uh, FAST can be used in different contexts. And when used for Agile software development, I call it Fast Agile. It says most commonly known as Fast Agile or just fast for

[00:04:56] Drew Podwal: short.

[00:04:58] Brad Nelson: And what, uh, what inspired you?

[00:05:00] Ron Quartel: Yeah. Um, I was at a conference in 2014 in New Orleans. Uh, it was the scrum scrum gathering, and the third day of that conference was, uh, an open space event. At that point, I was an Agile coach. And the theme around that, that time, you know, around 2014, there was a lot of talk around Agile scaling.

So I was an Agile coach. Lots of talk about Agile scaling. The coaching I was doing is, is at the team level. I was very comfortable and confident at that, and I was, I was looking at everything around in the scaling stuff going on, and I just wasn’t sitting right. And I’m thinking, you know, I’m gonna lead this to smarter people than me.

And when the dust settles, I’m gonna swing around and have another look at it. Uh, but in the meantime, I, I’m gonna keep it at arm’s length. That was, that was my attitude to, to, to scaling at that point in time. So, day three comes along and it’s, uh, an open space event. And we’ve just, if you, I’m hoping you’re familiar with Open Space, it really helps to understand open space to, to get a grasp of how fast works.

So we’ve just finished populating the marketplace and I’m, I’m looking at the marketplace and I’m looking at the crowd and there’s, there’s a good 800 people I think, or I think that was a number at that conference. And I thought, isn’t this just amazingly beautiful in 20 minutes, 800 people have self-organized a one day event.

I think this just feels so Agile just in, in how, how beautiful it and it forms and I thought, and there’s 800 people. This scales, this is Agile at scale. Why aren’t we using open space as a way to, to scale Agile? And that was when I put my finger on what I didn’t like about what I, what I was seeing was that it didn’t feel Agile to me.

Like it felt like we were doing reductions in determinism, sort of more waterfall feel to, to scaling approach to scaling than Agile approach to scaling. So I thought, you know, open space feels like it could be a good option. So it was just a crazy idea. But that was, that was the birth of, of the idea.

[00:07:15] Brad Nelson: Awesome. And can you give us our listeners maybe just a short description of open space if they aren’t aware of it or where they might go to learn more? Yeah,

[00:07:22] Ron Quartel: so open space, most commonly known as, uh, you might hear it called UN-conference. It’s becoming more and more popular now. And so if you go to an Agile conference quite often they’ll be an open space session or an open space day.

So what happens at an open space conference, it was discovered, invented by Harrison Owen, and he, he was someone that was putting together conferences, traditional conferences, uh, year on year. And he was so frustrated that. At the end of the conference in the feedback, the, the most popular part of the conference had nothing to do with all of the stuff that he’d organized.

It was always the water cooler con conversations. And he thought, you know what? Next year I’m gonna have the whole conference be just a giant water cooler conversation. And that was the birth of open space. And so , he invites everyone to a conference. They show up and he goes, all right, now you’re gonna, you’re gonna determine what, what we’re gonna talk about.

So people sit in a circle and they, uh, they all come up with, with something, not, they all come up with something. Uh, uh, Todd’s in the circle and Todd’s interested in learning about something. And so he’ll get up and say, I wanna learn more about Agile in aeronautics, and I’m gonna be over in room one at two, 2:00 PM And Brad gets up and says, well, I wanna share something really exciting about what I’ve learned about, uh, Gokin languages and how they test code, I’m gonna be in room number two.

And so there’s various reasons that people get up and say, I wanna be responsible for an event. So we put all of those into a marketplace. Uh, and in the beginning, I, I explained how the marketplace factor to, to urban space. So now we have a market space of events. People look at those events and then they decide which they go to, and they have the freedom to stay in that event or, or move out.

They, it used to be called the law of two feet now called the Law of mobility, which is cognizant of, uh, the fact that not everyone has two feet. So, um, yeah, the lower mobility, uh, applies and, uh, you, you follow your gut instincts and I’ve never seen it fail. It’s. . One thing we say in open space is be, be prepared to be surprised.

And every time I’m surprised it, I’ve always got value from an open space conference, and I hope that kind of explains it.

[00:09:49] Drew Podwal: I, I love open space events. I, I find them to be so immersive. There’s always so much to learn. I come away with them or from them totally like reinvented as an Agilists, as a person feeling really fulfilled with, with lots of new ideas and understandings.

And, and as a result, I, I’m always more energized at the end of them to then move into the activities that, um, for the rest of the week. Now I, I’m sitting here and I hope I’m not getting ahead. Uh, like I’m thinking about the idea of like, and I, and I am another four letter acronym with a lowercase a in the middle of it guy.

But I’m, I’m open-minded, right? I’m, I’m like, I don’t, I’m not a methodologist and I’m thinking that like, in fast. Do you run like an open space type event in lieu of what safe would call a PI planning? Is that or am I reading in between lines too much? Um,

[00:10:45] Ron Quartel: I guess there are some parallels to that. Uh, but now what if we’re running that every two days versus PI planning, which you do once a

[00:10:53] Drew Podwal: quarter, every two days.

Every two days or

[00:10:56] Ron Quartel: shorter. So the, the outline is to find the shortest possible, uh, scale that can work for you. And the shortest I’ve been able to do was two days that

[00:11:06] Drew Podwal: we got to play with. That’s really cool. And so how long are these, these open spaces that you, you run? They,

[00:11:13] Ron Quartel: that’s, that’s a great question.

And we, so the largest, um, we used to call it a tribe, but now we call it a collective. So you can imagine if you get all of the teams that you have that are. Related in some way and we’re gonna push ’em all together and we’ll say you are now one collective. I used to call it a tribe, you might hear me slipping between those words.

So now the entire tribe meets for this meeting, which is kind of based on open space. The entire meeting we found, uh, in the largest tribe I got to play with was about 60 people, took 15 minutes and would surprised me cuz it took 15 minutes when it was, when we were small, like when we started with about 16 people, we scaled up to 60 and still takes 15 minutes.

And that’s similar to, to other people. Out of heard, they’ll describe 15 to 30 minutes and there’s one meeting in fast and it’s called the fast meeting. And that that’s it. It’s this kind of open space like.

[00:12:13] Drew Podwal: So when I’ve done open spaces before, maybe I’m misunderstanding. It is we’ve, you know, set up the marketplace at the beginning or either asynchronously before the event, and then usually it’s like four hours with four time slots and that, you know, you grab your item from the marketplace and you put them in the different time slots.

So are you saying that the entire open space takes 15 minutes to run?

[00:12:39] Ron Quartel: So fast is built on the concept of open space and you’ve gotta kind of think not open space now. So there, okay. We, okay. So we have, we, we’ve, we’ve built a tribe. We, we get all the work that the tribe has to do and we throw it on the wall.

So now we can visualize, hey, this is what this tribe is trying to do right now. So that isn’t the marketplace. That’s, that is. The bulletin board, like that’s the, that’s something else. So we’re now looking at that and in each fast meeting, we’re gonna build a marketplace for that. Next, it, uh, I don’t wanna use the word iteration, we thought it was in the beginning.

It’s now called a value cycle. But for that value cycle that’s coming at that just next two days, we say, Hey, there’s 60 of us. There’s a whole bunch of stuff over there. What are we gonna do for the next two days? And, and really if you, if you get up to, to facilitate or essentially to to be a, a team lead, uh, we call it a story steward.

If you wanna steward a team for those two days, I’m gonna use two days as the example. And then people using the collective wisdom of the, of the tribe to determine what we, what’s the most sensible thing that we can do in the next two days. So Drew says, I’m gonna be working on feature A in room number one.

Brad says, well, uh, you know, I finished feature B uh, my, my team finished feature B that I was part of, but we left a whole bunch of tech deck behind. So I’m gonna be doing some refactoring and cleaning up over in room two. And Todd, Todd gets up and says, you know, we, I’ve noticed there’s a common, uh, architecture that’s falling out here, and I think there’s a real component, uh, layer that would help us.

I’m gonna be over in room number three. So I’ve just given three examples here of which Drew was the only person that Drew something off the wall. Brad and Todd both said they’re gonna be doing something else. So Todd, Todd’s forming a component team. Drew’s working on a feature team and Brad’s doing some refractory, and, and there is one role called the product manager who’s, who’s kind of cares about the big picture.

Product manager says, well, that’s the collective wisdom of the tri, then that’s what we’re gonna be doing, this, this, uh, value cycle. Go. And that’s what, what we’re relying on, on people, uh, caring about the big picture and, and doing the right thing and, and self-determining what should happen in what order.

I, I also

[00:15:09] Drew Podwal: noticed, so, oh, sorry. Go on, Brad. No, go ahead. Go ahead. I was gonna change. Oh, I also noticed, I’m looking at the, uh, the guide, the overview. I, I love the, the principles and I love specifically the first principle of Do the Right Thing. I could see how these principles are, are necessary culturally to support.

Having that mindset where people can pick items off the board, right? Or off the marketplace, or have the autonomy to, um, to not choose one and, and fill in the blanks and the gaps a little bit. Um, do you have to pay any royalties to Spike Lee for do the right thing or,

[00:15:49] Ron Quartel: that took me a sec. Uh, I should ask

[00:15:56] Brad Nelson: Sorry, Brad, what were you gonna ask? Uh, I’m, I’m changing directions now. So Drew is a big culture person. Yeah. Like time and time again, he talks about culture and, and I’m curious, this autonomy essentially is what you’re describing, Ron, does that take a certain level of maturity in your team, in your organization, or your tribe?

[00:16:18] Ron Quartel: Yeah. That’s a really great question. And. answer that in two ways. One is every adult outside of work knows how to act autonomously. So I know that every adult has the capability of being self-directed and, and self-managing. And I’m using the word self-managing here cuz we, we’ve kind of pushed autonomy like as far as we can.

So, you know, the Agile manifesto, we use the word self-organizing, the scrum guide just switched to the word self-managing and, and fast is really, is pushes that boundary, you know, right down, further towards self-management. So, in reality, and I’ve had had to talk with a few people on this one because there’s two schools of thought.

Some people think, yeah, everyone is capable of it and some people don’t. And I’m in the don’t school. Out of my experiences, I don’t think everyone is ready yet for having that level of self-organization and self-management, which makes me really sad and has really sparked my personal mission. I’m going down a branch here of untethering, the human spirit in the workplace because like what have we done as a society or our

[00:17:36] Drew Podwal: schools?

Or is it our

[00:17:37] Ron Quartel: churches or is it our, the way we govern. People show up to work and not everyone, you know, has that ability to, to self organize. Some people still just wanna be told what to do so they can do a good job, get a pat in the back and go home. And there’s safety in that for sure. And I can understand that.

And I don’t wanna take people out, I don’t wanna force people out of their comfort zone. So, I dunno if that answers your question, but I’d say, yeah, when you build a fast tribe, if you’re thinking about doing this experiment, find people that wanna do it and don’t force anyone into it. Or if you decide that this is something you’re, you know, that is, is working for most people, then find a way to, to help those people that it isn’t working for and find them something else.

Cuz it’s a different way

[00:18:21] Drew Podwal: of working. It feels like it requires like a high level of talent density or where, where everybody is, we have more people who are curious and innovative and problem solvers and want that ability to be handed a complex problem to solve as opposed to a ready-made here’s, you know, a bunch of bricks and some mortar and a trel.

Build me this wall. Right, right, right.

[00:18:47] Todd Hallowell: Um, well, and Drew you mentioned, and Ron you said it a little bit too, I think the thing too, to talk about in this is it really comes down to courage, right? You’ve gotta be willing to step out and, you know, you talk about comfort zones and getting out of it. It, it really is about courage.

And I think the other thing too that Ron didn’t touch on in this conversation, but he and I have talked about a few times, it’s you don’t have to have 60 people, right? It’s find that small amount of people that have that level of courage, that have that level of enthusiasm to do something different, to learn to break the mold, you’re dissenters, right?

You’re first movers and start a movement, and then what happens is as people see that the potential value they gain from trying something differently or adding a new tool to their tool belt exceeds the risk that they perceived present. That courage becomes easier to find, right? You’re gonna have to find some people who are willing to fail, and that’s when that risk or the potential for risk outweighs any value you might see.

And those are gonna be the people that really kind of you wanna start with, right? And then as those people start to prove out the concept, That balance of risk versus reward kind of changes a little bit. And you start to get some people who are, who are ready as your early adopters, but maybe they were your first movers.

And then as that risk reward continues to change, balance and reward becomes evident and risk becomes less, you start to see that, uh, enthusiasm and that movement grow. I mean, it’s just, it’s a classic case of how to build a movement. You can’t necessarily go in and expect to start with a large crowd of people.

It takes a few people who are willing to do that. Um, I think one of the sayings I’ve seen is that well-behaved women never made history, but it’s the idea of well-behaved people never made history, right? So go out there and take some risks, um, and prove that out, and then you start to get more people involved.

And it’s not always going to be a collective of 60 people. We haven’t gotten to it yet, and we can’t if we want to, but like how I got involved in this with this, with a small team and very similar in the principles to how FAST operates and what FAST is trying to get to is what this team did. And it’s, it’s generating a movement where I’m at, um, both at Insight and the client that I’m serving at.

So I think courage is a key thing to hit on too here. Not just autonomy or agency or even skillset, but, but courage is a huge piece of that as well. Yeah, I love

[00:20:47] Brad Nelson: that. I love that. Yeah. Yeah. And, and that was gonna actually be my question, uh, but then Drew piqued my interest on the culture. So Todd, where do you come into the picture with Fast?

What is your, your background with it and your relationship to it? Yeah,

[00:21:03] Todd Hallowell: um, that’s a great question. So about 10 months ago, I got pulled into the client where I’m at right now, and like, I don’t know, I think the statistic is about 80% of teams doing Agile use the one big five letter framework, right? That we all know, um, you know, that most, most organizations are using that are using Scrum.

And that was what the intention was at at the client where I was at. And we very quickly realized, my question to them was, why do you want to do Scrum it? They weren’t quite sure. And as we started to kind of dive into what they had, we realized that it wasn’t going to work. Like there just wasn’t even enough.

It was too much chaos. They didn’t even know what they didn’t know. Uh, the question became for them, you know, the contract that was sold working for a consulting company, they sell certain things in frameworks and it was, Hey, let’s do a two week sprint. And okay, well what’s the goal for the next two weeks?

Well, they were working in such a way that they didn’t even know and the conversation, okay, well what about for this week? And the answer was, well, we don’t know. Okay, let’s take a step back here guys. And the question became, what do you want us to do today? Cuz we can’t just sit around here, right? We’re here, we’re live, we’re active.

We need to get, we need to be making progress. So we need to be helping you out. We can’t just, the client’s not gonna let you just bill for sitting around. So we’ll work on this. All right, cool. We’ll talk to you tomorrow. And this just kind of organically became this 24 hour, and we call him, I know Ron in fast, we call him the value cycle.

But for us, it became these 24 hour learning cycles. And the team would discuss what’s the most important thing to do? All right, we have this thing, this is the priority. Okay, what are the pieces of work we need to do to get that done? And the team would step up and say, well, I’ll take this and I’ll take that and I’ll take this.

Cool, we’ll reconnect tomorrow and see where we’re at, make sure this is still the direction we’re heading, and make sure we’re all aligned. And this has been going on this way. And the clients absolutely loved it. So we’ve worked in these 24 hour learning cycles. Well, throughout the course of this client work, Ken Rickard, who we’ve discussed previously, he said, Hey, you need to look into this fasting cuz you’re doing like 75% of what they have in a principle base.

He says, and your principles really align and. . I wanna go back to what you talked about. My favorite principle about this whole thing is do the right thing for the right reasons. Like everything gets measured against that, right? This is a framework. If it doesn’t work and it’s not the right thing for the right reasons, guess what?

Chuck it. Do the right thing for the right reasons. That’s the purpose, and that’s kind of what drove us in this engagement. So I started looking into this and I was like, yeah, I don’t know if it’s a match. It still feels too framework to me and I’m, you can ask Brad, I’m a my favorite book. Is about descent and rebels and rebellion.

So for me, I’m like, I’m all, I’m very much like, how can I take these frameworks, break them into pieces and use the pieces I want? So when Ken said, Hey, go look at this framework, I thought, eh, I don’t know. But I looked and I was like, all right, this makes sense. So I reached out to Ron and we just kind of started talking about this and I, um, I think we connected on a meetup and I got to listen to him there.

And then we talked right afterwards and just kind of shared, and I asked him a bunch of really tough questions, um, and was impressed with his answers. And we’ve just kind of continued to connect through them. But it all comes back to that principle, and I think that’s what I love so much about this. It’s do the right thing for the right reasons.

If it doesn’t make sense, don’t do it. If you can do it a different way and get the same value, then do that. Because if that’s the right thing for the right reason. So that’s kind of what’s drawn me into all of this is that principle driven collaboration, principle driven delivery, principle driven development.

What are we trying to get to and do it because it’s gonna get us to where we’re trying to get to. Not because it’s an arbitrary practice that somebody has said we should do. I think

[00:24:19] Drew Podwal: it was a couple of months back when I first became aware of Fast, actually, probably about four or five months back. And when I started looking into it, I started thinking about like the other models in comparison and, and, and whatnot.

And I, I had this thought, right, like the thing for me is that being somebody who is a bit of a safe guy, the thing that I like about Safe is that it creates a model that is familiar to executives. And like my biggest challenge that I’ve had within my career is convincing executives that they are an inherent part of this whole, whole thing working well.

And I started thinking about it that like you could theoretically have safe. I also think this is an overcompensation to an even bigger problem, which is we have too many hierarchies. Um, Within this traditional org structure that we have at most of the enterprise companies where there’s EVPs and SVPs and VPs and directors and managers and programs and portfolios and whatnot, that you could theoretically implement safe from like the neck up and then replace and embed like fast at the neck down.

Is that something that you guys have thought about at all? And then also for you Todd, like where, where does, where do executives meet the rubber, where FAST is embedded, where you are as well?

[00:25:48] Todd Hallowell: I guess for me, so the, where I’m working in the client or I’m working at their safe shop as well, and, and we’ve met some of this with resistance and I think that we’ll encounter this continually because people tend to think that it’s a one or the other.

And to me it’s not like, If your car needs repaired, I’m not taking it to the mechanic who’s got a standard set of tools. I wanna make sure he’s got all the tools right. Cuz some of the bolts may be standard or some of them may be metric. To me it’s about equipping yourself with the right tools. I mean, and I’m not, I’m not a safe, I don’t have a lot of experience with safe Drew, but the understanding to me, and it’s as it should be with every framework is.

Use what you need and don’t use the rest. So like if, if you’ve got organizational constraints where you have to account for certain things or you need to address certain planning or even the, the release planning is just a, it’s a way, or the intended outcome is to bring the necessary teams together to talk about how all their stuff integrates.

Great. Do that. And then if your work is so complex or you’ve got so many integrations that you need to meet more frequently, or parts of that release train, need to meet more frequently, and maybe you benefit from a 24 hour or a 48 or a 72 value cycle and fast, then do that too. Like, nothing that says that these things are oil and water and can’t go together.

Again, it comes back to doing the right things for the right reasons. I think that, you know, if we, if we stop inspecting the practices and doing them, but the outcomes we’re trying to get to and whether or not those work, that’s, that’s the litmus that we should be looking at. I mean, and it’s not safe.

It’s not just fast, it’s any framework. You know, if you cannot look at a practice and understand why you’re doing it and ask yourself honestly, is it getting us to where we want to be in the best way, then you’re probably not really getting the most outta your, outta your processes. I mean, I’ve seen teams like the team I’m working with now that literally it’s, it’s funny, they’ve scrapped the event and one of the teams I coach, um, is scrap the event retrospective.

But guess what? They’re still doing retro, but they don’t have an event for it because they’re talking about this stuff every day. This is an example I’ve talked about with Ron recently. This is one of those instances where I think you need to inspect. Are you, are you focused on achieving an outcome or aren’t doing a practice?

Right? And that’s what these frameworks are really all built around. It’s like if you, they should be driving us to. Yeah, I guess that’s what I would say. So for us, it’s, it’s just a matter of asking those questions. Well, what is it you’re trying to get from safe? What is it you’re trying to get from Fast?

Are they giving you what you want? If they are great, if there’s another way to do it, then do that. If they’re not, then let’s figure something else out. I I, does that answer the question, Drew?

[00:28:18] Drew Podwal: No, no, definitely. Definitely. I, you know, and I’m thinking about it from a standpoint of, um, like I’ve been thinking about overreactions a lot lately.

Brad and I are gonna have a conversation Thursday around an an, what I think is an overreaction, but like safe is an overreaction. Right. Safe is an overreaction to the problem of large organizations that that think they know that their business is gonna always be run the same way that the org structures that we inherited from 20, 30, 40, 50 years ago still make sense today.

And we create these structures within safe and even like retrospective, right? Retrospective is an overreaction. We are carving out time to force people to retrospect because we know that if we don’t carve out the time for them to do that, they probably won’t do it. Whereas what you’re describing is more of a symbiotic state where it’s a framework that assumes that everybody is there at work to do a great job, and everybody is very positively charged and energetic.

And, and I love that. I would love to work in an environment like that. I would love to roll around and bathe in it and, you know, um, splash, splash around. I just haven’t seen those cultures in the, the companies that I’ve worked for and worked with as a coach that are ready to dive in there. And so when you said courage before, it got me really excited, but I also think that it doesn’t just require courage of all the, the, the people at the waste level down you requires courage in the leadership to, to say, Hey, these guys.

Or women, men, whoever. They’re onto something interesting here and I’m gonna protect them to try this experiment for a period of time. And, and I’m gonna put my neck on the line a little bit for that, you

[00:30:12] Todd Hallowell: know, let me, uh, let me address three different points that I heard there that I wanna talk about. So the first thing is, I don’t know that safe is an overreaction anymore.

That’s Scrum or Fast is I think that the permanent, the belief that a framework when you put it in should always be there. And as a permanent installation is an overreaction, safe very well way, very well may be the right solution or tool for a given problem at that moment. I think the challenge we see organizations is they say, okay, we’re a safe shop, so now we’re a safe shop from here on out.

And they don’t stop to think, okay, this solved the problem we had at a given point, but we don’t need this level of orchestration or guidance or structure anymore. I think teams do that with Scrum as well. I think that when you start putting stuff in and you don’t go back and say, When you look at it as a permanent solution, without ever going back to ask, do we still need to be doing this?

I think that’s the overreaction. That’s the first thing I would say. The second thing on retrospective, you know, people aren’t going to do it. They’re not comfortable. I think that to me, what I have found is it’s the opposite. What I have found is that, you know, we, we see it, we see this all the time, right?

You divide the world into two types of people, and we know there’s lots of types. But in this instance, right, you have people who are, who are gonna talk in a retro, and then you have the wallflowers who just kind of sit there. Now, that doesn’t mean the wallflowers don’t have an opinion. That doesn’t mean that they’re not frustrated with things that are happening.

It just means that they’re not sharing it. They’re not comfortable in that public forum sharing it. I. Be willing to bet my paycheck that those wallflowers still come to people within their sprints or their cycles or their PIs, and they’re complaining about things. They’re talking about, Hey man, I had a really good day today.

I loved when we did this, or we worked together. It was really a lot of fun working with you. Or, this absolutely sucks. We can’t get anything done. I’m pulled in a hundred directions. Right? These are the authentic reactions that we really would be looking to get out of a retrospective, and this is one of the things that I’ve been coaching.

One of the people at Insight on that I’m responsible for is, is kind of mentoring. And that is like focus on the outcome. If the goal is to identify areas to improve, if the goal is to identify on things to keep doing, listen for those things throughout the week. How many times, even with your people who are active talkers, you get into retro and everybody’s sitting around there going, they’re scratching their heads or trying to figure out what to put on the whiteboard, and you’re looking across at the room and if you’ve been paying attention and you’re like, dude, you’re the same guy to came to me this week and you had 40 things you wanted to complain about, now you can’t think of one.

So why, you know, we get into this situation. If you can capture those types of things, Throughout just the daily life. Why not just come to a retro and say, Hey guys, I was listening. I heard you this week. These are the things we talked about that are causing you pain points that are stresses and problems.

These are the things that are going really well. Do these all still jive and make sense? Cool. Are these things we want to tackle this week? Sure. Hey, guess what? Your retro just ended after 10 minutes and it was a heck of a lot more valuable than the last seven, eight months of 90 minute retro you spent, where people sat around scratching their heads.

People will naturally bring up the things that frustrate them, the things that make them happy. It’s just human nature. The challenge I think, with retrospective is we put it into such a formal situation where people can’t, they don’t typically perform under that kind of pressure in those moments because what you’re doing is you’re pressuring vulnerability.

People don’t do well, being vulnerable under pressure. The two things seem to be counterintuitive. I can’t remember what the third thing was. You had mentioned . Yeah, that was the third part too. But I,

[00:33:22] Brad Nelson: that, that’s interesting. You have my wheels spinning. And that’s what I love about working with Todd is he gets me to question my life every day that we interact.

You know, I think of retrospective as, as well as the ability to create space for teams to inspect and adapt. So it’s not always about necessarily that individuals aren’t going to do it. It’s that leadership doesn’t create that space for them. But I, I guess I never thought about the fact, the pressure component of it, of being put on the spot.

And that definitely happens to me all the time that Evan to me and our last episode on Thursday when Drew was like, Hey, so what was great about this presentation? And I was like, uh, every thought just left my brain.

[00:34:01] Todd Hallowell: I’m glad you said the word leadership. That reminded me of the third thing. So you talked about courage at a leadership level too, Drew.

And I think that if you have courage at your grassroots level, courage at the leadership level becomes less critical because again, Fast. The great thing about scaling, right, and we, we see, I see this happen too often where, or I see this not happening often enough. We typically think of scaling as how to make frameworks bigger, right?

When we think about safe, it’s dealing with large groups. How do we deal with com increasing complexity, increasing groups of people increasing, you know, integrations, scrum built Nexus, because Scrum couldn’t handle it, so it needed to be bigger. Scaling isn’t intended to be unidirectional, you can scale down as well.

If you’ve got courage at a grassroots level, you’re better at having it just at a grassroots level, in my opinion, than at just the executive level. If you have it at the grassroots level and you have a small group of people who are willing to step out on faith, find the smallest little area where they can tuck in without making disruption that’s gonna cause problems and prove the value of the principles that some of this stuff is built on, then what you can do is even without the courage of leadership, they start seeing the balance of risk and reward change, and now they don’t have to be as courageous.

Well, you did this over here and you got value outta this. Okay, you got my interest now because now you’ve proven me of the proof of concept. You can do it. If you’ve got some small faction of people willing to start to do that and show the value, you’re more likely to get leadership to buy in where they may not have had courage without that value prop.

But if you’re leading from the top down and people aren’t going to necessarily, that change doesn’t tend to be as lasting, Hey, you’re gonna do this and we think it’s valuable. All right, well we’ll do it. And then when the cat is away, the mice will play, right? If they don’t see the value in it. But that grassroots understanding of the value, we’re doing it cuz it makes sense.

We’ll do it in an area that we can get away with and show that value. You start to get buy-in and create influence from the inside out. Just kinda like throwing a stone into a pond and watching those ripples continue out.

[00:35:49] Drew Podwal: So I, and I, I love that analogy as well. The idea of like innovation riptides and things like that.

I, the first part of my career I spent as a project manager and, and I say this all the time on all the episodes, I would come home at night, cry into my pillow. Why are none of my projects on time? Why are they always at risk? Why is nobody seeing things the way that I’m seeing? You know? And, and then when I got.

First team that was trying to experiment with Scrum and I started leaning into it and understanding it a bit more. I suddenly felt this immense pressure up on above because my role as the project manager was to provide insights into the activities that was going on in the Scrum team. And at the same time, we were just getting like these huge, ridiculous.

Requirements that had way too much information in it, and probably 20% of it was the right information. And so it was my job to then convert that into a way that would allow the teams to have their autonomy. And it was like this thankless role that I was doing for a while, where, where I had this, the immense weight of the waterfall up against my back, and I had my arms, you know, protecting my scrum team so they can do their, their experiment in self-organization.

And so, like when I’m hearing you talk about this, like, what I’m wondering is when you don’t have that person up on high, that is protecting that space for you, how do you carve out the focus from all the project managers who are trying to say, all right, we got a status meeting, now we have another status meeting, we have to have another status meeting, and we gotta have another project kickoff and another project kickoff.

And um, like how do you, how does that work when all

[00:37:33] Todd Hallowell: that’s going on? , I think you’ve just gotta look for the smallest area you can carve out to prove out that value. Right? And it might be a, it might be seemingly infant decimal, like just absolutely tiny. But if you can start there and grow it, I find the analogy I regularly use when you’re trying to bring about change is that a boiling, a frog, right?

And if you’re not familiar with the analogy of boiling a frog, right? The idea is how do you boil a frog? Well, if you throw a frog in a pot of boiling water, it’s gonna jump right out. But if you put it in cold water and you slowly turn that water up, that frog will sit there. Never moving. Change is best received in, in these really small little increments that are almost unidentifiable.

So I feel like what we encounter is people are like, oh, but that’s not big enough to make a difference. Well, it depends on how you define difference, right? Teams do this too. Well, we can’t slice our story that small. It’s not. . Well, how are you defining value? Like if you can slice it even smaller and smaller, like we’ve done this, I’ve encountered this in vertical slicing conversations where you’re trying to get ’em to slice vertically and not just build F components.

Right? Well, but if we do that, it’s tiny. Like it’s just this little thing. Okay. But you’ve proven a couple of things, right? So people, we just have to start changing mindsets and perspectives. I think the, and I’ll go back to the example I used with retro, right? I’ve got somebody who’s working at a client, they’re very locked down.

There’s not a lot of freedom to try and innovate, but it was like, what’s the smallest little experiment you can try that you can do that might show that you can create some value? He said, well, we could probably try and do this. They’re more concerned with seeing what comes out of a retro than they are us having it.

Cool. You can still get to that, but you can try it a different way. So I think it’s just a matter, and it might be on one story, it might be in one activity. It might be in one task. It might be one conversation. But start changing the perspective at the smallest place you can where you don’t need that air cover, where you are enough of your own air cover.

[00:39:24] Brad Nelson: Interesting. So, Ron, what is, I would say something that you’ve learned through this journey of sharing fast out into the world and, and hearing people like Todd running with this concept and making it reality. I

[00:39:38] Ron Quartel: think I’ve learned a lot about the nature of work and the nature of organizations itself, and it’s really moved my passion or interests from Agile to, to teal where, you know, Drew’s talking about these organizational styles and, and, you know, the, the culture question always comes up and I feel like so many, you know, Agile transformations that I’ve been a part of didn’t work or that were doomed from day one just because the, the culture of the organization and the way that they think about work and the way they think about people.

So it fast really opened me up to new ways of working. and, and what’s possible and new ways of thinking about work and structuring our organizations. Um, that’s been the, the big eyeopener for me. And, and I now say, you know, I’m more passionate about Teal than I’m about fast. Cuz soon as you talk about something and they’re like, oh, you’re trying to sell me I’m fast.

I’m like, I don’t care if you do fast or not. What I do care about is that we start fixing up the places that we work, that we start creating human-centered organizations that, you know, that’s, that’s kind of what I hope Fast can bring about as well. So it’s kind of a two-way, two-way

[00:40:55] Drew Podwal: street.

[00:40:56] Brad Nelson: So you mentioned teal organizations, that’s like the, was it amber, orange, green, teal, like maturity of an

[00:41:03] Ron Quartel: organization?

Is that what you’re referring to? His language. And I’m so tom with that word, teal because everyone like, what does that teal mean? And it triggers some people. And you know, the benefit of the word Agile is it, it’s one term that, that, you know, people understand and it’s, it’s a tip of something very, you know, a lot larger.

And so this whole, there’s a whole movement going on ar around human-centered organizations, uh, and, and new ways of working and changing the way we work, moving out of the, the age of mass production, you know, into the age of disruption, um, you know, becoming adaptive organizations. So all of that, I’ve, I, we, we don’t have a flag yet, you know, we haven’t had 20 white men sit in a room and come up with a name for it yet.

But, uh, um, so I’m using Teal for now. Maybe a better term might come up, but.

[00:41:55] Drew Podwal: Reinventing organizations as a book was absolutely life changing for me. I, I read it for the first time. Uh, I was in London. I was coaching an Agile transformation at the post office. And, um, living in hotel rooms, it just completely like one, it validated so much of what I already knew and it gave me the words to better communicate that as well.

But then it also took it a step further, like with the idea of, um, horas. I’m gonna get back to it again. That’s where I want work, right? Like that’s the place where I want to work. And for me, the call to action in what I’m doing now is I believe that we can actually all work at places like that at some point.

And, and that’s why I do what I do each day, right? And that, that’s why I have the conversations I have with people and connecting people. So I really love the fact that like, like that’s what I was kind of getting at. The idea of, I feel like it was misunderstood when I said like, self is an, or safe is an overreaction, right?

When I say that, what I mean is that like safe is a great framework. It’s a great tool. It’s got lots of great concepts, many of which were are, are safe concepts, most of which are concepts that exist elsewhere in the wild. And were just put into a framework and it’s the thing that’ll get. The next a hundred miles.

300 miles or whatever. But it’s not the thing that’s gonna get us there. It’s not the thing that’s gonna get us to teal organizations and human-centered organizations. And it’s an unlocker that is, that will hopefully unhinge companies to get them to a place where they can get ready to shift into that teal mindset organization from my perspective.

And so when I said it was like an overreaction, really what I meant was it’s, it’s a reaction to the way that the paradigms that these big stodgy enterprises are stuck in right now to try to get them further along the line. But it’s not the thing like what fast sounds like. It’s not the thing that will help them to really become that, that SEAL organization.

Yeah,

[00:44:02] Todd Hallowell: Drew. Something I found myself saying in conversations recently and, and this kind of applies to any of them, frameworks are a great place to start. They’re a terrible place to stop. I think getting those things in place help people who are trying to learn and find a way, gives you guiderails as a child, I as kids, as infants, you put them in a crib.

So they have guardrails that keep them from rolling out, but as they grow, as they age and mature, you don’t see those typically on an adult’s king size bed. Right? I don’t need rails to keep me in my bed anymore. I’ve figured out how to do that through maturity and through growth. So I think frameworks are a great place to.

They’re a terrible place to stop and stay. They’re a great jumping off point. They give you a good foundation for the reason you pointed out about safe, all these things. And it’s true with Scrum. It’s true with fast. It’s true with any framework. You look like none of these frameworks. Own these principles.

Do the right thing for the right reasons. Communicate and talk and make sure that you’re not just talking to each other, but that you understanding each other, right? Communication and comprehension. Getting past communication and to comprehension. All of these frameworks are essentially textbooks written in a way to help you start doing these things, but then you need to evolve to move past this, right?

This is that concept of Ssha RI and kind of continuing to grow. So I think you’re right. I think this idea of. , don’t start there. This isn’t the destination. This is just the beginning part of your journey. This is how we set you off with a set of basic, bare minimum tools to keep moving. But I think that what has happened and the the over-correction is an oversimplification, giving these frameworks too much credit that they’re gonna get us to the end, right?

Versus now they’re just gonna get you out the door. This is that first step to get you moving and set you off with a base set of tools. But I wouldn’t want anybody to just know fast or just know safe, or just know Scrum or any of these. Learn all these different things. Take these tools and figure out what works for you, and then move forward with those and find ways to evolve those.

Find ways to break those, to refine them to get better. Not because the tools are important, but because the principles they’re teaching you to get to the outcomes they’re helping you to get to. . If you can learn to do those things with these tools, you can learn to do them with other tools as well. They just give you a basic set.

[00:46:07] Drew Podwal: I once heard, and I don’t know if there’s any truth to this at all, but I’m gonna repeat it and continue the myth if it’s not true, but that, uh, when Edgar Winter wrote Frankenstein, right, you know the song Frankenstein, dun dun dun dun dun. Yeah, I did that. Um, in, in the studio, they cut up the tape for the different segments and like threw them up in the air and then spliced them back together again based on where they landed and, and opportunity and whatnot.

Uh, just kind of feeling like there’s a parable there, right? In the sense that like, we could take some of this and we could take some of that and why don’t we try some of this for a little bit? And, you know, knowing that we’re just trying it. and if this configuration works for us for a period of time, let’s keep doing it.

But let’s not stop there and let’s cut up Frankenstein again and throw it up in the air. And as somebody who has major, major, major A D H D, right? Like I come up with frameworks for myself to be able to keep my personal life backlog on a regular basis, what winds up happening is it stops working for me.

Um, and I never know what it’s gonna be. And so what I do on a regular basis is I just. Tear it all apart and build it back up again with new tools and new ideas and concepts. And part of the action of doing that is very cathartic because it helps me to reset, it helps me to see what works well, what didn’t work well, and, and what are the attributes that I, I want to do differently.

So, but I wanna buy a t-shirt with the quote that you just said on it. I want every, like, every piece of my clothing to have on it. Uh, frameworks are a great place to start, but they’re a terrible place to stop. I think that’s so, I’d love. Yeah. The other, other

[00:47:52] Ron Quartel: way I’ve, I, I like seeing that in, in. Uh, a diff different framing is, is, you know, scrums really good at what scrums good at and fast is really good at what fast is good at safe is really good at what safe’s good at.

And that, and don’t kid yourself that any of these are nirvana. They’re not an endpoint. Find out what is good about them, what its strengths are, and what its weaknesses are. And then you’re in a really strong point o of of, of knowing what you’re doing and why, and when to switch between them. Well, waterfall is actually really good at what it’s good at, and we’ve thrown that baby out with a bathwater, and I’m like, no, no, no, no, no.

If you are in a highly deterministic reductionistic problem. , which is in the complicated zone. Waterfall actually works really well. But we’ve gotten this mindset of like, waterfall bad, Agile good. And, and that’s, that’s the, that’s where we’ve, we’ve cornered ourselves. Scrum is, is this thing on this pedestal.

Like I don’t, I know poo poo scrum, but it’s really good at what it’s good at and there’s things that it, it’s not good at. And let’s get real and, and discover that for yourself and become. Start becoming honest with yourself about, Hey, you know, this thing isn’t perfect for this situation. This other thing is, is better and start to get understand.

Complicated, complex, um, you know, the difference between those and, and when you’re in those spaces, what should I be doing?

[00:49:18] Todd Hallowell: One of my biggest epiphanies in the last few years came, and I, I think most people have heard this idea that, well, they do their flavor of Agile. And I think historically it was like, oh, if they’re doing their flavor of Agile, there’s a negative connotation that comes with it.

And I started asking why? Like, shouldn’t that be the goal? Like their flavor, but not even just their flavor for their organization, but their flavor for that moment, right? This idea of what makes sense right now where you are do that. So if that means parts of this and parts of that, great, but I think historically we have a lot of people in our community that do what we do and they’re like, oh, well if you’re doing your flavor of Agile, you’re not Agile.

I think if you’re not doing your flavor of Agile, you’re not living with agility. Like that’s the key, right? You’re not, you’re not asking the right questions. You’re not pivoting as you should. Well, but here’s

[00:50:00] Drew Podwal: the challenge I have with you there, right? So like Capital One who laid off like 1500 people back in February and they laid off every single Scrum master and Agile coach, they were doing their flavor of Agile and along came a new and ex executive committee or new cto, whatever that was.

And, you know, Agile bad and out with the Agile. And so to me, Brad and I had a conversation around Shuja Ri with regards to this, and I think where we landed, like, cause I, I was under the, the mindset of that. I think it was what Ken Schwaber said that if you’re not following the scrum guide, you’re not doing Scrum.

And, and I challenged to say like, well, okay, what about like trying, like where does trying fit into Shu Hari, right? And I think that the thing is, is that the reason why we say if you’re. Following the Scrum diet grind, you’re not doing Scrum is that we don’t want you to blame Scrum if it doesn’t work out well.

We don’t want you to blame Agile if it doesn’t work out well. And that’s kind of exactly what happened at Capital One is they, they blamed Agile and now they’re doing some weird. DevOpsy type experiment that is, you know, is it the flavor of DevOps? Uh, it’s, you know, it’s in the ice cream con, you know, container.

But I don’t think that what’s inside the, the pint is, is really DevOps.

[00:51:21] Todd Hallowell: Yeah. I’m glad you brought up both those things. I guess what I would say is that just like religion, it’s been hijacked over the years in the centuries, right? For people for their agendas so they can say they’re doing their flavor of Agile and it’s just a way to kind of blanket or cover themselves and other decisions they’re making.

I love the fact that you brought up the scrum guide piece too, cuz it’s, I think Brad and I have talked about this at work. Like to me, I know they had the revision, what was that, 2020? I think they came out with the most recent revision, like the most recent revision literally needed to be, in my opinion, one sentence at the very back of the guide.

And that was that if you’re not doing all the components of Scrum, this isn’t Scrum, but. That’s okay. Mm-hmm. , like there may still be value in that, right? Yeah. Like do what makes sense for you at the time. But I think it’s important to call out a delineation between the two. And I’ve had this discussion with many people.

It’s okay to not do Scrum and Deduce, do part to Scrum that makes sense for you. The reason that I think it’s important to identify when you’re not doing Scrum is it, so you can’t blame Scrum. Instead you have to carefully inspect your implementation of whatever it was you did. Like that’s

[00:52:21] Drew Podwal: the key.

That’s point out like you, what you just said, the response. Cause people can’t see, right? But as soon as you just said that one little statement of, you know, you’re not doing Scrum, but thank you for trying the three of us here nodding our heads. I, my hand, my fist went up in the air. You know, like that you’re, you’re full of really great statements and isms and that.

It’s just awesome. Right? That really resonates well with

[00:52:45] Todd Hallowell: me. . And, and I don’t, and I appreciate that. And I don’t have anything, any ill will against Scrum. I, I think Scrum, like we’ve said, it has a place and a purpose, right? Just like a flathead screwdriver does. Right? Or a hammer does. And I think that the pieces and parts of Scrum are valuable.

I think the point that Scrum would like, would like people to understand is that we believe that our framework is most valuable when used together to deliver this set of outcomes. But that doesn’t mean that you should throw the baby out with the bathwater if you can’t do everything. Let’s say that your organization isn’t structured to give you fully autonomous product owners with a hundred percent agency.

Does that mean you shouldn’t do any of it? No, if you can still get value from review and getting feedback from stakeholders and get them involved, or you still find there’s value in retro or in minimizing complexity, uh, and convers and increasing, increasing collaboration through a daily connection, right?

Call it a daily scrum or whatever you wanna call it. I don’t care. , then do those things. Just don’t call it Scrum cuz it’s not, because scrum like baseball has a very specific set of rules. Now I can go out and play with a bunch of friends and do very similar things, um, and play very similar. Like we get a lot of fun out of fielding the ball and swinging and hitting, but we’re only playing with one guy in the outfield.

And, uh, you know, there’s, and you get one pitch. It’s not baseball anymore, but we still have a lot of fun doing it. And there’s still something to it. But I can’t, when somebody comes along and says, well, you’re not doing baseball. I shouldn’t be trying to defend what I’m doing is baseball, because there are a set of rules.

And Scrum even calls them rules for that reason. But I think it’s important to recognize that call a spade a spade. If it isn’t Scrum, be okay with saying it’s not Scrum. Scrum does not own, and neither does safe, neither does fast any of these things that existed outside of it. Scrum doesn’t own empiricism or inspection and adaption, right?

Safe doesn’t own planning out big releases. I think the thing is, is people get so afraid to say they’re not doing it, that they call it what they feel like it should be. and then when the implementations fail, they blame the tool rather than the implementation. So

[00:54:36] Drew Podwal: if we were gonna, let’s say I was a client, developer, architect, product manager, and like we were talking and I came to you guys and said, I saw you guys present at the last conference.

I want to get started. I want to try this on as an experiment. What are your recommendations? Where do you start trying fast?

[00:54:57] Ron Quartel: Yeah, I get asked that a lot and it’s a, it’s a really good question. I have to think about that because when the, the, you know, when fast emerged and evolved, it did so incrementally, and I don’t know if I could, I can’t like prescribe the same incremental steps because it, that was just how it happened where we were at that point in time.

But my answer now is typically, well, why don’t you host, uh, or facilitate a, a hackathon Because companies are kind of used to that. They understand that. Say, ha ho, facilitate a hackathon and, um, use fast, but don’t say that you are using fast. So, cuz a hackathon is so similar to Fast, right? You get the entire company come together, they sit in a room and then they go, all right, we’ve got a hackathon for two days.

Who’s got an idea? and someone will get up on the stage and go, yeah, I’ve got this idea. Someone else go, oh, I got this one. I’ve got, okay, now we’ve got six ideas. The rest of the room go, all right. And they pick which idea they’re gonna go with. They sit with that person for two days and they produce working software at the end of two days.

That, that’s fast right there, right? That is fast. So you do this hackathon and you get to the end of it and you go, Hey, how, how did we find the hackathon? How did it make you feel? How you know? Was it, how did it compare to the way we normally work? Do you wanna run an experiment with using this process for our work?

and just see who puts your hands up and then go, all right, you like, come over here. We’re gonna, we’re gonna try this like hackathon experiment with work. Don’t mention fast, don’t mention the guide. Don’t do any of that. But just like, start from that point and then, and then later you can drop out here.

Here’s what we’re doing. It’s, it’s actually based on this thing called fast. What can we borrow from it? Do we wanna take from it? Do we wanna do fast by the guide or have we discovered something else that works just

[00:56:46] Drew Podwal: fine for. I miss hackathons. Um, I, I actually, Brad, while you were gone, the episode that we recorded, there’s a guy named Jamil Matine who works for Zencaster full-time, but he has a, a non-profit organization.

He, he was a Marine, I was in the Navy, uh, non-profit organization called fall in.org, and he runs a, a open hackathon every three months that’s virtual for veterans who are getting out of the military or recently separated for them to socialize and collaborate and, and build challenging things. And, but I, I miss the days of like going to hackathons, um, in New York City at like Huge Inc or wherever it was.

And, and AWS was there and Google was there and you know, all the swag in the middle of the room. Um, and such great things came out of those events. There’s a lot of innovation, um, opportunities to learn. Yeah, that’s

[00:57:43] Todd Hallowell: really cool. Yeah, I can weigh in on that last question too, just to for a second. I think and, and Ron kind of got there a little bit, but I think it’s just at a more, let’s just say existential level.

It’s more of a start where you are, like understanding what it is you’re doing. Cuz here’s the thing, right? I think we’ve said it a few times now. None of these concepts, the outcomes or the practices are unique. This isn’t Nirvana, I think Ron was the word you used, right? These things exist outside these frameworks.

So under helping the client to understand what are some of the things that you are doing already today that. We could incorporate that are minor tweaks. Um, I’ve had a real life example recently where I was able to do this. The client that I’m at had a big bang release with multiple different integrations that had to come together.

Big surprise here. Guess what? Big Bang stands for? Big blow up, right? That explosion. You heard that bang was not at all going into production. It was all falling, all falling apart when they tried to integrate four different applications together and they hadn’t talked to each other. So what did they do?

What was the response? They pulled these groups of people with all the skills necessary to build what they should have done in the first place together into a war room for two weeks, for 12 hours a day. on end for two weeks and they got all the stuff done, they got it fixed and they got it deployed and it was only a week behind schedule to get it through everything.

So when I asked him afterwards, cuz I was in a meeting with the CIO and the cto, and he said, so what would you have done differently? And I said, I’d have done what we did in the war rooms all along. I said, what you had was focus, you had a clear direction and a singular priority. This idea of priorities blows me away, right?

Priority comes from the Latin word, prioritize, meaning a single thing, right? It’s a single elite thing. Above all else, they had a given priority and they were given the focus and all the skills. To work through what they needed to do. And then when they got that done, they moved to the next. So what was happening in these war rooms?

Well, the product manager would say, we need to get this done. This is the goal, right? This is the big thing we’re working on right now. And the teams would step up and people would say, well, we need to do this for that. I’m gonna go over here and I’m gonna in breakout room too, and I’m gonna work on this.

Well, I’m gonna need somebody from this group. I got you. I’ll come with you. Well, we need to do this. Okay, I’m going to breakout room three. You know what? You’re gonna need my help. I got you. I’m coming with you. And it literally was seeing this thing evolve. So I think understanding and helping clients see that this isn’t nirvana, where are you?

How can we help you understand that this isn’t something new? It’s just adding a little bit of structure and, and this is my, my word for 2023, intentionality or intentional, you know, being more intentional in what we’re doing instead of reactive. If you can help clients see that, Hey, this isn’t Nirvana, this isn’t new, we just wanna add some intentional to it and help you with that, I think that the adoption becomes easier.

[01:00:21] Brad Nelson: Is this something that, let’s say I have a, a Scrum team and I’m doing most of Scrum, is this something that I could just introduce into maybe like my daily Scrum? Like, we don’t have a plan, but we know there’s work that needs to get done Daily Scrum, Hey, what are we gonna do in the next 24 hours?

[01:00:36] Ron Quartel: My, my introduction to you was through extreme programming and there’s a lot in common.

There’s a lot of xp a actually fast. So when my, my first XP team, I would, I’d show up at work at nine o’clock. By nine 30 we would have a, a, uh, a huddle. Wasn’t, wasn’t called the Scrum, but with, would stand in a semicircle around a board. on that board was everything that needed to happen in the iteration.

And then we’ll just talk around that semicircle usually in order. Sometimes it didn’t matter and, and when I showed up to work, I had a hunch of there was a couple things I might know what I wanted to work on. , I’d be really passionate about it or I might be like, I dunno what I’m gonna do yet. Or I’d show up and someone say, Hey, I’m gonna be be on this.

Who wants to pair with me? I’m like, yeah, I’ll do that. That sounds interesting. So every day we, we organize our day and, and it was emergent based on what happened yesterday and how we’re feeling the next day. And that was how I, that was, that was what Agile was to me. That was the best team I’ve ever been, I’ve always been looking for that in Havana.

And a lot of fast is, is me trying to get back to that. It’s me being selfish, like saying that’s sort environment I wanna work in again, by the way. And so it’s that, uh, all over again. But, but that you can’t escape it. So I’ve made self-organization inescapable, uh, now, which is kind of what brought to your point, maybe that’s what you gotta do for, for Scrum team.

Say, Hey, why don’t we, why don’t we loosen up a little more? And cuz that’s really what that, that scrum needing is supposed to be, isn’t it? Like, hey, , what are we gonna do today? Mm-hmm. , but come up with more emergence to, to that meeting and, um, to Todd’s point of, you know, maybe that’s your, your baby steps towards, um, moving to this space of, of a complex adaptive system.

[01:02:27] Todd Hallowell: I would say it depends, right? I mean, that’s kind of how we started with where I’m at, at this client right now. What’s the purpose, right? When I see it depends what’s the intent or the purpose? What are you trying to get from your daily scrum? If your daily scrum is there because the organization told you to do.

and you come in and it’s like, Hey, we’re status updating. We’ve all been there, right? We’ve all felt that pain. Probably not gonna be a good start, but if you’re using the daily Scrum as intended, and I’m gonna, I’m gonna, it’s an inspect and adapt opportunity. Learn from the last 24 hours so you can adapt your plan and how you’re gonna approach the work for the next 24 hours.

It’s very similar to what the fast heating is, right? We sync up on what we’ve done since we got together the last time, so we can adjust and reorganize and go back after this problem again. Now, if you’ve got a lot of different integrations and different complexities and different applications talking together, you might need to make your meeting a little bit bigger.

It might need to pull more people in, but I think that the intent of both is very similar. What’s our goal? Where are we trying to get to in this next iterative cycle? This next cycle, right? Let’s throw iterative out, like where are we trying to get to as a group in this next cycle? and then what do we know about the last cycle that keeps, that helps us to be more efficient in our pursuit of our goal in the next cycle.

If you are fo, if you think about the daily Scrum that way, there’s not much difference between that and a fast collective. It’s bringing the right people together to identify what’s important and then how you’re gonna pursue it together. I, I would agree to that.

[01:03:53] Brad Nelson: And it’s funny that you brought up XP, Ron, cuz I almost said that at the beginning that there’s part, like fast reminds me a little bit of XP where it may be a little extreme for people, which means it might be kind of hard, uh, to fit in anywhere.

But I’ve known organizations, Todd and I, uh, are both from the same area. And there was a competitor at one time that did XP and they were brilliant at what they. And they were very focused and they didn’t pretend to be what they weren’t, which is great. But I do wanna say, uh, this has not been a fast episode.

We’ve definitely, uh, used up a lot of time and, uh, , I could talk all night to you guys, but I do wanna make sure that I ask you about the training you guys are creating.

[01:04:39] Todd Hallowell: Yeah. Take it away. So, uh, Ron and I have been collaborating for about the last four weeks over the course of his move and all that added complexity.

We just love complexity, um, to build a training outline, right, and actually craft some of the first training. So the first publicly offered training will be coming up May 10th and 11th in Columbus, Ohio. I know there’s some others on the books as well. Ron is gonna be leading one, as I understand it, a few days prior to Agile 2023 in Orlando.

There’s one scheduled for, um, Copenhagen, uh, that Ron had talked about me going out to at one point. Not gonna lie, I’m a little disappointed. I don’t think I’m going. Copenhagen sounded very beautiful and nice to go to, but we’re gonna have the one coming up in Columbus. Um, so you can get out there and sign up for that.

But we are getting together for that. I’m actually going up to Detroit here in, um, on the, here in a couple of weeks to dry, run and build this training with Ron. Now, currently the training is going to be built in person. We, we both agreed that we kind of wanted that foundational in person. Training built first and then we’ll virtualize it.

Um, I have found trainings built virtually and then reversed into in person don’t work nearly as well as opposed to in person first and virtualize. Um, so we’ll be doing that, but um, the first training will be available there and you can find it at fast Agile dot io under the training site kind of and sign up for those there, get the links for that there.

Uh, we are excited about that. Think it’ll be neat to get people just kind of interested and learning and understanding really what this comes down to and, and honestly, you know, it’s a fast training, but it’s really just about getting people to focus on principle driven collaboration and how they can do the right things for the right reasons.

And that’s the lit by which we should be inspecting everything.

[01:06:10] Brad Nelson: And do I get a piece of paper when

[01:06:11] Todd Hallowell: I’m done? , we’ll give you a digital badge. You can stick on your LinkedIn profile. Brad, how about that? Perfect. Perfect. It’ll even have a teal color to it. . Nice.

[01:06:23] Brad Nelson: Yeah. Uh, and I’m actually, I’m speaking at a Agile beyond in a few months, and I’m still hoping to, uh, sweet talk Todd and Ron in the showing up there to, to maybe make a guest exp guest appearance, uh, TV d.

But yeah, so we’ve been talking for a good amount of time. Love everything in this episode. If you are capable of traveling for one of the first trainings, I think it will be awesome opportunity for anyone to be the first in. And on that note, what else do you want to share as kind of ending thoughts? Ron?

I,

[01:06:57] Ron Quartel: I was thinking of a, of a comedy ending like, Hey, come to this first training and we’ll, we’ll give you the special certification that you are at the first one. Training .

[01:07:08] Brad Nelson: They’re numbered. Yes. Numbered certifications. Yeah.

[01:07:12] Drew Podwal: Y Yk. .

[01:07:14] Todd Hallowell: I guess I would yuck too. The last thing I would say is that this, right, this isn’t meant to displace any of the existing frameworks, right?

This is meant to be another complimentary tool. If we as, as human beings, as servants of our clients in consulting or our employers, if we’re FTEs, have a real desire to help provide the most amount of value to the people we work for, to the clients we serve. If we have that true servant leadership, servant heart that we want, we can only be best equipped to do that with a broad set of tools.

This is another tool to add to that tool belt. I think it’s something they can get people thinking radical. Thinking differently. Like I said earlier, one of my favorite books is in Defense of Troublemakers, so I would say come to the class, learn a new tool, find a new way to make some trouble, to make sure that you are, you have everything necessary in your tool belt to deliver value where you are and that you can pick and choose from this buffet of, of abilities and perspectives.

Awesome.

[01:08:07] Drew Podwal: Oh, I’m excited for this. I think that’s awesome. And I am already looking at the registration page right now actually as we speak, so I might be one of the first, uh, I’ll treat you to

[01:08:17] Todd Hallowell: dinner. Drew, come on down man. I’ll take you out for a good dinner. Oh, sounds awesome. Yeah, yeah. Come visit

[01:08:22] Brad Nelson: us, . So what’s something, uh, I guess that you’re gonna take away from today,

[01:08:26] Todd Hallowell: Drew?

[01:08:27] Drew Podwal: Um, well, you know, okay. A couple of things. One, aside from those two amazing quotes, Todd, that you had, Ron, like you talking about the idea of, of development cycles parallel on the concept of a hackathon or the idea that like, uh, scrum meetings or Scrum events or PI planning or whatever your, your time box like boundary is paralleling a open space really.

Got me charged like that, I’m gonna think about those ideas for at least the next like week or two and, and figuring out like how to work that into my own coaching, right? Because both of those types of events, hackathons and open spaces always result in, in some really, like well charged people who are newly inspired have a set of direction and ideas and you know, if you put that at the heart of your team’s way of working, then the things they’ll be able to do.

Will just be tremendous, you know, the outcomes they’ll be able to achieve if you give them the autonomy and the trust and the space to work in that way. So I’m really like looking forward to seeing how this unfolds for sure.

[01:09:44] Brad Nelson: Yeah, I’m also excited to see where this goes and if it picks up steam, I think it’s fantastic.

You know, the thing that kinda stuck with me that I’m gonna be noodling on is some of your comments around about autonomy when it comes to like, we all have autonomy in our daily lives. Why is it so hard in, in the workforce? And it made me think of one of our last episodes with Patty who used to be a school teacher and talked about how our school system is set up to kind of teach that tayloristic approach to leadership.

But I’m gonna definitely keep noodling on that and I, I think as Agile Agilists, I often view us as being like altruistic. A lot of times in interviews I’ll say people work 90,000 hours over their lifetime. , and it’s my goal to make that as enjoyable as possible. A and so I just love this conversation of like, how can we make people awesome?

Right? Like modern Agile would say, uh, whether it’s our, our businesses, our stakeholders, our team, or our clients.

[01:10:44] Todd Hallowell: Love it. Well, thanks guys for inviting us on. It was a pleasure to get to talk about this and to, to meet you Drew and to share and kind of dive into this a little bit. Appreciate

[01:10:51] Drew Podwal: it. Yeah. Thank you guys.

This has been wonderful to be a part of this journey and get a sense and also, you know, to say that this is our first recording with four people, so thank you for being part of that experiment a little bit. It went well, I think.

[01:11:04] Brad Nelson: Yeah. Yeah. I appreciate you guys joining us. As Drew said, uh, I think I forgot to warn you, this is our experiment for four people, A and Ron.

I look forward to, to meeting you in person. Drew, maybe you’ll be in person too soon. I think so.

[01:11:17] Drew Podwal: That would be really cool. I would definitely love that. Awesome. So www dot Agile for Agile Agilists dot com is our website. Please feel free to leave us a message on Memo fm, which is embedded into the website, and you can record a voice message or you can just go old school and leave us a, a text comment.

We want to hear back from you guys and, uh,

[01:11:38] Todd Hallowell: thanks. Thanks everyone. Thank you. Thanks guys.