Pete Behrens: Leadership, Culture, and Behaviors | Agile to agility | Miljan Bajic | #27

Pete Behrens

Speaker: Miljan Bajic 00:54

So Pete, first of all, let’s start definition of leadership, a lot of times there’s different ways that people define leadership, how do you see leadership and how would you define leadership?

Speaker: Pete Behrens 01:07

Wow, okay, you’re going to start out deep on me? It’s interesting, I know, when we teach our classes, this comes up a lot, like who’s a leader? And how do we define them? And we, I guess the way I look at this is to think about that shipside, the act of leading. So I think much less about the leader as a role. The leader is a title, I think more about the act of influence, the act of alignment, the act of getting a disparate or collective group of people doing something valuable.

And so when it comes down to leadership, it’s something everybody does, whether they’re aware of it or not, and so that’s where I think when you try to think about educating leadership, it’s how do I do those things better? How do I influence better? How do I connect better? How do I enable and do something valuable with these people better? So maybe a long-winded answer to what is leadership. But, yeah, it’s an act.

Speaker: Miljan Bajic 02:28

And it’s also something I think that we’ve discussed this before too, that it’s situational, right? So a lot of times our situation will require a different type of leadership. So could you maybe talk about situational leadership and what that means to you?

Speaker: Pete Behrens 02:46

Yeah, and that’s really when you think about agility and we get into this concept of, what is agile? Agile isn’t adaptiveness, it’s a recognizing with data, how do we respond? I think if we go back to the root of what is an Agile process, it’s an empirical process. It’s a inspect and adapt process. It’s a, I have data, so let me make a decision versus I’m going to guess what to do. And so yeah, when you say situational leadership, while we don’t necessarily use that in our definitions, we talk about situational leadership. And well, the way we talk about this is, as a leader matures, they start to develop layers, or I don’t want to say personas, but there’s depth to a leader as they develop.

And so a leader with one level of depth, has a hard time situationally adapting, they’ve got one tool, one hammer, everything’s a nail. As soon as you start to build another layer, now I’ve got a screwdriver. So maybe I can do some things with a different tool. So situational leadership is that ability to adapt your tools or adapt your approach or adapt your style, adapt your power, whatever it might be that you’re using to that situation. And so unless you start to create those new layers and new tools for this leader, situational leadership is kind of a waste. It’s not helpful without having some of the basic tools and infrastructure to situationally adapt.

Speaker: Miljan Bajic 04:28

And a lot of it is also about awareness. We talked about everybody that you hear talks about awareness and being aware as a leader or as a person, right? So what is it from your perspective, how do we feel somebody that wants to lead and be better aware, what’s awareness and how do you develop that awareness?

Speaker: Pete Behrens 04:51

Well, I think what you’re getting at is the heart of probably any leadership development program and I think if you were to go to any expert or read any of these books at the heart of what you’re going to find there is self-awareness. And so this is where my understanding of myself will help me understand then how to apply that self or some level of that self in various situations.

So yeah, self-awareness is a very deep topic, I wouldn’t even call myself an expert. In self-awareness, I’ve done a lot of study under various, what I would consider experts or expert aggregators, like David Rock, I think is, does really well in this, I wouldn’t call him necessarily that expert either, but he’s an expert aggregator, he gets experts together in neuroscience and other things. And that to me, has informed me a little bit more about okay, what is our view in terms of that cognitive awareness? What is our metacognition?

That second operating system running in your head that’s always going telling you wait, you shouldn’t be doing this, yet you’re doing it? And how much do we listen to that? And so, yeah, I think all leadership coaching, all leadership development at its root, is really getting towards, are you aware? And how do you develop that? And how do you, in a sense, leverage it to be a better leader?

Speaker: Miljan Bajic 06:32

Yeah, and one of the things when I took the survey, agile leadership class with you, we talked about, I think it was from leadership agility from expert achiever catalyst concept, but that’s also from Bill’s work for those familiar with Bill’s work, it’s really that cognitive growth, as humans, as adults, it’s really about adult development, how we see and perceive world and as you move from expert to achiever, to catalyst, your awareness grows, so you’re able to see situation, or situations differently.

And I think as coaches, consultants in organizations, a lot of times we’re helping people move across that spectrum, so they can actually see things broader in their organizations and see things more systematically. How do you help leaders when you’re working with clients, and you’re working specifically maybe with executive leaders? How do, besides coaching, or maybe what are some of the coaching techniques that you use to help them develop that awareness?

Speaker: Pete Behrens 07:48

Now, this is a probably a lot to unpack there. Do you mind if I take you on a bit of a journey through this dialogue? Is that fair? You and I got a chance, post COVID. You came to my class, and I really appreciated that but even some of that, so one of the things you’ll notice, when we teach, we go back to history first. And so we think about, well, everything we’re doing now is not brand new, agile is not even brand new. In fact, if you were to go back in time, there’s this great article I was reading about the concept of prestige for service, was the name of the article, it’s very odd title prestige for what is that? So go back in human history all the way back to the nomadic time, this is before agriculture. This is two-point X million years ago, when humans were just running around the earth.

And they talked about leadership at that time, was a pay to play service. So if you as a leader did something for a tribe, if you hunt or if you protected, or if you were good procreator or whatever it was, you got things from the tribe, they gave you things like the better tent or the better meat or you got prestige because you did something and, we don’t teach this part in the class but to me the history is fascinating. Because Okay, circle them, move up now to 13,000 years ago, and we start agriculture in cities and we start to build these walls and, all this other stuff starts to happen, which I believe today, you could argue most corporations are built on the Game of Thrones technology of fiefdoms and castles and kings and queens.

I mean, that’s what we see today. And what’s really fascinating when you look at the human brain science behind this, our brains are built for autonomy. Back in the day when you are my leader, and you provided service great, but if for whatever reason you started to steal from me or you started to do stuff, and you didn’t deserve it, I just kill you or I run away to start my own tribe and then I kill you, right? So, we had autonomy. The problem happened when we built these kingdoms and these castles. As soon as there was this dysfunction, people were no longer safe to leave, because as soon as they left, they had no power, and then they get killed. So all of a sudden, you didn’t get to choose your leader anymore. It was because they’re the child or whatever that dysfunction…

Speaker: Miljan Bajic 10:26

So the rules of the game changed a bit, because…

Speaker: Pete Behrens 10:29

A lot, yeah. So the brain still thinking, Oh, autonomy, but the system change. So my point of that story is, if we don’t understand history, and we don’t start to understand just the roots of who we are as humans, it’s really hard to put that in context today. And whether that’s Taylorism of the 1900s, whether that lean in stop the line mentality of empowering under Deming, whether that’s today in thinking about or even take post heroic leadership of the 1980s and 90s, or servant leadership that came out in the 60s, and 70s, all of these things have a context.

And if you don’t put them in some of those contexts, I think leaders have a hard time recognizing the value. So when we’re working with leaders, having a bit of that history, connecting back to some of those things, agile is not new. Agile is a different context of what we’ve been doing for the last 50, 60 years. And you could even go back two-point X million years. And it’s kind of going back to some of those freedom days that humans are built on. So to me, that’s an important characteristic in helping leaders understand better about their role as leader.

Speaker: Miljan Bajic 11:46

Yeah, that just reminded me in a sense, it’s like understanding the history, but really, it’s about understanding ourselves, right? Through that history, we get a better understanding of ourselves. And then it goes back to understanding myself individually. What motivates me, what motivates others? And how do I better lead in this context as a leader, right?

Speaker: Pete Behrens 12:09

Exactly. And you’re bringing up things around Bill Joiner’s work, the expert achiever Catalyst, and our training does center in that realm. And so I would say, the second thing we try to do for leaders is provide pragmatic, meaningful connection to things they understand because, when I think about myself as a leader, the last thing I want is a theory that’s yeah, whatever. I want tools, I want pragmatic things that are meaningful, and most of the leaders we interact with had a fairly rich, technology centered brain, they’re thinkers more than feelers. They like to process things, but they don’t like to waste their time on agilist and a lot of places we work in, they don’t want a lot of bureaucracy, they just want to get to the point.

Let’s go. So, the tools, the models, everything we try to do, we try to bring this down to the simplest thing possible. And so something like Bill Joiner’s work, Einstein says all models are wrong, some are useful. Bill Joiner’s, work is useful. It’s not right. It’s a model, of course. But I find it to be incredibly valuable. Leaders can see themselves even with one hour’s work of exploring the model. Leaders start to say, oh crap, I’ve been manipulating? I didn’t realize I manipulate. There’s so much bad leadership because of lack of awareness, not because of intentful misdeeds. They just don’t know.

Speaker: Miljan Bajic 13:54

Yeah, and a lot of times it’s exactly that. When I go in organizations, you see people are trying to do the right things. It’s just like they’re not aware that they might be causing the else some people are actually suffering from some of the decisions that they’re making, and they might not even be aware of how a decision that they made has just made somebody else’s life. Or they, that much more miserable and it is very interesting and when I look at it, it is that practical stuff.

So how do we help the leaders who are busy especially in today’s context, help understand them how to see that , what they’re doing and how they’re influencing others? A lot of it also comes to change the culture right? We’ve talked about influencing and changing the culture. So how do you shape the culture? How do you create alignments through boards, certain type of cultures? What have you done from that perspective?

Speaker: Pete Behrens 15:07

Now, you’re hitting all the big topics here. So yeah, culture is awesome, fascinating subject. The way we, the way I have found, I say we a lot when I say we, I talk about our community in terms of the Agile leadership journey, we can talk more about that a little bit later. But, this we really is a reflection of it since I helped create it. But what we talk about is, the micro culture, and the macro culture. And this is another fascinating thing that I’ve come to over time early on, everything was a bound culture posters on the wall, these big change initiatives, we got to restructure the organization, all this macro stuff, that’s incredibly hard, incredibly expensive, and takes the top-level leader to enact it.

And those are still going to happen, those will always be really big cuts through the organization that are going to have a potentially huge impact, positive or negative. What I think a lot of leaders miss, and what we try to inspire in leaders is the micro culture. The thing is every leader at every position, in the organization can influence a decision, can influence a meeting, can influence a dialogue, a conversation. And it’s in these micro moments that culture really lives. And in this is where a leader shows up, not into, hey what are our values that we put on the posters that we put on our website? But how do I exhibit that value in this meeting, in this conversation?

Speaker: Miljan Bajic 16:52

So are you saying it’s about behavior? Because it that exhibiting, that is you’re talking about specifically behavior, right?

Speaker: Pete Behrens 17:00

Yeah, but what is behavior stem from awareness and mindset? Yeah, so behavior is a symptom. Behavior is a symptom of thinking. I was just in a workshop with a client just yesterday and it was really ironic. We are talking about leadership power style, assertive and accommodative, and how we show up as leaders and being more aware of our own power style. And the most senior leader in the room, came across and, had diagnosis a little bit and in front of his whole rest of his team said, I think the problem is skills. We don’t trust our team because they don’t have enough skills. And so I asked the leader in that moment to just step back and reflect, okay, what power style are you demonstrating right there? Because pretty much at that moment, everybody else shut up. And he was trying to get them to think like, what do you think? What do you think? What do you think? And nobody responded. And the previous day, he had asked a very open-ended question, hey, what do you guys think about this expert? And there was all sorts of conversation.

And it was just one of those really cool micro moments of being able to call out a behavior. Okay. And notice the difference in those two dialogues. Yesterday, the rich conversation and the open question, today, the very closed question, don’t you think it’s skills? And, and how that impacted everybody’s ability to feel safe contributed So yeah, it is behavior, but that behavior stems from my own awareness, and then my own my own thinking on, what does it take to create empowerment, engagement or implant this conversation?

Speaker: Miljan Bajic 18:48

That’s a great example. And like that, I totally relate to that, the behavior is a reflection of your thinking. So if we have, a lot of times leaders are thinking like, I want stability, I want predictability. Right? I want that control, maybe or some sense of control. So if I’m thinking that way, what are the behaviors that may stem from that type of thinking? Right?

Speaker: Pete Behrens 19:17

Yeah and the organizations reflect what the leaders are doing. So, if the leader sees competition, likely that leader is invoking competition, if the leader sees disengagement, the leader is part of that system that’s creating that disengagement. And so we’d like to start with the leader. Because when you when you start to think about any organizational initiative that tries to come in and agile transformation changing, doing scrum or whatever, it will be trumped by whatever leadership is doing. And so what we try to do is hack into that leadership and say, okay, we’ve got to start to change that dynamic. Then we can enable some of this other traditional agile stuff to happen. And yeah, you’re right. It’s creating that awareness to recognize that that leader is being mirrored by those around him or her. In the organization, we need more hers in leadership.

Speaker: Miljan Bajic 20:18

Absolutely. And maybe this would be a good time to go back to, I think based, I was trying to do a little bit of research and just trying to get a sense of but you started agile leadership program in 2011, through Trail Ridge, your consulting company, and now it’s morphed into agile leadership journey. And there’s a lot of people that have been trained to that. And when you reflect back, what are some of the things in the last 10 years? Like, could we talk maybe, and explore a little bit about where when you started talking about leadership in 2011? Versus today? Where are we as a community?

Where are you as far as, how have you grown through this process and through the experience? Because I think we’re about to hit this another wave of thinking or maybe even paradigm where we’re focused more on like you said, that ship? So could you talk about the maybe a little bit about the background, and agile leadership program with Trail Ridge, what you’re doing with the Agile leadership journey, and the current state? So there’s a couple of different things here that we can start a little bit at a time I would like to spend?

Speaker: Pete Behrens 21:41

Well, let me take in another journey. So I think it’s probably helpful to have some context. So, my background is engineering. And so when people say, well, okay, how do you go from engineer to leadership educator, it seems like a big jump for a lot of people. And I actually argue what I’m doing is engineering. In fact, I think what all leaders do is engineering. And if you look at, okay, what’s the root of an engineer? It’s to optimize a system. Okay, mechanical systems, electrical systems, data systems, storage, whatever. What is the job of a leader? Optimize your people system. So when I look at what I do today, I help leaders optimize people systems ,some of the most complex systems in the world.

And if you think about, our organizations are developing products and services for customers, most leaders end up focusing on those products and services for customers, we’re trying to get those leaders to focus on the system that’s building those products and services for customers, the people, in the organization, the teams, the culture. So what’s fascinating from that perspective, is this switch for leaders to switch from the working what we call in the system, to on the system, and that switch. So when I was, in my own journey on this, I was a VP of engineering and I had worked years for Rational Software.

I don’t know if you know, that background, but, so I was in the process space, but as a leader building tools, and doing all the good things, the bad things, the waterfalls, the Agile [inaudible 23:21] type things that we did back in the 90s and early 2000s. And I said, I want to try this agile stuff. And so as a leader, myself, I and Dean Leffingwell actually work together. In our first agile implementation, I was VP of engineering, Dean Leffingwell, was one of our investors in our company that was we’re working together on this stuff. We, we both sucked at it. And it was at that moment, I realized, this agile stuff’s cool. And it’s really hard.

Speaker: Miljan Bajic 23:53

Yeah, it was really, I actually listened to the podcast that you did with Dean recently. And that was actually good listen, so I really enjoyed it. And I really didn’t know that you guys work together. So, that was really cool.

Speaker: Pete Behrens 24:08

Yeah. So yeah, got a lot of different history. We could explore there. But yeah,. So fast forward a little bit. I ended up getting laid off from a VP role and longer story there that we don’t need to get into. And I had a choice. And I thought, okay, this agile stuff, easy to understand, hard to do. If it was hard for me, I know it’s going to be hard for others. And so this is about 2004 and five when I’m starting Trowbridge and trying to decide how best to do this. And so yeah, what went through and tried to determine who’s the best at that time. What’s the best ship to connect to XP. There’s DSDM going on, you’ve got , even some of the Crystal stuff is out there, Scrum is out there. And it’s like a guessing game at that point. And the one thing that made me choose scrum over everything else was they had an organization.

Everything else was scary. Yes. It was like a three number. I think it was Esther Derby. It was Mike Cohn and Ken Swaybar. But they had something. And they had created a little community with a couple of events. And so I thought, that’s probably the best bet. So that was my going into becoming a scrum trainer in 2006. But I actually joined that because I literally hated the two-day scrum masterclass, like most people do, how could you be a certified scrum master in two days? That whole argument. That was me?

Speaker: Miljan Bajic 25:51

Why did you take your scrum master class lit?

Speaker: Pete Behrens 25:55

I took it with my comb. And Mike awesome. He didn’t do all of the Hokey stuff, I would say contributed he was much more pragmatic. Mike Cohn is awesome and even today, I just can’t imagine that guy. Circuit. What is enough? 15,16 years later, he’s still doing the damn same thing. Like how the hell do you do that? I can’t do the same thing for like two years. So yeah, so but I joined the scrum alliance to change the scrum Alliance. And my goal and change the scrum Alliance was to bring coaching into the scrum lines. And so Mike Cohn gave me the permission to create the at the time the CSC, the Certified Scrum coaching program. And we did that in 2007. With the help of like Roger Brown and a few you need to interview Roger Brown, he’d be a really good one for you.

Speaker: Miljan Bajic 26:46

I was going to talk to him while I was in San Diego, because he’s still there, right?

Speaker: Pete Behrens 26:50

Yes, retired, and, but they’re surfing. Yeah, enjoy life. So my whole point was join the scrum alliance to make it better. And that was the coaching program at the time. I never so,10 years as a certified scrum trainer, never taught a public class. Trained 1000s of people, but it was all in service of coaching and client guidance. So yeah, the whole leadership thing. That happened because in those first five years, I was consulting under my company and training and doing Scrum. I noticed a pattern. We teach them, and they say, my leader won’t let me do this stuff, or my organization doesn’t let me do this and I just really got frustrated with that. And I’m like Okay, this sucks ,like Ken Wilber says, this sucks and that makes me sad, right?

I think that was what it is. So I would say that, but it wasn’t enough for me. I felt like we needed to do more. And so that put me on a journey of leadership. So this is 2007 Eight. So yeah, it took me a few years to build the toolset to understand culture, to dive into leadership, to look at David Rock, to I’m going on a search. I’m like, feel like one of those now. You know roamers around the world trying to figure out what’s the right stuff? And, so yeah, 2011 was the first time I instantiated the class. We called it at the time leading and coaching agile organizations. And what’s really amazing to me, everything we’re teaching today, is roughly the same tools and models but how we teach it and the nuance and the language, everything’s completely changed around it.

The models actually held together really well. Now, so yeah, so the cow that came that came out of the scrum Alliance, saying the number one request is get leadership training. And so they asked me to come back in and help like we did with a CEC to create the Cal educator and I worked again with a couple other teams people like Peter Green and even people outside to come along. So like Pollyanna Pixum, Steve Denning, he’s another guy you got to get on your, your show. Yeah, so that was just fascinating to bring these people together and to co create the cow program was pretty was pretty fascinating. Yeah.

Speaker: Miljan Bajic 29:41

It is. And it’s, I think just from coaching, I really respect you for that, the point is to coaching and it’s so important, and I think , one of the thing that when Howard and I spoke with him ,when he was part of the original right he worked with you I believe when he You guys did the original coaching. Or he was there at scrum Alliance? Was he?

Speaker: Pete Behrens 30:05

No. The original coaching happened way before he was probably still with what solution [inaudible 30:10]? Or whatever . No, that was way back that we probably had even Carol as manager, I don’t even remember.

Speaker: Miljan Bajic 30:21

[Inaudible 30:21]. So maybe I get that, but definitely what I was telling him is, at least, what he was saying when he came in recently that focus on coaching, and I think I shared that same feeling with you is like you go to the class, and then what right, how are we creating more people that I use the analogy cooks and chefs, but like, how are we creating more on that spectrum? We can just expect people to take it to the class and, and fully understand it. So how did the leadership journey come about? So you’re doing all this stuff? And then I’m assuming talking to others, because it’s a group of you that came up with that, or was it your idea? How did Agile leadership journey?

Speaker: Pete Behrens 31:11

Yeah, let’s first talk about the premise behind it. What’s really interesting, the scrum Alliance works. And even Scrum works pretty well, because there’s a really clear framework. We have roles, we have ceremonies, we have the flow and some of the key tools. And so no matter who you are, you can teach a different ways, you can have different quality, but the students going to get, for the most part, the same thing at the end. Agile leadership is a wild west, right? There’s nothing binding it. So the risk and reward for the scrum Alliance was, we don’t have a single model. So we don’t want to make a bet on a single model. Because there’s too much creativity in the world right now.

And we want to enable that creativity. So we want to allow a diversification of programs that share learning objectives. The problem with that model, so the success of that model is you can expand it, you can grow it, you can you can create a lot of diversity, people [inaudible 32:26]. Yeah, the options. The downside is a client asking for certified agile leadership has no idea what they’re going to get. So from the clients, per say, especially global clients, they’re going to get very different models, they get different approaches, they get different, in others, there’s some shared learning objectives. But the people behind them, you have to go to the same trainer, you got to go to the same company to be able to get one thing. So the premise, behind the Agile leadership journey, is, can we get a shared group of people that we’re willing to bet on the shared model?

And we’re okay to adapt that model through an empirical process. And so the toolset we adopted because I helped create it was what working and we train 1000s and 1000s of leaders through this program. It’s a vetted, program that works. And so we said, let’s start there. There’s some core, there’s some adjunct. But let’s use some of these core models. And if you want to come into this program, you agree to use that framework, so that we can have consistency. So if somebody chooses agile leadership journey, I know I’m going to get a certain scrum like framework, a certain leadership model, cultural model, how I’m going to go through transition model, things like that. And, then we said, Alright, let’s build this community so we can inspect and adapt, and let’s allow freedom to experiment and bring those back into the system. And it can change over time. Now, how good are we going to be at that? That’s something I think we’ve got to prove out. And there’s always risk of being consistent and adapting. And so trying to find those balances, but that’s the premise of agile leadership journey.

In about 2016, when we started this, that agile leadership journey switch, and this is when Pete me was saying, I no longer want to teach Scrum. Leadership has become so important, so valuable, so much more meaningful to teach that. All I want to do is leadership. And so that’s when I dedicated my working career to leadership. And that’s when I started to test is this successful because it’s Pete? Is it successful because of the model? Can other trainers teach this? And so the whole hypothesis was let’s see if we can scale it, let’s see if others can teach it and get similar results. And that’s what we’ve been doing ever since 2016. And today, we’ve got about just under 40, global guides who are teaching coaching using this curriculum. And the way we look at this, it’s a parallel to scaling scrum safe, less whatever it is you want to do. This is a way to scale mindset, a way to scale leadership and values in the organization, that we do not teach a specific, we don’t teach agile, which is…

Speaker: Miljan Bajic 35:42

Exactly. I think some people also leverage leadership circle, or even some people leverage, specifically the assessments ,Bill joiners assessment, or leadership circle assessment. Maybe just a follow up question to that, then is, what is your take on these assessments like leadership circle? Like the one also Bill has, and there’s many different assessments, right to help organization assess, and I find them helpful, but sometimes, they can be a little misleading as well. So I’m assuming there is assessment as part of the Agile leadership journey and part of that trying to approach or the combination of frameworks that you’re putting together?

Speaker: Pete Behrens 36:32

Yeah. So I look at assessments like I look at models, they’re all wrong. And some are you said, , so yeah, assessments are useful. When a leader puts in the energy they get ,the energy up, garbage in garbage out, quality in and quality out. Same thing with an assessment. So the leaders that take it seriously get a lot out of assessments, and it doesn’t really matter. I just think it’d be bad assessments, but leadership circle, Bill Joiners, alliterative agility you could argue one’s better than the other blah, blah, blah, whatever leader is going to put meaningfulness in, they’re going to get some meaning things. Yeah. But we don’t do that. That’s not a starting point for us, though.

That, to me is a pretty deep place to go. And it’s pretty intensive. And so what we try to do is separate awareness from practice. And we use those terms rather than teaching and coaching because for a leader, it’s about inspiring the awareness and developing the practice. And this parallels Cal one Cal two are now they’ve separated Cali, Kelo, Kelty, and then Cal two, so what we do is we want to inspire as many as possible. So we try to make that as easy a bar as possible. So it’s just about self-awareness. So put yourself in there. What do you think?

And how do you ,and you get value from that, you get value from those tools, and you can self-assess to a certain degree, you’re going to we all lie to ourselves, but it gives you know, people get value without a formal 360. But then we move that 360 into the practice program. And so when you come with us for six months, okay, now, let’s go deep. Now we can put it into practice. Exactly. And so yeah, we leveraged assessments. And that’s true on the leadership side, as well as the culture side. We have assessments on both of those sides. Yeah.

Speaker: Miljan Bajic 38:39

And, yeah, so it can help. And I like what you said about the awareness and separate the awareness and practice. And that’s a really good way to look at it. It reminded me of a lot of times I use Johari window just to help people create that awareness of like, hey what’s not known to me, and just creating that going through that exercise or introducing that to a concept, but the practice is next on the person if they really want to start developing that awareness and start exploring, especially that unknown.

Speaker: Pete Behrens 39:20

Well, you came up, why would I want to, maybe I’m going to turn the circle on you here a little bit. And you came through our awareness workshop last spring. So I’ll put you on the spot of being interviewed here on the podcast. What was your experience in going through that program?

Speaker: Miljan Bajic 39:39

It was so good, in a sense that I really liked the group. I liked the cohort, it was a small cohort, and I really liked the exchanges and what we learned from you, but also what we learned from each other. And there was also some of the things that I didn’t know that, when we start talking about I started in making connections, right? So, it was, again, that awareness, and then I was able to put it into practice. After ,it’s almost like when you have a light bulb go, like, oh, shoot, I didn’t think about it that way. But the way either pizza or aircon or whoever it was in that class was, I never actually looked at it from that perspective.

Now I have a completely different view of this thing that no, I was looking at it from my own. So it was like that, those learnings from each other, and then going back and in some way, trying to put it into practice, or we’re talking before I started recording, I’m writing a book. So it was like, oh, now I have a new way to explain this thing that I wanted so. So that was, it was still short. I think we all agree. I wish it was longer. And it was, even though we did I think it was like four or five, six weeks where we met. But it’s still flew by. And I feel like I haven’t done yet the Cal two .

And I teach now Cal one, I want to start teaching Cal two. But it’s that ongoing discussion with people that have desired to learn to grow. And being, also I think another thing was really that I liked how you created the safe environment. We all, there was a couple of us that knew each other. But there was also, some people that , I never met before. And it was great to develop that trust and safety. So we could talk about some of the things that a lot of times, it’s not easy to talk about in a group. Yeah.

Speaker: Pete Behrens 41:52

Yeah. Thanks for that. And talk about an accident of COVID or a driver of COVID. A lot of people say, COVID’s been the best digital transformation enabler. But I would suggest COVID’s been probably one of the most creative drivers for a lot of people in a lot of industries. And that includes me in teaching online.

Speaker: Miljan Bajic 42:17

And I was going to say that, because I don’t want to point to that without sounding like I’m kissing speed. But, it was no, I learned ,this was, so just for the audience that are listening, this is like, March or April 2020. And I believe this was the first-class leadership class, they did. So, I was just impressed, your preparation for the class combination of the videos, and then the way that you organized mural , that also made me, like Man, I get to step up my game, this is really cool, how it’s organized, how much effort and time I can tell how much you put into it. And that was another thing besides just how professionally you took this whole thing. And I remember you saying, I’m playing around with cameras, I have one camera here. And you were learning through this whole process, as you were putting the class together. So, I did learn from that perspective of delivering online content. You gave me ideas of what I needed to do it in the classes I was teaching.

Speaker: Pete Behrens 43:31

It’s interesting a lot of people say, well, what is going to stay when COVID goes away, like, what changes are going to stick. And I do think while , remote education for our elementary schools, and high schools is probably really pathetic. I, believe adult education remotely, is not going away. In fact, it’s probably going to continue on escalated path. In fact, we had clients asking for us for better remote education before COVID. And we were hesitant and really stuck in our ways. And now that I’ve gone through this process, and we’ve learned a lot since your class, even extending our modular times how much we’re spending.

We’ve had a lot of people go through our program that have gone through the person and go through this and say, this is better. Yeah, we’re not in the same room. But the modularization spreading out over time really being able to little bit of practice in between each session. Think about it, process it. There’s so much gain that we get through this process of remote connection and learning. I’m really starting to think, do I want to go back to the classroom in such an intense microcosm where, it’s engaging it’s fun, but it’s that really big up and down and now forget about it versus a little bit lower energy but it sticks with them longer. So it’s going to be really interesting to see how our community training coaching community responds in the long term on remote education.

Speaker: Miljan Bajic 45:13

It is really interesting, so I started doing a [inaudible 41:18], like three, four years ago in that same kind of format longer pool. And what I found with that, and I still I tried it with CSM too, is the man, most people that are taking especially screwed by Scrum Masters, a certified product owner, they just want to go in and get it done. Right. But you said, it’s that quick, it’s drinking from the firehose, or whatever you want to call it.

But people that are really interested in taking a month-long approach to consuming these ideas and techniques, putting them back into practice, is really more valuable for them and everybody else because you have a chance to digest. And I was listening, Jim Benson is also working, and I had to, I’m going to interview him as well. But he was talking about how he purposely designed his certifications to be four months long, based on how we learn, that you want to it’s almost like you want to let things marinate.

Speaker: Pete Behrens 46:26

And that’s when you joined our class, we went through that design process quickly in March, April. With that long term in mind, we said this isn’t a COVID response. Let’s design this forever. Let’s design this for what we want as far as what’s going to be really good education. And, that’s the intent. So I love what Jim Benson’s doing, I think more trainers should do that. In fact, I’m pretty upset with a lot of trainers who don’t haven’t refactored their training in a way that makes it valuable online.

And we’ve had a lot of people like you that hesitated doing that, than they came to our class, because we get a lot of coaches and trainers come to your class. And they’re like, ah, I don’t know if I ever want to teach the other way again, because they all of a sudden start to see it. And so yeah, that’s, was our thinking anyways, and I’m not saying we’re perfect. I’m not saying we’ve got it all worked out. But it’s, definitely causing me to think, what’s going to happen when stuff goes away? Yeah.

Speaker: Miljan Bajic 47:30

Yeah, and I’m trying to think about that, too. Because another thing from learning. And even if we go back into training, I’m thinking about, how do I bring some of this stuff into a physical? How do I combine some of these tools? And if we go in a physical, how would we use neural in a class and combine some of the things that work really well in virtual? Would some of this work also in a class where people are there, but they’re for some parts, they’re interacting on murals? So it’s going to be interesting to see how things pan out, hopefully, when we go back.

What is your thought about, where are communities heading? Again, I do think there’s a lot of things that indicate to me, maybe it a lot of it is subjective, but where there is a paradigm ,that’s shifting, and I think we’re going to be more focused maybe on the people side of things. I’m not sure. But are you seeing anything slowly shifting? Do you see any new paradigm or anything? What has COVID triggered besides training that you think we’ll be seeing in the next maybe two, five, ten years? I don’t know.

Speaker: Pete Behrens 48:58

Yeah. I appreciate the question. Certainly, I don’t put myself up as a futurist. But I don’t think, but yeah not just take COVID out of it. I think the writing’s on the wall. There’s a lot of commoditization and art right, so scrum training commoditization, you can learn Scrum and a lot of different ways you don’t need a $1,000 course to probably do that. And so I think, that’s going to threaten a lot of Scrum trainers. I think the coaching side and that’s what I love about Howard. So I was on the board of directors when Howard came in and pitched and to be honest, he blew me away. The simplicity of his pitch to the scrum Alliance was really impressive. He uses that card technique, he did that technique as his presentation to the board. Yeah, that’s awesome.

Speaker: Miljan Bajic 50:01

So for people that are not familiar, Howard is the CEO and the Chief Product Owner scrum Alliance. So when he communicates to our community, it’s via video, and he doesn’t have any slides. It’s on these little cards with couple of words on them. So yeah,

Speaker: Pete Behrens 50:19

Yeah. So unfortunate though, I think, and I’ve seen this, I’ve been predicting this for the last five years. Scrums commoditizing. And that’s part of my reason for getting out of Scrum .I think, okay, there’s enough people that can do that. So what’s the next wave? Well, I believe some of this wave we’re seeing right now is we’ve got to focus on leadership, we got to focus on the organization, we’ve got to focus on the systems. And those are becoming more complex, they’re more remote, they’re more global, they’re more dynamic, we’re seeing faster, you look at the auto industry cars go from a six to seven-year cycle, from design to deployment down to now two to three years. So we’ve cut that in half. That’s huge pressure, right?

How do you get a system, that’s been working forever to restructure like that, or you’ve got a medical company that basically has been built on two, three-year hardware cycles of diabetes pens, and all of a sudden need to go into two three months cycles on software for the pens that updates the data so they can manage the data. So you’re talking about massive shifts in the way business is done. And scrum’s a tool and agile is a tool, but that the system, how that system works? That’s to me where the meaning and the purpose is. And I don’t think there’s an answer there. I don’t think there’s a one way to do that. And that’s why it’s a fun space to be operating in. As a coach, I really enjoy the complexity. And I really enjoy the co-creation that we have with our clients.

In fact, I’m working with a medical client right now that’s going through that hardware to software process. And one of the senior leadership said Pete’s you’re not like most consultants. So yeah, how is that? Well, most consultants come in, and they sass and then they give us recommendations. And so they, yeah. And she happened to be going through, we’re teaching the class at the same time, because our philosophy is, we’re not coming in here to tell you how to do your business. We’re coming here to teach you leadership, and help co-create with you and your business. And so our engagement model matches our teaching style. And so as you start to see, what I’m trying to be is trying to be more catalyst. I’m an outsider here, I could tell you what I think, but that’s one data point.

You’ve got a lot of really smart data points in this room, just like you said, in our cohorts, there’s a lot of smart people there. If it’s only the teacher teaching, you lose a lot of data. Same with the organization. Yeah. So I think it’s about bringing out that power that’s already in the organization. It’s about, there’s going to be a whole subsystem of AI most of these jobs are going away. It could be at some point programmers go away. So what are you getting into now with having a living wage or just get into that concept of jobs are optional. Does everybody have to have a job now? So, I do believe that’s where some societies will continue to head and, many jobs, white collar, blue collar, etc., will continue to be mechanized automated.

Speaker: Miljan Bajic 53:52

It [inaudible 53:53] that’s why, it’s tough to guess or there’s, it is a guess and it’s tough to understand how things will change because it’s all complex and dynamic. But I definitely see those things changing. What would you recommend to maybe Scrum Masters and people that are aspiring to get better at understanding leadership, agile leadership, maybe as a last thing here? What would you recommend to them? Or maybe as far as, if you were in their shoes, what would you do? Obviously, again, it context matters, but is there anything that you would like to share?

Speaker: Pete Behrens 54:45

Yeah, well as a good coach consultant. I’ve always got an opinion. I found, so when I go back to what what’s helped me the most, I find ,I learned the most when I can learn something outside my systems, so I think actually going to scrum gatherings, going to Agile classes, is very limiting for many people and isn’t going to really shock you that much or create that much change. There’s a few and we like to think our program is starts to bring that in, but what our program is doing is actually trying to bring in some of that outside versus so bring in leadership, bringing culture, bring in change. So studying those different elements, change management, organizational development leadership, meditation mindfulness, I mean, there’s a huge swath of things to think about how humans, how organizations systems work. That, to me is, where I think if you’re in that, I like process, and I like to improve systems, that’s where I would encourage people to explore.

And that’s one of the reasons I’ll put a shameless plug in here. We started our podcast called relearning leadership. And the reason yeah, the reason we did that is our whole goal here is that I think all leaders need to continuously relearn, all leaders need to rethink how we’re doing things today, because it’s going to change in the next six months, nine months, few years. And so we’ve got to be on that same growth curve. And so our goal with three learning leadership is to bring in interesting problems, how are we thinking about them, and then help leaders understand maybe how they could apply that in their world and connect some of those dots for them. So just explore outside your bubble is my recommendation.

Speaker: Miljan Bajic 56:46

And it seems like relearning leadership is also all about awareness, because it’s a constant re-evaluation and being aware of what’s going on. So that’s a really cool way to look at. I don’t know if you guys intended that. But that’s when you were describing it. That’s at least what I saw. What I’m interpreting it is.

Speaker: Pete Behrens 57:07

Yeah, well, there’s so much creativity that’s going out there. And the latest podcast episode we have, , which is awesome is rethinking the procurement process with Lean agile procurement. We’ve got another one coming up with how do we do what’s called participatory budgeting. So getting the community involved in the budgeting process, not just giving feedback, but actually bidding and saying, let’s buy this or this. So it’s, rethinking all of these systems in different ways. And that’s what’s fascinating to me. And that’s like you, what keeps me engaged, is all this creativity that’s going on in the world and finding different ways to do the problems we’ve been faced with for decades.

Jon Kern: Agile Manifesto, Scaling, Cow Tail Squeezer | Agile to agility | Miljan Bajic | #25

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: Team formation, Dynamic Reteaming, Change | Agile to agility | Miljan Bajic | #24

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.

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

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.