Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/dev ops: shipping without drama
54 Plays1 year ago
John Kimball joins the podcast to talk with the team about Dev Ops, Agile, and mistakes companies make when adopting Agile.
Recommended
Transcript
00:00:02
Speaker
But I thought DevOps Days really built upon the momentum of the Phoenix Project, really carried that movement forward. And it's one of the best revolutionary movements that have happened in IT in my 35 years.
Podcast Introduction
00:00:27
Speaker
Welcome to the forward slash. I am your host Aaron Chesney with my beautiful co-host James Carmen. James, who do we have on our list of victims today? I am so excited. ah John Kimball, this this is like a blast from the past. I'm so happy to see you, John. We worked together a long, long time ago, many, many years ago. I won't mention how many, but ah John reached out and and you know said he's been listening to the podcast and he'd be interested in coming on and and just
John Kimball's Career Overview
00:00:57
Speaker
chatting with us. So ah John Kimball, tell us a little bit about you know you know who you are, what you do, all of the fun things, you know how how you got to where you are today.
00:01:06
Speaker
Sure. My name is John Kimball. I am in the middle of my fifth decade working in professional IT. I have been in IT for 35 years. That means I started my career in 1989.
00:01:20
Speaker
ah If you were to describe my 35 years, I'd like to break it up into three chunks to be as quick and descriptive as possible. So the first 10 years, I was a UNIX-assisted man. I worked with many different flavors of UNIX. Started with Microport, went to SCO, went to Sun, went to Solaris, went to AIX, ended my UNIX-assisted man career in 1999 with Irix. The SGI is a beautiful flavor of UNIX.
00:01:54
Speaker
ah Then a good chunk of my career, I'd say 20 years, right in the middle was Web Systems Administrator, Web Application Server, discovered, ah hey, I think this Internet and Web thing is going to be big. So I might want to pivot off the Irixes and the AIXs of the world and go and become a Web ah Server Administrator, Web Systems Administrator.
00:02:21
Speaker
and eventually evolve into an application server administrator. So that was hard, I'd say for about 20 years. So that was good, long time for IT. Pivoted off of that and I was like, you know what?
00:02:33
Speaker
I think this DevOps things got a shot. I think this is really going to take off. I think I really need to start moving my career into those fields and into some newer fields.
Transition to DevSecOps
00:02:46
Speaker
So for the last five years, I was a DevOps engineer briefly, but now I'm a DevSecOps engineer.
00:02:54
Speaker
ah Again, it it appeared like DevOps was, hey, this is good. And then it was like, man, there's a security component. And the way I looked at it was,
00:03:06
Speaker
Security vulnerabilities are never going to stop. And the hackers are getting better. So this field looks really hot, real stable. And it looks like when I first started, a field where there's more ah demand than availability. So I've been doing DevSecOps quite a bit for the last five years, currently doing it now.
00:03:32
Speaker
ah Let's see. Personally, I've been married for 28 years. I have a son who's 25. I have a daughter who's 22. I live in a house in the middle of my street. So you mentioned it's pretty cool. You seem like you took a very, very deliberate path through your career, kind of and analyzing and looking at the market and seeing what's hot, where do I need to position
Influence of 'The Phoenix Project'
00:03:53
Speaker
myself? What what drew you to to DevOps what specifically?
00:04:00
Speaker
ah Good question. ah started well the big thing is the Phoenix Project that's what drew me the Phoenix Project came out they're like you got to read this book you got to read this book I got it I read it it was mind-blowing I mean it was like oh my god this guy is talking about us he's talking about everybody really he's talking about everybody This book, ah if you read that book and not go have an oh, yeah moment, then I don't know what IT branch you've been working in. Maybe you're working for like a mom and pop shop probably. But again, I mean, that was an enterprise book. But ah that
00:04:41
Speaker
That really opened up my eyes. And I was like, yeah, this guy's onto something, Gene Cam. I met him briefly at a conference, which is one of the highlights of my career. ah But yeah that really opened the door for me. And I it was like, guys, you got to get this book. You got to get this book. I mean, the book is free. There's an audio podcast of it free. Just go to SoundCloud. You can get it for free. Listen to it.
00:05:09
Speaker
i mean it will change the way you work. So that was that was a big aha, but big moment in my IT career. Yeah, i I did the book um on audio and it was it was a good it was a good book to listen to as as far as, you know, cause like some technical books that you get into that you're like, oh, I can't listen to this. They're just droning on about numbers and code blocks. And I can't see the examples, but this one, because of the way the the writing style and the way they present the material as more of a, like a novel,
00:05:45
Speaker
it It reads very well and is I highly recommend that to like anybody. like I do a DevOps talk as part of our onboarding at Collabority here and i I recommend that to everybody coming through the door to listen to that book.
Impact of DevOps Days Conferences
00:06:01
Speaker
ah Really quickly, I think what really also like built upon the momentum of the book was that DevOps Days Conference was shortly after that and all across the country. And now it's all across the world. And those conferences were dirt cheap. i Compared to other conferences, especially the ones ah sponsored by vendors,
00:06:25
Speaker
that those conferences were dirt cheap. So they knew, they were like, look, this is a movement. We need to get people on board. What's the best way to get people on board? Well, heck, we'll have conferences all across the country for a hundred bucks. And they're like three, four day conferences with all of the leaders. We got the guys who invented DevOps. We got the guys who invented the term. We got Gene Kim. I mean,
00:06:51
Speaker
And so that we went to, I mean, I've been to a bunch of them. i Matter of fact, I've even spoken at two. But and I thought DevOps Days really built upon the momentum of the Phoenix Project, really carried that movement forward. And it's one of the best revolutionary movements that have happened in IT in my 35 years. Yeah, that one in the the, I haven't read the follow, I have the Unicorn Project, but I have not. ah read it yet um
00:07:22
Speaker
The other one ah that I always tell people is, is accelerate, right? I mean, that was yeah one like that. If you're and you know selling it to developers, the unicorn or the Phoenix project, like we get it. We were like, yes, I'm bought in wholesale, right? But trying to sell, you know, sell the notion of DevOps to those, you know, kind of pointy haired bosses type folks, accelerate is a fantastic book for that. That's, that's actually putting, you know, this is, <unk> you're going to get return on investment. Like there's real money here. Doing this is actually a good thing for your business, not just,
00:07:52
Speaker
the geeks that that that want to do fun stuff, right? um So that that one's always been one. I think I've, I don't know how many copies of that book I've purchased and given away, but I give that thing out like candy and, and you know, especially with clients, you know, hey, this is a fantastic book. It kind of helps you. you ah understand the way we think about software engineering. I read most of the Unicorn Project. It is definitely tailored towards developers, but to your point Accelerate was first. Accelerate was way before the Unicorn Project. I need to read Accelerate. It's on my list. Yeah, it's a good one. You'll like it.
00:08:26
Speaker
I may have a copy of that. Oh, nice. so jack like i might have a guy I think I have a copy of the unicorn project if you've lost yours. I think he keeps it by the case. he just the it's like here you go here's number i know i got my copy right here yeah I probably gave that to you.
00:08:46
Speaker
yeahve I'm a book guy. I hand out books to people. that's I feel like that's one of the best gifts you can give someone is knowledge. so that's i don't know It's a cheesy statement, but it's it's true.
00:08:58
Speaker
um DevSecOps, in what way, like to kind of explain that a little bit, like what what what do you think that that means and in introducing security in the mix? yeah how How does that happen?
DevSecOps Approach Explained
00:09:11
Speaker
so The big thing about DevSecOps in my mind is shift left. Let's get ahead of these security problems as soon as possible in the development cycle. so let's shift left and So that's a different mindset big time prior to DevOps. I mean, good God, waterfall, security maybe came at the end.
00:09:39
Speaker
during the pen tests and stuff. And that was it. So this is a total revision of that. It's like, no, you don't wait till the end of security and then scramble and then go, hey, dudes, we're going live tomorrow, whether these are fixed or not, I've got V2 sign off. So you go live vulnerabilities and all in the old waterfall methodology. So in DevSecOps, it's like, well, let's flip that.
00:10:06
Speaker
right Let's find these out really early in the development process. Matter of fact, let's find them out in the IDE as the developer codes. Boom. This is critical, dude. you This is not going to go live until you fix it. so That's the big takeaway I've had from DevSecOps. Again,
00:10:32
Speaker
It's a collaboration, and it isn't throwing things over the wall. Oh, good luck, Ops. And then, you know, who's to blame for all the vulnerabilities? Oh, well, he wrote the code. Well, he deployed it. Let's get out of that game. That game did nothing. That did nothing. Didn't help the business, I'll tell you that.
00:10:54
Speaker
Yeah, nobody won with that. Nobody won. Too much finger pointing. Nobody, if you're if you're not accountable for the running of the software, you'll you'll take shortcuts. What do I care? I don't have to run this thing. It falls down on his face every night. John, that's John's problem. I'll let him deal with that, right? that's That's not cool. I always call that like the blame salute, where it just it's just one of these guys. Yeah, yeah i mean it's either this guy or this guy. Not me. It's a famous miss one.
00:11:24
Speaker
Well, that's very astute of you. I love, I love the fact that, you know, you, you came from a, an ops background, primarily, you know, system administration on Unix and then into like more web admin. ah lot A lot of, you know, those kinds of folks felt like DevOps was a threat to them. Right. And they, they kind of fought against it. So I love this. Yeah, I did. you I thought it was, you know, I thought it was very revolutionary and I was like,
00:11:49
Speaker
You know, there was too much. I mean, after decades of animals, between death and ops and throwing things over the walls, like, at least you got to give this a try. I mean, come on. And it's, you know, collaborate. Talk to the developer. I mean, do you think the developer wants to write bad code? Do you think the developer wanted to create a war file that when you deployed it had an infinite loop? but you know, sucked up all the CPU resources on your server and paged you at night. I really doubt it. He's probably under stress to make a deadline. He made the deadline, but let's get let's get out of this game. This gets us out of that game. It's worth a try. A loop of blue screens of death, that's not what we need. Nobody wanted it to do that on purpose.
00:12:43
Speaker
Well, and that used to be my secret weapon for getting things done back in the day too was I'm going to befriend at least one ops guy that's going to help me get my stuff working and in work with them. And, and always, it was always kind of like.
00:12:59
Speaker
tiptoeing, walking on eggshells, you know, kind of ah approach until there was that level of trust that, okay, this guy isn't going to point fingers at me. He's really just looking to make his system better. And and once we got on even footing,
00:13:15
Speaker
then we could get things done. And then and and this was this was back in the 90s before the whole DevOps movement and and all of that. and And then when I heard about the DevOps thing, I'm like, oh, yeah, that's what I was doing. I'm like, yeah yeah, that works really well. yeah Yeah, there was a time I collaborated with a bunch of developers and I was like,
00:13:40
Speaker
Hey, that was good. And it was funny. It was like, you know, prior to that, it was always an ops first down. It was always a bad. I was like, God dang it. Do you test your code? And again, I'm i'm coming from the ops side. So yeah i'm in I'm in the ops camp. So I'm like, did you test your code? Good God, I'm on this bridge because of your code. Well, it works on my machine. But then one time, this this developer was like,
00:14:11
Speaker
We deploy this code. It works in dev every time in prod. It just sucks up all the resources. Let's let's work together on this and figure out what the culprit was. Culprit, bug in the app or app server.
00:14:26
Speaker
So really mine, but nothing I could have fixed unless I dug deep and memorized all the QM fixes that the vendor had done, which is never gonna happen. But ah yeah, lo and behold, you collaborate and it was like, oh, we need a QM fix for the app server. Put the QM fix on, boom. Apps, totally stable. All right, what's a QM fix? What's that stand for? Cumulative fix. Cumulative fix.
00:14:56
Speaker
a term a vendor loves to use that has three letters. I got you. I've never heard that one. Yes, they're famous for, the the three-lettered vendor is famous for cumulative fixes. I got you.
00:15:12
Speaker
Okay. Very cool. All right. So you've obviously had a ah ah ah great career, a long career, and you' you've seen a lot of things. Can you recall any like particularly sticky situations that, I mean, I should have shared one just now, but like anything in particular that jumps out at you through your career that you, you know, really rough situation you had to work through and and how did you get through it?
00:15:36
Speaker
So yes, I have one. I'll never forget it. June 2015, it was a warm day when my boss came up to me and was like, dude, we've got this proof of concept. And I've been listening to the meetings. And I was like, I'm sending in the big guns I'm sending in Kimball. Go in there and fix this proof of concept out of control.
00:16:04
Speaker
So I was like, oh boy. So I go in there and they're all the other. I'm like, where's your Kanban board? What's a Kanban board? Oh boy, we're going to have some fun. Okay. We have Jira.
00:16:21
Speaker
We're going to use a Kanban board. We're going to put tasks on the Kanban board with names on them. Those names are going to be accountable for this task.
00:16:34
Speaker
um They had some contractors they brought in doing project management. I don't know what their technique was. I'm thinking it was rockfall technique, the reverse of waterfall. So I was like, yeah, it's 2015. We're going to use Agile. ah You might have heard of it. No, we haven't heard of it. All right. Well, you're going to hear of it because that's what we're using and from here on out.
2015 Crisis and Agile Solutions
00:17:01
Speaker
We're going to use a Kanban board. We're going to have what they call Scrum meetings. We are going to meet. We're going to be locked in this room. That's another thing. We're going to be locked in this room until we figure this proof of concept out. And we're going to deliver, because I've done this before, and we've always delivered. So it's got a shot. And from what I'm hearing, you guys got no shot where you are now.
00:17:25
Speaker
So, we're going to be locked in this room. One, two, we're going to have a meeting every morning and every afternoon before we leave at 3.30. I'm going to hear three things out of you. What you did today, what you're going to do tomorrow, who is blocking you? Because I am the unblocker, so I need to know who is blocking you.
00:17:48
Speaker
So this was just a hodgepodge of technologies. I'll bring one up. You used to be familiar with, Jim. WebSphere Commerce Suite. Oh, nightmares, nightmares. This had WebSphere Commerce Suite. This had Samsung tablets. So the project was we're going to put kiosks in store. We're going to put tablet kiosks in store.
00:18:13
Speaker
so ah Yeah, web server commerce suite, little bit old web server application server. The other thing I come there and it's like, we're waiting on machines. We're waiting on machines. I go, no, you're not. There's this thing called the cloud. We're going to provision a machine in minutes.
00:18:33
Speaker
We will go live in the cloud if they don't if we can't get the machines provision, folks. You leverage the technology that is at your feet. and Some of you came in from the cold, I get it, but we're going cloud from here on out until the prod machines come online. So at least we can start doing development efforts. So long story short, we made it. um Employing some agile technologies, we made it. ah We delivered ah and yeah, there were kiosks in the store for a proof of concept store in 2015.
00:19:10
Speaker
i love that I love that concept of use the resources you have available and because there are many times where people think that they're blocked when it's like, no, you have you have resources available to you. I remember running shadow servers under somebody's cubicle desk because we couldn't get rack space or you know ah our budget wasn't approved for server orders or we didn't even know what the server stack needed to look like yet.
00:19:40
Speaker
And so we're like, well, we've got to work as a team. We got to make sure all of our stuff works together. So we're just going to run the shadow server here, or we're testing out a new process. I remember, um, and at, at Cengage, we were running our Jenkins servers on PCs in every, in every team space. And so everybody had their own like Jenkins server who may have been Hudson at the time.
00:20:08
Speaker
But, it you know, it it was, you control your own Jenkins until we can get to a spot where we've proven this out and we can get, you know, better resources available. And lo and behold, a couple of years of doing that and no more Jenkins servers in the team spaces. We've got, you know, rack space that has, you know, several nodes available for building and we didn't have to worry about it anymore.
00:20:35
Speaker
Yeah, yeah. I've been down the road of PC development, too. The one thing is funny is people are like, we need a development environment. We need a development environment. Guys, a development environment has a 0% SLA. Do you really care the platform of development environment is on? Heck, we're going to run these off of a freaking network of PCs if we have to. We need to deliver a product. Do not.
00:21:03
Speaker
hold the, I don't have a dev environment. And again, that's gone away with Docker. And I mean, that's gone away. So we're talking the old days. So some of the young folk are probably like, what are you guys talking about? I was like, yeah, there was a day before Docker and it was not fun. You had to wait for dev environments sometimes.
00:21:24
Speaker
Yeah. I love being able to run everything locally now. Especially for languages that were dependent on a native environment. Right. You know, so like, well, it has to run on Solaris. So I need a box that runs Solaris. Yeah. And that was, that was always a gotchas. Um, but you know, a lot of these languages were platform independent. I got an air quote independent because.
00:21:49
Speaker
Not all of them were. So you'd move it from one platform to the other and you'd end up with errors. But yeah, that's, it's definitely one of those things where it's like, yeah, use your tools, man. Use your tools. Oh yeah.
00:22:04
Speaker
Think outside the box. Yeah. Those, those shadow servers, man. I i can't tell you how many times I had to do that. Right. Like that's you just get stuff done. If I have to go buy something at best by myself and stand it up and, and, you know, just put it under my desk, aye right get stuff done and don't let things get in your way. That's yeah all right. So you, you seem like you're a fan of agile. Sounds like.
00:22:29
Speaker
So I really like Agile, but I've noticed some myths and misuses and some disturbing observations when using Agile that I wanted to bounce off you guys. ah So myth number one, Agile is new. No. So you guys have been asking me questions. I'll ask you a question real quick. Don't use Google. When was the Agile manifesto written? What year?
00:23:01
Speaker
I'm going to guess 98. I'm going to go a little later and say 2003. Oh, Aaron was probably close. 2001. 23 years ago. Second question. Last one. What year was Jira released? First one. First version. I'm going to say 99.
00:23:26
Speaker
I have no, I'll go 2005. Oh, 2002. 22 years old, 144 in dog years. That is not new. Right. I've worked at companies where contractors come in. They can't, Agile, what's that? Jira, what's that? A combine board. What's that? As you, as I alluded to my former story.
00:23:50
Speaker
I can't believe these people, I go, you have been in the IT t field working professionally on projects where you had to deliver and you have no idea what the Agile methodology is. And it's 2015. Heck, I had one in 2021. I've never used Jira. I've never heard of it. Oh my God.
00:24:17
Speaker
I mean, some of these people come armed with Project Man... ah What is it? Microsoft Project and Excel sheets as their tools of choice, as their weapons to deliver this project. I'm like, get in your time machine, go back to 1995 and flourish. Check the calendar. It's 2024.
00:24:40
Speaker
right You have got to be on board. It's been going on for two plus decades. It's not going away. If it does go away and it would be replaced by something better, it's not going to be replaced by Microsoft Project and Excel. I'll tell you that.
00:24:56
Speaker
i I heard something, so last night I was looking into, I'd never read the book Clean Architecture, and then I was watching a video, and Uncle Bob, he was giving a presentation, and he said something, I'm gonna maybe butcher the math, but it was something along the lines of like us software developers ah the the community basically doubles in size every five years. And so there's a, there's a lot of new people. right Maybe that has something to do with it. They're not, they, they really haven't been around for, I don't know, but yeah, I thought that was, that was fascinating to me. Cause he was like, Oh yeah, since you know, that that's actually, we've doubled three times since whatever he was talking about. I don't even remember what he was talking about, but like some book coming out, um, I've already, Jacobson's book, Ivar Jacobson, how are you say it? Um, anyway,
00:25:39
Speaker
Maybe that has something to do with it. Is it just, there's constantly such a ah large influx of new folks into our industry all the time? Maybe that has something to do with it. I don't know, but I'm with you. Like Agile, what we run into on the consulting side, because Agile gets a, you know, it gets a bad rap, right? And I don't think it's.
00:25:56
Speaker
I don't think it's, we always distinguish it by little a agile. I don't think little a agile gets a bad rep. I think of everybody's bought into the principles and like, yeah like if you stick to the principles, everybody's like, yeah, and that makes sense, right? It's the big a agile stuff that the frameworks and the, you know, I always, uh, and of course, nobody's going to get this reference, but I always think of it like the brainy Smurfs of the world. Like, well, actually have a Smurf always says, you know, those right. Um.
00:26:22
Speaker
the agile coaches and my wife's gonna kill me my wife's an agile coach for a living but like that you have to stick to the exact thing the book says like you know job i've opinion it's always you tweak it you take the principles and you tweak it for what makes sense for you all and and that's the thing I think that where it's getting a bad name is everybody tries to like everybody go by the book and get very litigious about things. So I don't know. That's fine for a day. That's a good segue on my next topic, which is misuse. The the number one misuse I've seen is Agile that I can't stand. It's more of a pet peeve than anything is. Agile being used as a shield to avoid future work. So we've got these people who have worked with some people over the past where
00:27:09
Speaker
They fill up their whole quarter with stories and you come to them and go, uh, I need somebody to help me with, uh, let's say, uh, remediate a critical security vulnerability. Nope. All booked up. All booked. And I'm like, you're not really getting the agile man. You haven't read the agile manifesto, have you?
00:27:32
Speaker
No, but we're little A Agile. We got Jiro, we got stories, we do scrum meetings, we got a scrum master, we got a product owner, we got a product manager. We're doing Agile. Yeah, you're doing little A Agile to a waterfall methodology, which is you, the Agile methodology was you will react better to change. Here I come with a five minute change.
00:27:59
Speaker
I didn't expect that reaction of I'm booked and I'm using Agile as my shield. Look at my compound board. I got no place for you. All right, let's come to a middle ground, folks.
00:28:13
Speaker
budget in 10% a week, 20% a sprint for incidentals, something out of the blue, emergencies. And by the way, when the VP comes to you, I really want to be a fly on the wall when you tell them you're booked for the quarter. You've got no room for them. And you might do that to your peril.
00:28:41
Speaker
I have, I have been in that room before and it does not go well. yeah imagine I would put some money. It wouldn't go well. Yeah. There's, there's usually a few shades of red that happened in the room. When, when, when that drops out of somebody's mouth, it's like, well, we don't have room to do that. I'm like, well, you're going to make room. Right. And right it also reminds me of a, um, a Dilbert cartoon that I saw before where, um,
00:29:11
Speaker
in in like the first frame, the pointy haired manager comes in and he's like, well, we need to change all of these specs and and work to a new requirement and deliver on the same date.
00:29:26
Speaker
And it was like, and Dilbert's like, we can't, we can't do that. It's, it's, we're too far along here. And he's like, oh, sure we can. We're agile. And he's like, that's not how this works.
00:29:42
Speaker
yeah yeah yeah magic at all Yeah, I think that, you know, now. I look at these situations and and ah I've had them happen with clients and and we've had situations with clients, but i oftentimes when you look at those sort of behaviors,
00:29:58
Speaker
Most people are good people, right? You know what I mean? They're just trying to do the best they can. They've been trained to, to think that way. And then, and a lot of it is, and I think of good hearts law, right? So when the measurement becomes a target, it ceases to be a good measure all about that velocity, right? Our velocity, we got to get that number. That's a target. Whereas actually the velocity really should be used as a barometer where if the velocity does drop, well, then that just means that more unplanned work.
00:30:24
Speaker
is entering into the mix or we have more prod support or whatever it happens. It's just an indicator. So, but if you make it a target, now you're going to do everything and drop everything and, and focus on that target. Cause that's what you're measured against. And that's, that's a lot of times that's one of the misuses of agile is like using a velocity as that target. And like you have to get to it as opposed to letting it be your indicator of when things are starting to go, you know, you're you're not as optimized as possible, right? i think when it When it suffers, that's unplanned work. That's, you know, all of those sort of things. And to your point, Bill, you got to bill and show the unplanned work. And then based off those analytics, you can adjust your velocity accordingly. and
00:31:06
Speaker
um so I mean, I took I did two quarters worth of analytics to find out how much time people spend in meetings I've delivered no value So we baked that into our velocity and said that's two points every week guys. That's two points every sprint That's two points every sprint meetings out of the blue unplanned meetings and I threw in one for email. I was like all the core email I am's correspondences communication Devote one point per sprint for communication. Communication is key. i's yeah I don't know. i'm not I'm not in that camp. I don't like putting points towards anything other than the value delivery because really you you want to measure the value stream. not It's not a time tracking tool. Agile is not pro to be a time it's meant to be a a
00:31:54
Speaker
how we deliver value or measuring our effectiveness at delivering value. So when you add in those things, you're you're almost masking the problem, right? Because now maybe it's not good that you're spending that much time per week in in meetings. Maybe you should try to minimize some of those meetings.
00:32:09
Speaker
By adding it into your velocity, you're kind of papering over that problem of people sitting around navel gazing in meetings too damn much, right? I don't know. That's kind of where I think of it. I love to keep a purist view of velocity and let it kind of be my indicator when things aren't going the way we would like. We'd we'd like for it to get better and better, but stuff happens. To your point, things change. I mean, I know I've had sprints where, oh, God, I only had two meetings this spring. Well, that freed me up.
00:32:38
Speaker
Yeah, it's good. And I was able to live over more. So like more just an average. Yep. Yeah. And, and I do like it as like a watermark because sometimes you don't, especially in enterprise.
00:32:54
Speaker
there'll be a decision made that changes the process and you may see a velocity drop. in And instead of putting points into, oh, well now we've got to do like this new release process and it's costing us because we've got not only to learn this, but it's adding a bunch of extra steps to us.
Misconceptions in Agile
00:33:11
Speaker
You see that velocity drop, and then managers will be like, well, why is the velocity drop? Why are you guys not you know producing the 14 points you normally do every sprint? And then you can go, well, you instituted this process, and now we're spending more time doing that than we are producing value. And that happens. And the other the other thing I always you know, get asked about when you're doing like, especially on a shorter sprint cycle is like, why, why did we not deliver on this sprint? But then this one is like above. And I said, and I always tell him, I said, velocity is kind of like a sine wave, especially dependent, you know, and it's in the, the frequency of, or the amplitude of that, um,
00:33:59
Speaker
That sine wave depends on the complexity of the system. So if your system is more complex to where you're spending more time to get work done, your sine wave is going to have a very,
00:34:12
Speaker
um large shift between the points delivered, uh, from sprint to sprint. But at the end, it's going to average out to, you know, whatever your velocity is, because what will happen is, okay, this story took longer than we had in the sprint to complete, but it completes in the next sprint. And that happens across a team. And so you see a bunch of delivery in one sprint and then the other sprint is a bunch of work and not a lot of delivery.
00:34:39
Speaker
Right, right, right. And you know, a lot of times on that question is how how come you delivered more in this sprint than and it last spread the The quick answers have been remember all those um meetings, yeah we had to attend and that sprint and we didn't have to attend the other sprint that came into play. Remember that bridge we were all on? Yeah.
00:35:01
Speaker
That kind of took the points away from the velocity. So it's always, I can usually or just, especially if it's like one sprint to the next sprint, that when it's a short timeframe, you can pretty much recall like, well, here are the things that came up during that sprint that didn't come up in this sprint. And it's just, it's just life. Let me refresh your memory. Yeah. And those this types of conversations are kind of,
00:35:30
Speaker
I don't know it in a low trust environment where you people have to like account for like, well, why didn't you, you know, you're, you're not trusting your team. Right. I mean, right that comes down to, you know, I think it comes down to a question of empowerment, you know, cause an empowered team that, that owns the product and is, is, is free to try to improve their daily work. They're going to do that. They they don't want all the the hoops to have to jump through. They're going to want to improve their, their daily work. They're going to be proud of their product.
00:35:57
Speaker
You're not going to fix people problems with story points. You're just not. If you have people that aren't wanting to do the work, you just got to, what did somebody said they got? ah Actually, Mark Wiebe says this a lot. I don't remember what book he said he got it from, but it's like, if you can't change the people, then you need to change the people, right? Like guide people. So it it comes down to, you know, people just being bought into the mission. And that, that could be.
00:36:23
Speaker
from like, you know, are you sharing your vision? Are you explaining to the team why so they can get on board with why are we even doing this thing? Because if they're not engaged, you're not going to be effective. Right. So, Leslie, I have an observation in the seven years I've been in an agile shop. And the observation is, Dear Lord, I never expected the bottleneck to be in reviews and approvals.
00:36:47
Speaker
I can't.
Bottlenecks in Agile Processes
00:36:49
Speaker
So we finally got this nirvana of a system called Agile and all of the bottlenecks you used to have in waterfall are gone. You're doing your security testing upfront. Everything's rolling along and everything is just flying and the poll requests get submitted and like some emails in the past, just nothing.
00:37:14
Speaker
And it's like, dude, I just need a review and approval and a merge. We're off to the races again. So I, like I said, in my wildest dreams, I never thought the bottleneck was going to come down to reviews and approvals and merges.
00:37:35
Speaker
I, and I guess I'd go back to like, you know, empowerment and autonomy of the team because it, you know, Usually when you see that it's an overly prescriptive process that they're having to abide by usually the why where you would see that symptom ah because you're, you know, you don't want to sit around waiting for it. And I know I don't want to, as a developer on a team, I don't want to have this backlog of reviews that I want to, you know, looming over my head at all times.
00:38:02
Speaker
But if you're empowering a team to make adjustments to how we do our daily work and and improve things as as they see fit and how they best work together, some of those things start to smooth out. So I think it's it's ah it's doing agile without doing lean.
00:38:18
Speaker
Right. So that and embracing some of those lean principles of removing waste, right? You know what I mean? Like that's, I think that's where those things and you're seeing, I think the whole, you know, DevOps and lean and agile, all of these things are like come into like this culmination. We're kind of getting this like Uber process now. Um, I'm happy for it. I think it's a lot of these principles are all starting to converge into one and and it's going to be.
00:38:41
Speaker
I think there's a missing ingredient still, but i but I do think that we're converging on something pretty special in the industry and hopefully we'll get to a point where we finally solve that productivity, you know, crack that nut that we've been trying to do for 40 years, 50 years, whatever.
00:38:55
Speaker
Well, and I think part of it too is that there is a lack of trust, you know, especially as you get more tiers of management or more teams involved, like with that, with that growth spectrum of now you've got a bunch of developers all working. you You don't have that guarantee that they're all doing it the same way. So how do we ensure that then you put in process for check, validate, you know, and, and.
00:39:26
Speaker
reassure that we're doing the right thing and have all these processes on top of that. And that becomes more of a bottleneck. I'm living through this right now with the, with the client I met where they they have
Code Deployment Challenges in Agile
00:39:43
Speaker
enforced almost a waterfall type process after the work is done in order to get it out the door. So your, your time from completed.
00:39:56
Speaker
story to delivery to production has grown to a large amount of time. And so you end up large change sets back into a production release, which is a recipe for disaster, right? The larger the change, the more things you change at it at incremental times, the more likely something is going to break in, unfortunately, you know, processes and things like that, um, that aren't automated in ah aren't following those lean principles. And they define that as value because they they think of protection as value. Right. Right. And.
00:40:44
Speaker
those things end up causing this delay, delay, delay, you know, get this approval here, get this reviewed here. You've got to go before this committee to get all your check marks checked off and you've got to fill out this form, this form and this form and then so supply this report, this report and this report. Oh, and by the way, did you put the cover on your TPS report. Did you get the memo? It's that kind of mentality of make sure all your ducks are in a row before you get to production. And it's like, okay.
00:41:19
Speaker
And instead of let's get it out in production and test it before we give it to the public. So there's there's in, you know, as part of the DevOps and we, as a talk that I give, we talked about the difference between delivery and release and you know, deliver it to the environment that you want it in, <unk> test it there, then release it out to your audience that you want, especially with cloud in, in load balancers and being able to redirect things quickly and on the fly. It's like, there's no reason to have that out in that environment, test it internally and you know, put it through its paces, make sure it works well. Right. Right. And then flip the switch for your customers. Right.
00:42:06
Speaker
I'm a proponent of reviews and approvals, and I'm also a proponent of a reasonable checklist to get things in. I think a lot of the problems are, what is the change? And so what I call a lot of the changes we do in the ops area, especially in DevSecOps, these are quick wins, folks. I didn't alter Java code here. Matter of fact, you are not vulnerable. I'm trying to put in an exception.
00:42:33
Speaker
So this is just a quick review. Now, you might argue with me on the conditions, oh, no, I don't think we're vulnerable. OK, let's have a healthy discussion about that. That's fine. But I get a little frustrated at people not recognizing the quick wins and the ones that really need the rigor.
00:42:52
Speaker
And it's a little frustrating when things, like I said, it just seems things are just flying and you hit this PR wall of review and approvals that I just never saw a comment with agile. I thought, well, that's going to be fast too. And the changes are going to go in because they were all tested. And if they weren't, well, why did you put the check mark in that you tested this in QA and it passed all the tests and blew up in prod.
00:43:21
Speaker
Well, I didn't really tossed. Yeah, I didn't think so so. Sometimes you, you know, you have to, you know, the old saying, you can lead a horse to water, right? But like, sometimes yeah actually you you have to go through the motions of leading that horse to water in order to finally like, Oh, I guess he will actually drink out of that stream. I'll give an example. So we we used to have these, uh, go no go meetings. Right. And for that as, as, uh, Aaron was alluding to was, you know, you had to bring all this this information with you.
00:43:50
Speaker
And one key thing was I need to see your test report. And I, I'm like, okay, I can do that. But so what, what are you doing with that test report? Well, we look to make sure every test case passed. I'm like, well.
00:44:05
Speaker
Our build process is set up so that if a test case doesn't pass, the build fails and I don't have software to bring to you to to ask, can it go or no go? Have you ever had anyone come here with a failing test case that said, I want to go to production? No.
00:44:22
Speaker
So why are we not trusting the automate? You know what I mean? Like we had to go through that exercise of kind of like, here's the stream. Take a drink, please, horse. like And then finally, some of those aha moments happen. They're like, oh yeah, what we're doing in here is really silly. and you But it's it's funny. what You can talk yourself into being OK. I've seen that. It's uncanny.
00:44:42
Speaker
the process is people can can do and continue, it's like frog soup, right? You can continue to do and do processes, add steps in, and by the end, you know, six months to 12 months down the road, you're you're doing this just convoluted thing and you you don't realize it. So. Yeah, yeah, yeah. It's crazy. um All right, Aaron, do you want to introduce our are are lightning round, I think, is that what we're calling it? Yeah, or lightning round, where we ask a series of questions that mean nothing, as far as technology is concerned, they're more just kind of off the cuff questions um to get us to know you a little bit better. And okay you think so I'll start things off. So what's a nickname your parents use for you? Uh,
00:45:33
Speaker
They don't really have one. I had a nickname in high school, Bomber. but po We might have to hear about that one. Do you like the description, it's really bad. Is it like a... Fourth grade. Oh, yeah. So fourth grade, this kid was shooting pencil leads.
00:45:55
Speaker
to me and going, here's the bomber. And it was like, oh, you're a bomber. And that stuck till I graduated high school from the fourth grade. Oh, my God. That was my middle name. people I mean, i't some people didn't know my first name. Bomber. I didn't know my last name. Bomber. That's Bomber. No kid coming into school. there's That's Bomber. He plays basketball. Yeah.
00:46:23
Speaker
I had a friend growing up, his nickname was Bean, and I i didn't know what his real name was. And but somebody said one day, like, oh, hey, did you talk to Scott or something like that? And I'm like, Scott, who are you talking about, Scott? And I've known this guy for years. And they're like, Bean. I'm like, oh, oh, that's his name. Yeah, I get the guy in high school like that, too.
00:46:47
Speaker
that's so trip All right, so my my first, we're going to do five each, we'll do ten. Do you like the smell of gasoline? Yes, I don't know why. I'm the same. especially Especially when I was younger. Now I could probably, they it's a little detestable now, I really liked it as a kid. I did too. Remember. Yeah. All right, what's your favorite junk food?
00:47:15
Speaker
Little Debbie Stacks coming to mind right away. Oh, so good. Pick one. I don't care. I got a little Debbie snacks. I had that every day for lunch for decades. I went to Cliff bars now. So after about a decade and a half, I got smart and went to Cliff bars and was like, you know, they have the same amount of sugar, but they've they're a lot better for you. Let's go with Cliff bars. So it's Cliff bars today. ah Prior to that, it was little Debbie big time.
00:47:47
Speaker
Yeah, I used to, I used to like unroll the Swiss rolls, like chocolate off of them. Oh man. Fudge rounds. Oh my God. Fudge rounds were a dollar a box and perfect. Oatmeal cream pies. That's mine. Yes. my Number two. Coming in at number two for me is the oatmeal cream pies. Oh, okay. All right. From one to 10, how hot do you like your shower water? Six.
00:48:17
Speaker
Good answer. What does a person need to be happy? Doing the thing they want to do. ah Going to work every day and wanting to go to work. Doing something you want to do and find that challenging and fun and you want to do it. So I've been blessed with IT and why I got into this field. i mean i I remember senior year 82.
00:48:49
Speaker
Computer lab. I'm like, ooh, this looks great. What's this? And everybody's into video games and stuff like that. And here's a, oh my god, we got a computer lab? And I was like, well, I'm going to sign me up for that class. And got an A, and I learned basic. And it's just the key to happiness is if you're going to work every day and you hate it, oh my god, you need to find you need to find a passion. You need to find something that you like, that you can go to work every day and go, yeah, all right, what's up? What are we doing today?
00:49:18
Speaker
Or, all right, I know what did um I got to do today, and I want to do it.
00:49:25
Speaker
but Like what you do. and work day It's like what you do. If you're going to, especially at a job, I mean, good Lord, these jobs, and unless you're independently wealthy, you're going to spend a lot of time at your job. You better like it. Yeah, absolutely. All right. If you were given the opportunity to fly into space, given today's technology, would you take it?
00:49:48
Speaker
Yes.
00:49:52
Speaker
All right. That was a simple one. ah What's for dinner tonight? Pork roast. Oh, I know where I'm going for dinner. yeah I'm going to Nada's. They're going to cook it for me. Oh, there you Well, you asked. That's the answer.
00:50:13
Speaker
Uh, let's see. I'm not going to do that to you. Uh, here's the one I won't do. Tell me what you like to do on weekends in a Valley girl voice. So no, no, we won't do that to you. That's something Aaron did to me on like our, our episode together. have I had to say something from like a Valley girl. I'm like, popular all right. Do you find handlebar mustaches handsome? Yeah. now No, no.
00:50:43
Speaker
ah If you could ask God one question, what would it be?
00:50:52
Speaker
Why do people die young? Why do kids die? How would you rate your karaoke skills on a scale of one to Mariah Carey?
00:51:08
Speaker
I'll go three. I think and want to be good, but I don't think I am. All right, so that concludes this episode of the Forward Slash. I'd like to thank our guest, John Kimball, my beautiful co-host, James Carmen, our production staff, and I am Aaron Chesney. Thank you for listening. Stay tuned for future episodes.
00:51:34
Speaker
of the forward slash where we lean into the future of IT.