Jon Kern

Speaker: Miljan Bajic  00:28

How did Peter Coad impact your career and how did you meet Peter originally?

Speaker: Jon Kern  00:37

I believe it probably started through me looking for some object oriented information and books. I remember reading a few different authors but Peter Coad, initially was coauthoring with Ed Jordan or object oriented analysis, then object oriented design. I think that might have been the first introduction to Peter and then I believe, I met him in some conference, I want to say maybe in New York in 92, or something like that and then I discovered the UML modeling tool, just the baby version of what became the greater software, control center but it was expensive. I was at that time, working in a Defense Department contractor and I was in the aerospace group, there was a Software Group but I was kind of leading the charge with object oriented and C++ and things like that, whereas the core team was FORTRAN or C, things like that. I found this tool that they were advertising that kept models and code in sync, up until that time, I was doing PowerPoint modeling and sequence diagrams and excel and things like that. It was good for design and doing it and then pretty soon you just throw it away, and you’re left with your code. 

So that really intrigued me, but it was like, I want to say $1,200 and so I asked, could I please get it in like three installments of my wife doesn’t get, because I wasn’t getting my company to pay for it, I was paying for it. Then I had a little personal exchange with him at that point and so that kind of sparked a relationship and it really grew from there through the through the mid-90s. I remember helping them voluntarily being like a groupie, helping them essentially getting things ready to release to be put on a (inaudible 3:31) like a CD and so interesting lessons learned about what it takes to publish something, and having to have things ready way ahead of time and then once they’re ready, they can’t be changed, because they already were put into the document, things like that. I can change the configuration and we can we can support that, oh, no, you can’t. What do you mean I can’t? Look, no, let me explain. We’ve already cut the, oh, I get it, because I have to put it on a CD. So that was back in the day when the publishing was a lot more rigid. So then I started working with the team pretty closely, kind of behind the scenes and voluntarily. So that’s how it started. That’s how I met him.

Speaker: Miljan Bajic  04:25

What was he like, in what ways I know you, at least couple of times that I’ve heard you, you mentioned how he drilled the importance of frequent delivery and in what ways similar to that, did he influence your thinking and kind of the way that you think about software development? 

Speaker: Jon Kern  04:50

Yeah, I think, he was an electrical engineer. I’m an aerospace engineer. We both refer very visual, visually oriented, modelling and systems and a holistic approach. So I think a lot resonated there. And he kind of, I would say, was my object oriented mentor, and then certainly the Feature Driven Development, you’re kind of going along that vein, I think the first couple things, that 95 I also formed my own company, so I was like sub-contracting to Peter, so I was still involved, at that time it was object International. So I was doing stuff with him to do some Java courses, do some oh-oh courses and provide consulting. So I would kind of do that as part of my own company, do consulting with Peter Coad and clients and things like that. And then it just sort of, there was an opportunity with the European organization, to kind of get out from under some other relationships with another organization. So we were able to form a new company called Together Soft, so he had brought my family down to North Carolina and this would have been late mid to late 90 probably summer of 99, or September-ish, yeah late summer of 99. And then he basically like pop the question, alright Jon, we have an opportunity here, quit your company, quit the company that you founded, let’s join and let’s get a few people to start up this new Together Soft. So I kind of went half time with my own company for a few months and then the beginning of 2000, that’s when we kicked off with a handful of the team. So we kind of grew it out of his basement, so to speak and there was a cadre of initial folks and so I was no longer the only outside sales guy slash technical implementer slash product owner, we were able to hire some people. And yes, it was phenomenal. It was like 10 years shoved into three.

Speaker: Miljan Bajic  07:42

That’s awesome. Just a couple of things that just made me think about, just like going to conferences, one of the things that I’ve missed over the last year, year and a half is those relationships, like you said, you met Peter probably for the first you communicated, but you met him for the first time and I can just reflect back on how many relationships I’ve developed just through conferences, and he was also the foot for listeners that don’t fully know. He was one of the people that got invited to Snowbird and he said, hey, Jon, you go and you go there, and you’ve talked about something that stood out to me, the way you said somewhere that Martin Fowler was such a good facilitator during the two day, you guys joke around it wasn’t really two days, it was half a day’s and the restless skiing and drinking. But can you maybe talk about maybe start with Martin how he said at one point he asked you guys to write something on index cards or something like that, and then down on the floor, maybe talk about that. I have a couple of questions and couple of people but…

Speaker: Jon Kern  09:00

I found some of my notes. I believe if you Google the Agile uprising, you go to some website, yeah, Ryan so he’s a good friend and a nice interview over beer.

Speaker: Miljan Bajic  09:19

I was actually listening to that and it was like, you guys were sitting at the bar or somewhere because there was some noise in the background.

Speaker: Jon Kern  09:29

Yeah, it was basically his phone sitting on a beer glass. I think that might have been his first not as professional as later internet. But yeah, so there’s some documentation floating around, maybe even on my Flickr account, I don’t know but every call, kind of the beginning before we got to some of the, like the exercise that he referred to. It really was a little bit of a introduce yourself and give a little synopsis of your development techniques and I had created a lightweight process before it was called Agile, almost out of self-defense and but published it in of all places like Lotus Notes book. I kind of had blended mostly from my DoD experience, a little bit of that plus FTD plus XP kind of blended a little, so each of us describe kind of what we approached software development. So that’s where I learned, for the first time things like DSDM, never talked about, never heard of it, never heard of Scrum. XP, of course, was very popular. So there’s a big XP contingent there. So everybody kind of explained a little bit about how they worked and what their processes were. The beauty is there’s not a lot of really solid memories. 

Yeah. Makes it better. It does. It’s kind of a blessing. But I do remember the exercise that you’re talking about was, I think Martin was getting at putting some concepts that were important to us. Today, you might do a sticky notes up on a board but in this case, it was just some index cards. And we were trying to combat, the heavyweight processes that dominated the industry, and the rational marketing machine that dominated, none of our little methods had any kind of market share and so we were trying to get at a little bit of what elements might be in common, almost like if you get a bunch of model object modelers together, you’re probably going to get some kind of build some sort of distraction so I think something along those lines. I know for sure, I put a word honesty on a card and I use that in the sense of, especially with DOD project management, Gantt charts, all kinds of things, that were an illusion and it’s not that it’s just us, but it’s that you can’t be 90% done with something. The experience of living in that old world and the methods and the processes that we were using really promoted you either done or not, there’s no partial credit. It’s a frequent chance to work in results. That was one of the big points that I remember tossing a card in there.

Speaker: Miljan Bajic  13:32

I’ve just heard and I do want to interview Martin. I spoke with Chat Hendrickson the other day, I was saying, can you please help me get in touch with Kent and Martin because I have some questions for them too because I think some of the things that they also did should be, in my opinion, discussed a little bit further but I know everybody’s busy. I also wanted to ask you about Michael (inaudible 14:02)and what was your recollection as far as his contribution? Does anything stand out? I know, it’s been many years.

Speaker: Jon Kern  14:14

I mean, some folks were more quiet than others. I do remember, pretty sure I rode the ski lift with him. I remember we had some nice conversations and then also, I think, we probably got together on the 10th anniversary too if I recall. So I might be muddying some of the recollections but yeah. I was probably pretty sure I was pretty vocal, but maybe not overbearing, but I had a lot of opinions and I had a lot of experience with heavy weight and trying to do the right thing, especially my Defense Department experience, you can imagine, we had contracts, of course, we have to do contracts to get the work but build the rapport, the contracts are the last resort. Things like creating crazy amounts of documentation just because some process said it, that’s waste of money. A lot of these things are near and dear and important to me from the kind of work I was doing and trying to do it in a more agile, more lightweight manner. And I think Mike was coming from I’m not mistaken, I’d have to look at my notes. I wonder if I wrote anything down if he spoke. I know Kent and the XP group, the scrum group, probably Alistair, Jim and Crystal. Did Mike give an introduction? He might have, I don’t recollect.

Speaker: Miljan Bajic  16:11

Is it true somebody said, it was him that recommended, how did you guys come up with Agile? Was he the one that recommended or show the book, maybe do you have any recollection of how you guys decided on agile? 

Speaker: Jon Kern  16:29

I have potentially made up stories in my head. I don’t know, I think it’s mystery. At the time I was working with some chaos theory, enhanced fighter, maneuverability, fighter agility so I was doing research in that area and I used to admire the barn swallows at my house, and you could see how they could dynamically change their plan forms , put their wings or sweep them back and sweep their tail back and go really fast so either the word was mentioned, and I said, oh, yeah, because I’ve been working on that.

Speaker: Miljan Bajic  17:15

Well, you’ve been thinking about that…

Speaker: Jon Kern  17:17

Yeah and then fighter planes were more agile than bombers. I mentioned something, I don’t actually know. All I can say is, it either resonated because I was doing work in that area or maybe I tossed out as a synony. Because the thing that I remember is Alistair didn’t want to be known as a lightweight anything, like, yeah, guys, uh, being called a lightweight, that’s not good. Even though the conference was lightweight, methodologists, that’s a bad word. Humorously I think that’s what kind of kicked off, yeah, we got to call it something else. And certainly the idea is, to allow teams to be much more reactive and dynamic and be able to move in and not be stuck in a giant, slow waterfall heavyweight process. So as we discussed the benefits of the kinds of lightweight methodologies we were practicing, agility certainly was a good, really good word.

Speaker: Miljan Bajic  18:37

Why did you guys decide like an over, I don’t know who I was talking to, or her speaking, maybe Jim Benson, were  saying over, it’s almost like fundamentally flawed, because it picks one over the other versus it’s a balance between these, it’s not one. When I teach in classes, and I tried to make that point that it’s not one versus and even though you guys pointed down at the bottom did you consider anything or was just immediately this over that?

Speaker: Jon Kern  19:12

I don’t recall why or how that came about but I would surmise it was because we had a lot of pretty wide range of experience in the room. I’ve been doing a lot of consulting with different companies. I’d like to say it expressed the breadth of our experience and the humility with which we acknowledge there’s no one size fits all, every context is not the same and you need to use your brain. We think we got to the basic gist for I would say immutable traits of teams and doing software delivery. So, I think the gist is right, the matter of degree is left up to the reader. I think it’s a powerful level of ambiguity so that people have to stop and think, you can’t just blindly follow. You can do Scrum and name only, but you can’t follow the Agile Manifesto and name only. And you have to swing the pendulum for each of those sort of elements. Each of those dimensions to suit your needs.

Speaker: Miljan Bajic  20:51

Yeah, I think especially, maybe Alastair was talking about individual’s interactions over processing tools, it’s like people don’t even read after that almost. That’s such attention grabber that’s resonates with everybody. Even if you just left it at that, I think that’s how powerful that first value is.

Speaker: Jon Kern  21:14

Yeah, it’s super powerful. Absolutely. I like to say, I’m a big process not and I’ve built and sold tools, I love tools but none of those have the impact that, you know I’ve said for decades, you put a bunch of really good people in a room, they’ll create a process. They’ll even create tools if necessary. You don’t need agile, you don’t need Scrum, you don’t need lean. They’ll reinvent something that works. That’s the power of people, if you have the right people, the right culture, and the ability to explore and learn, you’ll get good results.

Speaker: Miljan Bajic  21:58

Well, that’s the thing and as you were saying, you got to use your brain and some of the things that you guys stood for, and what the Agile Manifesto is, is like, use your brains and you joke around, or maybe you don’t joke around, you talk about robbing IBM, and what it was, like, today. I mean, it’s a good and a bad thing but if you look at safe, if you look at Scrum,  if XP had the market and maybe if XP had Ken Schwaber, XP would have been… But the good thing is that, specifically I think Ken like I don’t think agile or what we know as today agile or scrum would be without Ken and some of the ideas that he had, how popular scrum has become, and how popular safe for that reason too. But we all know you can’t really follow I call these recipes and I think I call it in every single interview that I do but it’s almost same things that you guys were fighting 20 years ago, and we need somebody to come up to say like, hey, none of these frameworks. You got to contextualize you got to get people to start thinking because that’s almost like the Agile Manifesto 2.0 or something just like, get away from framework start thinking.

Speaker: Jon Kern  23:31

Yeah, yeah. Add a fifth bullet, use your brain and then, damn it. I mean, you’re absolutely right. It’s safe. God bless its soul, it does remind me of rough in that rock. If I ever had a question about software development back then, I pull up my CD with ROCK and I could find, ah, that’s what that acronym means. It’s the software development requirements specification or some such crap. Here’s the role, here’s the three roles that have to create these deliverables and boom, there’s a recipe. I like to joke that I can close my eyes on a safe diagram, put my finger on it, open my eye and go yeah, I agree with that because I might have landed on some agile principle or some lean principle and I don’t have any issues with any of that. I think in the hands of the right kind of organization, safe can work but in practice, some of my observations and some of my fears from attending some courses is the lure to a command and control enterprise organization who can’t do Agile in the small and thinks that maybe if I apply this larger framework, it’ll go better. The lower from what I can tell is, it’s very prescriptive. So it has really a ton of references, even templates for certain documents, it’s got starting like starter recipes. So it’s extremely enticing in that, oh, if we put this into our organization, now people will know what to do. I didn’t know what to do before. But now this is more prescriptive. So it’s that it fits the mindset and I’m sure Leffingwell would cringe like, it’s not what, it’s like…

Speaker: Miljan Bajic  26:01

I took actually the class with him, I don’t know, six, seven years ago, and I’ve been part of safe implement, Dean knows, right. A lot of it is like people are asking for it and there’s no doubt in my mind that Dean and I think he’s been explicit about it in the sense that, you’ve said it before, a tool with a fool is still, or a fool with a tool is still a fool, right? So it’s the same thing. I’ve been in organizations where they just blindly they bring salting company, you train everybody on safe, you’re there and after six months is slowly starts falling apart, because everybody starts fighting for their own little fiefdom, again, and old habits kick in. But all those patterns, the people don’t fully understand why certain things are safe so they start compromising things, it slowly starts falling apart. So like you said, with more experienced organizations, and people that want to dissect the safe and say, what’s working for us what’s not, what do we need to change, it’s going to work, for people that blindly apply it, it’s not going to work.

Speaker: Jon Kern  27:16

Yeah, and that’s the same thing with Scrum, or anything agile. And that’s what we try to do when working with teams is try to infuse that more of the agile mindset, you need to try to think a little more holistically and understand the nuances, of how these elements and how these different pieces interact, and not lose sight of we’re trying to deliver value, we’re trying to make customers smile. And I like to use the phrase that, Mind the Gap, reduce the gap in time between doing something and getting feedback. That plus the people process and tools, there’s not a lot of complexity to some of these ideas. But the devil is in the details of trying to deliver, trying to simplify things,  trying to build that kind of a culture, and it’s often times lucid.

Speaker: Miljan Bajic  28:16

And I was listening to you, I think your talk in Greece that you’re giving. And just as I was thinking, things to ask you and one of the things that stood out, you were trying to depict the Agile or describe it, I think you were saying, how would you describe it to your mother. And one of the things that stood out, it’s almost like you want to create hypothesis to validate something and then you want to have the shortest feedback loop to validate to see if you’re on the right track or not. A lot of times, that’s really the essence. Doesn’t matter if you’re doing software development. You create something that you want to validate and what’s the quickest way I can find out if that’s true or not if I need to adjust?

Speaker: Jon Kern  29:03

Yeah, that’s exactly right. And I think that requires humility. It’s a bit of  personal developmental journey of your mind to be able to step above your expert self. Because the expert self is often the enemy and it can be, the customer is an expert and thinks they know exactly what kind of thing you need to build. I’ve heard that story before, or the developer, the UX team does this full blown. It comes back to the matter of degrees and it’s a risk mitigation and I think my engineering background with that holistic view, maybe makes it a little easier for me to try to understand that what parts of the system present the most risk and how can I shorten the learning to see if the hypothesis is provable or not? And yeah, it’s that kind of an attitude.

Speaker: Miljan Bajic  30:10

And that’s tough. There’s more and more, but developers don’t have that systemic, big picture view and a lot of times, the developers that have been programming for decade plus, it’s usually indeed, it’s like, leave me alone, right, let me just do my job, let me code. Are you still seeing that? And that’s part of that mindset shift that you’re talking about. Trying to see the big picture understand the big picture?

Speaker: Jon Kern  30:49

Yeah. And sadly, I don’t have any magic, secret weapons or potion. For example, talking with one organization, couple of senior developer and developer. Let’s have some discussions around behavior driven development but instead of you write the code, maybe if you’re lucky you write some unit tests, but you damn well aren’t writing any acceptance test, because that’s quality assurance, I’m just going to write my code and send it to the next step. And then they’re going to figure out what the feature was and then they’re going to write tests. How about we bring that forward in time? How about you worked instead, to write those acceptance test? Oh, but won’t that slow me down? Well, maybe your current self, it’ll slow you down a little bit but overall you’ll deliver value faster, you’ll learn to get a little cocky about my code isn’t working, well check somebody else’s. My codes fully tested and I’m pretty sure and then even the senior developer on this one call that I remember, he goes, well, does the QA person then write those acceptance tests as behavior, cucumber tests? Will they help? But no, anyway, that’s what you’re combating is, I just want to code, it’s hard for me to see the value and maybe the standard.

Speaker: Miljan Bajic  32:34

(inaudible 32:35) like the bigger problem, being understanding, like, what’s the business problem that we’re trying to solve? Understanding the business, and then saying, okay, it’s me just programming is not going to solve the problem, maybe. Understanding the bigger picture, understanding how I can help solve that problem is that kind of thinking that goes behind. I’ve been teaching at the University recently and it’s interesting how kids these days are going like, at least developers are thinking more as I’m a problem solver. I think part of it is like it’s being pushed in schools, too and people are teaching as well, are saying, you have to look at yourself as a problem solver and you have to look at things systematically, rather than through your own point of view, or maybe through your own specialty.

Speaker: Jon Kern  33:34

Yeah. And part of the essence of Agile is doing less. If I’m good at writing, sort of, the acceptance test that lets me know when I’m done so I don’t over build a feature, I don’t go color outside the lines. And I like to use phrases like, yeah, try to think of what the minimum you need, and then maybe do a little less, because you might still not be right, and then go test it. It’s how do you try to instill that ability to calibrate and that comes if you are able to paint the bigger picture and people feel more part of the whole versus I’m stuck in a silo and I’m just doing this job. I just come in, and I code all day and I don’t want to have to think or I’m not allowed to think beyond that.

Speaker: Miljan Bajic  34:36

I recently worked with California DMV a little bit and you said, you’ve worked many years with the Department of Defense. I’m assuming that’s what you’re referring to, as you say DOD. I’ve heard your thoughts on government in general, but I think we’re screwed when it comes to waste of money. I’m sure that you probably know what I’m talking about. And it hasn’t changed much. I’ve also spent a lot of time working in the public sector and it’s kind of sad to see how much money and how much is wasted. But also I tell people, it’s almost like, if you want to go back in time, go work in government and some of these biggest agencies, because they’re still doing things that were done 20 years ago, from contracts to how you still have cobalt, then helpers, actually, you don’t have. People are retiring, and you don’t have enough people to actually maintain these systems.

Speaker: Jon Kern  35:40

Yeah. Right. I used to say, technical debt can get so bad you go bankrupt.

Speaker: Miljan Bajic  35:49

I mean, it’s like any debt. You can, if you acquired too much debt.

Speaker: Jon Kern  35:56

Yeah, and smaller but in certain organizations, there is no feedback, there is no pressure, it gets slower and slower and you can spot it. I remember being at my local library, this is probably 15-20 years ago, the kids were younger, probably a long time ago. And I could tell by them pecking away that the software just sucked, like can you show me that? Sometimes it’s embarrassing to admit you’re in software or my wife would be on the phone with some  pharmacy or insurance or a bank or credit card, or Venmo or something. And then some goofy thing that’s seemingly impossible and I’ll just say, that’s because whoever wrote the software for these people on the phone, didn’t put a solution in there for your problem. And so their hands are tied, they can’t do anything and go blame the software.  As an aerospace engineer coming to the software world, and seeing some really horrendously architected systems, I used to say things like, yeah, most people wouldn’t set foot in a building or drive over a bridge or flying an airplane, if they could see it, it was built like some software, even a lay person would know, oh, boy, that looks like crap. That doesn’t look safe, I’m not going into that software. In our world, we can’t see that, or at least most of us or we choose not to and I think that’s one of our biggest conundrums as an industry is, to me you should rebuild your software every couple of years.

Speaker: Miljan Bajic  38:03

Well, that’s true but in government too, my concern is that I don’t see a site like, in scrum, some of these things legislation, these change laws, I don’t know, if you still working with some of these agencies, but it’s really difficult for me to be positive to assume that they’re going to get out of the mess that they’re in. And it’s just like, oh we get new money next year, and make sure that we spend the money from this year because I left we don’t spend it we’re not going to get it, which is fundamentally flawed, it’s just more waste.

Speaker: Jon Kern  38:44

Yep, that’s correct. That’s why I call it fed Zilla because it just keeps eating more and it gets bigger and bigger and bigger and doesn’t solve any more problems. So I think you’re right.

Speaker: Miljan Bajic  38:57

So maybe to switch it up. That’s kind of sad and just in general, I think it’s sad how much money is wasted from that perspective but tell me about the cow tail squeezer. I heard your stories about it, but how’d you get to work on the cow tail squeezer, how someone gets that project or initiative?

Speaker: Jon Kern  39:23

That’s a good question. How did (inaudible 39:27) find us? My little company? How did that happen? I don’t even remember but as an engineer, you’re often going to manage their space often a lot of competing requirements. And so same thing with the cow tail squeezes the competing requirements are, it’s a really rough environment, because they’re out in the wild, they’re not really out there. You don’t go pet these cattle. They’ll kill you if you walked into the pen or you’re probably just trampling. So it’s really rough environment, and this thing has to last for a certain number of days, it has to have a battery that can last that amount of time as well. And it’s not a clean environment so it’s wet and poopy. And then it needs to have a certain amount of force just to every so often turn on and apply a little squeeze. And that little squeeze, was researched by some PhD, that the joke is from sea slugs to humans, that along the median line along your spine, it’s like, if you couldn’t tell if it left or right, just a little, there’s something annoying me. It increased, well increased libido, it also increased appetite. 

So the idea was to help reduce the use of steroids and to try to do it more natural, and even found, it helped with Parkinson’s, all kinds of funny things but the cow tail squeezer was a good example of finding the sweet spot where I had to research solenoids and power and force the squeezing and plot the variability, the variables, to find something that would meet all of those different requirements. So that’s a good story about, it’s not unlike building software, where sometimes you have to compromise, you don’t necessarily have to build everything that somebody conceives of, sometimes you need to find a balance, and sometimes you need to have competing interest sort of battle it out and strike a point that all right and maybe everybody had to compromise, but we got something out the door. So that’s a lesson for software too. This is another good lesson. 

So there was a trade show they wanted to go to, and they wanted a certain kind of demo software to be able to show stuff. I forget the details. But it was going to be used once throwaway software. We needed it in a couple weeks’ time I forget maybe a month. And so I said to two of the developers that worked for me, Mike and Ed, I said, I don’t care what you’re doing. I don’t care how you do it, you can use Visual Basic for all I care because just get it to work and then it doesn’t have to work again. So doesn’t need to be maintained. Normally kind of building things right is often the fastest way but not always. Sometimes, treat it like a prototype, just get it up and running. I think I said I’ll charge them 10,000, it only took us 5000 and I gave the other 5000 to the guys, here you go. Here’s what’s leftover. Enjoy. That’s a another good example of, keep it simple, right? And context matters. I’m not building something to put the space show up in the sky. This is just a throwaway prototype demo thing for trade show. So you know, dial it down.

Speaker: Miljan Bajic  43:38

Now all the way through 11. 

Speaker: Jon Kern  43:40

So that’s a very, very funny. That’s probably the funniest scenario I’ve ever worked on.

Speaker: Miljan Bajic  43:46

That sounds like a funny thing. When I heard about the cow tail squeezer. I was like, I got ask John how he got that gig.

Speaker: Jon Kern  44:00

And the crazy thing is, there was a dairy cow, it’s called going off feed, and it’s dangerous. When a cow goes off feed, it’s hard to get their gut restarted so they can die. And so there was a dairy cow that was off feed and the farmer said, yeah, sure, I’ll experiment with it. So they put the thing on the dairy and they’re much nicer, you can go up to him and pet him and put the thing up. And then the guy Bill, hit the button, turned it on for a little while and there’s a little bit of a delayed reaction, I forget 15-20 minutes, something like that. And the cow suddenly kind of like it would be, even though he had beautiful hay, trying to feed it. And then it got up, went over and ate and then he turned it off and then it sat back down, laid back down and repeated that two or three times. There’s literally like a switch that for unknown reasons that cause hunger and it got up and ate. It demonstrated that it can also help to save the animals lives without the need for veterinary and (inaudible 45:16)

Speaker: Miljan Bajic  45:14

Chemical, it’s something very natural.

Speaker: Jon Kern  45:18

So it’s very obvious but really strange. Strange.

Speaker: Miljan Bajic  45:23

You guys haven’t tried that with humans yet?

Speaker: Jon Kern  45:26

I think they were trying it for some kind of patient. 

Speaker: Miljan Bajic  45:29

So maybe as a last question here, I also got a kick out of Giovanni and Johan analogy, your Italian and German heritage and background. So maybe from those two perspectives; from Giovanni Italian and Yohan, the German. What kind of message would Giovanni give to the Agile community versus Yohan? I’m assuming this is I don’t know, is this southern Italy where people are at least, I have some friends from southern Italy where they’re this is how it is and if they didn’t say how it is, it’d be disrespectful.

Speaker: Jon Kern  46:25

Well, it’s because I’ve been working for the past few years with John Turley at adaptiveness, he’s helped me learn more about, vertical development of your human (inaudible 46:41)

Speaker: Miljan Bajic  46:42

I know, I’m very familiar with that.

Speaker: Jon Kern  46:46

matter of fact, I’ve started a course with Harthill to learn more about this kind of development, because it’s fascinating, it’s kind of a missing piece. So it’s taken me a while to listen to the fact that there are sometimes different people on my shoulder and it’s like a muscle that’s, you have to learn to exercise and let it go most time, we will often tamp down that kind of…

Speaker: Miljan Bajic  47:17

The way that I describe cognitive, what you’re referring to is cognitive development, human or adult cognitive development. It’s like operating systems. So if you have Windows ME running, it’s different than whatever the latest version is and some of those at certain times have advantages. But a lot of times, we don’t even know what operating systems we’re currently running and how we degrade. I’m writing a book actually, on that whole cognitive development and I agree that’s the missing piece in agile and psychology in general, we don’t understand the people.  It’s like almost one size fits all and that’s what we are, we’re a lot more dynamic.

Speaker: Jon Kern  48:03

I’ve learned to typically, not always, sometimes Giovanni blurts out, and that, my heart rate goes up, and my head wants to explode. And one of the folks I’m working with three other coaches that were working on a project right now with the company. And he was describing kind of a, I guess, a sprint review, where we’re looking over the software that was built, I forget if the sprint was like, a month long or something like that, but the gist of his report this morning was yeah, I just got out of that, watched it. And, yeah, well, the PO wasn’t happy and blah, blah, blah, blah, like it got a bad review, had all kinds of comments about it and stuff like that. And yet the heavyweight process has a lot of work upfront. UX, and this and that and that’s what we’re trying to help them with, you think you’re taking it to the nth degree so maybe if we tell them everything they need to do, it’ll be right maybe, but apparently not, but they just did a month and then you’re not happy with it. Let’s have some conversations around, number one, that’s kind of demoralize it, number two, can we shorten that? 

So I joked with my colleagues, I said, yeah, I’m trying to not let Giovanni come out and have my head explode about how this happened, like, I just don’t want to shake their neck. I don’t want to say it’s not that hard, because apparently it is hard but the secret to my success is typically simplifying things, get stuff at smaller, paint just enough picture, do a small amount of work, get some feedback, and don’t think you know it all, and don’t think that doing more upfront, is going to yield perfection at the end, because you need to have tighter loop cycles. So you need to break that down, you need to put smaller things in the pipeline, show some things and you need to understand elements of risks. Giovanni likes to come out in those situations where, because I think what happens is I empathize the pain, that’s soul crushing to development team, we just worked on something that you probably over specified. We’re about to embed with some teams to see some more details but I’m going to guess just judging by the 14 step process, it’s probably over design and you don’t get the right answer. Obviously, no one’s coming to work trying to do the wrong thing. 

Speaker: Miljan Bajic  51:18

The system now or it gets better.

Speaker: Jon Kern  51:22

It’s the system and how can we help break down some of those walls and some of those silos so that we can have better outcomes and deliver more value. And so Giovanni doesn’t have to come out. So the joke is sometimes…

Speaker: Miljan Bajic  51:44

Giovanni takes over, yeah.

Speaker: Jon Kern  51:46

And that’s our code word. If I’m on a call and (inaudible 51:51) says, Giovanni, like, oh, I need to go on mute, I need to go out, bring out the German the more engineer, not the emotional. But that’s kind of the joke behind that is, like, Giovanni can get me in trouble sometimes. Because I’m passionate, I often joke, software would be easy without all the people, but at the same time, it’s very people oriented and it can be a lot of fun, or it can be a lot of misery. And to me, it’s how can we help folks learn how to deliver more value more quickly, make the business happy, make customers happy, and in turn make you happy and it is possible. So I think that’s one of the reasons Giovanni comes out. I feel the suffering.

Speaker: Miljan Bajic  52:54

Well, thank you. I know, we’re almost out of time and thank you for taking the time and I hope you’ve enjoyed the conversation. I really liked and I have tried to pick up some of the stuff that you haven’t thought about, some stuff that I didn’t know. I’m not sure if there was something that I didn’t know what to ask you. Is there anything that you think I should have asked you that I didn’t that I can edit it out?

Speaker: Jon Kern  53:24

No, I don’t. I mean, it’s fun to talk about this stuff. I could talk about it for hours. I really appreciate your time and you ask good questions and it’s fun. Yeah, I enjoyed it a lot.

Speaker: Miljan Bajic  53:40

Thank you. I was talking to my Mike Koon, I was joking around. I was like, Mike, for us younger folks, you guys are getting older and time is quaking and I want to get some of the people that actually paved the way for us. I know Ryan, I know Ryan well. He used to come up here to Portland, Maine too and he was telling me when he was interviewing the Agile Manifesto signers and outers, but it’s like we wouldn’t have jobs probably, if it wasn’t for agile, and the jobs that we currently have, we’ll be doing something else. And I think we’re all thankful for whatever it came out of, I know nobody expected it, but we’re thankful for you guys getting together and creating what you did, because I think many people lives are better.

Speaker: Jon Kern  54:42

And that is touching I mean, being in different conferences around the world over the past 20 years. People genuinely are thankful. I know we hit a special chord and that resonated with so many people and it’s almost like it gave them the freedom like Oh, thank goodness. And so I know it’s meaningful and it’s humbling to have been a part of that even though it was sort of accidental.