James Grenning: How to Make Your Team an Iterative Engineering Machine Safely

Richard:

Hey James, thanks so much for joining us today.

James:

Richard, thanks for inviting me.

Richard:

Is there anything you would add on to that, that introduction? Anything else you want to say? Anything I missed?

James:

Sure. I’ll add a couple of things. I’ve got a wife of 42 year years, wonderful wife, three grown kids, My wife and I spend most of our time in Florida now for obvious reasons to avoid the Chicago winter. Three grown kids with spouses all off the payroll for a long time and seven grandchildren, seven and under, which is an amazing statistic that some of my friends down here in Florida are jealous of. And then kind of on the work side I’m… COVID pretty much killed traveling, which is okay. I don’t miss it. I thought I might miss it, but I don’t really miss it. And I’ve been doing live training remotely for a long time. And now for the last years, I had figured out how to do it with video. And I’m about to start my first cohort through what I’m calling myself self-pace training and then hopefully I can reach more people in the world that way and not always have to worry about people hitting my schedule and they can learn to on theirs.

Richard:

Right. So exciting. Well, I think a lot of us have had similar experiences over the last couple of years. So this podcast, It’s about all the things you talked about and more, it’s about teams and I’d like to ask people about the best team they’ve ever been a member of in their entire life, right? And this is arguably a work context kind of podcast but this doesn’t have to be a work team. Any work team, non-work team, any group of two or more people who are aligned with a common goal, that’s one of the ways I define the word team. What one of those is the best one you’ve ever been a part of in your life?

James:

Well, when I heard that question I’m thinking well, there’s two that come to mind. So coming up with just one is hard and actually three come into mind pretty easily after I think of the two and you know, it’s hard to always put a limit on stuff but my first job was interesting and maybe it wasn’t the greatest team, although it was the most extremely diverse team because they were mechanical people, electrical engineering, and a few software people and we built the first color weather radar display system and that was kind of a cool thing back then to have built. But probably my next team was the most enjoyable team that I got to help form. It was at a company I worked at in the 80s and part of what I was brought into the company to do is to bring maybe some more process. So we were trying to learn waterfall back in those days. And I came from a government contracting thing with the FAA. And so we were in a growing company, it’s where I met Bob Martin. He recruited me there and we were both young guys working on different parts of this system. And I recruited a team from the college I went to. I’m wondering why the women went away from software development because my team was half women and half guys.

Richard:

My most recent guest said the same thing. she got into software development and it wasn’t unusual for there to be women at that time.

James:

I think back in those days there wasn’t somebody saying, oh, you should go into computers. For me, it’s like I was trying to avoid computers. There’s typing, you know there was all kinds of bad stuff going on and I thought, I’ll just stay away from that. And then I had to do some programming in one of my calculus classes and now to simulate Newton’s method, if you remember that, about finding the area under a curve and it was fun. And I was just kind of shocked by that. And so then somebody will pay me for this? It’s like, “Oh, okay Yeah, I’m going to do that”. And so we recruited a team from that same place and I think a lot of the story was similar as people that were interested in solving problems, bumped into computer programming. And so we had this really great young team and we lived Conway’s Law. Do you know Conway’s Law? your listeners basically.

Richard:

Share with us .

James:

The structure of your team will reflect the architecture. And so we had a five or six person team and basically each person took a responsibility area. You know, one’s communications, one’s UI one’s database, one’s resource management and we would sit down in a room and have a conversation about how the system works. And it was great. We are doing great things, learning to build a really cool system. The one bad thing about that team is that we probably weren’t good enough at communicating to the boss. And in these days there was a lot of motivation to do things and very unrealistic deadlines, like everybody still lives with today. And he wasn’t very tolerant of missed deadlines so that team we were doing good things but he got mad at us because we couldn’t do the impossible and eventually kind of spread us around a little bit, which was too bad ’cause it was a really cool team. The next one, I actually wrote a story about this team and it was right after I’d learned Extreme Programming. I took a week off from this client, I’m working at object mentor, Bob Martin’s consulting company at the time in the late in the 90s. And we had been learning about extreme programming from Kent Beck and Ron Jeffries, Ward Cunningham and Martin Fowler. And I had to take a week off of my consulting job to go learn about Extreme Programming. And when I got back, I was so excited about it. I started to try to get the people that I was consulting with to try it. And now this was a company that was pretty, very waterfall, document oriented. What documents do we have to produce? There’d be this big stack. And I talked to the director and he, being as the outside disruptor. He said, “Well, that just sounds crazy enough so that that might work.” You know ’cause I explained to him some of the stuff I was like, can we try it? He goes, “Sure, I’ll give you a waiver for some of your processes.” But the rest of the organization fought us about not producing all the documents, but the team was really cool. We worked together nicely, people were learning, there was maybe half experience and half inexperienced people and they were all just kind of sponges to try new things and also very critical of it. So it was an interesting story. One of the bad parts in that story, I keep talking here. Is that one day in a big company, this can happen to you. Somebody else is at our team meeting. It’s like, “Who are you?” It’s like, “I’m the new guy on the team.” It’s like, “We’re getting a new guy on the team.” “Yep, here I am.” And he was not all in on Extreme Programming. He’s like, “Where’s your architecture document, where’s your this, where’s your that, where’s your the thing?” Now you can’t program together. Oh no, I won’t do that. And for a month we got zero done and we actually had to actively get rid of him because there’s no way he would play with us. And so we had to get the team leader to go move him somewhere else. That was a very bizarre thing to have happen but it was a really cool team then as soon as the disruptive factor was gone, we got back to work and pretty cool stuff.

Richard:

Cool, on the second team, there was a problem with meeting unrealistic deadlines that were assigned to you. What happened on the third team, the XP team.

James:

The XP team we actually… So we’re working, one team was doing XP and maybe five other teams were doing waterfall listenings. And I was with this team for about a year, which is unusual. Usually I don’t do long term gigs like that. And this was every other week for about a year. And by their own metrics, we produced about twice as much working functionality over that period, than teams not doing that. And they had a measure for that, I forgot what the metric was exactly. They said our quality was about the same, it wasn’t a lot better but we had a lot more of working system. And so the interesting thing about working with a XP flexible team next to a bunch of waterfall teams is somebody come to schedule chicken where everybody’s like, “Yeah, well make it”. “We’ll make it”. “we’ll make it”. Every single scene they’ll make it. And then when somebody finally says, well, we’re not going to make this deadline and then that destroys the gigantic PERT chart that’s been established. The PERT chart that shows all the dependencies now it’s all ruined. And what really made the waterfall people mad was when we were in the room and say, “No, we don’t care we’ll just move our… Your integration’s moving out two weeks? We’ll just move it two weeks. We’ll move something else and it’s like, “You can’t do that. Don’t you have to go talk about it?” It’s like, no, we can do it. We know what to do. We’ll just move that, so it was pretty cool.

Richard:

That’s awesome. That’s awesome.

James:

Surprising, I was brand new at it and I’d never done it before but the ideas seemed to make sense to me after trying things the other way I guess with 20 years of experience doing things that didn’t work, something that sounded like it would solve problems was kind of cool.

Richard:

It actually worked and it’s really unusual, there aren’t that many opportunities to have decent data or decent experiment showing that XP or any particular practice gives you better results. So it’s a really nice natural experiment that happened.

James:

Well, then the next thing that happened after that is they want to do it in more teams. And so, because what they do is this company, I’m not going to name them because they value process over it just about everything. It’s like “Okay, James, go to another team and do exactly the same thing”. It’s like, that’s not possible.

Richard:

You should document how you did it so it can be reproduced.

James:

Yeah, that’s not possible actually because these people have different skills and will do something like it but a little bit different and that’ll be okay. And it’s like, “No, it’s got to be just the same”. And then they put a big waiver, like you’d have to do a 20 page reason why you were going to do this rather than the standard process to give to the QA police. And so it was just too easy for every reason to keep doing what they did and it all mostly weathered and died I think. It was too early for this company, it was too radical at that time.

Richard:

Now I want to dive deeper into one of these teams if we could. Now I feel like I don’t remember the name of that old game show when I was a little kid but the host was Monty Hall. Should we talk about team one, the team behind door one, the team behind door two or the team behind door three.

James:

Okay.

Richard:

Which door? Which team should we dive deeper on?

James:

Yeah, the XP team was just very willing to experiment. Right I mean, so we had things we had to do. They wanted to get stuff done but they were willing to experiment and try something that was not what they usually did.

Richard:

Okay. And sometimes people get precise about the word experiment. Do they have any criteria to evaluate the experiment? Is just open to trying new things in general or was there some threshold to see whether it worked?

James:

I suppose there was the measures later about how much did you get done. But there was the continual demonstration of something new every couple of weeks, which was something there, now were there metrics about it? Not really, except for these final ones which I was unaware of that were going to even be measured by them later in the process. I know a team next to me that I coached there at the same place a couple of years later, they got to QA and didn’t have enough bugs for QA to find. And so they were sent back to go find more bugs because they didn’t have enough and so there was a metric about how they worked in finding problems early is at their phase gate. They weren’t finding as many problems as they’re used to and so they thought something went wrong, so they sent them back to start over. That was yet another team but that didn’t happen to the team that I did the XP with the first time.

Richard:

Okay. So these are some great objectives. I don’t know if they’re exactly objective metrics but there ways that we know objectively that this team was really good, right? They produced about twice as much stuff as the other teams. You were demoing something new every couple of weeks, so there was observable progress, it was very objective. Is there anything else objective about this XP team that goes into knowing that it was such a great team?

James:

We had really good access to… Well, the team member was the system engineer on the product was one of the systems engineers that built the last product so he knew it inside and out. He knew what we wanted and we could ask extremely detailed questions and he would come back to us with extremely detailed answers. And at one moment I just like, “Where are you getting these answers?” He said, “It’s in the old code in the old system”. It’s like, “There’s an old system”. I didn’t even know there was an old system, It’s like we are just building the thing they kept asking us to build. Would’ve been nice to know that. This is in the day of big design problem because a system was built around Time-division multiplexing which is what phone calls you use, landline phone calls use to share time on a digital medium for what they used to use, not anymore. And it was moving the voice over IP but all the technology was mixed in with the business and so it had to be–

Richard:

Interesting.

James:

Reinvented.

Richard:

Yeah.

James:

Right.

Richard:

Cool.

James:

You’re making me remember stuff I’d forgotten about.

Richard:

Likewise, Time-division multiplexing. How about subjectively if you take yourself back to this team, were there any sensations, any feelings, anything that you felt within yourself or that subjectively goes into knowing that this was a really great team?

James:

An interesting thing happened at the XP group is the boss was really I think very insightful because there were some things that we wanted to do and he said, “You’re never going to be able to do that here”. I said, you know what we want is a team room. And he took me to… I think where I’m going to is understanding what the limitations of where you are are, okay. ‘Cause so much is possible. He took me to this room with maybe 100 engineers in it. He said, “You see that wall over there”. And it’s a cube farm and then there’s private offices with doors along the side. He says, “You see this office, if we change anything, we’re going to have to redo the whole office to bring it up to current company specifications.” Okay. Which means the union’s going to come in and take everything apart and put it together. And the guys who you’re going to need support to do this, the guys who are going to lose their private offices in this idea are right over there and you’re not going to get them to do this. So let’s see if we can find some other way for you get a collaboration space. And so we were talking more about shared Pla cubes and the shared place. He found a nook in a cranny that we could go to but there was battles, we like half won that but we couldn’t win it in a big way.

Richard:

Yeah.

James:

Yeah. What are the limitations? So that was discouraging but it was also, I mean at first it was discouraging but then it was, then what else could we do? If we can’t solve that problem, can we solve a different one and kind of end up with the same result.

Richard:

All right. How about some of the concrete behaviors? We’ve said this is an XP team, an extreme programming team. Were there specific XP behaviors that you tried and others that you didn’t try? Was there anything you did in addition to extreme programming that helped this team be so successful?

James:

Yeah, we had an existing specification for the product. And so we’re looking at that and thinking, how do we turn that into stories? Now stories, the system engineer said, “That’s a little too light for me, how about we’ll do use cases instead”? So we did. So we did use cases. So we took this requirements document and basically turned it into a list of use cases. It’s like, this is like our big story list. And now if we’re going to work on one, let’s elaborate one of those. And so he’d write a formal kind of use case up and we’d go work against that. So it was kind of a variation but it was very radical for their environment ’cause what they would want to have done and what their official process would say is do all the analysis first and then you can start design and then you can start development and we were just doing everything all at once.

Richard:

In small chunks.

James:

Yeah, doing in small chunks and extreme programming is silent on documentation. Now it doesn’t mean it’s anti-documentation, it just doesn’t give you any advice about it. And I remember Kent Beck and company telling us in the 1999s if you need documentation, make sure that you know who the customer is and make sure you know why it’s valuable and understand it’s expensive. And so do that carefully, it’s not free. And so we started pushing Beck and the organization and grew a requirements document. So there’s kind of blending into their environment. We started with three pages and everybody looked at it it’s like, “Are you kidding?’ This doesn’t weigh anywhere near enough. As if how many trees dies as measured progress. But every time we went through an iteration of learning something, we added to it. And so it grew so that by the time we were done, we had a pretty good writeup of the… Let me call it the equivalent on US map of the architecture. So you knew where the interstates were but if you wanted details, you’d have to go into the code. And we just stuck with that even though somebody else, other teams were doing other things we were able to let that idea prevail and that was pretty cool. We worked in kind of long iterations, long compared to what I’d think now, but really short for them a month long. That was as short as they could go and we did pairing and we rotated pairs regularly and usually senior people with less people. But I noticed, i learned a lot the from the less senior people and everybody knows secrets about how the IDEs work and everything that nobody else knows. And so you get this nice… Now there’s mobbing of course where you have this intensified but we got this really good spreading of the skills and so like some of these young guys are just out of school and getting to learn things that took me 15 years to learn ’cause I’m explaining to ’em why this is important. And that they’re showing me immediately of something I didn’t know. And it was just very cool, that whole give and take. The only time we really got into trouble is when two junior people were together on a week when I wasn’t there and then I came back and we noticed we would run code coverage just to see, are we really doing a test driven development? And ’cause if we stopped, there’d be a hole in coverage if we weren’t doing it, we found a hole and it’s like, Oh no, we tested that, you just have to go and reconfigure this thing here and then run the test again. And actually they found ways to pass the two tests but not in the same system. So they had a contradictory requirement, they didn’t know what to do so they configured the system two ways and then we said, okay let’s keep running this code coverage at the end of the week and maybe two guys work together that are the junior guys, senior guys got to come and look at it soon.

Richard:

Yeah.

James:

And they were all… Retrospective was a little bit natural for them. It was a natural thing for them to kind of look at how can we improve.

Richard:

I’m curious about rotating pairs. We’re talking about pair programming and changing who your partner is periodically. How frequently did you change partners?

James:

We’d probably work together generally for the day or maybe half a day.

Richard:

Okay. So, pretty frequently.

James:

Yeah, and it was good because then everybody got to know the code. So people think you’re pairing to, all the misconceptions about pairing. One of them is somebody’s going to watch me to make sure they catch me when I make a mistake. Well, sure. that’s true. But then I’m only going to drive for a while and I’ll only be able to take so much if you told me all the mistakes I make. We’ll take turns and I’ll watch you make mistakes. No, we’ll work together and the rates which we make mistakes is unbelievable to me. And today still I know my rate is measured in mistakes per minute. Probably not per hour, but per minute. And especially in the feedback loop of test driven development. We switch pretty often and one of the problems was getting some of the senior people ’cause they always get pulled into other review meetings and things. So lots of times it was me rotating with the new people in the group and that was fun, I had a good time with that.

Richard:

Cool. How about some advice for listeners and viewers? How could they reproduce some of this team’s success?

James:

Well, let’s see, I don’t know your listeners, are they largely scrum advocates?

Richard:

They might or might not even care about agile or agile product development.

James:

Alright. Okay I like to caution people about, and you’ve seen my little graphic of…

Richard:

Yeah, you could put that up or you could give it to me, we’ll add it on later either way.

James:

Let’s see, little pain you can’t see it all but basically I get to talk to scrum teams fairly often. I’ve been invited to do keynote talks to them, which is nice of them to. I don’t really have anything to do with scrum, but it’s nice of them to invite me. And I said, what do you want me to talk about? And it’s like, “Well, you could tell us some things that we’re doing wrong”. It’s like, okay. “But be nice”. And so I have this talk I do about the importance of the technical side of agile. And one of the things I noticed in scrum, most of the teams, and if you go to a scrum gathering, there’s almost no technical people there. It’s all the people that are running the technical people and the engineers are off somewhere. And I’ve discovered through reading lots of people’s opinions about agile that are in engineering opinions on it. They hate it because they’re being micromanaged by all these people that are into scrum and they don’t know how to iteratively engineer. And so it it’s painful and so company people will come to me with this pain, I’ll say, well, you started doing this wrong backwards. We always taught the engineering practices first so that when a story comes up, an engineer actually has an idea of what does it mean to do something small right now and make it tested and et cetera. How can you do that If what you’re used to is working on requirements for four months and then working on design for four months and then working on code for four months and then debugging for two years. But if you’re used to that, it’s a different thing than can I deliver something in two weeks. And so if your teams are struggling with iterative development, have you helped them get access and learn iterative engineering techniques? So we can do it safely. So that would be my advice to teams that are trying to iterate. And if you’re not iterating, why aren’t you? Okay, so DevOps I think is going to pull on technical practices. So this continuous deployment that’s going to pull on, you’ve got to have good things going otherwise you’re going to have the old garbage in garbage out. But if you got to put something good into that pipeline, and so that means you’re going to keep going back further and further in your processes to ensure the thing that goes through that pipeline out to your customer works.

Richard:

Yeah. Now I have an opinion but I want to hear what you think. DevOps, agile? Are they different things? Are they the same things? What do you think?

James:

DevOps is very not surprising to me. I told you about the Extreme Programming training in 1999, it was called Extreme Programming immersion one. And one of the people there, I’m not recalling his name right now but I’m picturing his face but he told a story of… And they lived near Kent Beck in Oregon. And so I think Kent had been working with them somewhat and they were practicing all the Extreme Programming practices in the late ’90s. And they built this machine that sorted French fries. And if I’m remembering the story right, truckloads of potatoes, I’m going to embellish it a little bit ’cause stories have to grow a little bit. Truckloads of potatoes get dumped into this hopper along with the golf balls and stuff that the farmers were shooting into the field. And then it goes down this conveyor belt, and there’s cameras watching. And the potatoes would go over a gap and an air gun will shoot foreign objects out of the air. And then the potatoes would go through and get cleaned somewhere around. Maybe there clean potatoes that go into this, I’m not sure. But they eventually get peeled and sliced and lots of stages of manufacturing so that you can have perfect French fries wherever you go throughout the United States. They had a pipeline then–

Richard:

Machine now.

James:

They had a pipeline then which would produce. If they made a single any code change, it would go as far as producing the ISO file that they would burn onto the distribution CD that they would send to a site. If right and so now someone, the last step someone would have to choose to burn that ISO. It didn’t automatically burn it ’cause they probably were changing stuff too often. And so it went through lots of stuff.

Richard:

Somebody had to put CD into the machine.

James:

Say again.

Richard:

Or somebody had to physically put a new blank CD into the CD burner.

James:

That’s right, yup. And so for me, when I heard the word DevOps, it’s like, what is that? And then somebody explained to me, it’s like, oh yeah, okay. Sounds like the natural conclusion to someone doing Extreme Programming. So other pragmatic programmers of other… Pragmatic programmers of other Agile Manifesto contributors. Right? So reading a pragmatic programmer in the late 90’s as well, if you have boring repetitive processes and I kind of live with this every day, this advice is rattling up here. If you have boring repetitive processes, automate them. ‘Cause not just because you’re going to save time, although it’s nice to save time. But I might spend a week and not save that week. But what I do get from the automation is a big step in quality because you work through the things that if I’m going to deploy something again and again, then I’m going to make mistakes in that and it’s not going to end well. I was contemplating making a course and putting it into teachable. I dunno if you’re familiar with teachable but it’s one of these online learning systems and one of their advertising points is, no need for programming ability. ‘Cause everything is mouse clicks. For me that’s like, oh no, this is going to be bad. ‘Cause I’ll have the video that I use as promotion on my website. I’ll use it during a class as one of the modules they have to read and I put it and I had it in teachable to be in at least three places. And that means if I make a chain change in that video, I have to remember what the three places it is and actually go and do that. And because of that problem, I’ve decided finally after paying them for two years I’m not going to use that service. I was building the content, I just said, nevermind. I’m not going to use the service ’cause I can’t import my content. And over the last month what I’ve been doing is adding basically teachable capabilities to my website. So had to build it myself. But ’cause now I can make a change, It will appear everywhere.

Richard:

Yep. I’ve got stuff going on in my head. It’s it’s all related. So I think by the way we’re talking about it, I was also practicing a thing that was very similar to what we call DevOps today. And I think it was just like that. It was sort of a pride thing as well as higher quality and all that. I used to say the computer was laughing at me, If I was doing things manually that it could do automatically. Like I should be writing code that automates these little scripts that automate this work. So the computer doesn’t laugh at me anymore for doing computer… You’re a human and you’re doing computers. You’re doing the computers work. Stupid human.

James:

Well, yeah, getting off of Windows is an important thing ’cause windows made automation really hard. Like that was probably the first thing that got me in the mid 2000s trying to automate things with Windows command line, whatever it’s called was nearly impossible ’cause they were missing key things to be able to actually have a robust bash script, not a bash script. Robust script, whatever they call that. And so that moved me into Mac when it had the ability to do a boot. So I could have Windows if I needed in virtual machines. And then they had a command line with Unix. So then things could start to be automated.

Richard:

Yeah, for sure. For sure. Now, I have so many other things I want to add onto, but we’ll save them for later. Is there anything else you want to add? Anything we haven’t touched on that you think is important for people to hear, any projects you’ve been working on recently? Anything at all?

James:

Unfortunately, my team is… I’m the one person team here, which for my website development, I’m the IT department, I’m the sales department, I’m delivery, I’m accounting, right, so. But when I’m playing customer for my system, it’s amazing how I can’t get it right. I say, James, you would like this certain thing. It’s like, okay, I’ll try to build that. And then I build that and it’s like, no, you don’t need that, that’s no good. Oh yeah, you need it to be different. And so I would say, you know what, don’t be surprised, when you give someone… This is why iteration is so important. When you give somebody something they ask for, they’re going to say, “You almost got it right, Oh, I wish I would’ve asked for something different now”. Right.

Richard:

Perfect.

James:

Yeah.

Richard:

Brilliant. And how could people get in touch with you if they care to? I’m sure they do want to.

James:

There’s Twitter, jwgrenning. There’s wingman-sw.com is my website site. If you’re an embedded systems engineer, you should definitely think about taking my course. I will be offering so far I’m just doing my first cohort through the self-paced version of the class, which will be a partially self-paced. we’re going to have a meeting every week as a debrief for each of the three modules. And then once I’ve had people go through it that way a few times. I might offer it for individuals to take as well if they want to then they can shoot me questions by email or something, but sound right.

Richard:

Awesome.

James:

And you don’t have to be embedded C or C plus plus is what my courses are really good for.

Richard:

Great. All right. Well James, thank you so much for joining us today. It’s been a really fun conversation. Thank you.

James:

Thanks Richard. Appreciate you inviting me.

Richard:

And dear listeners and viewers, remember to support this podcast, just visit my website Kasperowski.com.