Enterprise Transition Work, and Where It Started
0:00Well, hello, everybody. This is another edition of the agileexecutive.com podcast. And as always, this is one of your hosts, Michael Coté, available at peopleoverprocess.com, as well as the agileexecutive.com. And we've got another guest with ourselves today. Would you like to introduce yourself? Sure. Hi, I'm Dean Leffingwell. And so what exactly do you do in the agile world? Well, currently, I'm mostly gainfully employed as a consultant and enterprise transition expert for very large software enterprises, transitioning to agile. Started this work back four or five years ago, working primarily with BMC Corporation. I was the executive mentor and coach working with Israel Gott there, which is probably how you hook me up here. And that was my first larger scale agile transformation, one that touched, you know, in the hundreds of people. And it was kind of fun because it was a Greenfield model and we were able to do all in, meaning we just, you know, started from scratch. We, you know, eliminated the, you know, the governance model and all the constraints and procedures and documentation protocols associated with the waterfall. And did that transformation starting in 2006. In 2007 or maybe early 2008, they published a case study, which you could find, you know, googling BMC Agile or on my blog.
Scaling Software Agility, and a Career Before It
1:20Since then, I've done a couple of things. I've written a book called Scaling Software Agility, which is probably the thing that captures my thoughts the best. I actively blog on enterprise agile. Off and on, a CEO, had a startup two years ago in the internet identity space and got that launched okay. Formerly, I've been an executive. I was co-founder of Requisite Inc. In the 90s, sold that to Rational. I worked at Rational for four years and, frankly, just had a blast working with some very talented people. So you're a Requisite Pro guy then? I am actually the founder of Requisite Pro. Yeah. That still comes up all the time. Like Red Monk, the firm I'm with, does a lot of work with IBM. And Requisite Pro comes up all the time. It's sort of like, it seems like it's been around for a while and everyone's used to it. And everyone's kind of afraid of what's next, if you will. They're concerned about migrating to the next sort of thing that Rational might give them. I understand. Requisite Pro has been around for a while. I think the first cut was 96 or so, maybe 95. I actually continued my responsibilities with Requisite Pro at Rational, but I also took on responsibility for the Rational Unified process. So at the time that I joined the company, it was a process called Objectory. And it was kind of an odd but really potentially powerful use case-driven approach.
Requisite Into Rational, RUP, and the UML Authors
2:43And we rolled that into Rational. That became the Rational Unified process. So launching and marketing that was one of my most interesting projects. I also had responsibility for Rational University. And I also had the privilege of working with the UML authors, Brady Butch and Ivar Jakobson and James Rumbaugh. So I was also, because of the tight coupling to the RUP, I had responsibility for methodology and courseware. So that was a great career until about 2001. I left just before the IBM acquisition. I'm not sure if they had sussed it out and knew I would never make the cut or I just got lucky. But in any case, I didn't go along with the ride for IBM. And basically, since about 2002, 2003, hooked up with some people at Rally Software. Ryan Martins, who is certainly one of my mentors and taught me much of what I know about Agile. And I might have taught him a few things about large-scale software development. So basically, since about 2003, I've been pretty fully dedicated to Agile, other than the last startup I did, which was, of course, fully dedicated to Agile, too. But we were a commercial vendor. We used Agile as our process model, not as a means to itself. So I have experience as both a CEO and a consultant in actually applying Agile development. Well, you know, while it's sort of a foil for Agile, if you will, but since you were involved in a lot of rough work,
RUP as a Box of Process Nobody Could Assemble
3:59I'm always curious, like, you know, as, I guess I sort of grew up as a programmer during the rough age, if you will. And it seemed like, it seemed like rough at, you know, this might be a little retrospectively looking at it, but it seemed like it was sort of like a box of process that you could assemble into whatever you wanted. And somehow, instead of being sort of a flexible process, when it was thrown out to the industry, both on the selling and buying side, it was sort of combined into everything in that giant poster that you would have, instead of sort of being guidance for assembling things together. And so, you know, for someone who's probably as familiar, you know, as you are with it, I mean, I wonder, you know, it's not so much like the snarky question of, like, what went wrong there? But, like, what was the, what would be that, what's the misalignment between what seemed like a pretty reasoned out, flexible sort of process, and then the rigidity that people seem to get upset about RUPP so much about? Well, you know, RUPP has a couple things going in its favor. And one of the first is it's the first real codified iterative and incremental development model. And shops are able to apply RUPP in a highly iterative and agile fashion, but that's not always the case. And because of the lifecycle overlays of inception, elaboration, construction, and transition,
Why That Was the Authors' Fault, Not the Users'
5:16I would say that, in general, you know, this was not the fault of the user. This was our fault. It was often misapplied as basically a set of iterations inside a waterfall model. The reason it seemed inflexible is that it was really big and it was delivered as a website. So while you could tailor it, it was no mean feat to sit down and actually tailor it. And then you had revision management issues. So it was easier to use it out of box. Now, since we were rational and we supported large customers, you know, clients like Ericsson, I remember, was probably our number one licensed user of many of our tool kit kits. RUPP had to be extremely broad. So it had to be really broad. It had to be reasonably deep. And it had to do both in a codified way. So it ran into hundreds and hundreds and hundreds of pages. And while there were smaller instances that were tailored, if you just got it off the shelf, it was just big. And because it was big and a website, it didn't feel particularly tailorable. And then if you add that to the fact that there are the lifecycle phases, which, you know, many applications go through. But we think far more of, you know, streaming models now than we do lifecycle development. You know, none of the programs we ever develop, that we develop ever really die, or at least not within a decade or so. So I think that the streaming Agile mode, I think, is just a better mental model.
A RUP Shop Is Harder to Move Than a Waterfall Shop
6:34But if you took that overlay out of those kind of assumed waterfall-like phases, it was, you know, really a well-structured and well-thought-through iterative model. Now, with respect to Agile, it's a lot more iterative than the waterfall. But at the same time, if you're dealing with a RUP shop, in some senses, it's harder to convert them to Agile because they're already iterating. And in many cases, they don't have quite the pain that the waterfall companies do. So it's not so easy to run into a, you know, a highly embedded RUP shop doing everything with use cases and move them to a more Agile model. Even though I like to do that, it's not a trivial thing. Yeah, no, I mean, there's a lot of sort of artifact friction, if you will, between moving between those two processes that seems like it would be hard to resolve. But, you know, going over sort of like you were mentioning, sort of maintaining long-running software projects and code bases, if you will. And what with the sort of enterpriseness of the enterprise Agile that you see a lot of. One thing I'm always curious about is a lot of the discussion around Agile that I see and I have with people is sort of about the first few versions of some software project. Like we're like making the new version, then we'll have the supported version, then who knows what's going to happen in two years.
Does Agile Work on Version 12 of Something?
7:54And I wonder, like, usually enterprise connotes it's been around a long time. Like we're working on version 12 of something, essentially. And I wonder, like, if you've seen, like, does Agile change when you're working on old software? Like how do things apply differently? Because I don't really read a whole lot about, like, Agile and maintenance mode, if you will. Well, you know, if you look at a group of just, say, any enterprise with, I'll just pick a fairly large, medium to large project team of 500 people. What are the odds that those people are all working on new stuff, right? Pretty low. They're probably, they may have 60 or 70 percent devoted to existing product lines, maybe 80 percent. And of that, they may have 30 or 40 percent of that time or even more doing ongoing maintenance. So, you know, in the enterprise, you find more legacy code because you find more code. Now, the way I look at legacy code is if I take a Greenfield project and look, you know, look at that same project, two days later, I have new legacy code, right? All code is legacy code. The only question is how old it is. Right. You know, it might be three hours old because it was my last iteration. Now, good agile development creates legacy code that's more maintainable because if you follow, really do agile right and you embed, you know, many of the XP principles and practices along with the scrum project management practices, you'll create more maintainable code.
Scrum Fits Maintenance More Easily Than Greenfield
9:21Now, having said all of that, when it comes to the basic scrum-like software project management practices, it's the same. I mean, even doing, it's in some ways easier to do, start something like maintenance with scrum with a daily stand-up and a short prioritized backlog and setting objectives rather than just, you know, fixing what we can. And trying to theme a sprint or a maintenance release to provide value added in some domain or some kind of requirements area where you gather together a few defects and try to make an impact. So I would say in many cases it's relatively straightforward to add agile to the enterprise, but then you hit test and test automation and people freak because they can't possibly go back and add test automation to their legacy code any more than an agile shop would touch, you know, the code they wrote two years ago and say, okay, we're going to add test automation around all that. It mostly doesn't happen. So whether it's Greenfield or not, I think you mostly have to approach it incrementally. And what I try to get teams to focus on is let's worry about the new code. What's one of the interesting experiences that I just have with an agile team is in transitioning, it's about 110 folks, 30 or 40 of whom work on a particular client-side application. And they had built a lot of inventory. They had a lot of code that was written and untested and undeployed. And consequently, they couldn't put anything new through the system because it was bottlenecked.
Unsoldered Boards, and Moving Test Inventory Out
10:38And it was, you know, basically like a bunch of unflow-soldered circuit boards sitting in front of the flow-soldering machine. So you couldn't push anything new through. And we got them very oriented on moving their inventory out. And what they meant by that was testing what they had. And they became very, you know, kind of conscious and started doing test automation and realized, oh, my gosh, this is coding. And it's not drudge work. It's not just manual testing. It's really hard work, and you really have to think through it. And we had some discussions then about the next new release, which was about ready. And all the new stuff had been tested. And they said, well, we're not really comfortable yet because we haven't really been able to add much test or test automation around the rest of the application. And we had to remind them that the rest of that application was already deployed to something like 10,000 users. So we probably couldn't stop right now and add additional automation to what was already deployed. Right. There was no sense in converting your customer-based, you know, unit tests to code-based unit tests, I guess. Yeah, I mean, it was just – and the problem becomes kind of imponderable. So you've got to, you know, not go overboard. And like I said, I like to focus on, you know, what could be done incrementally. You know, what's the next thing we can do to, you know, lay down some new good code? And, you know, if you're a good XP fan, you understand refactoring.
Improving Code as You Touch It
11:54And when you touch a piece of code, you try to improve it. Yeah, definitely. So getting back, you know, also to the enterprise part of Enterprise Agile. And actually, you know, I was at BMC myself during all that. And I think I remember seeing the back of your head from the back of those giant rooms where we'd have meetings. The big planning meetings. Okay. There you go. Right. And, you know, the thing that I found when we were doing all that at BMC and then subsequently when I switched over to the dark side of industry analystdom, I guess, when I was talking with people about it, is that, you know, while there's a lot of sort of entrenched developers and even QA people who get all upset about switching to Agile, the sort of, like, next challenge becomes, like, plugging it into, like, the product management and the marketing and, like, the whole – the sales and the whole rest of the organization. But, you know, essentially any process, software development process you have or methodology is sort of a leaky abstraction that sort of drives what goes on in the rest of the company. Absolutely. Absolutely. You probably remember when we were moving the, you know, the internal release cycles on the BMC product from, you know, on the order of 12 or 16 months down to four months. We thought that would be infinitely good food until we started talking to training and support and the sales team and service level agreements.
What Happens When Agile Hits the Rest of the Company
13:13And, you know, it really hit the fan at that point. And that was just – I think that reflects our own naivete about how much impact Agile does have in the enterprise. So while that is absolutely an issue and I deal with it a lot, we see, you know, conflicting governance models, issues of, you know, not being able to do what I call the Agile release train, building PSIs because people think that's a release. And if you call it an internal release and everybody knows you're going to release it and, you know, the hackles go up everywhere and we're not going to release that often or whatever. There are a lot of challenges there. Well, I have to tell you, though, there are second-order challenges because the first-order challenge in an organization of three, four, five hundred developers and testers is can they write code in an Agile manner? You know, can they build code in a time box? I have it tested and ready to ship. So I don't – when I approach organizations, unless they've already hit that problem, I don't lead with the issues you're going to yet discover. Oh, sure, sure. Because, you know, the Agile process will expose them. They will be there. But I try to be concerned about those on a just-in-time basis. And if the teams can't get more reliable about the release dates, there's no sense in bragging about how fast they're going to be anyway. Yeah, yeah. There's a certain – you know, you've got to worry about your own health before you worry about your future wardrobe, I guess. Absolutely. And what you might be wearing.
How Much Depends on the Project Office
14:28But so when you do get to the point of the future wardrobe, I mean, how – are there sort of, like, standardized ways of working with sort of the rest of the company? Or does it end up being sort of, like, customized for each company? Because, you know – A ton depends upon the size and scope and strength of, you know, the project office or the PMO. And that varies tremendously. I mean, I work in enterprises where that is basically, you know, to tease a little bit, the mothership of all impediments, right? Right. From the standpoint of, no, those are just kind of project managers and they kind of help the teams. A really robust project office, you know, PMO, is a pretty – I don't know. It could be a potentially really large adversary because they've built their whole world around a couple of things. Basically, commitments that they like to think they can make on a very long term that none of us ever meet and we're all embarrassed. But if you take away even the pretense of a long-term commitment, it, you know, it undermines their whole – kind of their whole thought processes. And then if you take away all the governance things they use, you know, the design complete milestones and the test plan complete milestones, but you haven't put in place actual agile development where you're creating, you know, code in – you know, potentially shippable increments short term, you've given them nothing.
Why "We're Agile, Drop Your Milestones" Loses
15:58So I would suggest that the way not to approach that is as follows. You go there and say, look, we don't make those long-term commitments anymore and we don't need your bleeding milestones. We're agile because you will lose that argument. Those are big, beefy boys and girls and they have organizational prowess. They understand the politics. They have controls on all the, you know, the quality assurance guidelines. They interface to the customer. Many of them really are effectively the Uber product managers because they drive programs into the market. So you've got to really approach that, you know, that – those gates with some healthy and hefty respect for the problem that is ahead. And in many organizations, they're small or they're, you know, they morph very quickly. And others, like I said, they are the mothership of embeddements. And you have to take that on not, you know, not in a frontal assault way because that brings up the wrong connotation, but directly and persistently. And you have to be smart enough to understand that just because, you know, these new scrum masters and these new ex-peers have some ways they think that are better, those aren't really arguments that sell well in their project office. They don't get scrum. They don't write code. That's not what they do.
Barbarians at the Gates
17:13So – and you can't talk about XP practices and the philosophies are just, you know, a piece of it that they don't necessarily ascribe to as well. You know, the teams are empowered and then the best decisions are local decisions. So it's kind of a, you know, a worthy adversary and we are the barbarians at those gates. Yeah, it seems like sort of pulling together a couple of things you've, you know, you've said about the development, the agile development team fitting into the rest of the organization. It's almost as if you have an existing process, if you will, that you have to apply a sort of like old design pattern where you kind of have a facade going on where you interact with the rest of the organization in whatever way they're used to interacting. Meanwhile, you're transforming yourself and slowly you're changing what those interfaces are to the rest of the world. Just to pick one, like, you know, until – to your point, until the development teams have become agile themselves, they can't really give good metrics that fit into the rest of the organization that's always expecting metrics. Correct. So that's iterations or testing or things like that. And it seems like if in flight you want to change stuff, there's a bit of – there's a lot of overlap of reporting in the old style and interfacing in the old style until you can convert everything over to an agile way of doing things.
Writing Adapters for Milestones You Cannot Remove
18:29One large organization I worked with with about 1,000 practitioners had a very stiff PMO. And yet at the same time, you know, at the team level and at the software engineering management level, they recognized that they needed to go to agile in order to be able to survive and thrive. And what they ended up doing was coming up with a set of adapters because there were design review milestones, if you will, and test plan complete milestones. And, you know, defect counts that had to be at a certain level before you could ship software. And those were really orthogonal and in many ways in conflict with the agile process. So it's not that agile development that people don't do designs, but it's unlikely they have a thing that they could ship for review by others. And that basically building the friction of, you know, stopping that team and saying, okay, you need to pass this milestone before you go on, builds all these non-lean delays into the process and just really, you know, frustrates the pig, if you will, on the agile teams. So even with adapters, it's not a trivial problem. And, you know, you just have to take each organizational context into space and you indicate, sorry, into mine. And you look at each case specifically and say, how far can we go here before we get into what kind of trouble?
Five Hundred People Take a Year or Two
19:47And do we need adapters? Do we need, you know, some PMO people on our team? Can that be restructured? Can we lighten the milestones, you know, to less milestones? You know, what can we do to soften that up? Because at the enterprise level, if you're seriously dedicated as a team and you're talking about teams of teams, let's take 500 people. Ask yourself the question, how long will it be before those 500 people are really agile and able to ship a PSI every 60 days? And the answer is a year or two. Well, that can be a pretty long time to deal with all those adapters as well. And yet the alternative is worse, which is you don't get to be agile or you basically go into water scrumming mode, which is you go as far as you can. You have design iterations and then you show your design review and then you have development iterations and you show your code and the defect count. And then you have, you know, quality iterations where you add test automation and you end up programming yourself backwards into the waterfall model, which is what those governance milestones were generally designed to enforce. Yeah, yeah. That's interesting. And so I had a follow-up question, but I seem to have forgotten it. But it does seem like – well, on a somewhat related topic. So having been from BMC, I do a lot of sort of IT management following and coverage.
Operations People Discovering Agile
21:02And I've been noticing, especially with a lot of the sort of cloud computing talk that goes on nowadays, it seems like there's a lot of IT department and operations people who are sort of like discovering some ideas of agile, right? And it seems like there's some interesting potential for sort of agile operations, if you will, or like people applying agile things to setting up IT infrastructure. But pulling back a little bit to the here and now, especially since you said you were running a sort of an online identity sort of thing, I wonder how you've seen sort of the development team, like delivering fast iterations, fixing in with the IT department or the administrators who are just sort of the ones who – you know, this is the cynical way of putting it. But you throw the software over the wall, but you throw the software over the wall, and these people are in charge of making sure it's up and running. And, you know, it seems like even more so than PMO folks, these people don't want anything to change. I mean, their ideal world is I set something up and I never have to touch it again. I agree, and there are certainly challenges there, but I would have to say that I think the challenge there is more just coordination and cooperation with IT who has, you know, distinct milestones, you know, IP addresses they need to set up, servers they need to stand up, firewalls that need to be breached or whatever that can really affect your development model.
Inviting IT to Release Planning
22:20And, you know, these ships generally run in largely, you know, parallel universes. IT actually has a fairly fast duty cycle. In many ways, you know, they can do things in some cases much faster than the development team laying down greenfield code. So what we try to do is basically invite them to play, and at the enterprise level, the invitation gets extended primarily at the release planning boundaries and try to kind of influence their model that way, make sure they have their stories and they know what iterations they're in, and influence them over time. Such as eventually, you know, they will tend to adopt the agile model, and I've got a couple cases right now where IT is getting it. They're involved, you know, after the third or fourth release planning session. They're doing better. They may have a daily stand-up. They know to attend the demos because they have stories for their IT work. So you can get them ingrained. I wouldn't say that, you know, the PMO, because we've taught them essentially our waterfall model over the last 20 or 30 years, in many ways is philosophically misaligned, you know, long-term. Big, you know, enterprise class, you know, aircraft carrier commitments. Because it's a huge commitment, then we have to have all the design done by March. You know, we've taught them models that don't work very well. I don't think we've taught IT models that don't work very well.
IT Is an Easier Problem Than a Stiff PMO
23:36I think IT has been largely on its own with their, you know, their kind of quick fixes and patches and upgrades, et cetera. So it's not a killer with IT. I think in some ways it's easier than the project office, especially if it's a pretty stiff project office. It's just one more impediment to work through. I would say that in general when you start the agile process and you increase the communication with those folks and you talk to them every day or every sprint, a lot of your fears really go away because it turns out, you know, their paycheck is exactly the same. They come from the same gene pool. They live in the same city. And even though they've been in this other department, they're really trying hard to do a good job. And when the development teams realize that they've also got to, you know, upgrade, you know, whatever, their whole IT infrastructure or, you know, a new vignette release at the same time that they've got to stand up this new server so I can deploy my new web application, you start to get an appreciation of the problem. And I think that appreciation causes each of you to look at each other a little bit differently. It's a less jaundiced eye. We're all working here and it's hard. And once you understand each other better, you can build trust because of the understanding. Whereas right now, you don't know what they're doing, but they're not doing the stuff you want them to do. And that doesn't matter which side of the fence you're on. The developers are working on stuff. They don't really understand what real deployed infrastructure is like.
Communication as the Whole Mechanism
24:53The IT people are doing God only knows what. They're upgrading Exchange server, but I can't get a web app stood up for the life of me. So really, just communication. Yeah, I mean, exactly. Both literally and figuratively, a lot of these, like you keep coming back to the problems get solved when you get to people in the same room for some amount of time. And just like have them understand each other, which for as much as we're probably both smiling about it, is an extremely difficult thing to do in the overall IT department with developers and all the different stakeholders and IT folks. But it was hard for us, too. I mean, we had firewalls or literal walls between developers and testers, and that was the test department, and you didn't go over there. And I know one organization that had this document they called Tech Specs, which as near as I can tell, were detailed design docs you wrote for the purpose of not having to actually talk to a tester. Exactly. So, you know, when you put those people together, yeah, it's awkward at first, but then pretty soon they're forming a team. And, you know, the face-to-face communication of the Agile Manifesto, that's a really big hit. And I don't think it was any easier to get our developers and testers to talk than it was to get IT ingrained. And I just look at it as a kind of a continuous envelope of enhanced communication.
Release Planning Is the Enterprise's Sprint
26:11I tend to structure that around release planning, which is, you know, kind of my mantra, you know, the cyclical cadence. I think that, you know, release planning is for the enterprise what a sprint is for the team. And once I have that kind of cadence locked in, then I know when I need to talk to them, and I know what commitments I need to try to get from them and what commitments I need to deliver to them. And then all of a sudden, it's, you know, it's just one big team. So a lot of it is this, you know, this concentric circle of a small team, a little larger team, a team all the way through the PMO, and eventually the enterprise. It's just that it takes, you know, years to achieve that. You know, even if at all levels everybody wants to do the right thing and they know they want to be more agile, I think one of the problems we face is who doesn't want to be more agile, right? Oh, of course, we want to be more agile, but what does that mean? So it's just, you know, a growing ring of influence that starts in my mind with the credibility of the team. Yeah, everyone loves a homemade pie, but no one wants to cook it. One of the groups I was with, we basically were doing our release planning, and we were multiplexing between kind of too many code lines. And we decided that it would be best if we would, you know, kill one. And in so doing, there were going to be some pains, and there was going to be this deliverable plan that might not happen on the plan that we had. And we went and discussed that with the CEO, and basically it was kind of funny because he didn't think the team was going to be on time anyway.
Credibility Comes From Meeting Small Commitments
27:28So when they came up with a credible way to improve their performance, he supported it fully. So we didn't even have enough credibility in that case to make good arguments. So you start by regaining that credibility by getting, you know, the essence of trust generally is to make a commitment, meet your commitment to somebody. So if a team can say, okay, in two weeks we're going to do this, and they do it, and then 10 teams do it, and then 30 teams do it, and then that thing becomes, you know, a big increment, an internal release, or maybe even a release, then the whole organization says, wow, I think we can trust these guys. And by the way, they have some issues to discuss, versus, hey, they're the developers, they're always late, code quality is crap, and they're telling us we need to change our behavior. Yeah, no one really trusts what they regard to be a bunch of bozos, so you have to establish that credibility. It's almost, you know, you have to use the old sort of like the positive transference of negative energy or like judo stuff to basically pander to low expectations ahead of time. Like if this person doesn't think you're ever going to deliver anyways, then even if you do like half a bad of a job as you could do, that's still tons more than they thought was possible, and you can just will down until you actually do a good job. Undercommit and overperform, and then when you engage with teams, they have all these huge worries, you know, like the PMO and milestones and what are we going to do about IT, and, you know, I generally put those worries aside, and I have to say is that when the teams are performing, those worries come into context, and also they evolve.
The Feared Obstacle Is Rarely the Real One
28:59So the fear that you had, and I know a number of situations where we feared that this would be a big challenge. By the time we got there, it wasn't, and something else was in its place, but none of it really matters until a team of teams can actually build some software that works. So you just try to talk to the teams, let's not worry about that, let's get some credibility, let's see what we can do in two weeks or a sprint or 60 days, and, you know, in maybe six months or so, we'll be fairly decent at that. And by nine months, we're going to have real credibility, and then the impediments will actually be more obvious. They'll start to be seen before we even get there. It's not like the rest of the institution is stupid, you know, the buzz and the rumor mill and all the politics. They'll work in advance, and people will see those things coming, and the problems will actually move. So if you started a natural transformation, you said our problem is A, B, and C, and yet the teams couldn't yet write code that worked, by the time you get there, they're going to be D, E, and F. So why bother? You know, it's not the last responsible moment to worry about that next-level problem when you're trying to get a team to write good quality code that works. Yeah, yeah, there's no sense building road humps when you don't even have roads yet. It seems like the main issue. Well, great, well, unless there was anything else you wanted to mention, I think we had a nice little episode there. No, it's, you know, I kind of talked about the things that I'm currently engaged in, and you got your questions in, so I'm good if you are. Well, that sounds great. Well, thanks so much for spending this time to talk with us today. That was good stuff.
Machine transcription, lightly formatted. Chapter headings were written from the transcript; speakers are not identified, so nothing here is attributed.