Chet
Hendrickson

Extreme Programming (XP), The C3 project | Agile to agility | Miljan Bajic | #22

Episode #22

Miljan and Chet talk about Extreme Programming (XP), The C3 project, Agile Manifesto, and several other topics. 

Chet Hendrickson

Speaker: Miljan Bajic  00:34

Chet, when did you start coding and why? Because I think I want to know why you got down this path of programming

Speakers: Chet Hendrickson  00:46

I was in graduate school. I was in graduate school studying economics at the University of Cincinnati. And in order to do analysis of various things. I took a class in programming, I learned a variant of PL one, which is a language that IBM created many years ago. It was a combination of COBOL and Fortran, programming language one it was called. And so I took that class and really enjoyed it. And it was back in the old days, when you had to punch cards and horse at a university, the card punches, the key punches, the ribbons were always worn out. So you can punch cards and you have no idea what across the top or what it was. And so I discovered that I really enjoyed that. 

And I was back much better at it than I was economics, it turns out. And so I moved from being an economist to being a programmer. And so I enjoyed that way, way much better. And I ended up going to a different school, went back to where I got my undergraduate school and took all their programming courses and then went into software development. And so it turns out that the things I learned in economics are starting to feel incredibly useful. There’s all kinds of interesting things we had to do because of that background. It lets me explain things in ways that maybe other folks can’t. So I come at it from that, I had a problem that required programming, and therefore, I learned to do that. And I discovered I was way better at it than the problem I was trying to solve.

Speaker: Miljan Bajic  02:29

So what attracted you? What did you really like? Do you remember, was it the problem solving? What was it really that got you hooked on?

Speakers: Chet Hendrickson  02:43

It was the problem solving. There’s actually something that works and something that doesn’t. And you compare that to economics, which is almost entirely theoretical, we would spend weeks doing mathematical proofs of some esoteric idea and you discover somewhere in the middle of it, that you had a sign wrong someplace, and the whole thing was [inaudible 03:06] and only at the end, where the answer you got didn’t match up with what the answer is supposed to be in a university setting, that you can figure out that this is, well, we made a mistake somewhere and you go back and found it. And so having something that either with actually sort of works in some way, and that has some degree of truth to it, was really compelling. And it makes sense to me how you did those things. 

And I think that’s kind of as I progressed through what I used to do in software, I hardly do anything anymore. But it’s all about having a way of expressing what you want in a way that this machine can understand and comply with so yeah, I think that’s what drew me to it was that. Of course even there you are always doing something that is fundamentally ephemeral. And so if you have a desire to actually create things and solve problems, software is fun to a certain degree but every now and then you need to do something that’s actually physical, whether it is cooking, I like to cook, we talked about more on the air about cooking, I cook. I cook because that is, I do something I get a result. 

When you have feedback and it’s meaningful, right? Now that I’m moving towards almost not as retired to some people we just talked about, but nothing more towards working less. I’ve returned to woodworking, I used to build stuff when I was younger, now I’ve gone back to building things, right? So the room over there is now a workshop and had been doing cabinets and things. So as we move to a new house and I’m building cabinets and building furniture here and there. So my wife and I are doing that together which is kind of fun.

Speaker: Miljan Bajic  05:00

That is it and especially with less traveling, everybody that I talked to, it’s like they generally they miss that part of traveling and talking but they also enjoy the more time that they have at home especially for those of us that have traveled a lot throughout the year. What else have you like reflecting back maybe just a little bit, but what else have you changed? And what does it say about you? In a sense, like you said, you like more practical stuff, you like to see results and who’s really Chet underneath? What else can you tell us about yourself to maybe others? What motivates you?

Speakers: Chet Hendrickson  05:48

That’s a hard question to anybody, that’s kind of self awareness. I often tell people that I run stateless, that I wake up every morning, and it’s a fresh universe and I just go off and do whatever I feel. And to some degree, that’s true. But there are some things that are kind of woven through my life. Like I said, I like to cook and I enjoy doing that. And I do all kinds of stuff like that. Like I said, I’ve been building stuff. I have throughout my entire life been involved in something called trap shooting, which is shooting clay targets, fly out through the air and have been very, very successful at over the years at a competitive level, and was essentially the world champion at point back 30 years ago, but I’m going to the state championships tomorrow. And so, I do that. I know, I’ve done various things in my life. Some of its things I go back to and others you try something and you say, well, maybe that is it for me, I took up flying probably 20 years ago. Because I always was fascinated by flying and a family friend of ours when I was a child, became a pilot. And I used to go fly with him. And took flying lessons and discovered that I mostly scare myself [inaudible 07:22] well, I’m sure I could get good at this because it’s not that hard. But there are times when I’m afraid of what I’m doing right here. And maybe that tells me I shouldn’t be doing this. So I love doing it, I decided that maybe that isn’t what I should be doing.

Speaker: Miljan Bajic  07:38

Maybe you can, so much taking empirical approach to flying. Well, maybe you can but to some extent.

Speakers: Chet Hendrickson  07:45

It’s a lot like programming in that you do stuff and you have a pretty good idea of what’s going to happen but isn’t necessarily what happens and it’s not about control. It’s about influence. And to say, [inaudible 08:0] 

Speaker: Miljan Bajic  08:01

Yeah. [cross talk 08:02]. 

Speakers: Chet Hendrickson  08:06

Yeah, yeah. And so and so skiing, you have mostly influence over where you go. Not exactly control. Flying is a lot like that. It’s a lot of skidding around in the sky, as opposed to skidding around on the snow. My wife’s a much, much better skier than I am. But yeah, I came to it late in life. If you grew up doing it, you’ll be a whole lot better than I am. I didn’t start till I was in my 30s. And so…

Speaker: Miljan Bajic  08:37

Yeah, it was 1984 Winter Olympics. So yeah, it was like everybody went crazy around. So maybe to switch gears a little bit, what are some basic ideas that are still true today that were true decades ago when you were punching those cars that have to do cobalt on mainframes? What are the key things that you think are still true?

Speakers: Chet Hendrickson  09:02

I think the first principles, I think are always the first principles. And I think it’s the being able to take a smallest step as you can reasonably take in order to learn something and like, all this stuff we do [inaudible 09:26]. That’s Oscar. I don’t know. I can’t even see. It’s what’s the smallest step you can take to give you enough feedback to know whether you’re on the right path or not and I think the challenges that we have in XP and Scrum and any other. Oh, there it is. Any other agile process is discovering what the smallest step we can take really is, as opposed to what the biggest step we can take is and our history has always been, you find a small step and you do that and you get bolder and bolder and bolder, you take bigger and bigger steps, until all of a sudden you fall over and it’s like skiing where you know okay, I’m done with the bunny hill, and I go here, and here and here and you finally get to the double black diamond, you nearly heal yourself and you go back to the greens. 

And that’s the same kind of thing everywhere is knowing when it’s okay to take a little step and not kill yourself. And knowing that just because you did that thing and you didn’t die, it doesn’t mean it was a good idea. There’s a difference between surviving and it hasn’t been a good idea. My buddy Ron always says just because you jumped off the roof and survived, it doesn’t mean it was a good idea, right? So, wondering what the good ideas are? Working with people and understanding that we can solve more problems as a group than we can as individuals and that the importance of having people who approach problems differently becomes incredibly important. And so one of the things I dislike about the world we’re in right now, when I’m training from my basement. I don’t know whether your room looks like that or not.

Speaker: Miljan Bajic  11:39

It’s just my feet back [inaudible 11:40]

Speakers: Chet Hendrickson  11:41

I don’t even bother. I’m in my basement. I honestly, I have windows at my basement, I’m in my basement and is, you lose that sense of that little community you put together for a couple day class, and you all come together to do something. And the fact that I am in some ways more experienced in the subject we’re talking about does it mean that they don’t have things they can teach me about what we’re doing? And I think we lose that in this virtual world, because we just don’t have that interaction.

Speaker: Miljan Bajic  12:19

I mean yeah but also I spoke yesterday, you probably haven’t heard of him. Andy Singleton from here, he’s in Boston and he’s been doing remote teams for 20 years, right? And him and I were talking about just it’s like, it comes down to communication and collaboration, right? So 20 years ago, it was a lot harder but the technology is getting better and it’s easier to communicate and collaborate. So it’s probably hard to replicate in-person collaboration, building trust, but it’s getting better, right? So there’s some type of hybrid model or ways of working, is going to emerge from this. 

And what’s nice about it is now that people are more open to collaborate across the globe. Like he used to be like, oh, we need to fly people in. And yes over the last 10 years, I think it started being more, but I think now what we’ll see is, and the kids that I used to teach, appear in Maine, like undergraduate, and the way that even scrum, when I teach scrum in the undergraduate, the way kids think today is different than what we’re used. So for them, it’s a lot easier to be able to build relationships there. So I think the future in a sense is going to be some hybrid between what we’ve experienced over the last year, mostly for most people and the typical in-person.

Speakers: Chet Hendrickson  14:04

My concern about some of that is that, of course, until you have experienced the one and working together in the same room, talking in a way that if you can hear, hear somebody say something on the other side of the room, that is important to you, you can hear it and communicate. Going back to flying, if you’re flying on an airplane, you have your headset on listening to all the communication that’s going on around you, you can tell when the controller is saying something to you. You hear that, you listen to it, and they can be talking to 10 other airplanes and you just walk that out when they talk to you, you hear it. And that kind of happens in a room where you have a bunch of folks sitting together, working together in the way that the XP started out, that you hear something and you say, okay, I’ll be over that, I know the answer, that I’ll come over [cross talk 15:06] whereas online, I don’t know that you can get that same sort of communication happening. Maybe we can train ourselves to do that but I’m concerned about scale, then you have 20 people in your class, a class of 20, 25 people are you going to be able to read, whether they’re engaged in what you’re doing just by scanning. 

We know that in zoom, all of a sudden the pictures get smaller and smaller, and before you know some of them aren’t on the screen. And even if I had a 60-inch monitor, I wouldn’t be able to be engaged in the same way I can engage with, it’s the difference. I’ll steal another line from Ron, which is the difference between a hug from your mother in a politely written note. Well, a politely written note is okay but it’s not a hug. And so being in the classroom with people is that level of engagement, whether we can hug or not, it’s that level of engagement. And I’m at a point in my life, where if this is the way that’s going to be, I might be ready to go do something else for a while, I’m old enough and I’ve done things successfully enough that I could quit. And so quitting is in only doing the things I want to do. As opposed to the things I’m doing today just to generate and do business is different. So we’ll see where I am a year from now.

Speaker: Miljan Bajic  16:51

Yeah, and I think yeah, we’re all speculating and guessing. But there is something about younger generations [inaudible 16:58] I was teaching class a little while ago and all of a sudden people start taking notes, as I’m talking like they’re adding, people are commenting like you will always stickies and putting things on mural and mural dyers. And I was like, what’s going on here? I didn’t tell them and they’re like, yeah, we do this, it’s cool to like, they have chat, they have comments and they’re adding and then like I used to pay people to give me notes in college. And this is like another way of just how kids I saw used to now collaborating and communicating in different ways than maybe what we’re used to.

Speakers: Chet Hendrickson  17:46

And I think we see that as kind of a generational thing, I had a class a few weeks ago where I had a certain people off into breakout rooms, and it [unsure word 17:57] to do something. And after 10 minutes, or something, I’d call up, I closed the breakout rooms and brought it back and discovered that one of the groups had not done anything. And they said, you never came in and told us to start. So now, I tell people start and again [inaudible 18:21] so I can tell them the story, they all get to laugh and it’s like no, no, is just start. You’re allowed to start.

Speaker: Miljan Bajic  18:31

Yes. And I think everybody’s learning. I want to take us back to 96. When you join [cross talk 18:39]

Speakers: Chet Hendrickson  18:41

I can’t go back to 1896. 

Speaker: Miljan Bajic  18:46

1996. Chrysler’s CT project, I want to know, how did you end up on that project?

Speakers: Chet Hendrickson  18:55

Well, it started before that. The payroll department, which is what CT was, was a payroll system had been struggling to replace their old COBOL unit record system for a while, several years. And the guy who was in charge of this, a guy named Tom Hatfield had been working with the payroll folks and done various things. And somewhere along the line, they had actually purchased a package off the shelf system that was sold by the neighbor of one of the senior managers in the IT department. And so they bought this, he was lacking in a whole completely different area, but it was the no way that we’ve been around big companies so you know how those things work.  So they struggle for a couple years probably trying to figure out how to install this system that didn’t work any way that the payroll people wanted to work. And so they had to mangle this thing. 

And they finally gave up, finally gave up. And they did, I think a couple other things. And so it was finally decided that they were going to, we were going to, the company was going to write something from scratch. And this was kind of 1993 1994. And the whole idea is of oh, we’re just coming into bloom. And so they started out by wanting to model and design and kind of the traditional kind of approach. And we had a fellow there was a fellow over in Ann Arbor, Michigan, so not too terribly far away, named Jim O’Dell. And Jim O’Dell had created a modeling language. And he would partner with a guy named James Martin, who was big in kind of previous world. So he hooked up with James Martin, and they’d created the Martin O’Dell modeling language. That is before your UML and all those things, there is a proliferation of modeling. And so somehow, Tom got ahold of Jim Modell and Jim O’Dell started showing up and they started modeling things and doing interesting stuff. 

And after a little while, Jim said I’m kind of busy, but I had this friend, have a colleague that I’ve hooked up with over in the UK, and you should have him come over and help you. This young guy is really smart, okay. And so this guy named Martin Fowler started showing up, commuting from London over to Detroit, and spending a week over here at the strip. And they fester and fester around doing all this stuff, drawing pictures. And they brought in a consultant who helped them learn Smalltalk with us. But back then you either did C++ or you did small talk. And small talk was a whole lot better world and C++. And so I started doing small talk. And they sort of had little dates put together a little team, they were doing this modeling. And they were actually writing little bits and pieces of Smalltalk code to learn how to do stuff and to solve little problems that payroll folks had. So they actually deployed some little tiny little applications that help people do things written in visual works mobile. And so it got to the point where we needed to add more people to do this thing. And I knew Tom, I’d met Tom, like the second week at Chrysler. Because I turns out that I needed to talk to Tom because I was doing something, I had always worked in benefit systems, personnel kind of systems and retirement and workers compensation and all those kinds of things. And one of the things we needed to do was access payroll data. And I needed to get to this payroll data and in order to know how to use it, I needed to test it. And it turns out that they had some test databases that were like, five years old. And so I went to Tom and said, do you have any way of making new test databases? And he was just amazed that somebody wanted to test I think. 

And so I impressed Tom my second week there because I was figuring out how to build databases where I could test stuff, and nobody had ever ask of it. So I rebuilt the test systems that the payroll system had, even though I wasn’t in payroll and on and on. And so by the time this came around, I had been hired, I was a contract programmer to start with, and I had been hired. And now I was in charge of a small team there. And me and a couple of my buddies knew Tom and knew they’re starting this payroll thing. And so I got put on it. I said, I want to work on this payroll and my current boss saw that as odd and interesting. 

And said, do you really want to go over there to stop being a team leader, I’m moving your way towards being a manager, and go over here and be a programmer on this payroll thing? And I said, Yeah, because I think it seems like fun. I think we’re going to do something interesting and I think I can help them. Because I think I know how to do things and be successful. And I think I can probably help. And so this all started happening and this was 95. And we hired some consulting company to come in and help us, they brought in half a dozen or a dozen people and we worked building this payroll system for about a year, a little over a year, and Martin was still coming over and looking at what we were doing. And he was very, very concerned and the interesting thing is that the consultant guys wouldn’t talk to him.

Speaker: Miljan Bajic  24:58

Why?

Speakers: Chet Hendrickson  25:02

They were afraid of him. They were afraid, he wasn’t anybody, he was just this young guy from the UK, moved to the US, but he would not show up, they wouldn’t have any meeting, they wouldn’t talk to you, they wouldn’t show him what they’re doing, nothing. Because they were afraid of having anybody look at what he was doing the might be more than they did. And so finally, all this relationship kind of soured, and we got to like 14 months into this project. And we had something that was short of working after 14 months, but it was very, very slow. And only sort of work. And a couple or a few of us thought that if we could get it to go faster, we could probably figure out the deficiencies. And on the internet as it existed back in 1995 1996, there were a group of what we call listservs around programming called comp Lang and then the name of the language. So there’s comp Lang and there’s small talk, where people communicated about small talk stuff. And so I read this, I look at it every day or two. 

And somebody asked a question to the comp Lang, small talk group saying, I’m going out to all these languages and I’m asking people to write a program in each one of those languages to generate the lyrics to the song 99 bottles of beer on the wall, for the song 99 bottles of beer on the wall, take one down, pass it around 98 bottles [cross talk 26:48] generate, that goes all the way down to no more bottles of beer on the wall. And so people had written these little programs that were not particularly very interesting. They were just mostly just basically just a display of the lyrics. Somebody had written this beautiful program that had a chorus object, and the lyrics object and you said sing to it and all this stuff. And he had tests on your work and he had results, a performance tool showing where it was spending time, and how the performance tool was programed to generate the lyrics on 99 bottles of beer on the wall. And so I went into work and I said, I printed out this thing. 

And I said, here, look at this, this is the guy we should have for coming [inaudible 27:33] we should bring this guy in. And so we all looked at this and said, yeah, we got to get this guy. And so one of us contacted this guy, Kent Beck and he showed up and he looked at the stuff and we fooled around a little bit and started teaching us how to do unit testing. And we discovered all kinds of really awful stuff that these consultants, the guy who was the architect for the system had written some code that was completely wrong, that they had built a system that was based on timestamps and you did things and you updated stuff based on the timestamp. And when something was done, there was an interesting architecture. But he decided that the timestamp class in small talk wasn’t what it ought to be. He wrote his own. 

And it turned out it had a bug in it, that the milliseconds had to run through twice before the second would increase once. And so we would have a situation where time did not run linearly, it would go back, right? And so first unit test we wrote was just checking calling [unsure word 28:45] and see if it was always greater than the last one and the test failed. The first unit tests we wrote. And so this caused these people to basically all quit and leave. And so we’re just kind of left by ourselves. And setting around, Kent and another I remember about a guy named Dan Wells, decided that the right solution was to start again. And so Kent went and talked to the CIO of Chrysler and said, we should start again, they store everything away and start again, it was a good learning thing we did, a good learning exercise. It’s time to now start through.

Speaker: Miljan Bajic  29:27

What was your first impression of Kent? I mean, that’s pretty ballsy to go up and talk to…

Speakers: Chet Hendrickson  29:34

He’s such an engaging person. He’s such an engaging person, that he just sucks you in no matter what. And so we didn’t have anything. We didn’t, I think and I still would and so he went and our customer, our business partner, Marie had gone on vacation. She was in Florida, it was the week of Valentine’s Day in February and so one of us called Maria and said, we decided to throw it away and start again. While she was on vacation, she said, I’m never going on vacation again. And so she came back from vacation. And he sat us all down and taught us the process he made up, that he and [unsure word 30:24]. And didn’t have a name for it. And it’s just how we were going to work. And he said, okay, we’re going to do these things called user stories. So what’s your user story? And a user story, that’s a good question, what’s your user stories? Imagine we’ve written this program and it’s the best possible payroll you could ever imagine. And we ship it, the payroll folks are using it. It’s in production, it’s being used. 

And after they’ve been using it a little while, we go talk to him. And they tell us all the wonderful things this new payroll system does, they can do with it, how great it is and all the things they can do and all the problems it solves and all this stuff. And he said, imagine we would write those things down, all the stories they tell us about the payroll system, write those down and go get it our time machine and go back in time and build that. That’s what a user story is supposed to be. The story your user would tell about what your product does for them. None of this as I went sold that garbage, the store your user would tell about your product. Now, there’s one problem with that of course, which is there’s no time machine. But you had to overcome that. So imagine what this product was be like.

Speaker: Miljan Bajic  31:43

And also understanding and it goes back to empathizing with the users and understanding what’s going on and what problems they’re dealing with and looking through their eyes, right? Rather than typically, you would look as a developer from a systems perspective and through own eyes.

Speakers: Chet Hendrickson  31:59

Yes. And so it’s like putting yourselves in the hands of that. And of course, as a practical matter, what we did was, Murray had written a big huge requirements document, sometimes over this period. And so we got some five by eight index cards and we gave her some glue and a pair of scissors and we had to cut it up and glue portions of this requirements document on cards. And so that’s how we did it to start with was, she cut up the requirements document and glued it onto cards. And after a while, she started dragging things. And we just went down the path of talking about stuff and she dragged stuff down. And that’s in random course, we kept them in a lunchbox. We stored the backlog in a lunchbox. 

Speaker: Miljan Bajic  32:45

That is awesome. And it’s interesting because I don’t think I’ve heard that story. I’m sure you’ve told it before. But I think it’ll be interesting. Where did this Ron come into this? When did you meet Ron?

Speakers: Chet Hendrickson  32:58

Well, Kent was only going to come by like a week every month. And Martin was doing the same sort of thing. We decided we need to have Martin because he saw what was going on before, he was the guy who told us that these other folks are out there off the rails, we probably still need to have somebody who’s a second check. So we brought Martin in, get Martin. And Kent said he needed somebody there full time. And so he reached out and his buddy who used to work with the word Cunningham, there’s somebody you should have asked to come on as we’re cutting him.

Speaker: Miljan Bajic  33:36

I have him on my list. 

Speakers: Chet Hendrickson  33:39

Okay. So he called the board, said, you know anybody in Detroit? And Ward said, I think I do. And he called up because years ago, a few years before, Ron had been working with little startup companies. He’s based in Ann Arbor [inaudible 33:55] just outside. And they were doing this little startup to build this little program. And they had brought in Ward to help them. And so he said, I know Ron Jeffries, who was in Ann Arbor. And so he gave Kent Ron’s phone number. And he called up Ron and said, are you near Detroit? You’re in Detroit. He said, Well, I’m in and around close enough. Okay. And so he said, Okay, cool, we’ll talk to these guys. And so he came over and talked to us. 

And I think we sent him home the first meeting. But he came back a second time when we came in. And so he stayed with us. He was our onsite person and we would not have been anywhere near as successful as we would have been without him. So it was a good decision to bring him in although the first time we were not too sure about him. Because we didn’t know how many of these guys we needed. Because we had Kent, we had Martin and now we’ve got Ron whose there full time. And it turns out after a while, Kent and Martin would show up on the same week. And that was a wonderful experience to have both of you guys working together on stuff, writing code with both of them, looking at things and doing things with both of them. 

And then Ron coming in and Ron there all the time and helping, Ron wrote almost no code. He wrote almost no code. But he influenced everything we did. In the final analysis, there might be more code in that system that Kent wrote when he was there every week as opposed to Ron because he was like, I’m not going to write the code, I’m going to help you figure out what’s the right thing to do. So he taught me amazing things that I would not have learned otherwise about how to solve problems in ways that I had no idea he could solve.

Speaker: Miljan Bajic  35:43

True coach, huh?

Speakers: Chet Hendrickson  35:44

A true coach. Not getting on the field but helping people do things better than they would have otherwise. So yeah, absolutely. All of them, all of them are like that. Working with those three guys was just an amazing experience.

Speaker: Miljan Bajic  36:02

What are some of the memories like maybe with each one of those like, well, if you reflect back since you first met him, what are the things that stand out? What are the things that you remember?

Speakers: Chet Hendrickson  36:17

Well, of course, with Ron, it’s happened every day. And so there’s interesting things. I just said something about stuff he taught me how to do. He had worked with some really odd guy. Odd is probably the right word over Ann Arbor, who had a belief and I think probably correct, that the basic mathematical underpinnings of relational databases are is wrong. And he had a different set of math. And So Ron at one point had actually built a database system based on this alternate form of math. And so there are times where we’re dealing with large pieces of data, that he would just bring out just a little bit of those ideas about how you deal with that to be able to process huge amounts of data in incredibly ways that I had no idea you could do it that way. And so and things that most people, that most systems don’t approach, and so on. So we had a system situation where we needed to take a huge chunk of data in and rearrange it and put it in a different order. And my solution was to file transfer it back to up to the mainframe and run it through a short program and then bring it back down. 

And so I started doing that and Ron said no, we just do this. And we wrote just a little bit of small talk about that much. And it did the thing we wanted to do in less time than it took to file transfer to the mainframe. We had the problem solved by the time the file transfer finished. And so taught me how to do those kinds of things with playing with indexing, creating your own indexes, and manipulating them and then rewriting the file based on what your index was using basically just pointing using a pointer to go through the file and pull out the data you want. Martin is just a fun guy to do everything, all kinds of stuff with, so he’s just a wonderful guy. And I actually went off and work with him a little bit after he got a real job. And so yeah, all the stuff we do with Martin was always fun. We actually worked together to create the first acceptance testing framework we used. So we wrote it together. Actually, I wrote part of it, decided it was no good and we threw it away and did something else but he was very influential on how we did that. Well, I had a lot of fun with Kent, we had to move data from our servers to the mainframe. And of course, they use different languages. 

The server’s down, you’re using ASCII and the mainframe uses something called episodic, which is a different coding characters. And so we had to actually create an episodic file in our smallbox system to be able to send it to the mainframe, because the things that would automatically do the translation don’t actually work on all the things you need to work on. And so there was one day when Kent and I wrote a translator from ASCII and episodic. And I had my old IBM green card is called, even though it’s yellow, that shows what the binary is and what characters it represents. And we use those two things and we actually wrote that translator together. And so that was fun because it was stuff that, Kent had never done anything like that before that. It was foreign to him. And so I was kind of the expert on this stuff. And we did that together and that was fun to do. So, we had one of the rules of extreme programming, is now called sustainable pace. 

And it started out as no overtime. No overtime. And we had a special meeting of overtime, which is having to be at the office when you really just don’t want to be. And there were days in working on that project, working with that team, working on that team, where I wanted to go into work on Sunday. And if my wife hadn’t stopped me, I would have gone to work on Sunday, it would not have been over. Because we had so much fun doing that but it was not overtime. It was fun every time we did stuff and there were times we had little conflict here and there and all this stuff that happens. But we were a good team and we learned how to work with each other. We had created our own culture. 

Speaker: Miljan Bajic  41:01

How big was this team? How many people are we talking about? 

Speakers: Chet Hendrickson  41:05

Counting Marie and sometimes she had two or three assistants working with her. We were probably Max about 15 or 16. So probably 12 developers more or less. So a nice team, kind of on the hairy edge of how big you ought to be. But still of course, we did everything in pairs. And so it made your size logically a little bit different. Again, that’s as big as it was. And we completed our product, our system in 11, three weeks sprints. So 33 weeks which we came up with and we hit the date, because it was already made, and we hit it. And we’re facing something that was took 14 months and didn’t work. So we did it in less time with fewer people and worked way better. Eventually, they replaced what we did but with an off the shelf solution, they bought something from PeopleSoft. And it took two years to implement in three times as much money with the team three times [inaudible 42:18]

Speaker: Miljan Bajic  42:21

And that’s probably still true today, like when you look at it and maybe to shift gears a little bit, I’m interested in there are 17 authors of the Agile Manifesto.

Speakers: Chet Hendrickson  42:36

Yeah, hate everyone else.

Speaker: Miljan Bajic  42:39

I’ve signed the independent online and you’re the first on that list. What insights did you have? How did you get to sign up online first?

Speakers: Chet Hendrickson  42:50

Well, I’d left Chrysler and I got in to work with Martin at Thought Works. I spent about a year at Thought Works with Martin. And I was talking to Martin, he said I’m going to this thing that Alistair is having, Alistair is doing this thing out in Utah. And a bunch of us are getting together and we’re going to talk about some stuff. Okay, that’s interesting. So maybe I should go. So I’ll call up Alastair and said, you know what? I understand you’re doing something, yeah. You know, blah, blah, blah, and talk about it. And who’s [inaudible 43:21] and told me who’s coming in, this is kind of interesting. But you got Kent, you got Ward, you got Ron, you got Martin, and he got two or three other XP guys and it sounds like it’s interesting, but it didn’t really feel like I need to be there. Didn’t really feel like I need to be there. And so we decided that I probably didn’t need to be there which was a bad mistake. Guys, it could have been at the Agile Manifesto, including me freestyling my consulting rate, and nothing else. And so I didn’t go, I didn’t go. And so Martin came back and said, Oh, we wrote this thing. Somebody told me, hey, blah, blah, blah and Ward is putting up this website, and he’s going to publish it. Okay. And you can go out and know and you can sign it on the website. Okay, so I was the first person who signed it, because I’m the first person who knew about it, because nobody knew. This was before everybody heard of the Agile Manifesto. Martin came back on Monday, he told me that we did this thing and you go out here to this website that were built, and you can sign it. So that’s why I’m the first signatory is because I’m the first person to have heard about it. Because I didn’t know [inaudible 44:39]

Speaker: Miljan Bajic  44:42

You wouldn’t have [inaudible 44:43]. Great, I think if you did, but going back to diversity.  

Speakers: Chet Hendrickson  44:49

Yeah, one more white guy have [inaudible 44:50] with one more white consultant have helped. Probably not, probably not.

Speaker: Miljan Bajic  45:00

Given that, I didn’t know the context by given that, everybody there like you really should have been but…

Speakers: Chet Hendrickson  45:08

Yeah, a lot of people think I did. I can straight on that sometimes you know. Even sometimes you get a drink in a bar based on being me. And so some people believe I was, so I’m close enough for them. Okay. 

Speaker: Miljan Bajic  45:25

Yeah. We got a little bit of time here left. I have a couple of questions, but I’m interested from your perspective, what should I have asked you didn’t know enough to ask? Like, what is something that you would ask? Well the question I asked Ron is, I told you before we started, I reached out to Ron to say, hey, give me some things on [inaudible 45:47]

Speakers: Chet Hendrickson  45:50

I think I can give you questions for Ron. [cross talk 45:53]. I feel like I can talk about most about anything. There’s challenges in every space we go. And I think that bringing more and newer ideas in are probably helpful. And if nothing else, the question you might, should be asking, the old gray backs like me, isn’t what insights we have about what’s happening and what might happen in the future, the best question might be, who should I talk to? Who should I be talking to, to get new and better ideas from the world? 

Speaker: Miljan Bajic  46:45

Then who should I be talking to? Who do you currently respect and think that we should be talking to and maybe bringing some more spotlight on?

Speakers: Chet Hendrickson  46:58

There are some really interesting non-old white men out there. Jessica Kerr, Jessy Tron, she’s known, is incredibly interesting. And if you don’t know her and don’t know the stuff she’s been talking about for the past few years, you really ought to talk to her. She did a keynote address at one of the Agile alliances technical conferences a couple of years ago, talking about the beginnings of opera and how that was actually something that was intentionally done, that there was actually a group of folks who did not think music was moving in the direction they wanted it to move that there needed to be a new idea. And they got together and came up with what opera is. And there’s actually a term for this community, is called a camaraderie. I can’t pronounce it. The word before my man in a moment. A cammarata, cammarata, I believe is the term, which is this little intentional group of folks who come together for a reason and work together. 

And to the extent that the folks who were the birth of XP and Scrum and Agile were little group for this cammarata kind of things happening. And so talking to her about those ideas plus whatever else she thinks is interesting right now, incredibly useful. There’s another wonderful person, Kat Swissotel out in Arizona, I think Kat is. Who’s one of those people that if somebody says, who should I invite on my podcast? I say call Kat, because she’s brilliant. And that’s somebody we ought to need to have more spotlight on. And so I’ve talked to those two folks, tell the m that the old white guy have suggested we talked to them. Because they know that we need more than a lot guys in order to prosper. And I think that’s probably the most interesting question you could ask, which is, who should I talk to that isn’t white guy? And it’s Jessica and Kat, I think are the folks you want to talk to.

Speaker: Miljan Bajic  49:33

Great. That’s a really good way to look at it. And to really [inaudible 49:39]. One of the reasons I didn’t ask that is like, hey how disconnected are these people [unsure word 49:45] or whoever, right? And sometimes I’m making my own assumptions. And you just you made me think about something that I haven’t thought about and just… Maybe as a last question, I want to just maybe focus on Scrum a little bit, a lot of developers don’t like Scrum. And for various reasons.

Speakers: Chet Hendrickson  50:12

Yes. They mostly don’t like what we call dark Scrum. 

Speaker: Miljan Bajic  50:20

Yeah. And how do we help developers? I know you and Ron have talked about, like when it comes to investing in developers, training develop. So you created the scrum Alliance, the first CSD program, it’s being revamped right now. But in general compared to, there are a lot more developers as you’ve talked about it, as Ron has talked about it, but what can we do to help developers?

Speakers: Chet Hendrickson  50:47

I think, unless we put ourselves in their shoes and understand how scrum has impacted them and not Scrum as described in the scrum guide or necessarily taught by trainers but what actually happens on the ground. I think we know that one of the manifestations, perhaps the most significant manifestation of this thing that Ron and I called Dark Scrum is the daily scrum, the daily standup as most folks call it, we were forced to stand up for 15 minutes for some odd reason. I always like to say that this is called the daily scrum, we don’t care what physical posture you take off, you can stand, you can lie on the floor, you can hand on the ceiling, we don’t care. But saying we do care that you have to stand for these 15 minutes. That’s kind of silly in it. And that it’s a serial interrogation, where you have to stand there and confess what you did yesterday and what you’re going to do today, and what you need help with.

Speaker: Miljan Bajic  51:56

[inaudible 51:57] that you’re busy. Yeah. 

Speakers: Chet Hendrickson  51:58

[inaudible 51:58] that you’re busy. When I became a programmer, maybe once a week I had to tell my boss what I’d been doing. Where I didn’t have to tell them every day, maybe not after the first week, I didn’t have to tell you every day what I was doing. But once we understood that we were on the same page, we’re trying to accomplish here. But think about what happens is we tell you that here’s this thing that you have to build something in these little slices of just a few weeks at a time, without giving them any insight in how to do that, because they have been taught in their training and in university or wherever, how they learn to program to work in a particular kind of way. And they’ve worked in that particular way their whole life, we went off and you did analysis, and you did design, and you built this thing and [inaudible 52:52] and on the very end, you’re supposed to have something that work, now the fact that never actually happened, didn’t matter to us very much.

And now we’re saying do this completely different thing. And we’ve not taught them how to do it. And that was what the original CSD did because it was based on the XP immersion courses, which is teaching people how to do that. And I think one of the things that happened in the original XP immersion that happened in Ron, in my five-day Developer course, everybody in that class, every little team put together in that class failed at one point or another. They had a sprint, we had a 90-minute sprint, that 90-minute sprint where they didn’t get anything done. And the important thing in a five day classes, you had time to do that. And then the most important thing is in the end, discover how to survive to get back on track from that, how to recover from that. 

And in a two-day class and a three-day class, you really can’t do that. Even if it’s a two-day programming class, you might get to the fail part. But you won’t get to the recovery part. And it turns out that programming is way more failure than anything else. And that’s the thing nobody is taught how to do, is recover from failure. You read a programming book, and the guy writing the book has apparently never made a mistake because there’s no mistakes in the book. If you go off and you read any of Ron Jeffries articles about programming, you will see how frequently a real programmer, a world class programmer makes a mistake. Because he tells you what he did wrong. And he tells you how he got out of it.