Month: January 2022

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.

Heidi Helfand

TRANSCRIPT

Speaker: Miljan Bajic 00:38

So Heidi, how do you define a team? You know, a lot of times people ask question like, what is it team? What is the work group or you know, just everything in between? So how do you define a team?

Speaker: Heidi Helfand 00:49

Yeah, so I define a team as people that come together and they have joint work, like a shared compelling purpose, it could be as little as two people or it could be larger than that. And then there’s also this concentric notion of teams. In English, at least people might call something that might be like a work group where people are working in parallel, really, with different teams, they might call that a team. So it’s a word that’s quite ambiguous, but in general, the smallest unit is two, their thought partners doing work together.

Speaker: Miljan Bajic 01:23

Okay. So I’ve been thinking, you know, you and I, I think you came to the Agile mean, two or three years ago now, that a keynote, and it wasn’t until recently that like, just a light bulb kind of went in my head and I thought of you and I was like, I got to bring Heidi and I want to talk to her. And really, the whole concept of reteaming and the book that you’ve wrote, is just like, it’s almost like now in the future of teams, is seems to go in that direction that you talked about. And I think I was aware of that you know, before you coming too and talking about that, like I was familiar with your work. But maybe let’s explore a little bit the evolution of teams first. How do you see, you know, how have teams evolved and where does maybe talk about what is reteaming and where does that reteaming fit into that evolution of teams?

Speaker: Heidi Helfand 02:27

Sure. Let’s see. Yes, I wrote a book called dynamic reteaming, the second edition was published by O’Reilly in 2020. And yeah, so I have the basic philosophy that teams evolve and change. You know, we have this thing called time that happens and things just change just inherently. If you think about yesterday to today, and all the different things that you did, and all of the different things you were exposed to, what you had thought about, how you felt, it’s a lot of change. Change is just an inherently natural and normal thing. So a team might start and begin and they will pass through time, they’ll work on this joint work together and then maybe things will happen, maybe things will happen that are outside the control of the team and then things will change, right? We look at COVID-19, definite impact to our teams, our companies, our lives that many of us weren’t expecting and it really kind of changed maybe how some teams operated. Some teams that were always inside an office suddenly we’re all distributed and working from home. And so we had to adapt to these situations. Team change is just natural. Sometimes teams will grow bigger, team members will be added, sometimes people leave teams. And maybe sometimes this is the choice of the team, the team creates this change and other times like we talked about with COVID or it could be any kind of outside force changes the team composition. So the book is called dynamic reteaming. It talks about five different patterns that exist out in the world for how teams might change.

Speaker: Miljan Bajic 04:22

So maybe let’s, I was actually thinking about you know, a couple of those patterns. So let’s explore some of those patterns. So what is one by one pattern in…?

Speaker: Heidi Helfand 04:33

So one by one pattern is just someone might join your team or someone might leave your team. It’s as simple as that. And we might not even really notice this a lot if it’s very normal in our context. It becomes amplified if your company is going through hyper growth for example, doubling or tripling in size.

Speaker: Miljan Bajic 04:53

And like it seems like also like you know, I’ve been talking to top leaders in the Agile industry and outside. And we’ve been like, so addicted to prescriptive frameworks to prescriptive way of doing things. One of those ways is also like, Hey, this is what your team is, the team should be stable, the team should be this, this team should be that. Again, it’s great but the reality is that it’s a lot more dynamic than that. And I think that’s kind of like, you know, I was thinking and the reality and especially the future now is our world is becoming more and more complex, that we have to use our heads a little bit more, rather than, hey, the scrum says you should have stable teams. Like the environment is a lot more dynamic than just, you know, following things blindly. And is that really the essence and the message that you wanted to send with the book or is there something else to it?

Speaker: Heidi Helfand 06:02

Yeah, I think that the main message I want to send with a book that team change is inevitable, you might as well get good at it and lean into it. The book describes and has stories from companies all over the world and how they grow and change. I’m a practitioner, I’m someone that works inside and helps companies grow bigger. I’ve worked at multiple startups. As the 10th employee of a company, I left that company when there were 650 people, we had a lot of re-teaming, a lot of growing and changing. And it wasn’t just us, the people that I interviewed all over the world shared their stories. So the book really proves the point that team change is real. And it has lots of different examples of it, that fall into the five patterns. I derived the five patterns from all of these different, true real life industry stories. I’m not trying to sell a framework, I’m not trying to sell consulting services to convert a company into some different thing. This is more of an, it’s like an anthropological study. I used a format of grounded theory that I heard about from Rene Brown interview people coded for teams right about, it’s a descriptive book. And then it has tactics for it, hey, if you’re working in one of these companies, and you notice a lot of changes, and you will, you should plan for it and here are some things to do that make it easier. So like chapter 13 of the second edition has a lot of practical activities that agile coaches, engineering managers, team members can do to you know, kind of master change instead of trying to fight it. Let me grab the book, it’s over here. This is what it looks like.

Speaker: Miljan Bajic 07:55

Yeah. By the way, I really like that cover.

Speaker: Heidi Helfand 07:58

Some of the things that I wrote about.

Speaker: Miljan Bajic 08:02

I like the cover, I really. I like the first one but I like this one. I think the second cover I like better.

Speaker: Heidi Helfand 08:09

Yeah, this is a really nice treatment and one of the partners at O’Reilly came up with the cover, and I liked it immediately, they gave me some different options and this one was just really just kind of spoke to me.

Speaker: Miljan Bajic 08:26

Yeah. Awesome. Well, congrats again. And I think it’s great and I tried to bring up the topics from your book in a lot of trainings I do and also teams that are struggling to understand this, you know that hey, especially like you said, if you’re growing or just in general, like, you know, there’s not one size fits all. So maybe coming back to the reteaming topic and like who’s responsible for to understand these patterns and reteaming? Because a lot of times we think it’s the managers. Is it really the managers or is it everyone or from your perspective who’s responsible for reteaming?

Speaker: Heidi Helfand 09:07

Who’s responsible for it, I think really depends on how the companies operate. What I’ve noticed is that typically, people that make decisions about team composition have been managers, directors, VPS CTOs. However, I always encourage team members during retrospectives to reflect on their team compositions, because maybe there’s a change that they feel they would like to try as an experiment to help them become more effective. So I think it’s anyone who makes decisions about team changes. It could be people that bring in people to the company like a hiring manager, very common. You hire five people, let’s say you have 10 teams, where are these 5 people going to go? You usually have an idea before you bring the people in. So we typically have a lot of reteaming that’s driven by new work. And so who creates that new work in the country is part of the conversation.

Speaker: Miljan Bajic 10:03

Okay so maybe to pick another pattern here, the merging pattern. I’m assuming that’s when you’re merging two teams or merging team members. Is that what…?

Speaker: Heidi Helfand 10:18

Yeah. So for sometimes what happens is that in order to get some work goals accomplished, two teams will come together, they will merge together and become one team and maybe they’ll stay like that. There’s a story in the book about a company in New Zealand, engineering manager, William from a company called trade me, how he had two teams that merged together and one of the reasons that they did was that they pair programmed. And they when they paired and switched pairs, they wanted more variety and knowledge amongst this larger group of people. So merging was a tactic for them. You’ll also find merging very common at the company level. Companies acquire other companies. And so there’s a, you know, there’s a lot that happens when companies merge. But this kind of notion of reteaming and I think why it’s so interesting is that it happens at multiple levels and if you’re at a company that’s changing quite dynamically, you might notice that huh, I have a new team member, oh, we acquired a company. Oh, I see, there’s a new team that sprouted up over there to work on a brand new product. You might notice all of these things going on and it can feel different than being in a company where the pace of change or the variety of change is slower. So sometimes it’s faster, sometimes it’s slower. I think it depends on the lifecycle of the company. Is it a startup? Is it a very mature company that’s been around for many, many years, that’s really starting to retire things and maybe even itself? There’s different paces.

Speaker: Miljan Bajic 12:00

Yeah, I mean, but it also seems like it’s something that’s more natural than stable teams in the sense like that, you know, things change all the time in nature. You know, the way that we form teams, the way that we form groups is dynamic, right? So it’s almost like we’ve been conditioned in order to kind of create certainty and to create stability to just think of teams and teaming is, you know, maybe one or two ways, but it is general in nature. And I think, if you think about traditional silos and where you have, that was another way to also constrain people, because you had, like, you know, hey, developers go on this project, analysts go on that project, you’d come back, but it was controlled. And I think what resonated and part of the aha moment is, I think it had to do a little bit with when I spoke with Dave Snowden and he was talking about like scaling and like how the Agile community get the whole scaling idea wrong, that you want to, you know, just create some boundaries, and that let people self-organize or self-direct. And in this instance, like when I’m talking to you and when I was thinking about reteaming, it’s really like, we have to get people that are on the teams decide how they reteam, rather than people that are so disconnected from them to tell them how they need to organize. And that might be challenging. And I don’t know if you see it that way, and maybe this is goes to how maybe organizations need to adapt for reteaming but what are your thoughts on that? Do you see any truth in that or is Miljan just talking nonsense?

Speaker: Heidi Helfand 13:48

I think Miljan, you’re making some really important points and I think it can be a superpower for a company to include people in reteaming decisions. Because the people are closest to the work. It’s like having respect for people is including them in the conversation. It doesn’t mean they always make the decisions about the organizational structure and where it’s going. But to be part of the conversation, I think is really important. And I think companies could be missing out if they don’t include the people in the decisions. And in the book, there’s a story about from Christian Lanois from Spotify, which we also applied at a company that I work at called Procore technologies. And it was a reteaming that was done in an open space with whiteboards. In both stories, really the case was there was a larger kind of team of teams, Spotify, they were calling them tribes, divisions, in this context. And that division, the tribe group kind of big and it was clear that it needed to split and it split into three. And people were included in these plans and the design before it was finalized and identified shortcomings in the plans that the, you know, very caring managers came up with. It’s just kind of like getting diverse opinions about reteaming, I think can help yield solutions maybe that you haven’t thought of. And so it’s kind of like you come up with, you know, you have a challenge and there’s many different ways that you could go about solving the challenge. And so getting the input is important.

Speaker: Miljan Bajic 15:31

It is and like, you know, and then the opposite side of that, or the completely opposite example of the one that you just described as Spotify, is like work with a client where they actually, it was an IT department of about, I don’t know, 400 people, and they divided teams into, you know, Scrum and Kanban teams. And the managers just put people in, they had to, like, you know, HR was involved, but HR didn’t understand a lot of this stuff, where people were just put based on their positions or the job positions, and you will have somebody that was promoted, or has evolved to like a manager or team lead, that hasn’t developed or written a code in 2, 3, 5 years for whatever reasons. And now they were put, like, when they were, you know, restructured, they were put as developers on a team. And that created like, such a toxic environment on the team. And that was just because nobody listened to these people, it was just more like, let’s put, you know, let’s quickly match their roles and so, you know, we also legally so we don’t get in trouble. And reflecting back, that created so much issue for the organization without listening to people and just putting people based on, you know, what they thought, you know, who should go where. It trickled down for a couple of years. And I can only imagine how much that cost the company because later on, people quit, they jumped to another team, you know, they applied, and essentially, that whole thing self-regulated, but it took the company about two years for people to go and get on the teams that they actually want it to be on and felt like they belonged or at least they felt welcomed because it’s one of these instances people don’t feel like they were welcomed. So that’s the side, you know, example, I saw some of the stuff that you’re talking about too. So what are the consequences, maybe anti patterns of reteaming?

Speaker: Heidi Helfand 17:49

Well, before moving on to that, just like that story that you just told right there, like, that would delight their competitors. I mean, imagine having a competitor who reorganize like that without the inclusion of the people, it created this big disruption, it didn’t feel like they were so effective. But then this startup is coming up in their industry next to them. Wow! You could really see how they could be disruptive into this. And that’s, you know, why we need to prepare for reteaming and do it well, because if we don’t, our competitors are going to do it. And nobody can kind of sit tight. You know, not to mention all the human factors that you talked about, too. I mean, these are people’s lives. To be reteamed by abstraction like this. And believe me, I’ve been through it myself in my career, my 20 plus year career in industry, it can be very, very upsetting. And it’s hard to become productive once, it’s like a Jenga that’s knocked over, it takes a while to put the pieces back up. So I think people are doing the best that they can. When companies get really big and you’re managing hundreds of teams, it’s a huge challenge that can’t be underestimated. People are trying to do the right thing. Like the people that were in charge of that reteaming, I’m sure you know, they’re trying to do the best job that they can. This is not easy. Which is another, you know, one of the reasons I wrote the book is just to try to understand the concept myself because I’ve just seen things play out not only with first person experience, but also you know, with colleagues around the world so. So yeah, so anti-patterns are things not to do with reteaming like. There’s a variety of stories in the book. Like you know, one of them like sometimes I hear people try to change the composition of their teams. They have like one team and they view them as superstars, and they want all their teams to be viewed as what they perceive as superstars so they try to break up that team and to spread the high performance. That does not usually work. You kind of ruin the dynamic and it’s not so easy to regain that or to create it in teams of other people. Sometimes, I think there’s something very magical about teams that really gel and have this sense of chemistry that helps them really achieve things and it could be in a very short amount of time. Time is not the factor that creates a high performing team, which is that fallacy of forming, storming, norming, performing. We’re so easy that we could just really try to keep these teams together and then get people to perform however you define that and you need to in your companies, but if it were only that easy, you know, you’re dealing with humans, sometimes they stagnate. Keeping them together for this whole time isn’t necessarily the answer. I do say though, you don’t want to break up a team that is delivering value at an acceptable or maybe awesome cadence to your customers, the customers are delighted with what they build. Team members feel like it’s an enjoyable experience. You want to try to keep those teams together. So I’m not saying bust up all your teams immediately, that’s gonna cause problems for you. This is very nuanced. And this is why we all need to study this topic, in my opinion. So one of them is like the anti-pattern of spreading high performance.

Speaker: Miljan Bajic 21:18

Yeah, I mean, like you mentioned, like, you know, pair programming or mobbing like, you know, that’s, you know, that’s without splitting, how you can help people get exposure. If you have a, you know, high performing team, get some people to, you know, pair program, or, you know, the mobbing and using more programming, to do that to actually learn and develop their skills without breaking up the teams right. So that could be one way, or at least that’s what I’ve seen that, you know, works. Without breaking things apart, how can we get others exposed to what they’re doing?

Speaker: Heidi Helfand 21:51

Yeah. So you know, it’s kind of like we were talking about before; you’re faced with challenges, and there are multiple solutions to consider, the pros and cons of each, right. So maybe doing some mob programming can help share skills, maybe someone can join the team, mob with that team, get a few tips and tricks to bring back to their other teams. There’s research that shows I think I cited in the book actually that if you nomad on a team for a short amount of time, then go back to your team, it’s beneficial for your original team, the one that you were in first. I think it’s also beneficial for the other team because they get to share and talk about, you know, what they’re doing.

Speaker: Miljan Bajic 22:36

Well, that too and like we get so used to seeing things the way that they are right. Like, you know, and just getting exposure to see oh so you guys do this different, I never thought about it. And that’s what I love about like co-training. I have co-trained with a lot of people and I always welcome that idea because you know, even though we might even teach same stuff, the way that somebody else does, it’s like oh I know now, I can take this and that and I can. So it’s always for me interesting learning experience, because I learned and I adopt I change what I do, because you know, I work with somebody else and they may be do it slightly differently.

Speaker: Heidi Helfand 23:14

Yeah, and I think that feeling is key, that feeling of I’m learning. And we learn from other people just as much as we learn from, you know, listening to talks, listening to podcasts, reading books, experimenting on our own, but that feeling, I love to cultivate that inside companies, that feeling of I can learn and grow and reteaming is one way that I can do it. You know, Procore has a nomadding program where people can go to a team for a short period of time and then go back to their host team. They talk to their managers where there’s a whole program around it. And I think it’s a really wonderful idea because it might energize someone. Or what happens also is that someone might learn that, hey, I’d really love to stay on that team that I nomaded with. And it gives people a low risk way to experiment with a new reality for themselves. I mean, who we’re with on a day to day basis in our companies and our teams, I think is very much tied to how we feel and our well being. So we can do a safe, kind of like a safe experiment, what would it be like if I was on this other team? And with a program like nodaming, I think it gives people kind of a safe way to test ideas like that before committing.

Speaker: Miljan Bajic 24:31

Exactly. And I mean, that goes also maybe a couple of topics. I also want to explore the role of HR in this, but also what you just said reminded me about Menlo innovations, I’m sure you’re familiar with and how you know, their hiring process of just, you know, bringing somebody on. So how does, you know what, you know, maybe if you want you can describe what they do there and how is that related to reteaming and teaming and also just making sure that you know, before you really start working with this group of people that you get a chance to understand what is it to work with them?

Speaker: Heidi Helfand 25:08

Yeah, yeah. So there’s a lot of stories from Rich Sheridan in the book. He was one of the people I interviewed in the book, Menlo innovations, love the company…

Speaker: Miljan Bajic 25:17

Joy Daink, right, is there. oh Joy ink.

Speaker: Heidi Helfand 25:21

Yeah, yeah, Joy Ink. And I think he wrote another Joy related book as well about leadership. And one of the things that I really love about Menlo as Rich described to me was that there’s great parity in the interviewing experience with the actual working experience. So they pair program and switch pairs, and sometimes switch out complete pairs to solve problems that they might encounter. And then people beyond just software engineers work in pairs which is a really fascinating to me. But when you’re interviewing, you’re pairing and you’re working with people. And so you really kind of get a taste of what it’s like when you get there. So I think, you know, that’s one thing that we need to do it, at all of our companies, I think is like having an interviewing experience, that really gives people an idea of what it might be like to join. And to be able to talk to the team members before you join is really key, if at all possible. It’s an investment when you bring someone in and it’s an investment for that person to decide to go to that company. So yeah, so we have to be really thoughtful about this and really put those programs under continuous improvement. So retrospectives are a wonderful tool to use for programs like recruiting, onboarding, you know, getting productive in your teams, you know, just using it at the team level is insufficient, we need to have feedback loops for all these different programs that we have at our companies

Speaker: Miljan Bajic 27:00

Well that too and I was recently, I interviewed Joe Justice, and he worked for Tesla. And he was saying to like, you know, the way that he was describing essentially is describing reteaming. And I’m like, oh, here’s another reason I need to reach out. But like, just the way that he’s like, you know, there are certain things that he could talk about, there are certain things that he can’t talk about but some one thing that he was describing, it was absolutely, you know, where it’s continuous reteaming.

Speaker: Heidi Helfand 27:32

Yeah. And you know, reteaming is a thing. You know, it’s one of the other reasons I wrote the book is I was tired of hearing like, or feeling like we’re doing it wrong. You know, in fast growing companies that grow and change double in size, you’re not doing it wrong if your teams change. So some of that outdated literature about teams that insist a stable team together forever is just inappropriate when you’re at a fast growing company, or a fast growing…

Speaker: Miljan Bajic 28:01

And sometimes it’s great, right. I just think being dogmatic and thinking that’s always the right answer. I think that’s what I, at least see as the biggest issue. Like this is, you know, you shouldn’t, you know, change the teams. And people don’t really understand that the core like, what is the benefit, even if you do, and then also like, how do you build trust, right? And how do you help and create an environment for people to build trust? You can’t just say, Hey, guys, go build trust, and, you know, and start getting stuff done. And it’s just that goes back to what I said earlier, there’s so much desire for simple ways of solving problems. And there really isn’t just the simple way, you have to contextualize each context is different. And your approach needs to be adjusted to your context.

Speaker: Heidi Helfand 29:00

Yeah, we’re in these complex systems, right?

Speaker: Miljan Bajic 29:03

And well, but you know, a lot of times people say, yeah, we’re complex and people, you know, talk about that they understand complexity, yet, their mindset and their approaches don’t align with what they’re saying. Because if they truly believe that they were complex in dealing with complex systems, then their actions and what they do would probably be adjusted to that, how you deal with complexities. What about the, I want to bring in HR, there’s lot of talk about agile HR, you know, obviously finance a lot of times organizations are, those two departments, HR and finance are the last ones to see how they can help the organization and adopt. Specifically how does HR help with reteaming or help supporting teams from your perspective and what ways can they help?

Speaker: Heidi Helfand 29:59

Yeah, I think HR, business partners play a really important role in employee engagement and programs to support it. So I’ve seen wonderful HR business partners who will help bring clarity to programs inside a company about changing teams, for example. So it’s, you know, it’s important to always feel like you’re contributing, you’re excited to go to work each day, you’re engaged in your work, you feel supported. And if you feel like you need to change, there needs to be internal programs that you can turn to, to kind of, to get some help. So this nomadic program I spoke of, you know, you can talk to HR about it, or HR business partner who sits, you know, with a technology organization or other organizations, HR is there to support people usually highly involved in engagement as I said. So to help depending on the size of your company and the formality and kind of this is all really context dependent. So how can you support the people who might want to change? How can you also support the people that are entering the company, that are onboarding? HR plays a pivotal role in supporting people that are joining the company, people that are leaving the company, so that one by one pattern, they’re supporting people in teams who join from an acquired company. Two companies merge together, the HR, business partners help with that kind of change, they help with the switching pattern, which we’ve been talking about not named. I really need to get refreshed when I switch to this other team. They’re pivotal in helping with that. Yeah, so you know, the goal isn’t adopt agile in the context that I’m coming from, that the goal is, help the company grow, change, and thrive to meet its business objectives. And so we partner with a variety of people. Recruiters help, our HR business partners help, we can partner with our friends in the sales department to learn of new information that we might choose to use in our teams. There’s a lot of partnerships that are possible.

Speaker: Miljan Bajic 32:15

Yeah. What about middle management? I mean, like, a lot of times people usually, you know, maybe functional managers, you know, in the more traditional companies that have people reporting up to them. When you work and coach those individuals, what are some of the things that you do to help them understand? Because I find them struggling the most.

Speaker: Heidi Helfand 32:39

So you know, a manager’s job is to support the people and to help amplify the information related to teams outside of their teams, right? We sometimes reporting out on information, also supporting the people and their growth. So your managers can, you know, help people come up with development plans, so they can chart their careers, and they could come from a coach approach where they’re really helping develop people. I think managers can play a pivotal role in helping people find the work situation that excites them now. And I think being aware of reteaming and how to support people, and to give people in teams, the ability to reflect on their compositions, is another important role that managers can play. So I think, yeah, I mean, definitely one of the targets for my book, you know, there’s ideas that managers can apply with how to best support the teams. So managers support teams and they support individuals. And so both of those entities change. And then also, let’s say, we have all this reteaming that’s happening due to external forces, maybe we’re in a company that gets acquired by another company and suddenly, it’s almost like, you know, that Jenga, which is that game I was talking about is knocked over. Managers are key people to help us make sense of what’s going on and what’s happening. So they’re our first route of, you know, managers are in this position where they can help us. So when organizations are changing really fast, I always tell people, talk to your manager, accept your manager thinks, your manager is there to support you. And, you know, there’s a lot of great ways that companies provide manager training, you know, talking with HR and learning and development departments, and learning is, you know, having learning programs is super important. So, managers can really be these key connectors to support materials and information for people when things change.

Speaker: Miljan Bajic 34:49

Yeah, and I think it’s getting better but absolutely. And you know, you touched on a couple of things, you know, from you know, coaching to understanding how to help them. I think another thing that when I’m working with managers too, is like, helping them understand, you know, that’s something that’s related to coaching but like how to better understand people and people on the teams. Like how, you know, something that motivates Heidi might be different than what motivates Miljan. So how do I read through that understanding that, you know, not everybody is motivated the same way, not everything is important and just being able through coaching and mentoring to help people understand that way? And this is not what managers were taught to do, you know, in traditional. So this is also new skill for many managers, a new skill or new skills to develop. And that’s at least what I’ve seen as a challenge, if the company is not investing in managers that you know, what I call the backbone of the organization, because they’re influencing, you know, up and influencing down.

Speaker: Heidi Helfand 36:00

Yeah, I think, you know, partnering with learning and development, having programs inside the companies that support manager growth are key. And you don’t have to have a lot of money to do this. I mean, just having book clubs where you get managers together, and talk about what it means to be a manager in our company, and aligning on that and getting buy in for that definition, you can do it with just organizing together as managers. You know, larger companies that maybe have more formal programs, maybe they have philosophies that they promote. Like for example, Gallup has some wonderful tools for manager training, or like Strengths Finder, for example. So with Strengths Finder, people take a short assessment and they get an idea of what their natural talents are based on Gallup research. Managers can use tools like that to help amplify someone’s talent and turn it into a strength. I like a lot of Gallup’s ideas for employee engagement. There’s a wonderful book that they wrote, Clifton, I believe wrote it, called it’s the manager, it came out a year or two ago which has a lot of interesting suggestions for how to manage today. And the other thing I was going to mention is like in, like Strengths Finder for example is a tool for self-awareness. So managers could leverage different tools to help people develop self-awareness so they are able to maybe even articulate if they don’t know, what do I want to be doing. Some people know, but some people don’t. So then you can maybe access different tools to help people develop a certain sense of self-awareness. But there’s, you know, it’s kind of knowing people, caring about them and directing them is important as a manager. So Gallup has a I think they call it a q12 employee engagement questionnaire. Looking at the 12 questions, can be very enlightening as well. Are you familiar with that?

Speaker: Miljan Bajic 38:01

No, I’m not too familiar besides like that I’ve heard and like I may have looked at it. But I don’t think I’ve ever actually either conducted or help somebody else conduct it.

Speaker: Heidi Helfand 38:12

You know, they make the questions public, you know, so like, some of the questions are, and managers can work with people on this, like, I know what is expected of me at work, very important thing. I have the materials and equipment I need to do my work right. At work, I have the opportunity to do what I do best every day. It talks about recognition or praise, it talks about people caring about me as a person. And then it goes on and on. And, you know, I had a colleague that I worked with a couple companies ago, and he went through this list of Q12, you can just google Gallup Q12 to look at the questions and he felt so unsupported in his previous job that just going through the questions himself and felt like he should quit and pursue a different job. [cross-talking 39:03].

Speaker: Miljan Bajic 39:04

It’s crazy, I mean like…yeah and like if you think about it, too, like, you know, you’ve seen the stats, but like, if 70 or so percent of people are disengaged at work, like what is that telling us? Like, you know, it’s insane and like, I could relate to that. I’ve worked both you know, inside the companies, outside as a consultant. And it’s like, you know, you can see that when you talk to people you probably felt it that way too where it’s like, I’m just going like, I’ll rather do something else I’m not even getting paid for but like it fills my cup in a sense of like, intrinsically, rather than you know, when I go to work and I think you know, just a couple of those questions that you brought up are so key just to kind of start that conversation and make sure that you know, there’s a lining and that people are actually you know, engaged and that they have everything.

Speaker: Heidi Helfand 40:06

Yeah, I think, you know, how can we cultivate an environment where people are excited to come to work each day? I’d rather focus there than spreading a particular agile methodology. You have to do a lot of different things. Learning new techniques is also important. But just the heart of our teams are the people, and they’re not excited to work with us, they’re going to be looking to work with someone else.

Speaker: Miljan Bajic 40:35

Exactly. That’s you know, something else you know, I think, you know, what you just said, the heart of what we do is people and we understand the people the least, you know, when it comes to, you know, just how our needs are different. So, it is interesting, I think, you know, talking to some people, like I think that’s, it’s been kind of brewing and it’s been discussed by think the next five years will be really about understanding the people and understanding like how do we actually contextualize and understand, you know, people inside going back to, you know, individuals interactions a little bit more? Maybe, you know, it’s kind of like and we’re closing here, like, what other tips, topics do you have for companies, for managers, for teams on reteaming? What are some of the things that we didn’t discuss that maybe I didn’t know to ask you, but you feel are important to discuss?

Speaker: Heidi Helfand 41:49

Yeah, so we talked about some of the patterns, we talked about the one by one pattern, we talked about the switching pattern, the merging pattern, there’s two other ones. One of them is when teams grow bigger and split. Sometimes our teams grow big, we add people to our teams, and then we feel less effective, meetings take longer, the work becomes unrelated. Typically, when engaging with a team and encouraging them that, hey, they can change their composition to be more effective, most of these teams will choose to split into smaller teams. And so you know, it’s one of the most common reteaming patterns is growing and splitting. Sometimes teams can go back together as well. None of this has to be permanent. And then the other pattern is the isolation pattern. So if you’re working in a company, let’s say you have one product that’s out there in the market, people are buying it, you’re maintaining it, you’re adding to it, but you want to start something completely different. It helps to start a team off to the side. I call it the isolation pattern. Empower that team to work differently so they can move at a different cadence. It’s a different type of work to invent something new than it is to maintain and work on a cycle of an existing product. You need faster feedback loops, so isolating the team and empowering them to have process freedom is really key. So I wanted to say that because there are those five patterns. Also, what I’ve noticed is that companies when they get to a certain size want to do some type of reorg. So there’s some tips in here about planning, executing and reflecting on larger reteamings. And so one of the punchline of all of this to remember is team change is inevitable, you might as well get good at it, and I would add include the people.

Dave West

Chet Hendrickson

Speaker: Miljan Bajic 00:34

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

Speakers: Chet Hendrickson 00:46

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

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

Speaker: Miljan Bajic 02:29

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

Speakers: Chet Hendrickson 02:43

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

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

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

Speaker: Miljan Bajic 05:00

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

Speakers: Chet Hendrickson 05:48

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

Speaker: Miljan Bajic 07:38

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

Speakers: Chet Hendrickson 07:45

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

Speaker: Miljan Bajic 08:01

Yeah. [cross talk 08:02].

Speakers: Chet Hendrickson 08:06

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

Speaker: Miljan Bajic 08:37

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

Speakers: Chet Hendrickson 09:02

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

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

Speaker: Miljan Bajic 11:39

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

Speakers: Chet Hendrickson 11:41

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

Speaker: Miljan Bajic 12:19

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

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

Speakers: Chet Hendrickson 14:04

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

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

Speaker: Miljan Bajic 16:51

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

Speakers: Chet Hendrickson 17:46

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

Speaker: Miljan Bajic 18:31

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

Speakers: Chet Hendrickson 18:41

I can’t go back to 1896.

Speaker: Miljan Bajic 18:46

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

Speakers: Chet Hendrickson 18:55

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

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

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

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

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

Speaker: Miljan Bajic 24:58

Why?

Speakers: Chet Hendrickson 25:02

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

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

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

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

Speaker: Miljan Bajic 29:27

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

Speakers: Chet Hendrickson 29:34

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

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

Speaker: Miljan Bajic 31:43

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

Speakers: Chet Hendrickson 31:59

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

Speaker: Miljan Bajic 32:45

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

Speakers: Chet Hendrickson 32:58

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

Speaker: Miljan Bajic 33:36

I have him on my list.

Speakers: Chet Hendrickson 33:39

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

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

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

Speaker: Miljan Bajic 35:43

True coach, huh?

Speakers: Chet Hendrickson 35:44

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

Speaker: Miljan Bajic 36:02

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

Speakers: Chet Hendrickson 36:17

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

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

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

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

Speaker: Miljan Bajic 41:01

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

Speakers: Chet Hendrickson 41:05

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

Speaker: Miljan Bajic 42:21

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

Speakers: Chet Hendrickson 42:36

Yeah, hate everyone else.

Speaker: Miljan Bajic 42:39

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

Speakers: Chet Hendrickson 42:50

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

Speaker: Miljan Bajic 44:42

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

Speakers: Chet Hendrickson 44:49

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

Speaker: Miljan Bajic 45:00

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

Speakers: Chet Hendrickson 45:08

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

Speaker: Miljan Bajic 45:25

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

Speakers: Chet Hendrickson 45:50

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

Speaker: Miljan Bajic 46:45

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

Speakers: Chet Hendrickson 46:58

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

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

Speaker: Miljan Bajic 49:33

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

Speakers: Chet Hendrickson 50:12

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

Speaker: Miljan Bajic 50:20

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

Speakers: Chet Hendrickson 50:47

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

Speaker: Miljan Bajic 51:56

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

Speakers: Chet Hendrickson 51:58

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

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

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

Scott Ambler

Speaker: Miljan Bajic 00:26

It’s been 20 months since PMI purchase. What is one of the biggest things that you’ve learned since the acquisitions? What something that stands out?

Speaker: Scott Ambler 00:43

Yeah. So I think the probably the biggest thing I’ve learned is just the wealth of material that PMI already had. We’d already been leveraging the idea that a pinball guide and a few of the other standards in discipline agile, because DA is a hybrid. But what was interesting was, I hadn’t gone into any great detail and into some of the actually anti-standards from PMI, like the around governance and portfolio management, good stuff like that. And it’s pretty impressive, every time I initially dug into something, I was always a bit worried of, what’s going to be in this? And they’re all solid. And it was interesting that they’re often misinterpreted. And that, including by me, so my expectations were a bit off. But then I looked at the governance standard for example, and it was solid, really good stuff. I’m not convinced enough people are actually listening to it. But yeah, certainly, it’s really solid and well aligned with the governance message we already had DA. So it’s just really impressive. And just the wealth of the PMI network, the chapters are incredible. As incredible how hard they work, and how they’re all about helping their members to learn and to improve and get better. I’ve interacted with maybe 30 chapters so far since joining PMI, they’ve all been impressive. Just absolutely fantastic organizations. It’s incredible.

Speaker: Miljan Bajic 02:18

Yeah. No, I can relate to that. Because I’ve been part of the PMI community for close to a decade, I have my PMP still. I was actually on the board of directors for PMI chapter here in Portland main, and board of directors. So it gives me a little bit of a different perspective. And I agree there’s a misconception out there, in the sense of what PMI is. And there’s also a misconception, I think about discipline agile that people just and safe too. I mean in a sense, people talk about safety, they talk about these things, but they never actually dug deeper to understand, they never took a course. And it’s just the perception of the high level. What was interesting to me that up to December, end of 2018, in some ways, I don’t know if you did, but others described discipline agile as a framework, and you’ve moved away from calling it a Framework to calling it a toolkit. Could you maybe elaborate on that? What was the decision behind that or reasoning behind that decision?

Speaker: Scott Ambler 03:28

Yeah, so the interesting thing was that we were always being compared to safe and Scrum and less than others. And the comparison was never accurate. Because where the frameworks tend to be prescriptive, they have one way of doing things, and it’s good ways, right? Meaning there’s a lot of good things to be said about safe and less than Scrum and others. But they tend to have one way of doing things and there’s a lot of rhetoric around is the art of the possible and you can tailor it to your own needs, and all that sort of stuff. But then they give you exactly zero advice to do that, right? And they certainly give you no advice to improve away and do better than what they have in those frameworks. And more with that wouldn’t make any sense for them to do that, right? Whereas we were taking a completely different approach. We were not prescribing anything, what we were doing in DA is, we walk you through what you need to think about. And then we give you options, and then we walk you through the tradeoffs of those options. That way, you can make better choices, because you’re a unique person, you’re on a unique team in any organization. So there is no such thing as a best practice, right? So with the frameworks, their pitches, there are here as some best practices for solving a certain problem. And certainly, they’re good practices, but they might not be best for you because you might be in a different situation than what those practices are actually effective for, right?

So our approach is to help you to understand, here’s the situation that we’re in. So instead of saying, here’s the one official best practice to rule more, we instead say well, here’s what you need to consider, here are some practices. So you do the best that you can in a situation that you face. So you need to choose the right approach for you. And then as your situation changes over time, as you learn and get better, then you might make different choices over time and rightfully so. So for example, in Scrum, you manage your work in the form of a product backlog, that’s a great technique. There’s six or seven other different, very viable strategies for doing the same thing. Some of those strategies are generally better than a product backlog. And some of them are generally worse than a product backlog. But the scrum folks only talk about product backlogs. Cause that’s the best practice, right? That’s the one official way of doing things. No, it’s observably not true. And then, the Kanban folks, they’ve got their way of managing work. And then of course, you get all this head butting, my best practice wouldn’t be your best practice. And it’s like grow up, who cares? Choose the right strategy for you. And then and by the way, there’s far more than just those two approaches to, right? So, we don’t go down that road. That’s what the frameworks do. DA is about helping you to improve and become a learning organization.

Speaker: Miljan Bajic 06:17

But that’s a huge shift for PMI, right? PMI is all or used to be by the book, this is the pin book. This is the best way of doing things. So it’s a fundamentally, I mean, PMI has been on this I think transformation journey since probably 2010, 2012, especially, I’m talking about specifically agile, but how is it I mean, I’m interested all for PMI to actually acknowledge that there is no one best framework and that you have to contextualize things. It’s a big, I think, switch, because maybe just to add to that, I think good experience, project managers, and know that you have to contextualize things. But I think the marketing message generally that came out of PMI is, this the best way, this is the pin bock, this is when you take the exam. So what have you seen for the time that you’ve been with PMI? How’s the mindset of people that are leading the PMI? Because it’s a huge switch in my opinion.

Speaker: Scott Ambler 07:24

Yeah. Well, interestingly enough, one of the reasons why PMI purchased DA was because their mindset had shifted, right? They didn’t buy us for the shift. Well, I am awesome, and it’s awesome to work with me. So probably, they bought us just because I’m so cool. But what happened was, the mindset had already shifted within the executive leadership, and it was becoming like, if you just look at the membership of PMI, there’s a phenomenally wide range of stuff going on in the construction industry, obviously, but in the IT industry and software development and then in between, so, variable wide range of projects and non-projects, regulatory and not regulatory and others. So if you look at the 50th anniversary book from PMI, which listed the top 50 projects of all time, just those projects alone, this huge range of stuff going on and rightfully so, right? So one size does not fit all. So I think it’s pretty obvious. Now, having said that, the term best practices is a phenomenal marketing term. It’s what people want to hear, it just told me the best practice, because there are a lot of people that just want to be told what to do. They might not admit it, but I don’t want to be told what to do. But I would really like to hear about the five best practices to do this, right?

Speaker: Miljan Bajic 08:54

It’s easy thing to do, right? Give me the recipe, right?

Speaker: Scott Ambler 08:57

Yeah, give me the one recipe to feed me every meal for life. And say, because you adults tend to have a different meal, you might only have 20 things you know how to cook. But still, you don’t need the one meal. You don’t eat spaghetti every single night of your life, right?

Speaker: Miljan Bajic 09:16

Exactly. Yeah, maybe. So this is a good segue into, I was listening to your podcast with Dave Pryor, who’s colleague of mine, and you describe the grocery shopping analogy and the challenges you’re trying to solve with that. So could you maybe share that analogy? And then I want to build on that analogy a little bit.

Speaker: Scott Ambler 09:41

Yeah, so basically, the analogy is you need to have a meal, right? So say you and I have dinner tonight. So you’ll go to the grocery store and you’ll buy the ingredients for that meal or you’ll go to your pantry and pick them off the shelf if you’ve already gone shopping, but what happened is the meal that I’m going to cook tonight is different than the meal that you’re going to cook. And the meal that I’ll cook tomorrow night will be different than what I cook tonight as well, right? So I need to be able to go to the grocery store, buy the ingredients I need to make the meals for my family, but I also need to have the skills. I need to know, what is mint? What is pasta? I need to use my hands on these ingredients and the skills to cook my own meal, right? So this is where it becomes a bit challenging, because it’s very easy. If I want to feed my family, I can take them to McDonald’s time, right?

And I could do that every night for the rest of their lives. And I suspect that wouldn’t work out so well. But if I want to have a healthy meal and I can even change up restaurants, right? You can’t eat at a restaurant, right? So you’ve got to have the skills to cook your own meal. And that implies you better have also the knowledge to pick the right ingredients in order to make those meals and to experiment sometimes to, right? So it’s a really wonderful metaphor for learning. Because, I do a lot of the cooking in my family and sometimes experiment and sometimes those experiments don’t go so well. But I always learned something. And sometimes the experiments are awesome. But certainly often not. But anyways, but you always learn and I’ve also learned to be a bit humble, and I will reap the joy of cooking every so often and watch cooking shows and stuff like that to actually pick up skills from other people. But yeah, so it’s a fairly decent metaphor. So I think, I look at the frameworks is like the Big Mac deal, or the chicken bucket from Kentucky Fried Chicken or something, right? They’re solving a certain problem, they’ll feed you a hamburger and French fries and a coke for dinner. And that’s the solution sometimes but it’s not always so, whereas we’re teaching you how to cook.

Speaker: Miljan Bajic 12:01

So to build on that teaching to cook, I use the analogy, and I first described like the differences between, cook by the book, somebody that takes a recipe and just doesn’t know much like myself unlike you or somebody else. I don’t know what I’m doing, right? So even when I tried to follow recipe, it usually doesn’t come out that great. Then there are cooks with unique style, right? And I say these are the most dangerous cooks, because they think they’re chefs and they try to do things. They are cooks with innovation, these are people that understand what they don’t know. And they’re inspiring to get better. And you have chefs that create recipes, that understand a chemical level, when you use parsley and another ingredient, how they’re going to interact at chemical level. A good chef knows that, right? So in Agile community, we also have a lot of people, we have customers demanding recipes yet we don’t have all the ingredients. So I joke around, I spent a lot of time here in New England. So I joke around like how New England Clam Chowder has about same amount of ingredients as Scrum. We doing daily stand ups every other day, our Scrum Master is our project manager and product owner, right? So instead of contextualizing things to their environment, we tend to blindly follow these recipes and frameworks. So now the challenge is and I don’t know from PMIs perspective, how do we get the full spectrum from cook by the book to Chef? We need all of them, right? But how do we get to that and to that spectrum?

Speaker: Scott Ambler 13:54

So that’s interesting, because I would argue with DA, we’re solving that problem. Because one thing we’ve done in our certification program for DA is, we’ve introduced cook, initial Cook, follow the recipe, character to Master Chef, we’ll teach you how to cook type of thing. And it takes time and we explicitly insist that you have experience, and if for some of the more senior certs, right? So it’s not just write us a check, and you by yourself assert. One of the great things about PMI is that we’ve always insisted that you earn your cert because it should be respectable and measurable and all those stuff. And actually, the DA or the legacy DA organization, we adopt a lot of ideas from PMI on how to run a cert program, we always insist to the header in your cert and show experience for the higher-level ones. So the DA cert program, basically, we’ve got the discipline, the scrum master which is basically into agile and into Lean. You don’t need any experience for that but very good training. It’s effectively Scrum plus, when it gets down to it. We cover a lot of stuff that they won’t teach you in Scrum, because they want one of the technical practices, they don’t want to give you any sort of skills to go beyond scrum at all, right? Why would it? And discipline agile senior scrum master, basically teaches you how to improve.

Where the scrum master teaches you how to improve at the personal and team level and be involved with team level improvement. The senior scrum master teaches how to lead it within a team and across teams. So it’s really all about how do we help these teams learn and improve and get better. But discipline Agile Coach goes way beyond traditional agile coaching. And it’s all about answering the question, what do you do when you’re coaching a team and then you have to interact with another team, like a disparate team? So you say you’re coaching a software team, but then you need to get funding for the team, right? We have to work with finance for that. And finance has a very different mindset, very different set of priorities, very different way of working, they might not be so agile at the present moment. And frankly, they’re an impediment to you, from your point of view, they’re impediment. From their point of view, they’re making sure you’re going to stick with things, right? And they’re effectively dealing with the children on the agile teams, right? So two different very mindsets there. So how do you get them to work together? And how do you get them improving and to agree on things? Or how do you work with procurement, or all three of those teams at once?

Because you’ve got to go off and buy something, you get funding for it. So anyways, this is what we teach in this financial coach, like, how do we improve across these disparate teams and convince them to experiment with a new way, a collaborative way of working across these teams that is different from all of them? Like the agile will get everything they want, the finance people will get everything they want, but they’ll experiment with potential new way of working, and to prove it out in their situation. And in the discipline [inaudible 17:03] stream consultant is all about, how do we improve across the value stream? How do we improve across the organization and optimize the whole? And that could be a collection of very disparate teams working together to bring products and services out to the customers. And that’s a very complex set of skills. And it’s mostly about Lean and flow as opposed to agile, but at the same time, what potential improvements do you have to say, improve upon what you’re currently doing with less? Or what you’re currently doing with safe? How do you solve some of the common challenges in the safe world? How do you solve some of the common challenges that we see with traditional approaches, right? So the philosophy in DA is you start where you are, so if you’re currently a safe shop or less shop, or scrum shop, great that’s where you’re starting, a traditional shop, great, that’s where you’re starting, and then let’s improve from there, let’s improve in small safe steps and over time and become better.

Speaker: Miljan Bajic 18:10

So almost like Kanban, like evolutionary change type of stuff. Start where you are and work from there.

Speaker: Scott Ambler 18:15

Exactly, yeah. And we also support faster change methods. So I mean, we applied bright line in, so our transformation advice is, it basically boils down to it depends. But that’s the real transformation advice that you need. One size does not fit all. So, some people want to tell you just fall quarter because following and following steps in order. And that’s a good approach in some situations, but that’s not the situation you’re in, this is not going to work.

Speaker: Miljan Bajic 18:48

Or you take a look at in this quarter, there’s ADKAR, there’s McCain, whatever. There’s a lot of frameworks out there and they do have general patterns, right? And I think when I started to dive in more and more into discipline agile, it’s like, the way that I understand discipline agile, it’s collection of patterns and practices. And you’re really just consulting with the client and saying, hey, here are some of the things, some of the options, I’m assuming you’re still getting them to make the decisions. But essentially, the toolkit is really to have some kind of baseline for discussion and saying, rather than here’s, let’s look at the ingredients that you have and let’s cook something that you can, delicious with what you have rather than blindly assuming that you’re going to cook up something that you don’t have ingredients for.

Speaker: Scott Ambler 19:45

That’s exactly it, right? You start where you are and I think that’s a really good analogy. So I live 45 minutes away from the nearest grocery store. So it is a decision for me to go grocery shopping. And so if I go to cook dinner tonight, and I have in my mind that I’m going to cook chicken parmesan. I go to the fridge and there’s no chicken, I got a serious problem, right? So what it really got to do is go to the cupboard, you say what have I got? Oh, it’s spaghetti night. That’s what it has come down to because I’m going shopping. And it is what it is, right? And that’s how you got to look at it. And I think what happens is, many organizations are looking for easy solutions because they want to get better, they want to be more effective, they want to become agile, whatever the story is, and they look for an easy solution. It’s just tell me the recipe, right? And the frameworks will, here’s a great recipe, but you know what? That’s a great recipe, but it solves a problem that this organization doesn’t have.

Speaker: Miljan Bajic 20:50

Exactly, it doesn’t solve any problems. If we look at last 20 years, and you’ve been around longer than that. Where has agile, people confuse popularity with Agile and Scrum in general, the whole movement versus the success rate of solving the problems. And it’s close to zero, and not many people talk about that.

Speaker: Scott Ambler 21:15

Yeah, well, it has had some successes. But I think a couple things have happened, right? So if you step back from that question and instead ask yourself, what organizations are succeeding? Well, I can find organizations that are very agile; Amazon, Google, eBay, and all the ones that are doing very well during COVID right now, right? Because they were able to react and adapt to the environment. So the Agile organizations have become phenomenally clear in the marketplace, if you choose to look at them. So then ask the question, well, how did Amazon get as good as they got? Well, it wasn’t adopting one of the framework, sorry, just wasn’t. Let’s do a reality check on this one, what it was, was their learning organization, they do the things that I was talking about earlier, where they make small changes over time, they run experiments, they figure out what works for them in their situation, they adopt what works, they abandon what doesn’t work. And they improve over time, basic case type of approach. And because they’ve been doing it for so long and consistently doing it, that’s why they’ve gotten as awesome as they are, right?

So there are some organizations and most of the techniques are very agile, very lean, very agile, like if you actually look at where they work, and they’re still doing some traditional stuff. So it’s all hybrid. So this is something that I think is absolutely critical. I think one of the reasons why the Agile community sort of struggled is because of their prejudices. And the purists have really taken the community for a ride. And so if you look at the successful agile enterprises out there, they’re actually hybrid enterprises. Because they adopt strategies that make sense for them in their situation. And sometimes those are reasonably traditional ways of working. So it’s exactly what we’ve been doing for years in DA. And what’s interesting, I remember like a year and a half ago, a lot of the purists, these purists coaches were telling us, we’re advising everybody, you can’t possibly be agile unless you’re collocated, right? If you’re trying to do remote agile, that’s not really agile. When you’re filthy, I wash my hands of you, I’m too good to interact with you because you’re trying to be real and agile, nobody is spinning that ignorant nonsense anymore. Nobody.

Speaker: Miljan Bajic 23:23

Because people don’t fully understand. If you understand the underlying pattern and it’s about communication, collaboration shows, so if you can figure out to better communicate and collaborate, doesn’t matter what, physical is great audit, but it’s not the only way. And I think that’s kind of…

Speaker: Scott Ambler 23:39

That’s it, right? So it gets back to do the best that you can in situations that you face. And you got to be flexible, right? So what was interesting was, when COVID hit, all these organizations had to scramble to go to remote working and put the infrastructure in place sometimes because people didn’t have machines and whatever else, let alone the ability to have a zoom call and all those sorts of things. So it was it and they had to learn, they had to invent techniques, because most of them didn’t even understand that people have been doing this for many years. And that these were solved problems, right? So the discipline agile organizations, probably are still doing remote already, but they just shifted techniques, right?

Because we were already talking [inaudible 24:26] because we were always open to remote work from the very beginning. We are open to large teams, remote work and regulatory environments and addressing architecture and technical practices and governance and many of these concepts which are swear words for some of the purists, right? Or the advice from the purist gets down to well, you’re smart, you can figure it out on your own. Well, okay, yeah, you’re smart and yes, you could figure it on your own. But that’s an incredibly expensive and slow way of doing things. When you’re dealing with problems that have known solutions and often many known solutions. So why don’t leverage learnings of others, right? So have a little bit humility. And so this is what we teach you at DA is to leverage learnings of others. So that way when you go to experiment with a new technique, like a technique that’s new for you, you can make a better choice with what you choose to experiment with, and thereby have a greater chance of success. And so then you end up improving faster and basically you have fewer failures, which means more successes, fewer failures. So you end up improving faster and cheaper. So it’s a very good thing. But it takes just a little bit of learning to pick up on this sort of stuff.

Speaker: Miljan Bajic 25:44

The organization should have the desire to develop cooks and chefs, right? Because we can’t just go and say, hey, give us this recipe so we can all follow, but you won’t use them. If you’ve been, as I said, you’ve seen this probably many, many times, but like you go to the Lloyd, people want to do one of the bigger companies that give you their playbook. They leave you with a big bill and they have. And your people have no clue what to do with the playbooks and things that they left after and I think that’s…

Speaker: Scott Ambler 26:17

And they won’t even read them. It’s a big assumption that people will follow and understand recipe, just like you were saying, right? You’ll read a recipe, and you’ll be going along, and they’ll say, well, Fracassi that this is, what the heck is Fracassi? Or you discover that you need a certain type of pan to really get the heat, right? And you don’t have that pan or anything close to it, right? So suddenly, you’re microwaving things when you really shouldn’t be, but you’re substituting hotdogs and fried chicken, because that’s what you’ve got.

Speaker: Miljan Bajic 26:52

And that’s what happens in organizations. The sad thing is, when I work as a coach with these organizations, sides of these organizations, so many people are hurt, so many people are suffering because of this, right? So it’s like you almost poisoning people in a way. You either intentionally or unintentionally. But there’s a lot of people I mean, over the years you just see the stress that people are going through, people that have been in companies for 20, 30 years feeling like shit, like, I don’t feel like I’m worth anything like, I’m replaceable. They just walked out my peer that’s worked here 20 years ago, they just walked him out to the front door, right? So when you start seeing things like that, you start realizing that this is much bigger. Like what that type of role it has, it plays in people’s personal life. But that’s a separate topic. I want to come back to certifications and maybe give you a little bit of hard time, I have couple of things then. So if we look at, I think Scrum Alliance, what Ken did with the Certified Scrum Master was, just copy PMI certification, if you apply it to Scrum, in my opinion, and that has worked really well. And PMI has been kind of the gold standard when it comes to certifications. Now , the PMI offers five certification. So when I was looking at, there’s still PMI, ACP. And then we have four discipline agile certifications. So I kind of chuckled a little bit when I saw the scrum master, advanced scrum master. And I know sometimes you have to go with the sales and we’ll be looking for and where the demand is, versus the reality. So obviously discipline Agile is much bigger than Scrum. It’s context driven, right? So could you talk about it a little bit? What kind of discussions did you guys have when you talked about coming up with whether those two certifications, Scrum Masters? This is an agile scrum master and advanced Scrum Master?

Speaker: Scott Ambler 29:08

Yeah, so we had a lot of heartburn for that. And so the reasoning was that, the [inaudible 29:15] has something called certified discipline agilest and certified discipline agile practitioner. And now those are relatively what scrum master and senior scrum master are. And what happened though was, if you go to the LinkedIn and indeed and anywhere people are posting jobs, they’re looking for Scrum Masters, they’re looking for senior Scrum Masters, it is what it is, right? It’s just the hardcore reality of the marketplace. And so what we wanted to do was provide people with a career path. So where the ACP was great and still is great. It’s sort of an add on to the PMP, right? So you want to get some knowledge and agile and lean and it’s a great way to do it. Got a really solid basis in it, but it didn’t really take you anywhere. Whereas the discipline agile certs, there’s a career path there, there’s a learning path there. And it’s a multi-year path, right? It’s not just a buy, buy, buy a type of thing, you better earn it. So that’s one of the big benefits for people is that there’s a very clear career path. And it’s all about improving, helping you to learn how to improve, so we help you get better at getting better. And that is at different levels, right? So as you gain more experience, it’s more viable for you to try to improve within your team or across teams or across the organization.

And the certs and level of experience required, knowledge required reflects that sort of learning and improvement path. So I think it’s really coherent and it’s exactly, right? It’s about far more than just Scrum. So it’s a bit unfortunate that we use the term, disciplined agile, scrum master and disciplined agile, senior scrum master for very good marketing purposes. Bu then it unfortunately doesn’t easily describe just the wealth of material that you’ll learn and how we go far beyond Scrum. And it’s interesting, we’ll have people that’ll, the company will have like an existing Certified Scrum Master. And like, I’ve literally taught workshops were at the very beginning of the first day, the guy sitting here like this and you know I’m a Certified Scrum Master. I know everything there is to know about agile, and I said, okay. Yeah, right? And then literally, by the end of the first day, the same person will be coming up to me and say, oh, this is the most awesome course I’ve ever had. You’re talking about issues that we’ve been struggling with for months. And not only do you solve them, you show several ways to solve them. And it’s like, I never heard of any of this in the scrum community. So yeah, of course not because they’re teaching you Scrum. And it’s great, don’t get me wrong, Scrum is great. But it’s very limited. It’s a 13 page. The scrum guide is 13 pages of awesomeness. But it’s only 13 pages. So you’re hanging your hat on a 13-page body of knowledge.

Speaker: Miljan Bajic 32:18

Yeah, there are some, being part of both communities, right? It gives me a little bit of perspective on both ends. And I think there are some people that are private scrum Alliance community that have been advocating for, I don’t know if you remember when Ron Jeffries, and chat and agile Baker started agile Atlas. And there’s still in a way, I think the underlying thing and what I like about discipline agile is, moving away from frameworks, right? Moving away from frameworks, contextualizing things, looking at patterns, practices. And I think, just alone during the interviews that I’ve done over the last month or so, people that I respect in the industry and when I asked them, what’s coming after this whole agile and agile to agility. Everybody’s saying we’re moving towards context driven patterns, practices and contextualizing. And that’s kind of what you’re describing, currently [inaudible 33:34]. Yeah, so…

Speaker: Scott Ambler 33:38

Yeah. So I would argue. My experiences is, the frameworks have a lot of value to add and a good starting points. Right. So when you’re first learning how to cook, yeah, you learn how to follow a couple recipes, right? Why not like? And that’s basic way you get taught how to cook, but then start learning the techniques and start learning, after a while, start learning to experiment. But yeah, you’re actually right, your context counts. And it’s good that the community is figuring that out. I think it’s a moving experience, figures that out, right? And other consultants will say well, it depends, well, yes, it does depends, context counts. But in DA, one of our fundamental principles is context counts. And we start from that very basis, because we chose…so we took a very different approach. So I’ll tell you a history. So in the mid-2000s, I joined IBM and I was there, at IBM Rational, I was the chief methodologist for IT. And I led a group of people who, we were going out to customers and helping to understand agile and lean and applying at scale in a phenomenally wide range of situations. And when I joined IBM, I was very clear, I had absolutely no intention of ever creating another framework or method because I’d done several in the past and all the arrows in my back had exactly zero interest in it based on actual experience. But then after a couple of years, we started noticing things.

And some things we noticed was that everybody was doing Agile differently. Nobody can really tell us what they were doing, right? [inaudible 35:17] scrum shop, which is meaningless, absolutely meaningless, right? Now, you might be doing Scrum, but you’re doing 50 other things and you haven’t pulled them out there, so you don’t really know what you’re doing. And sure enough, you go and you look, and then you go in and yeah, they’re doing little scrum. They’re doing calm on over here and you’re doing that over there, and so on. But they’re only focused on Scrum, because they’ve been overwhelmed with the marketing. So fair enough, right? And everyone’s struggling. That was the other thing too, everybody was struggling figuring out this agile stuff to apply it in their own situation. So it was interesting. So we basically came to the conclusion that there was a need for advice, there was a need for some sort of what we believe to be a framework at the time to tell people how to actually do this agile stuff in the real world, as opposed to what was being preached by the methodologist. But at the same time, everybody’s doing it differently. So those were two phenomenally different observations. And I just want to say…I would like to be able to say that we figured it out really quickly. We thrash for months on this, because it’s like, it’s black and it’s white, right? And I was finally reticent to get into the framework. And rightfully so, right? So then it was this, the light bulb goes on. And we realized we really need a context driven approach. And that’s where dismantle delivery came from, which explained how do you do Agile solution delivery from beginning to end. How to do projects? And really, how do you initiate things?

Where some people still thrash on Sprint Zero, we just said explicitly, first, you got to get going on it, there’s got to be some sort of initiation effort, it’s going to integrate, and everybody’s doing it. So let’s just talk about it coherently and discuss to do it. So we developed that, and then we brought DevOps into play, and then IT and then the rest of the organization. And that’s how the discipline agile toolkit evolved over time. Because we started realizing context counts in every part of the organization, and you need to be able to choose your own way of working in every part of the organization, and there’s opportunity to improve in every part of the organization. And if you don’t improve in every part of the organization, you’ve got a problem, right? So if you view your organization as a complex adaptive system, and effectively as a fleet of ships, right? Every team is a team, you’re a fleet, your organization’s a fleet, then if all these ships are going in different directions, then you’re not really a fleet, right? It’s just a bunch of teams doing their own thing. But if you’re a fleet, you’re basically going in the same direction, it wouldn’t be nice if you could actually work together and do whatever fleets do.

And so you do it effectively and get better at it overtime, right? [inaudible 38:02] I guess. So that’s the idea there. So context definitely, we need to contextualize approach. But here’s the hard lesson for all my colleagues in the Agile community, I invite you to have the humility to recognize that other people have solved problems, similar problems than what you’re currently facing today. So instead of making stuff up, which is a lot of fun, you don’t need to reinvent the wheel on everything, you really don’t. So all this random experimentation, all this rhetoric around failing fast and all that sort of stuff, sure, it’s better to fail fast than fail slowly. But it’s still failure. And yes, you’re learning something from the failures. But you know what? I don’t need to be stupid about these experiments that we’re running. And this is the problem with most coaches, is they’re not being smart about these experiments. You don’t need to experiment with the wrong thing, right? So if you know how to make choice, if you know you’ve got several choices, and you can identify a better choice, then you got a much better chance of succeeding. So just be smart.

Speaker: Miljan Bajic 39:11

Well, it goes back to the analogy of cooks and chefs, right? It’s almost like throwing stuff in and just blindly hoping that something delicious is going to come out like you got to understand what you’re throwing in. And when you’re experimenting, you’re basing it on your knowledge and previous experiences. Can you mix these two things? There are certain things that just don’t mix, right? There were a lot of times if you mix them, you might get poisoned or you might get an upset stomach. And I think probably that’s what you’re saying like, in a sense, there are a lot of things out there that we know that we shouldn’t mix. And there are things that we know that go well together. So just be more cognizant about.

Speaker: Scott Ambler 39:58

Yeah, exactly. And also be aware, I guess the thing, so the Amazons of the world often run into issues that nobody else has actually solved. So then they’re going to be experiment if they’re going to be doing true experimentation. But if your organization is not at the Amazon level, and the vast majority of organizations are not, then it gets back to the humility, just realize other people have figured out a lot of this stuff already. So why don’t you leverage their learnings? Let’s experiment with things that have a shot at working. And, why fail? And you’ll fail every so often, like, you’re still going to make mistakes and you’ll burn the food accidentally but you don’t need to experiment with silly things. And I think is the big challenge that the community faces right now is that first of all, understanding that the frameworks are only a good starting point, that you need to look beyond the framework. So one of things we’ve done in DA is we purposely don’t use Scrum terminology.

So if you remember Scrum, when they first came up with Scrum, they purposely chose silly terminology like spring [inaudible 41:15] and other things. To send a very clear message to everybody that this is different. And that was a great decision. That’s a wonderful marketing decision. It worked out really well for them. So we’re doing the same thing now. So we’re using older more accurate terminology because we want to send a message to the scrum community that there’s a lot more to the world than just Scrum and you need to wake up. So we’ll use the term iteration rather than sprint and we get a lot of Scrum people. Oh, my God, it’s really a sprint. Why would you use that? Why would you use this meetup term? Well, if you think that’s a made-up term, it’s because you don’t have a background. But also, we want you to think outside of the scrum box. Because scrum in many ways, it has done a lot of great things, but it’s really narrowed the conversation. And the people really struggle to realize it. There’s stuff that happens outside of Scrum that is very good.

Speaker: Miljan Bajic 42:12

And I think, you just made me agree, 100%. And you made me think of a couple of things. You made me think of extreme programming, right? And how extreme programming, you can’t do Scrum, or you can’t really deliver without extreme programming practices, it’s very difficult, right? But Scrum is really good at marketing or specifically, Ken really had a vision of understanding. I feel the same way for discipline agile, over the years and I think from the content and like your message and the idea is spot on. But marketing wise, I think, from the graphics, right? And people judge a lot of times oh, safe has this nice, polished thing, less has. And I think people a lot of times, like I said at the beginning, they don’t take a course with Scott or anybody else from the community, they’re just basing it on a rough idea by skipping through a couple of pages and saying like, oh, this is a bunch of BS, right? So yeah, marketing is big part. I think that’s something probably with Kanban, not as much but definitely experience and discipline agile reminds me of that where it’s the message is right but the marketing is not at the par where it needs to be. So I don’t know if you agree with that. And like what…

Speaker: Scott Ambler 43:38

I do, we’re actively working on that very issue. It’s easier said than done. One of the challenges is that DA is, there’s some complexities, it’s a complicated solution because we do complicated things. The fundamental problem in the industry right now is that, VUCA, right? It’s getting more complex, rapidly changing, all this good sort of stuff, all this great uncertainty, and then we look for the absolutely simplistic answers, right? And it’s crazy. And what happens is, and we’ve been [inaudible 44:18] and it’s a Twitter world where everybody wants to read things and 280 bytes and stuff like that, right? They want to read books, they don’t want any video that’s longer than five minutes, it’s pretty, pretty hard to get anybody to watch it these days. So they’re looking for these absolute simplistic answers for their exact problem. It gets back to just give me the recipe or better yet, give me the Big Mac deal. They just want the solution hand to them. And it’s no, you’ve got to unfortunately learn how to cook, so you’re right.

We have struggled with marketing, [inaudible 44:50] organization, we focused on content, we focused on actually dealing with helping organizations to do this and to teach people, we didn’t focus on marketing. So we got totally out of market and you’re absolutely right. I would say the exact same thing the XP guys. They completely got it marketed. It was strange, like in the late 90s I was hanging out with Kent Beck’s and the Ken Swaber’s, the world and all these guys and XP was very popular at the time because it spoke to people. But then they got out of market by Ken, by Scrum. Scrum was dead in the water in the water when the Agile Manifesto was written. And it wasn’t until Ken came along with a really great marketing strategy, the CSM strategy that scrum took off other than that, it was dead in the water, absolutely dead in the water. And XP was the thing, the really agile conferences was the Extreme Programming conference. It wasn’t an agile conference, it wasn’t until the third or fourth year that it became agile.

Speaker: Miljan Bajic 45:48

Yeah. And now you go to conferences, it’s getting a little bit better. But it’s all about, yeah.

Speaker: Scott Ambler 45:54

Well, Brahmins XP is hard, right? You’ve got to be skilled. And you can’t just take a two-day certification course and master it.

Speaker: Miljan Bajic 46:04

So I’m talking to [unsure word 46:05] after this one at 11:30. So it’ll be interesting. I really will say, I really enjoyed this. Maybe to switch topic a little bit. We have about 10 more minutes. So when it comes to the partners programs in training, like to scrum Alliance, we have CSDs and CC’s. I was looking at the traditional registered education provider to PMI that was updated this year to authorize training partner program. I was looking through it and I was wondering, first of all, I was looking at the names, just people that were training and maybe it’s just me but I didn’t recognize a lot of people so that could be a lot of them were PMI already, trainers. Then I looked at the pricing too, it’s a lot more than we maybe I don’t know, depends, like when you look at it specifically from scrum Alliance. But it’s more than what maybe I paid through scrum Alliance. So I was interested and this just goes out to people that might be interested in becoming trainers. And I know scrum alliance is put a lot of effort in setting the bar for the similar program to authorized training partner. So I want to maybe just spend a couple of minutes and talk about from your perspective, what is your vision specifically for the PMI a training program for discipline agile practitioners? And how could somebody that’s interested in becoming a partner training partner? So maybe first, what was the reasoning behind it? What is your goal with that and then how can somebody join that?

Speaker: Scott Ambler 48:04

Yeah, definitely still. So a couple things. So first, keep in mind that the ATP program, the authorized training partner program is about more than just DA, right? So there’s more organizations that trained for PNP and the ACP and different certs. And it’s basically two concepts, your accompany becomes an authorized training partner. And then they can have instructors to teach specific courses. So I could have an instructor that teaches PMP courses for example, I have an instructor that teaches DASM and DASSM for whatever reason. So to become an instructor, you have to work for an ATP or be socialized. So you could be a consultant or you could be contracting through an ATP, for example, but you’ve got to be sponsored by an ATP to become an instructor. The second thing is you’ve got to be qualified to teach the workshop. So if you want it, for example, say you wanted to become a DASSM trainer. You have to have DASSM certification you earned, you got to take the course before you teach it everything. You’ve got to be qualified to be an instructor. So there’s a training program for that. But you’ve got to be certified in what you’re teaching as well. So if you want to teach SSM, you got to be certified in SSM and well actually for anything, DA, the minimum now is you’ve got to at least be an SSM because as a senior scrum master, because that requires several years of experience and to be good instructor, you’ve got to be experienced in what you’re teaching. So that’s absolutely critical. And then becoming [inaudible 49:52] teach the DAC, you got to be a DAC first and so on.

Speaker: Miljan Bajic 49:57

Okay, so yeah, I guess the way that I understand now you clarify for me. So the partner is more like a company that can hire trainers to do that. So it is almost rap. You pay one fee, and you can have two three different trainers that training under that license.

Speaker: Scott Ambler 50:24

Exactly. Yeah. So that’s exactly what it is. So the training partners allowed to offer workshops, basically. And then they have qualified instructors to deliver the workshops. Yeah.

Speaker: Miljan Bajic 50:35

Okay. Yeah, because that’s a little bit different and scrum Alliance has reps that serve the similar role. But that was really helpful to clarify, because the price now makes more sense.

Speaker: Scott Ambler 50:50

Yeah. So what we found is, particularly with DA instructors, we’ve seen either existing ATPs hire instructors, and they’re also doing to PNP and other things. Or we’ve seen groups of instructors basically come together to form a company. Or, well, what they do is they work for an existing company and they all decide to hey, we’re all going to get, this company becomes…

Speaker: Miljan Bajic 51:18

Chip in a little bit. Yeah.

Speaker: Scott Ambler 51:21

Yeah, stuff like that’s going on. What’s also interesting what ATP is, you have to be in business for at least three years, you’ve got to meet certain qualifications. So it’s got to be a real company. So you can’t just start a company tomorrow and [inaudible 51:35]. So yeah, so all the ATPs get any instructors, they have to be qualified because your reputation’s on the line.

Speaker: Miljan Bajic 51:52

Yeah. No, that makes sense. So I was trying to look at how does the discipline agile deal with mindset and culture. And I ran across the discipline agile mindset and the set of principles, promises and guidelines. Could you please maybe just elaborate on that a little bit? Because I thought maybe that was the, from my understanding, the weakest part like was something that maybe DA hasn’t really evolved and developed. Because a lot of times, we talked about the need to understand the psychology and especially at the coach level, understand the culture. And the more I dug into it, the more that I saw, but it wasn’t like right in front of me, so I think it exists. But I don’t understand it. Well, I haven’t seen it. So could you maybe just talk about what is this discipline agile mindset and how does DA with mindset and culture?

Speaker: Scott Ambler 52:52

So yeah, so DA there’s an obvious focus on process, because we fill in the blank, the frameworks don’t want to deal with. So we believe in, you have to have the mindset, you have to know how to be agile, you also have to know how to do Agile, you have to have the skills as well, right? And it’s still like 85% on mindset. But without the skills, the mindset doesn’t really matter. And so, originally, we based the mindset on the Agile Manifesto. And very quickly, though, we realized that there, because our scope was bigger than software development, we realized that there was issues with the Agile Manifesto years before. So if you remember a couple months ago, in one February, the 20th anniversary manifesto, there was a lot of sessions how do we extend, how do we rewrite the manifesto, right? We were there 10 years ago. And so it’s happening because was blatantly obviously need to be done. But the manifesto authors didn’t want to update the manifestos, that’s the problems. So we weren’t constrained by that. So we started working on something called the discipline Agile Manifesto, we started addressing business agility, right? So as the toolkit grew to have greater scope, we also evolved the mindset in parallel, reflect that. And then about a year and a half, two years ago, we started realizing that the format of the manifesto, the values and principles was really clunky. It was great 20 years ago, but it just wasn’t getting the job done. And so we stepped back. And we asked the question, if we were to rewrite the manifesto today, how would we capture it? And it was a lot of effort, actually.

But we came up with now what we call the DA mindset, so it’s based on a collection of principles which we all always had, right? So one of the weird things with the DA manifesto was we had a collection of high-level principles, then the reworked values from the Agile Manifesto and then reworked principles from the Agile Manifesto. So two levels of principle of total mass, so I was one of our motivators to rethink things. But we basically captured in this format of a collection of principles, we believe in these principles that context counts, and we want to optimize flow and we want to be enterprise aware. So beyond the team, fundamental ideas, right? And those just pervade the toolkit. And then because we believe in these principles, we make promises to ourselves and to others that we work with, that we collaborate with. So we believe in psychological safety and we embrace diversity, we believe in making all work and workflow visible and much other stuff. And it’s mostly lean.

That’s it, that’s the one interesting thing about the DA mindset is, it’s mostly lean. [inaudible 55:51]. And then in order to fulfill these promises, we follow guidelines, we take a validated learning approach, we change culture by changing the system, fundamentally. We try to improve, one of the promises is we improve continuously. So this mindset pervades, I would argue, pervades the toolkit. And if you go poking around in the seat, we actually then for the various process blades, like marketing for example, or finance or vendor management, we then extend the mindset with philosophies because the marketing folks have or in a different world have different priorities than the finance folks and the IT folks, right? So there’s different mindset, so we extend the mindset with philosophies that are specific to that process area within your organization, and sometimes there’s some similarities between the philosophies, sometimes not, often not. But it captures the fact that you’re marketing and this is observable, right? This is very observable, the marketing people in your company will have a different mindset than the finance people, right?

Speaker: Miljan Bajic 57:03

So I think that’s the case for everybody. Because to some extent, we’re all been conditioned certain ways, right? So like, through company as well as outside. So I think that’s one of the, going back to the underlying principle, like context matters. And you do have to understand that and meet people where they are, and then all from there, because it’s easy to say, one size fits all.

Speaker: Scott Ambler 57:33

And that’s absolutely true of mindset. So I think that’s an important observation. So where everybody will point it, the Agile Manifesto as that’s the agile mindset, those are great ideas about software development that solve the issues 20 years ago from a bunch of middle-aged white guys in North America.

Speaker: Miljan Bajic 57:57

Couple from Europe, but yeah.

Speaker: Scott Ambler 58:00

Yeah. But I was on a panel with Kent Beck about a month ago. And he asked me, what do you regret about the manifesto? And the very first thing out of his mouth was, he regrets that it was a bunch of middle-aged white guys that wrote it. Fair enough, not exactly the most diverse community [inaudible 58:20] different times. But yeah, so the mindset pervades but I think we have for a long time had a focus on process just because the rest of the community was just so weak on the process after that and so focused and so strong on mindset, that we filled in the blanks in DA that everybody was very weak. And still, I would argue, still as weak on. So I think that’s the difference. But the mindset just pervades the toolkit. And I think we’re a lot more advanced than everybody else in the community, because we explicitly follow our own guidelines content. We believe in context. That means we have to respect the fact that different contexts mean different mindsets for people and that’s okay. There’s some [cross talk 59: 13]

Speaker: Miljan Bajic 59:13

Yeah, I think. Exactly. And I think what one of those things that you probably heard too is like, there are multiple truths, right? And that goes back to the mindset, so maybe as a last thing, what message or invitation do you have for Agile community or anybody for that matter that wants to learn more about display agile maybe either has doubts or doesn’t, what would you like to say as we finish here?

Speaker: Scott Ambler 59:41

Yeah. So I think give us the benefit out, go and check out the site pmi.org/discipline agile, or just Google being disciplined agile. You’ll find it fast enough and just give us a bit of time, right? And I appreciate there’s some density there. And we take on a lot of issues that maybe you don’t appreciate. But if you just step back and ask yourself, ss my organization dealing with these issues? I might not be, but is my organization dealing with these issues? And would it be nice to have some help? Then I think suddenly your mind will open up. And yeah, we use different terminology, but that’s on purpose. Because we do want to send the message out loud and clear that this is different. But you I think if you believe, if you can observe that people are unique and your team is unique, that context counts, then I think DA is something you should look at, particularly if you also have the humility to understand that you really are dealing with issues that other people probably solve. So they solve very similar problems. So I would invite you to learn from other first, right? Like, experiment wisely and it’d be much better for you, it’ll be much better for your organization. And it’s eye opening. I think, like I said earlier, the we run into all these agile experts, and then they first are learning DA and pretty quickly, they realize, wow, I really needed this a long time ago, because you’re solving some really serious problems that we can’t do, that we’re struggling to deal with right now. And that is a phenomenally common experience. But they had to give it a day, a day of learning. Some are few hours of learning sometimes in order to just open up to the idea that other people are dealing with these issues already.

Zuzi Sochova

Speaker: Miljan Bajic 00:28

So Zuzi, how did you get started? How did you get introduced to agile and what was your journey?

Speaker: Zuzi Sochava 00:37

I started this all in five, I was actually working for a medical company in the US in Minneapolis for Medtronic, and they switch to scrum at the time. And that was a really interesting journey because I was a developer at the time, got used to certain way of working, but that scrum was like, okay, Americans something, right? And then when I came back, my manager at the time, he said, now you have to be a scrum master. I was like, I don’t want to be a master. He’s like, yeah, but you have to, you’re the only one who ever seem strong for my company, right? Do something, right? I was like, yeah, but I don’t like Scrum. He was like, yeah, I don’t like it either but you just started. So that’s how I started, right? I got no other choice. I guess.

Speaker: Miljan Bajic 01:32

So you were willing to.

Speaker: Zuzi Sochava 01:34

Yeah. So I started with something which nowadays, I would not really see as a good start, but I guess I was lucky. And eventually, step by step we figured it out. And I also realized, like what should I do differently, right? So my beginnings were like every other I think, people who started without really like caring about it that much. There is this process, follow it.

Speaker: Miljan Bajic 01:58

Yeah, exactly. How did you get into training? So you started with that company, I’m assuming you gain some experience. And how did you dive into training?

Speaker: Zuzi Sochava 02:10

I did training on scrum much later on. So we got some coaches in the US at that time as the team, but I didn’t know I’m going to be Scrum Master. So it was just a team training and then practicing, right? And then when I came back, my company was pretty small so we were not really up to training, you should learn everything yourself. So within a year, I realize the Scrum is really working, which was surprised because I didn’t expect that. So okay, that thing is working. So maybe I should just start reading about it. So I just start reading, going to conferences, meeting with people, eventually, I have this dream, right? That I will help everybody in the Czech Republic, Slovakia, maybe a bit at that time as well. Like understand what Agile is about, know that vert even, like know that is Agile, right? And now I actually recently rephrase it, so my mission now is not let them know that agile exists, but actually let them know what it is. So they really understand. But we started Agile community, have a couple of other guys here in Prague organizing an agile project conference every year.

And actually, I went to a CSM training again, because one of my colleagues at the time he said, like, I don’t have that many people. So don’t you want to come so I give you a discount. So I said, Okay, why not? I can. So I joined a CSPO actually as the first one. And then Danko Kovatch came at Brock and we have a drink. And he was like, don’t you want to go train? It’s like, I don’t know. But we don’t say no to that thing. So I said, Okay, why not? I mean, yes. So we actually did a class together, which was really fun. And those type of things just happened to me. So over all, I ended up being there. And then I was in India at a scrum gathering. And I talked to a couple people, Carol at a time as a managing director, but also Bob Hartman. And they both told me, why don’t you apply for becoming a CST? Is like, I don’t know, I never thought about it. You should do that, both of them. It’s like a chat at the conference is like no prior or anything. It’s like, okay, so I Google it up that night. And it’s like, okay, I’ll apply today. So that’s my starting, right? Usually just not say no to things which were coming to me.

Speaker: Miljan Bajic 04:37

That’s awesome. But those people, I don’t know Dan [inaudible 04:40] that much. But I know Bob, I don’t know him personally. But based on what I know of them is that they’ve done that for others where they encourage others and nudge others. So that’s awesome to hear that. It was a little bit of nudge from others that got you into this space. So you wrote a book on this Scrum Master, then you just released recently another one, what is the agile leader and which I want to come back to but I would love to know, what’s your process for writing? How do you go about? Do you have a specific time of the day or how do you go?

Speaker: Zuzi Sochava 05:22

Well, no, It’s, I guess gone. But what I was doing, I started drawing. So when I was able to draw the pictures, and doing some small blog posts, etc. When I was able to digest that message in a picture, and combine those pictures together into some map, which was discovered all or half of it at least, then I thought I’m ready to write a book. So I actually started writing around the drawings. And I was writing the first book, the Great Scrum Master, I wrote mostly during our diving trips, and the morning and around land river diving, in the afternoon when we were sort of resting. So I was writing a book. And the second one and the translation of it back to Check because I wrote it in English. And then I was translating back the Check. I was actually doing like, we’re sitting at the beach. And that time it was Miami beach with my daughter, and she was enjoying there. And I was drawing those images on the beach and trying to write overnights. So I was always writing when I was traveling. So that’s simple to me and now I’m struggling writing a blog because I’m not traveling anymore. So I don’t have enough time.

Speaker: Miljan Bajic 06:35

Exactly. It is tough to find. But yeah, it’s interesting as I talk to people that have written and I’ve started writing couple years ago, and for me, it’s that routine, whatever time it is, if it’s in the morning or afternoon so, and everybody has, but I don’t think I’ve had anybody describe it as sketching first and then I’ve seen your drawing, which are really good. So I can see how you’re maybe thought process for that is. So maybe to come back to your latest book, The agile leader, what is agile leadership about? How do you describe?

Speaker: Zuzi Sochava 07:21

See it as being an agile leader is like a state of mind, right? It’s up to you to decide, I want to be a leader, I’m ready to take the ownership of things and have that vision and go for it. And of course, you need to hear that feedback from a crowd like other people ready to follow you, is it clear enough for them? Is it motivating enough for them? And things like that. But at the end of the day, it’s a state of mind. So the subtitle of that book is leverage the power of influence. So I don’t see leadership being anyhow connected with any management position. As a manager, you need to be a leader. But you can be a leader or you are a leader, even without being a manager, it’s just your own kind of mind, which is important to focus that way.

Speaker: Miljan Bajic 08:12

So the mind, I guess, I’m assuming you’re alluding to awareness and I think he talked about that in your book. Why is that awareness so important? And could you give us maybe some examples of the mind and may be mindset of, hey if I want to I can step into this leadership role. I talked about, like in sports, a lot of times you might have team captains, but other people step into that leadership role, like, hey I’m going to make this stop, or I’m going to motivate this other team member that might be down. Those are some examples of actually stepping into a leadership role. But how would you describe that awareness, leadership, or just awareness around?

Speaker: Zuzi Sochava 09:03

I think it starts with this dream, you have somewhere deeply inside their passion. And they asked me about [inaudible 09:14] or how I read this book, but it’s also, before those pictures, it starts with a dream, is that strong message, which I believe I have to tell the other people. And I feel like even though they all go to my classes, how many people can I teach in my life, right? Not that many, I can write it into the book, and they can read it, and they don’t even have to meet me. So this type of thing, like this passion, if you have that message or that’s something you’re really passionate about the dream. And when I was still taking care of the developers, I was a director of that engineering group and HR director at some point over time. So I was wondering like, how can get more people growing from bottom up, right? Helping them to take over the ownership and become leaders. I wouldn’t have call it that way at that time. But nowadays, looking backwards, it was exactly what I was doing. I was trying to encourage them to speak, encourage them to take over the ownership and say, hey, I want to do that. So we were as an example of those initiatives, we were trying to figure out, like, how can we help each other to learn? Because we were doing quite weird business which if you go to regular class, people don’t teach you those type of things. So we were thinking, okay, maybe we should learn from each other. So how can we start this? So we actually asked people like, what are you willing to share with others?

What do you think you’re great at? And the other question was quite the opposite. What do you want to learn from and whom would you like to learn from? And we actually came out with this nice ecosystem where people say, no, I don’t think I’m great at that. But then I say, Okay, I’ve got the five or six or 10 people saying that they would like to learn an agile from you. Oh really? I’ll think about it. And they actually, because they got that support and feedback, they start doing it. And then when other start the first one doing it, they start saying, hey, maybe I’m not sure but if somebody is interested, I might offer this. And again, make it happen. So I think sometimes it’s just about having the dream, having enough self-confidence to speak up and say, I’m going to do this, anyone interested? And they’ll say, yes.

Speaker: Miljan Bajic 11:38

Yeah, that takes courage. And you talk about courage as well, why courage so important? It’s one of the strong values to so…

Speaker: Zuzi Sochava 11:45

It’s one of the most important things, because we are always afraid of doing things and why are we here anyway? I like courage. I was never really caring too much about other things. So I always did a lot of what I wanted to, of course, you take a feedback from people, but you have that strong vision somewhere but it was actually shifting. But I was never afraid to speak up at the end those type of occasions, I guess.

Speaker: Miljan Bajic 12:12

Yeah. Nice. So I was looking at it and you’re using, I’m assuming from Bill Joiners, leadership agility, the expert achiever and catalyst. Is that where you were, I haven’t read the book yet. As I said, I just learned, but what are your thoughts on obviously, using those labels that Bill pulled from research that he did, and actually just interviewed Bill recently, what kind of impact did that have on you if that’s the case?

Speaker: Zuzi Sochava 12:57

I’m using it as one, I have this habit of having those books as a tasting my new kind of thing. If you go to that fancy restaurants you get like 12 course Menu, and some of those will speak to you more, and some of those not that much. So I tend to have those various different concepts, and trying to combine them together and show how they relate to what I want to say. So Bill Joiner is one of those. For leadership program, I’m using either Bill Joiners 360 or leadership circle 360. I found that Bill Joiner is, I would say, easier to do for corporate world, when you have like a traditional organization where you have those managers and managers of managers and the traditional structure of hierarchy, it works really well. But if you try to apply it for people without that structure in their lives, working blights like entrepreneurs, they have their own company with very little employees, maybe like contractors, but it’s more like a network than anything, then they sort of feel like it’s too hierarchical, and they don’t fit. So currently, I ended up [inaudible 14:15] when I teach or coach organization, which is more like traditional corporation, I would do Bill Joiners 360 because it’s really valuable and help people to reflect. And I’m most likely to do a leadership circle for all the other agile coaches who are like floating around the world and being everywhere, nowhere and don’t have the fixed structure in their main current position, right?

Speaker: Miljan Bajic 14:44

Yeah. It’s interesting and I’m assuming I think when I was just looking at the questions to ask you and looking at the contents of the book too, you have reinventing organizations, and all of those are based on what’s called Agile development stages, right? That Bill talks about. So how important is it for Scrum masters to leaders to understand psychology and these agile development stages in the way that they lead because essentially you have to switch and change your approach based on the situation and cognitive development of the group or person that you’re working with.

Speaker: Zuzi Sochava 15:30

I have my internal belief that if we have Scrum Masters coming from like this psychological, sociological background, we would actually have great Scrum Masters. The problem is, I tried to actually start the relationship as a faculty here in Prague, but it’s not been really successful, because for some reason, and I checked then later on with one person who actually made that shift, he has this background and he is working as a scrum master now, so we chatted about it, I was asking him why it wasn’t successful. And he said, most of my colleagues from school, they feel actually I betrayed what I was studying. Because I should be here helping people with issues in their minds and sort of healing people, doing some important stuff. And now I’m just doing some business for money.

And so I can’t repeat his own words right. But that was like a stick in my mind was like, oh, maybe this is just not appealing for them. They can get a good job but they don’t care about it because they have a higher purpose, higher mission. So we’re stuck with those technical developers like I was, right? Biggest Scrum masters and relearning everything from scratch. So of course, I don’t know enough about all those things. On the other hand, having a technical background gives you some sort of maybe same language with people, which makes it easier to connect, etc. But otherwise, I think I was always thinking if I should go back to school, and study some sociology or something like this, to understand this more.

Speaker: Miljan Bajic 17:14

Yeah, I dug into him, like I tell people. And I’m still learning, right? A lot about psychology, a lot about just how do you understand people better because Miljan can go in and understand, like how to facilitate this or how to do this or what’s the best technique for that. But if you don’t understand people, you can’t really be good scrum master or effective, you’re not a holistic scrum master. And this goes same for the leaders. And a lot of times people see that as a soft skill. It’s harder to measure, for instance, how do I know how to motivate Zuzi versus somebody else? And you might be motivated differently than somebody else. For you, money might not be an issue, for somebody else they might want more. And how, if you have a group of people or a team that you’re working as a Scrum Master, how do you align their needs? So what are you doing in that situation? How do you based on what you know currently? How do you show up and lead or maybe when you’re mentoring and coaching Scrum Masters, what are some of the things that you do to help them understand the importance of understanding people and culture?

Speaker: Zuzi Sochava 18:32

I actually put most of this, I think the biggest game changer, maybe let me rephrase. Because game changer for me was going to oversee organizational relationships, system coaching. And I was waiting for around, going around it for a long time, actually went to Lisa Atkins, Agile Coaching Institute for all their classes. And when I finished that year by year, eventually I asked Lisa like, Hey, I finished everything you offer. What’s next? Where should I go next? And she looked at me and said, you know, we’re doing ours. And we like it, you might like it as well. I said, okay. Thanks for advice. And I was thinking about it for a year, reading the orc website. And at that time, that website was sort of like not really appealing to me. It was not saying anything about what is inside. I was like, I don’t know, she recommended it, but it’s a lot of money, a lot of time, should I go there? Should I not? And then one day, I just said okay, I go and then you realize there is a discount if you buy all five classes. So I was thinking about it for about an hour and said okay, buying all five and just go for it. And so I went to Toronto for the classes and it was really nice, nice group of people and I enjoy it. I still have friends from that cohort by the way, and it completely changed the way how I look at things and how I do my coaching, how I do my classes approach, a lot of things, right?

Speaker: Miljan Bajic 20:03

What are some of the biggest difference if you reflect back? What is something that you did and now you wouldn’t do that again after that class?

Speaker: Zuzi Sochava 20:10

I think the biggest difficulty was, like I was looking at the organization from bottom up, thinking [inaudible 20:17] teams need something so that you have to understand, it was this overlying mindset, I wouldn’t have call it that way. I was trying to just give advices, talking to executives and give them advice as tried. It’s like useless, right? They no matter anyway. So when I start actually asking him questions and coaching them a little bit more, and be more reflective of the entire system, which is going on there in that organization, I was finally able to work with them. And there was behind me starting this CAL program and Kel to right now, and those other things. So I think I became more patient as well, because of that. And kind of there is this rule, right? System rules saying like that, who knows what is right and what is not? Which I learned in or spread. And so I think that’s the overlying principle, I tried to apply to most of those situation, it just looks like a perspective, there is a 2% of truth on every perspective, that’s cool. What else is here, right? And try to listen to the voice of a system, try to be more curious about those type of things. And having a technical background, originally, when I was starting, I knew in one plus one is always two right? Mathematics. So that’s how I look at life.

And there’s this, there’s this, that’s that, it’s wrong, or it’s right. And I think over the years, I shifted from like, okay, well, it doesn’t have to be either, right or either wrong. It’s actually both at the same time, either way. So how can I help those people to see that, to be aware of that, to accept that? So that’s what actually started at the beginning of the CAL classes, which emerged into the book, but it’s always like, I did a class where I talked to hundreds of people about their topic and try different stories and different things. And once it’s fits, I am ready to start drawing it and write pages of text and trying to describe it and sort of pull it out. But that the picture in my head is sort of coherent. So that was behind it, right? I try to feel like how can I help people to make that shift? And sort of understand that organization is a system, human relationship system and can you be aware of it? Can you stop judging it all the time? Like, this is right, this is wrong, this should be this way or this should be that way. Because who knows?

Speaker: Miljan Bajic 22:56

Exactly. And that’s so hard, right? And goes back to the awareness to. And then what resonated with when you said, like look at it from different perspectives, because there’s truth in all of these perspectives, right? Versus us being just tied to our own perspective. And I can also like, in my CAL classes, I’m also piling stuff down, writing about and getting immediate feedback from people. So I can relate to that. It’s really good to like, hey, I’m thinking about something or how would I explain it, you actually put it into class and…

Speaker: Zuzi Sochava 23:35

And see what happens, right? Exactly. I did a couple of those classes to sort of consolidate it because you have it in your head, but they explain it in one way and the right is the other way. And those things are interesting, right? But I think all over like being able to feel those relationships and focus on the relationships and see the impact of the work was a very important for me.

Speaker: Miljan Bajic 24:03

How much of coaching do you do? What does agile at the executive level look like? Because when I work with executives, it’s a little bit different, right? It’s themes at least that they don’t have time for a lot of the stuff and you have to influence, you talked about influencing, right? Influencing is a huge, huge part. So what are some of the things that you do and maybe talk about in classes when it comes to influencing and agile at the executive level?

Speaker: Zuzi Sochava 24:37

Agility. I did two things. I like to fix this functional teams at any level. So I have some clients that are over at this level, and its agility in a way in a sense, because agile brings transparency, collaboration, team spirit, etc. So I’m using this agile background for fixing those teams to be high performing, or at least performing, right? That’s one part of it. The typical question I got recently in capital classes was, what should I do with my managers? How should I explain them? Well, I don’t think you do explain them. They either feel the need or not. So can you make that need really visible? Can you make it painful? Can you make it emerge from space? So they say like, Okay, we have this problem. Once you know what problem they have, then you can say, hey, I know how to fix it. If we collaborate more, we might be more creative for whatever else, [inaudible 25:44] sort of advice or first organizations, but I’m there sort of step by step, step back, stop and reflect, think like, where are we?

Are we happy about this or not? And sometimes they actually say we are happy about it. And I’m saying, I know that it’s fine. I’m leaving, right? Yeah, I don’t think I have a job here. And that’s fine, right? And sometimes, they actually say, yeah, that’s exactly, they want me to leave, we just don’t know how, we were trying ourselves, and then you can help them, right? So I think it all started with that [inaudible 26:19], it says create a sense of urgency. But if there is no sense of urgency, then just unable to work with that. I just get out. I learned that through the years, I really worried about this organization who is struggling, not failing, falling completely not like bankrupting, that’s too much. But struggling, right? They slow down, they used to be super successful or successful, whatever, growing, growing, slowing down, slowing down, and now they see how it looks like down the hill, right? Looking back down the cliff. And they’re scared, they try to fix it themselves, like three times four times. They said no, those practices, right? They don’t help. So those are ready.

Speaker: Miljan Bajic 27:01

And there’s that sense of urgency there, right? They don’t want.

Speaker: Zuzi Sochava 27:06

Yeah, exactly. So very often, vigorous, funny conversation, like this afternoon, about some clients, right? Has been asking about something like new potential clients, right? They think that you actually are here to sell, I was like, I’m not selling, I’m waiting until somebody is here and say I want to buy, right? So maybe there’s the shift, right? I’m waiting for organizations until they’re at that cliff ready. And before that, I just check them a little bit, are you ready yet? Hey, that’s very kind girl, interested? No, not yet. No worries come later, right?

Speaker: Miljan Bajic 27:45

Exactly.

Speaker: Zuzi Sochava 27:46

So that’s part of what I do. But of course everybody has a different lesson, I try to catch those type of people who are like, ready.

Speaker: Miljan Bajic 27:54

It’s not waste of your time. It’s not waste of their time, if they’re ready. And I think we’ve been in situations where they talk about it but there’s no sense of urgency and so it feels you’re not contributing, so it feels at least when I go in and coach, I feel like I’m wasting their money, I’m wasting my time, I’m not motivated, it doesn’t feel good.

Speaker: Zuzi Sochava 28:23

It’s not helping them either.

Speaker: Miljan Bajic 28:24

Yeah.

Speaker: Zuzi Sochava 28:26

That’s the problem. They feel like they’ve been better without it. It’s too painful, right?

Speaker: Miljan Bajic 28:34

Yeah, exactly. It’s tough and maybe to pick it up a little bit. And you’ve written in your book about the need for organizational structure change, like HR, Finance. And I think especially like finance and HR, those are the last ones to go or to understand or shift their mindset. What are your thoughts? I mean, again, I haven’t read the book, what do you write in your book about HR? I’ll go back and read it, I promise. I didn’t know that you’ve wrote a book. I knew about the Scrum master one. But I talk a lot about finance and HR. So what did you write in the book and what are your thoughts on how finance and HR needs to look at things and maybe change their perspective?

Speaker: Zuzi Sochava 29:19

So I see HR much closer to me because I was working as an HR director for a while and it’s easier for me to imagine that. I’m not really a number person and mean numbers. I was good at mathematics just like numbers. I know it doesn’t make a sense really better. So I have a hard time to talk to core finance people because I feel like they’re from a different planet. But for HR, I think it’s really simple because they are here to help, to guide employees or their employee experience and make it really full fails. And that makes him satisfied and help everyone. Now, employee experiences in that sense, right? One of those things I want HR to look at is what is our culture? Currently right now, and where do you want to go? Miss it culture. So to give a few examples, rather than ever shifting, we really want to make it highly collaborative so people help each other, learn from each other, support each other, even across the teams. And the second thing want more innovation, they have no innovation at all, we had this mindset, like, do exactly what the customers say. And then we got this vision that we need to go back to mission, we used to be and start offering new ideas, innovations, etc. So we were shifting in those two quadrants, like collaboration, innovation, and we were like going a little bit backwards in competing, really tried to almost avoided, we didn’t like competing culture, because it was against a collaborative one. And the controlling culture was [inaudible 31:04].

Speaker: Miljan Bajic 31:05

And when you say we, who’s we?

Speaker: Zuzi Sochava 31:09

There was a company where I was working [cross-talk 31:13]. And then, when I was working with the clients, it was a big finance institution and they actually their shift was, we want to be more innovative. That was a business needs to get more innovations from people and creative ideas, etc. There isn’t one of those they’re controlling, not even competing, just want to get more innovations.

Speaker: Miljan Bajic 31:43

It’s like a lot of times, like, oh, we need more innovation. So we’re going to create an innovation department to [inaudible 31:48] for us, rather than embedding innovation in something that everybody does, right?

Speaker: Zuzi Sochava 31:55

Yeah. So that was really fun. Because we were able to work on that, applying bit of Agile and Scrum and Kanban, or whatever they requested. But really, the ultimate goal was regularly be able to come up with different innovations, and have a lab for that and do all that stuff. So it really depends where you want to go. And then the message for HR is all the processes you have, recreating position scale and career path, all those things are sort of a reflection of your current culture and desired culture. So for example, if you want more collaboration, and more or less controlling culture, then maybe having a manager being the only one and HR and the interview might not be a good fit. Maybe you should involve the team more. And maybe your positions should not be that fixed, like exactly defined, right? But more like general ones. And by the way, if you go even more, you don’t even need the positions. Now speaking of our organization, we didn’t need a position, we still have some because I wasn’t able to sell it to the board fully.

So we got an engineer position, not a software developer anymore, not a tester anymore, not anything else anymore. We got an engineer position, which was good enough. I was aiming for team member, but we didn’t. But step by steps, right? It is step by step. But then the bank, for example, no one will ever go for [inaudible 33:32] all the institution, we have to. So you don’t even open that conversation. Because it’s not in your way of do things. So always like where you are, are your practices supporting the current culture or do you need to shift them and sort of move to different directions? So I really like no positions, because this position some of the stuffing people in their boxes and don’t allow them to really be who they are. I like no KPIs, religious, like this purpose-oriented thing. On the other hand, I don’t think every organization is ready for that. I like radical transparency. But again, transparency is scary, right? If you don’t have trust, so those things are sort of interconnected, and you have to find a good match. It was really interesting. I got one of the people I was coaching, they actually got one day this is brilliant idea, that they asked the team, it was a high-level team of people who well, actually they got some issues in between of them which we knew, it was no secret, no secret in that. They say you’re on our team, we are now agile organization. So you guys distribute their salary yourself. It was a great brilliant idea from [inaudible 34:49] like a really, really bad way, right? They were somewhere here so and actually didn’t [inaudible 34:55] well on the first loom. Now going back to is it right or is it wrong, right? You might say that it was really a bad idea because those guys actually have a big fight. And through like, ugly, and it got escalated back to the leadership team again. And they didn’t want to talk to each other or even sit in the same room together. So they have to fix it and talk about it.

On the other hand, those individuals who started that fight or who were fighting, they learned something about themselves, eventually. And they were able to fix that through some external coaching, and be able to work with each other again after some time, so they learned something about themselves as individuals. The leadership team learned something as well that maybe they are not such a good team and maybe they should do something about it. And by the way, as a result of that, they change the CEO. Major was there on their table for two years, and no one was doing anything about it. So then it happened like this, by the way. So was it a bad thing or was it a good thing? That’s what I really like working with complexity, because there is no right, no wrong, no good, no bad, they’re just different things which eventually, we’ll have it out somehow and you can look at them as better or good, the learn from them. And if yes, well, we know that they survive. And if yes, well…

Speaker: Miljan Bajic 36:25

Exactly, in context is also so important, right? Like, in that good or bad, because the context dictates a little bit as far as like what’s good or what’s bad? For instance, I know everybody talks about and I brought it up, but from reinventing organizations, Frederick talks about morning star, right? So context for them, when it comes to HR, the transparency of salaries has existed for a long time. And in their context, that works, right? Where people actually see each other’s salaries, when you want to raise, you talk to your peers, you don’t talk to the HR. And in that context, it works perfectly. But good luck trying to do that in an insurance company or bank, like I said. It’s not going to work right away and the context needs to change to some extent, right?

Speaker: Zuzi Sochava 37:28

That’s true. And you need to raise a trust a lot. So you can’t raise a transparency without having enough high level of trust. And that’s tough, because people trust each other because he did his job. That’s not enough. You need another party to really trust them on a higher level.

Speaker: Miljan Bajic 37:48

So how do you grow trust? You’ve written about that to.

Speaker: Zuzi Sochava 37:52

Building relationships, right? Religious like doing those different team buildings, it’s the issue over the virtual now, a lot of teams are now living on deck, I think, from what they created before. Now you have a lot of team members in many organizations where they never see their colleagues. They just pick up a laptop and never seen anyone except zoom, then I was having recently a scrum master class, and she was saying, what shall I do? I was hired in March last year. And I never seen any of my team members. They’re saying they will never, they won’t started a video camera because their CEO said it’s not necessary. I don’t know what to do. I don’t know how I should be a scrum master. Now you’re telling me how this scrum master is doing. But I technically can’t do it. But I was like, I’m not quite sure I have the answer for you, right? So we have a nice conversation with the other guys as well, like, what do they do to really help people to show up on camera and build that relationship virtually? Yeah, at the end of the day, it’s about relationships. So how can you build a relationship if you never see anyone, right? For some people, it’s easier, for some people, it’s harder. It’s easier to go for a drink, but we are all friends.

Speaker: Miljan Bajic 39:12

Exactly. No, but it is. And I think it’s also easier for younger kids and older kids. I was recently doing a class and just something that stood out to me, so I’m doing the class in Euro, right? And I’m facilitating and all the sudden there was a group of younger people, they start taking notes on my mural, and I’m like, what’s going on? Like people putting notes, taking notes, as I’m saying, and I’m like, what’s going on guys? And they’re like, yeah, this is what we do, it’s now collaborated. They’re talking in the chat. I’ve seen the talk in the chat but I’ve never seen people actually taking notes. As they got people commenting on theirs. And I’m like when I was in college, its long time ago now but it doesn’t feel now long time ago, like I was joking, I would pay for the notes, you pay if somebody took good notes in lectures, you pay for it. And now it’s all transparent, they’re collaborating, as I’m talking and it made me think about just like, a lot of times, I’m saying like, oh my dad has a way of thinking because just in the environment that he grew up, and now I’m seeing myself being that guy, the younger kids are like, yeah, it’s been interesting to. So I started teaching undergrad scram in undergrad, [inaudible 40:37] and like, that’s another thing that’s so amazing, like, how they don’t have all the baggage, they don’t know what waterfall is. They never had, a professional job in a sense where what we consider and what we see mostly in there. So I’m thinking for those people that are so used to working and building relationships in the physical space, it’s easier but I’m also thinking that it’s going to be easier for people that are used to now building relationships in a virtual world. But they might have a better luck of developing that trust and relationship. But I don’t know, do you have the same?

Speaker: Zuzi Sochava 41:21

I think so. I think it’s also a bad culture, like very [inaudible 41:27] but also very abrupt. So there are some people from organizations they’re saying, no, we can’t use this. It’s funny. All those organizations went to virtual now, right? They asked people to be in a home office, etc. But they’re restricting them from, you’re not allowed to use Zoom, you’re not allowed to use Google, you’re not allowed to use Dropbox. And then it feels like how those guys can really collaborate. Come on, you’re making their life almost impossible. I remember one of my friends had a boss was actually telling how you have to be visible on the camera, from nine to five, like, all time, I want to see you just like bringing the kids from school or something. Can I work later? No, nine to five. Those companies just didn’t really realize this world is changing. And eventually, those young graduates, they don’t want to work like we used to have, I still remember my grandfather, when I was going from a college to the first job, he was like, maybe your father can find you a job. And you can stay, I hate to say that, like almost one sentence, and then you will have a job for the entire life. And it I was like, first of all, I don’t want my father find me a job, I can find myself. I don’t think I have a job for life. And now I’m playing like fourth or fifth things, it completely changed. And it’s so funny, because still my grandfather was saying there is a thing like [inaudible 42:56] I know he was working in that thing for the entire working life. But that’s ridiculous now, right? The graduates are not even knowing what they do. So they do here and here and here. And in 10 years, what I was doing is irrelevant, because they’re different technologies. And they don’t…

Speaker: Miljan Bajic 43:15

So this is maybe a good last question then or maybe some that we can discuss, what’s next? What’s in the next five years when it comes to agile and agility? The podcast I named is shifting from Agile to agility because we’ve focused last 20 years on agile, not so much in agility. So I hope that the next 20 years or at least 10 are focusing on the agility. But what are your thoughts, what’s next?

Speaker: Zuzi Sochava 43:45

I think we’re going to hear more about business agility, and more about the stories from all those weird departments like finance, sales, marketing, using this agile and I’m not meaning using Scrum or any framework at all. I mean, having that mindset of collaboration, transparency, trust on one hand, but also business value driven on the other hand, because without that, it doesn’t really make sense. I also hope that the profession of agile coaches will become more and now I’m looking for drivers not really structured, but maybe more defined. So we know what to expect from or what they need to do as business people and what to expect from them. And sometimes tired of having this thing, those project managers with agile, right? So I hope that those things will disappear. Eventually. I mean, you can be a project manager, nothing is wrong with it. But just don’t combine and pretend like those type of things. I would like to hear more stories like [inaudible 44:47] or those type of companies who are trying something different. Zappos, Menlo innovations, right?

One of my favorite it’s those type of companies who are ready to start experimenting at the organizational level. Who are able to try different things for another [inaudible 45:08] just say we try it now and see what happened in spite of that from that, right? That’s the agility at the organization level. So we don’t have positions now, but they actually realize they might need some positions so we do a few. But they’re going to be looking for a difference. So the organization’s currently, what I hear, there are a lot of discussing, like doing it office space anymore, right? So when this whole pandemic is over, do we force people to go back? And how are we going to do that? Because they don’t want to go back. I mean, some of them want to go back, but some of them don’t. And what are we going to do? Europe is in a way fragmented by a lot of things but if everything become virtual, you can actually hire any team in their time zone from anywhere in the world. And there are some places where you would work in different time zones. So for example, I like to work in the US time zone, because it allows me to have a free day, it was my daughter [cross talk 46:07] right? It’s not that bad, actually. Yeah, you might realize that working in a different time zone is actually an advantage. Because then we’ll change completely this work life balance.

Speaker: Miljan Bajic 46:24

It gives you options, right? And I was thinking because, I’m originally from Europe, and like, I spent a lot of time in Croatia and Montenegro, not so much in Boston, where I’m from, but summers are obviously, at least on the beach but I was thinking same thing, hey, I can work for four to midnight, and have most of the day and still asleep, from midnight to eight, nine, if I can. If I can get six hours, I’ll be happy to. And it just gives you options. And I think that’s something that’s going to be interesting. Also, you can find talent now, a lot of times people have been hesitant to outsource, at least for the area. And you guys are not too far from us. But I think you’re probably in the same situation where you have a lot of talented people, right? And now if I can get better people at the same rate here, why not? Everything’s virtual, they don’t have to be. So I think that’s going to be a game changer as well.

Speaker: Zuzi Sochava 47:36

That’s going to be tough. And also there’s people who are sitting in their living rooms and homes, right? They don’t have that strong relationship in that company they work for anymore. They have a relationship to the computer, and maybe the few of their colleagues, but those faces could be a lever. And it started to be interesting, what’s going to happen with that. Because then I’ve worked for this company, this company, who cares, right? Before that you ever going to get that office, I get a flower there and a few pictures on the wall, right? I got my friends, they’re like colleagues, behave, like a friend and I will love to go there. But actually, once we become all virtual, that whole thing is gone. So it will change and shake really significantly the organizations. And there are some who are able to adapt and take advantage of every crisis, by the way, right? Of course. And there will be some which will struggle. Let’s see, who knows.

Speaker: Miljan Bajic 48:37.

Yeah. And I was talking to, you’re probably not having heard of him, Andy singleton here in Boston. Yesterday, I interviewed him and he’s been doing software development for a long, long time. But he’s been doing distributed teams for 20 years or so. And I asked him as far as like, what do you think is going to be some interesting stuff that we’ll see in the next…? And he said, you’ll see more of communities, like you’ve seen, like with Wikipedia, where people just teaming up more virtually to solve world problems, or to create companies or what we’re seeing with cryptocurrency and some of these other things where the collaboration at the virtual level is going to go to the next level, essentially, he said. You’ll see a lot more innovation and a lot more going on, what he calls these communities. So I was like, yeah, that makes sense. We’re all speculating, nobody knows.

Speaker: Zuzi Sochava 49:42

I think you will see a very different way of working, we’ll see more agility in a space, essentially, we’ll see agile data spaces where it was not before because it was not really needed before that much. Now it might have been needed much more. But who knows, maybe everything goes back to something and we will be surprised where we end up. You never know what’s coming anyway. And that’s such fun because it’s not predictable. So it’s more interesting.

Speaker: Miljan Bajic 50:17.

Yeah. So maybe as a last question here is, what do you for aspiring Scrum Masters, leaders? What is an advice stepping into maybe mentor role? What is the couple of advices that you share with people for aspiring Scrum Masters and leaders?

Speaker: Zuzi Sochava 49:42

I have maybe one in mind, which was struggling with me like last week because of some other things. I think what they need is have their own dream, not just given a vision of something but their own dream, why is it important? And if you ask yourself, what happens if I stopped? Say, I don’t want to stop because I believe that that thing is important. So that’s kind of dream is at the beginning there and the dream could be, I want this team to be able to do this or that or work like this or have energy and be happy and burned or anything right? Then once you have that dream, then you might need to have a lot of self-confidence and courage to go for it and optimism. So the last thing will be the optimism, because if you give up. It’s going down. So don’t give up. It’s going to be better.