129: James Grenning

Listen to full episode:

Joe Krebs speaks with James Grenning, who is one of the 17 signatories of the Agile Manifesto, about embedded software engineering, test-driven development, planning poker and a new exiting project he is currently working on ; a tool to automate and streamline training content management.

Transcript:

Joe Krebs 0:10

Agile FM radio for the Agile community. www.agile.fm. Thank you for tuning into another podcast episode here with Agile FM I have a James Grenning with me. He is famous for being part of the Agile Manifesto signing the Agile Manifesto back in 2001. And he wrote a book test driven development for embedded C a lot of people know him. From that embedded work, we will talk about that we might start off with the Agile Manifesto. We'll talk about planning poker. And we will be talking about training. There's a lot of stuff you have to cover in this in this podcast episode. But first and foremost, welcome to the podcast gents.

James Grenning 1:00

Joe, thanks so much. I really appreciate you inviting me. It's really nice to be here. And I was looking through your list of other people that you've had on the podcast, listen to a couple and great really nice to be among the company that you keep.

Joe Krebs 1:11

Oh, thank you so much. And obviously this is way overdue that you are joining me on this podcast, we had folks from Agile Manifesto, other other folks that have signed the manifesto, we had folks that have little to no exposure to agility, but we could always connect the topic to agility. But this one, I have to say when we're talking about embedded software and software development, and agile practices for that, I myself will be a little bit out of my comfort zone. So are many of our listeners, possibly. And that is probably because it feels like a niche, but it is not a niche in the in the software world out there. And I think it's growing. Is that Is that correct?

James Grenning 1:58

Yeah, well, there's certainly millions, I don't even know what the right number would be millions of embedded software developers. And I'll tell you, one of the big secrets is that embedded software may be special. But that doesn't make it special enough that agile test driven development and the modern practices wouldn't work for it. So dependency on hardware is like a dependency on a database. If you're going to accelerate your, your development, you've got to manage those dependencies. And so at the core, it's the same problems. And they just look very different.

Joe Krebs 2:33

Yeah. What I wonder, because your background was already before 2001 was in that territory, right in technology that was related to embedded software, telecommunications, things like that, right? As far as I know. And you came to the Agile to the snow Snowbird and actually the funny thing was just yesterday, before we do this recording here, I saw a person with a baseball cap that said Snowbird on it, and this person had nothing to do with agile, but as a tourist is famous, and I will be speaking with James Grenning tomorrow. And he obviously acquired that and snowbird. But when you went to the Snowbird, you were maybe the only one that somehow related all these discussions to embedded software development,

James Grenning 3:20

Actually, actually, there were at least a couple of us, a few of us, let me say, because Bob Martin and I grew up at a company called Teradyne. He was there a little bit before me, and he recruited me to Teradyne back in the early 80s. And we were both working on embedded systems in larger systems at Teradyne. But that's where we started. And all that later when I joined Bob, and his consulting company in the mid 90s. We did a lot of work and large embedded systems like these big printers at Xerox and such. So Bob had a lot of embedded background. John Kern worked on fighter planes and avionics and things like that, if I remember correctly. And Steve Mellor is also known. We I got to know Steve Miller better because we would cross paths at Embedded Systems conferences quite a bit. And Steve Mellor was really into model driven, but he also his depth also was in embedded systems. So there were a few people there with that perspective.

Joe Krebs 4:22

Did you guys look through the lens of embedded software development during those discussions? Or were they like more like, discussions around agility and how to build software in general and just embedded

James Grenning 4:31

real embedded really didn't come up there. I was learning from all the people there and I also tell people the truth and I went there because it's like, you go into Snowbird camp, I want to go and Bob had invited me I worked with Bob at the time. And I love to ski so I was there. In the meeting was really interesting, because the guys that I'm with were kind of my extreme programming heroes, Kent Beck Ward Cunningham and Ron Jeffries and Martin Fowler. And I am getting to know these other people. Right. And so in Bob Martin, of course, a long, long time, friend and colleagues there.

Joe Krebs 5:11

Yeah. So so that obviously had a huge impact on on your career and you continue to writing that book, maybe roughly 10 years later about test driven development for embedded C, going forward a little bit in time today. When people are listening to us right now to this to this podcast, when they're hearing embedded software development, what do they have to picture? What is? What is a good definition for that? So they have a feeling of what kind of problems arise there? And, and then we talk a little bit?

James Grenning 5:42

Sure, well, embedded systems are everywhere. Now. I mean, we rely on them. They're extremely powerful, too, they can be very small, like it might be cheaper to have a microprocessor in your pen to turn on a light than to actually have a physical switch, which is kind of crazy, you know, so you could have an electronic rather than a different kind of switch. So embedded software is everywhere. I generally have, I have my definition, which is, you don't recognize the thing is a computer. And that's a very broad definition, because I would like to have a lot of people be able to learn something about agile for embedded and about test driven development for embedded, you know, things that were mind blowing to me when I bumped into them with extreme programming 1999. It's like, oh, my gosh, why didn't we think of this before, this solves so many of the problems that I have to live with. And so while we hadn't, and it took some real geniuses like Kent (Beck) and Ward (Cunningham) to come up with this way of working for the engineer, I'm an engineer. So I kind of think of this from an engineering perspective. But you know, so the difference is, you don't really think of it as a computer. It's not a website there. Although now embedded systems have web servers in them often, many of many do like your printer is an embedded system, but you can connect to it through your local network and open up a web browser page and configure it. Right. And so, you know, the lines are blurring, your car is unbelievably complex, hundreds of millions of lines of embedded code, talking through various ways to make sure when you put on your touch your brakes that they come on.

Joe Krebs 7:29

Yeah, it's self driving car capabilities?

James Grenning 7:33

Yeah, well, that's scary. I mean, knowing how generally bad software is, excuse me, some of mine as well. Knowing how bad software isn't just me driving the current, the best thing I heard about best reason to trust a computer over a human is that well, humans are even worse than, than computers at driving cars. It's like, no, no, there's probably a pretty good argument. Because humans are can be pretty bad. Yeah. But yeah, so that that time is coming here. It makes me a little bit nervous. My car has a few things, which I do like, but of course, I don't over trust. You know, I'm letting it break for me and slow traffic, but my foot is ready. And paying attention it really completely trust it. But it's done so well. So far. Yeah.

Joe Krebs 8:17

Well, I think it's maybe it's a combination of two things are fully self driving right now. Right. But we are in a situation where cyclists can help you can help protect you more as a driver. So it's not like you're not alone. You have cameras now. And they help you make decisions.

James Grenning 8:31

Yeah, no doubt getting out of my driveway. Now, if, if I go back to you know, I'm in Florida right now, but I often might be in Illinois. My 2004 Honda in Illinois doesn't have any of the modern stuff. So I feel very vulnerable backing out of the garage. Now. My modern cars down here in Florida. I can't make a move without them getting mad at me. It's like, did you know you're about to back into something? You know? Yeah. you have a wife to help with that. But then also the car house?

Joe Krebs 8:59

That's right. Yeah. All the help we can get right. Absolutely. So I used to be a long, long time ago, I programmed in Smalltalk, and there's garbage collection and Smalltalk. So if we're going a little bit to technologies, like what kind of technologies are being used, I would assume Smalltalk is not suitable for that because of garbage collection. Right?

James Grenning 9:22

Well, originally, interestingly enough, Kent Beck and Ward Cunningham were building oscilloscope in Smalltalk in the 90s. Right, and so they actually were working in embedded systems, even though you know, they didn't look like it because they're developing Smalltalk. Still in embedded systems, C is the king of all languages, as it is for developing Linux, and other things to kind of get close to the hardware. C++ is also popular, I'd say that they're similarly popular. Python is making a move. I worked on a IoT radio system a few years ago, I was building a product I put my brother's company. And there was a, I guess they call it an ecosystem, where you have a small Linux box, you know, this, like a super Raspberry Pi, with this radio that makes a mesh network. And then these little radios, which are microcontrollers, and the the language that you program the little Linux box with was Python, and you had a micro Python in the radios. And we chose this vendor just because well, we can build a prototype really quickly, if we don't have to worry about all the multitude of things you have to worry about when you're working in embedded C. There were some new problems, though, because a millisecond isn't very fast. When you're talking about the real world, you know, when you're talking about peripherals and things, and the best we could get from a timing perspective, where we could actually cause something to happen frequently was about a millisecond. That wasn't if I wanted to get away from that we would have had to program in bare C. So we figured out a different way, we actually made up for the limitations of Python, because we needed to look at something at the microsecond level, like 100 microsecond 10th of a millisecond, we had to look at that cadence. And the Python couldn't look at that. But we could read some we could create some hardware, that would extend the signal that we were interested in watching. To a long enough duration that we could see it in Python, which seems kind of crazy. We made up for the lack in software with hardware, usually you're making up for the lack of hardware with software. But you know, we're in the beginning, it's like, okay, what can we do? It's like, oh, we could build a little delay circuit in here and, you know, stretch that signal out. And then we can see it from the Python code. It's like, Great, let's do that. You know, what's all bright breadboard anyway? You know, we didn't, we weren't building millions of these yet.

Joe Krebs 11:49

Curious about is James is like in product development, right? So in embedded software development, there is a there's another product as either let's say a robot, or there's an arm or something that moves. The software control is like, let's say a hardware. And that's like, for me, like just helped me understand like this chicken egg kind of situation. So is the hardware first, is this software first? Or? Or is it a parallel effort? Which I think it sounds like it but how do you develop software for something that might not even exist yet? In terms of hardware? Phases? Medical specifications?

James Grenning 12:25

Yep. Yeah. So there's, there's a few different things you can do. And I've got a couple of resources that might be interesting. One is, I wrote a paper long ago, talking about progress before hardware. So if you knew what you're trying to build, but you didn't know what the hardware looked like, you can build the core of the application out towards the hardware, pushing the interfaces out and out more until you reach this end, where you know, there's a radio there now, and I need the radio, or there's some IO pin signals that we can control. Right, eventually, you push so you could start in the middle and work your way out. Another thing you can do is you can start in the out and work your way in. And I'm sure you can mix these together as well. So in the early extreme programming project, where we didn't know what the hardware was, we started working on the business rules of a police radio system, right from the beginning, based on the requirements documents in the you know, conversations with the customers and what we know the previous system did. So we're able to start in the middle and work our way out. While the hardware engineers had time to figure out what the hardware looked like. This IoT system I worked on more recently, we, and I've got it, I've got a video, which people can watch a conference presentation, which is tracer bullets and something in a Greenfield. In a greenfield project, those are some of the keywords were we recognize that there was a number of risks to the project that we're going to do like, what radio system should we use, okay, that has a performance we need, you know, 10 pressure readings per second with 10 sensors. That's what we needed. So we knew we needed to be able to handle that traffic. And then what was going to happen next, well, that radio would have to talk to an analog to digital converter thing that takes real world signals in an analog and converts them to digital, right, you know, so a pressure sensor reading might come in as a digital number which could be converted through some characterization of the hardware into a psi. Now we got to get that all the way up through layers and layers to a tablet for the technician who's who wants to know what the pressure is. And they can read the reading on their phone or whatever it is. So we looked at their in architecture that might work with that and we identified about five layers of risk. And so what we thought here, our biggest risk is can we find an effective technical solutions. So we built a walking skeleton, which involved? Can I just get messages between these two computers? And 10 radios at 10 readings per second? Will it keep up with that? And I, I got the vendor to write me a script that did that. It's like, oh, great, okay, so I could run it, I could run around with the radios, take them down the block, you know, put one on the other side of the garage door, bring them into a industrial setting and put them on the other sides of machines and things we could experiment to see if they worked. And we found out they did work, they worked fine. It's like, okay, we can build with that. So that was one risk removed. The tracer bullet idea comes from Pragmatic Programmers. So we just shot an idea at that was like, okay, we can do that. Now. What are the some of the other risks? Well, we've worked with this analog to digital converter before, and it has a special way of interacting with it, I wonder if this radio can talk to it? Or do we need to change that hardware too. And so we figured out how to get that radio to talk to the other thing. And then we worked our way up, how do we get to the tablet, through the little Linux box web server there to a tablet, and eliminating risks, and we're able to get a pressure reading from the lowest from an actual sensor to the screen. Right. And so we're able to prove that it's possible to do what we want to do. And a cost effective way with software, we understand each of the pieces throughout the throughout the slice. Right? And that was decide whether or not we're gonna build the product.

Joe Krebs 16:30

Yeah. Is this fascinating? While I was listening to you, it's like, it's like, I think this is just an example of how complex the world is. And what people should be aware of when they're writing a text message to somebody who sits next to somebody else is like, what is happening, you know, text messages in nanoseconds when this is just,

James Grenning 16:48

it's amazing. Any of it works.

Joe Krebs 16:50

Yeah, it's amazing that it works. But it's also interesting to see like, how, what kind of technology is involved involved? You're literally sitting next to each other and just dropping some texts. Right? That's it.

James Grenning 17:00

Yeah. My little example was all before we even connected to a cloud, because the next thing was going to happen, which we hadn't explored yet was, how do we get the data that is needed now to prove to an insurance company that has the right water pressures here for these fire pumps? How do we get that into the report? Right? And that's really what all they want us to report, all this other stuff is a means to an end. Right. So

Joe Krebs 17:23

it's fascinating, right? We, you know, we are potentially while you were talking I was just thinking about where embedded Systems are like it could be I mean, this is just the sky's the limit. Right? And probably is, this is

James Grenning 17:37

where aren't they? They're in your doorbell. They're in your key fob.

Joe Krebs 17:41

Yeah, it's everywhere. It's okay. Let's talk a little bit. Yeah. So complexity, is there the hardware software kind of connect, and how they're being developed? Obviously, there's product development, life cycles, etc. But there's also an it's obviously I want to connect the dots with you here is what makes all that so special about agile development practices. When you are working, let's say in an embedded world, what's what's happening to unit testing? How is testing being done for somebody who is not familiar with us and the complexities of that?

James Grenning 18:12

Okay, great question. So what really was an aha moment for me, in late 1999, when I went to the extreme programming immersion that was being hosted by Bob Martin's company, object mentor, and hit really didn't know that much about XP or test driven it was called test first programming at that time. And it's kind of blown away when Kent Beck started demonstrating test first programming. And he was writing the core code that he needed in a test environment. And the light bulb in my head was, oh, my gosh, for 20 years, I have 20 years of experience at this point in my career. We've been waiting for hardware, we'd write code, without the hardware, and we'd wait till the hardware came. And then we start running our code with the hardware that we have. And the hardware has problems. And the software has problems, of course, because humans wrote it, and nothing works, lots of pressure. And we're under the most pressure to try to get something to work late in the development cycle, where there's so much unknown. And you know, so many problems because we have this code that we couldn't really run and Kent is running his code in a test environment. I thought, I'm trying that next week. I was with a client, and we're working in C++ and embedded radio again. And so we just started the next Monday said, I learned some crazy stuff last week while I wasn't with you, will you guys try it? And at first they were the engineers were afraid because it's like, no, we are processes we do it like this, you know, we write the document and we write that we do a design then we write some code, we have to get all this stuff reviewed. Bla bla bla bla bla, and I said, Well, let me let's go talk to the director, you know, because I was the outside influence here. They hired me to come in I help them with some stuff. It's like you might want to know about this. And he said, that just sounds crazy enough where it might work. So he was an experienced guy. And he said, I will give you guys, I'll do what I can to clear the way in the organization as much as possible for you to try this. And we tried it and it worked. And that was kind of my entree into it in C++. And I got pulled into the C side of it a few years later, when a friend of mine said, we'll come to China and work with me with these European companies in China, and get these people doing TDD and C. And then I did that, and then ended up leading to the book. It's all all an accident. Yeah. I talked to I was asking Ron and I said, you know, we had to go to the embedded systems conference with this Ron Jeffries. I remember him saying, don't, don't the embedded systems, people think they're electrical engineers. They didn't really align themselves with software. It's like, that's kind of right. But so I started going and talking about this stuff at Embedded Systems conferences, and they were pretty much, you know, evil. James Grenning, you can't do that you can't work that way. And, you know, slowly, people started to think maybe it would help. Yeah, I started to see it differently. You know, so

Joe Krebs 21:15

yeah, you have to go back also, it's like, this was a while ago, right. So like, obviously change and this new stuff at that point, like talking about these topics, but also shows the point that you can learn at conferences right? conferences are important to, to attend and to share and connect. And yeah,

James Grenning 21:15

I got to tell you, the sales cycle was really long, we're gonna talk at a conference, and it would be three years later. And then I got a call from somebody, it's like, you know, that stuff you're talking about, you still do that? And it's like, yes.

Joe Krebs 21:44

Come on,

James Grenning 21:45

Come and show us.

Joe Krebs 21:46

Exactly. Come back. He was like, Oh, wow. Like, hardly remember your name. You know,

James Grenning 21:51

One of the guys I saw at the conferences a few times, and you know, it was like one of my, when I went independent from object mentor in 2008. His company invited me to Finland to help them learn, it's like, Okay, I'll do it.

Joe Krebs 22:07

Fantastic. James, you're not only like, although we have been talking about, you know, embedded software development. For a little bit, we touched on the topic. And I, I just hope that listeners are getting a feeling of the complexities of that. It's just like, unbelievable, we could probably go on for a while. But I also want to make sure that listeners know that you're not only known for the work on embedded software, software development, it's the whole focus on on software engineering practices, like in general, test driven development test first design, refactoring, etc. So and you also behind the original planning poker. So that's what I wanted to touch on, too is I gave just so many, I don't know how many people are doing planning poker on a, on a bi weekly basis, or more often, right? So here's the originator. And how did didn't come up with this technique?

James Grenning 23:05

Well, I happen to be in Salt Lake City with a client. And it was post Agile Manifesto, I believe, but we were out there object mentor group, by Martin's company, we were coaching a company and because my career had taken me not just through engineering, but also in the management, I often ended up coaching their managers, and facilitating planning meetings, you know, but I had never really done it before, of course. And so we're in this planning meeting, and there's the engineers trying to come up with their estimates. And I was responsible for them, getting through it and coaching them through the process. And the, I noticed that in the beginning of the hour, the two senior people would talk and they would come up with a number and then they would justify it for an hour with different approaches. And at the end of the hour, nothing had changed. Except we understood it better. And that was really valuable conversations to have, when we're trying to just go through a planning thing and take a stack of cards and estimate them, I realized we're gonna be there for three days. And that's really not what we're trying to do. We're trying to just pick the next two weeks for the work and we can't spend three days planning for that. So I had ever and the rest of the group, the other eight people were just kind of napping. They were not engaged because the two guys were dominating, you know, they were the dominant, dominating few figures. And something we learned at the big company was Teradyne, back in the early 90s was part of TQM, which was brainstorming techniques. And one of the brainstorming techniques was to silently brainstorm, right everybody get their ideas out all at once. So for some reason that day it came to me it's like, let's have everybody grab a note card because as as test as Extreme Programming aficionados, we always had no cards. So I dealt out note cards, everybody just said, listen to the story, write down your number. And then we're gonna all reveal at once. If we agree, we're gonna move on, we know you want to do it one way, you want to do it another way, we don't care, we just want to get an idea. If they differ, then we'll talk about we're making this up at the time, okay, I was making it up to solve a problem, the meeting was going to take too long. And so we got through the thing pretty quickly, then, with probably as good of information as we had before. And then I went and wrote the paper and put it on the object mentor website. The next time we went back to the client, the manager who was totally against agile, said, Come here James, we went off into a room, he goes, I gotta talk to you. Close the door goes, you guys are making all this stuff up. I read your paper. It's like he's mad at me. It's like, well, well, yeah, we're making it up and solving your problem. So it's kind of interesting, but that's how it that's how it started. About a year later, I told people to stop doing it. Because one of my other one of my colleagues grew up at the same company Teradyne, Lowell Lindstrom, he said, You know, there's another technique we use kind of like planning poker, which was affinity grouping. Let's go try that. And so we started doing that in some of our classes to, to get the feel of it, which would be basically stacking, you know, organizing the stories, easy ones on one side, hard ones on the next side, and then spreading them between and putting numbers at the end. And it was super, it was fast, you could do hundreds of stories in an hour. So I would if people want to do estimates, I would steer them that way. And I would also tell them, if it isn't a one or a two, you can't you don't know it well enough to work on it. Okay, don't pick a don't pick a five, don't pick an eight, don't pick a 10. Don't pick a 50. You don't know enough?

Joe Krebs 26:54

Yeah, don't pick an infinity.

James Grenning 26:56

Don't don't take those. If they're the most important things, you got to peel some learning out of them. And appeal, like we did with the water pressure system. We look for little stories that demonstrate that we understood how to build the system. Right, you know, demonstratable progress.

Joe Krebs 27:17

I always tell folks that are doing planning poker, that this is a facilitation technique rather than estimation, right, it's disagreement brings out another conversation. That is facilitates that conversation. So a quick way for facilitating the number at the end site. It's it's not a contract, but..

James Grenning 27:34

the funny the funny thing about that, because that's the most cited benefit to, to planning poker I've heard. And my motivation was to get people to shut up. Because these two guys wouldn't stop talking and get the other people involved. Right. Now, as it turned out, we talked when we needed to, when we agreed, this is one of these techniques to find where you agree, something that would be really important to us in our world today. Right? What do we agree on? Okay, we can make progress on what we agree. And if we don't agree, we can either put it aside for a while. Or we can find out what our differences are, and see if we can get closer or put it aside for a while. Right. And so, you know, it was one of these amazing techniques came from Deming originally, I'm sure and then went to Japan and, you know, got validated there and came back here. Back here. So, right.

Joe Krebs 28:25

Interesting. Yeah. James, this is fascinating to talk about. And obviously, we talked a little bit about the past, we talked a bit, you know, what's what's currently in the near past what's going on? I want to take a little bit of a look into the future with you. Because you have worked on so many cool things, and you were part of so many cool things. That whatever you're working on next, must be a cool thing. And so we chatted a little bit about that you're currently developing some form of or you're utilizing your own training platform. And it sounds super interesting. And I would like listeners to hear about that. And, you know, maybe you can share some thoughts of you know, where you are with this product and where this is going?

James Grenning 29:11

Yeah, okay, thank you. I'll just go back a little bit because I wanted to travel less. And so I started doing remote training about eight years ago. And it turned out that that worked nicely to be able to involve people that were smaller groups and not maybe the early adopters and accompany whenever there was a way to get to them. And it was a disaster. When I started with the people that took it said, Oh great, I learned something would have been better if you're with me. And I started evolving my system to support that remote delivery, and it's evolved quite a bit. Now I'm not a web developer, but through the school of hard knocks. I've developed a system to help me deliver my remote training And you can tell I've been around a while. So I'm, I'm trying to find ways to work less. But I feel like I still have a mission to help people learn this test driven thing, especially the millions of embedded systems engineers, if there are, so I've, I've started to create learning content. And I looked at some of the platforms that were available, I looked high and low. And I spent several months looking for a platform that was going to work for me, which meant, so for instance, one of the platforms teachable is great for somebody that isn't an engineer, I suppose. But it wasn't great for me, because if I had a video, I wanted to post there and also featured on my website, and also use it in my live training, I've got to manage that thing three times. And that's just not sustainable for me. And I know my weaknesses in that would be one of them. It's boring work, and I wouldn't do it. So what I needed is a way to have my course in a repository in a way that I could configure it for, if somebody wants to take it all on their own. And I've got maybe 20 people going through it all on their own right now. There's an early the first people going through it, or if I'm doing a live remote course, people can, I can get more done with the time we have together. And if you're going across a lot of time zones, really four hours is about the most time you can manage a meeting. So there's stuff for people to do before and stuff for people to do after each meeting. That gives them a good experience in learning. So we, they watch some of the lectures on video, but we get together to do exercises, right and give them feedback and answer questions. And so I've been building this platform. And it's I think it's working nicely. I've learned a lot about web development. Luckily, my son is an awesome developer that happens to have web skills could help me with some of it. And so that's my that's my system. I'm hoping to get people to hear about it. Yeah, it's kind of hard to get the word out.

Joe Krebs 32:05

We can help right, it's people can get in touch with you at wingman-sw.com

James Grenning 32:10

That is wingman-sw.com that is right

Joe Krebs 32:17

People can get in touch with you and possibly even sign up for training right there and experiencing it if they're interested. But also to experience the platform is that does that include like, even like, different versions of video sizes of video? Because all of these platforms have probably different kind of requirements, right? In terms of high definition or not?

James Grenning 32:40

Sure. Well, you'll see that I've learned a lot in the process. So I've kind of gone to a shorter style of video, I think I record them in 1080p. But because it's it's served through Vimeo, you get to adjust your site to whatever you need. And I've had a lot of fun with it. I made a green room, I've kind of discovered how I can have fun doing it. And have it hopefully not be too boring for people. There's two example videos on the front page of wingman-sw.com, which I have a little bit of fun with my wife is one of the frames I tried to draw upon. Well, a lot of stuff. So yeah. And try to use visual metaphors for people to help them learn something.

Joe Krebs 33:30

And also like the the training approach, right, especially for, you know, I would assume software engineers, you know, how long can you focus on something probably not eight hours, but if you're learning on your own place, and then you come together for, you know, exercises, what a great model that is. I think that's more engaging.

James Grenning 33:46

Yeah, and the videos are typically no longer than 20 minutes, sometimes a demo will last longer. But I've been trying to cut them down into smaller bite sized pieces as I've been learning, you know, what is effective, and for people to be able to find their way through the second time, because it's kind of hard to find your way through. And it's subtitles because one of my clients said, you know, it's hard to really hear every word you're saying. It's like, okay, so it's like, how can I do subtitles? It turns out, there's an integration with Vimeo, you can get subtitles added with no problem. And I could actually probably convert it to another language without huge expense. So it's been an interesting learning curve. But then the other thing is that integrates with an exercise environment. So people can actually do programming in my environment where they don't have to go through the hoops of setting up environments and things for all they can just go do the exercise and learn the thing that I'm trying to help them learn at the same time to experience it, right. You can't learn without experiencing. And so I wanted to make that easy. So I've got this cyber Dojo based delivery system, which you know, so I'm managing several servers now, which of course is way outside my area of expertise. But as an engineer, I have fun doing those things. So...

Joe Krebs 35:09

sounds like it sounds like you're really, you know, surrounding yourself with very interesting projects and products you're developing. James, I want to thank you for spending some time with me. But the listeners out there so that they get an impression of who you are how they can get in touch with you that they see embedded software development that could be done in an agile way. You have written books, and you know, every time they are holding up their cards for planning poker, teams, James Grenning, right? And and they do that a lot. And most importantly, they can get in touch with you for your training software is there a name? you want to share is this the name for your framework for your tool?

James Grenning 35:52

Oh, I don't really have a name for this would be the wingman software, why I call it my training center. Okay. I also use another system called gather town, if it's live training, which is I don't know if you've seen that or not. But if you do any training, or if any of your listeners do training, gather town is pretty awesome for getting collaboration to happen. Zoom, you've got breakout rooms, but somebody has to manage that in agather town. You've got a little icon to just walk into the room that you're supposed to be in. And it's kind of it kind of turns into a virtual world. It's really very impressive. It changed my life. I get there several things that have changed my delivery mechanisms over the years. That's another one of them. But I appreciate you having me on and letting me start about the stuff I'm doing. It's always kind of fun.

Joe Krebs 36:41

Advice for the experts. Thank you so much, James, and I'll put all the links up on the Show page so that people can get in touch with you. Thank you and, you know, enjoy the rest of the day.

James Grenning 36:53

Okay, you too.

Joe Krebs 36:54

Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.