Month: November 2023

A look at some of the best database and RDBMS tools for Java software developers. Learn more about Java and database programming.

Java developers often rely on specific database tools to efficiently manage data storage, retrieval and manipulation. In this tutorial, we explore some of the top database tools for Java developers, specifically Grails, Struts, Java DB and MongoDB.

Jump to:

Final thoughts on top database tools for Java developers

Tools like Grails, Struts, Java DB and MongoDB provide essential abstractions, interfaces and functionalities that abstract the complexities of database management. From GORM and Hibernate in the Grails ecosystem to JDBC and Spring JDBC in Struts applications, these tools empower developers to interact with databases effectively. As the software landscape evolves, staying up-to-date with the latest tools and best practices is essential for successful Java development.

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie with InfoQ Engineering Culture Podcast. Today I’m sitting down with Dion Stewart and Joel Tosi. Dion, Joel, thanks for taking the time to talk to us today. My normal starting point is who’s Dion? Who’s Joel? So let’s start with Dion. Who’s Dion?

Introductions [00:23]

Dion Stewart: Hi, Shane. Thanks for having us. Yeah, I am a developer/coach. I started off my technical career back in the 1990s as a small talk developer. I learned small talk at the University of St. Thomas in St. Paul, Minnesota from a guy named Dave West. One of the reasons I bring that up is there are some InfoQ articles about Dave West and in particular an experimental program that he initiated at Highlands University in New Mexico. So I think there’s a couple articles on the InfoQ site still about that. That’s pertinent because that apprenticeship program that he ran has a lot of similarities with this Dojo model of experiential and immersive learning that Joel and I have been part of.

The other thing I’ll say about Dave West and my experience at the University of St. Thomas is this predated Java. So at the time, there were really only two games in town for commercial OO development, C++, which a lot of Smalltalkers say isn’t really OO. But anyway, that and Smalltalk. Dave was bringing people like Ward Cunningham and Kent Beck and Rebecca Wirfs-Brock, these luminaries onto campus. And as a result of that, I got exposed to test-driven development and continuous integration and some other practices that eventually made their way into extreme programming. I was exposed to them even before extreme programming was a thing.

In the ’90s, I was purely a developer. In the early aughts, I kind of moved into this player coach role where I would be put on teams as a developer, but I was also sort of nudged with a wink, “Hey, teach these folks automated testing and TDD and some of these other practices.” Around 2010, I started full-time coaching. I coached for David Hussman. Sadly we’ve lost him now, but he had a company in Minneapolis called DevJam. That’s where I met Joel. And around 2015, Joel and I were part of this thing called the Dojo at Target, which I’ll leave that for later. We’ll get into that.

And then the last thing I’ll say is my partnership with Joel, we’ve written two books. The first one was on Dojos, it was called Creating Your Dojo. And then the one we released earlier this year is called Coaching for Learning.

Shane Hastie: Welcome. Joel?

Joel Tosi: Typical engineer by trade. Spent the early 2000s with a mercantile exchange in Chicago, so low latency, high throughput systems, all of that kind of fun stuff. Engineer manager. I was a really bad manager, but that’s beside the point. Then I went back into architect. When I was an architect for Mercantile Exchange, that’s actually where I met David Hussman. And at the Mercantile Exchange, we were trying to figure out how do we get better at some of these engineering practices. Got lucky and met David. Had a great relationship there, trying a lot of ways of better engineering practices, which was always fun with really risky scenarios as well as really complex environments. When I left the Mercantile Exchange, went to Red Hat for about a year or two, was a North American architect, began kind of helping organizations design and implement systems.

When I left Red Hat, I remember speaking to a lot of my friends that are great engineers, but I always felt like Red Hat was great technology but wasn’t great products. And they’d always ask me, like, “What do you mean by that?” I go like, “I just don’t feel like we have beautiful technology. But the way people want to use it, we’re not building it how people want to use it. We’re just building really cool things.” And I think that was partially David rubbing off on me because David and I became good friends over the years. And so then left Red Hat, started working more closely with David, usually doing more of the engineering side of things, but also really just help teams understand their product and then kind of embrace more simplicity. How do we get bigger impact, but keep the code clean and make it easy for us to do things? And just really easy to build guidance into the dojos, hung out with Dion and the rest of is history.

Shane Hastie: Cool. I’d like to just take us on a slight deviation. Dave Hussman, the dude.

Remembering David Hussman [04:28]

Joel Tosi: Yes.

Dion Stewart: Yes.

Shane Hastie: An incredible man. We’ve lost an absolute genius and guy. Tell us a little bit more about David.

Joel Tosi: Oh man. I think it’s easy to tell stuff about David mostly in stories. But when I first met David, he came into the Mercantile Exchange. This had to be the first or second day he had ever been in the Mercantile Exchange. So again, Chicago, trading systems, big, all of these. Our problems are the most complex in the world, this kind of views in the world. And David sat down and he is… I’m there and we’re sitting with some executive leadership, and David just very calmly said, “I think we can do better on testing.” He gave some examples and the director of QA at the time stood up, started screaming immediately at David shaking the table, and David just leans back, puts his hands in his hair, and he goes, “I’m sorry if you feel that way, dude, I’m just telling you what I see.” And David just gave him an example. And you could see the guy get upset and then he just kind of sat back and everybody immediately listened to David because David didn’t react. He didn’t react to the emotion, he just talked to the data.

That was one of the beautiful things about David, was he would just get to the essence of the problems just very succinctly in a kind way. He could have came at this gentleman harsh and he didn’t. It was just, “Look, here’s where we’re at. I want to help, but we have to see eye to eye on this.” And just the way he handled the situations was amazing. There was plenty of other stories, and I’ll give Dion a minute here, where David loved music. And so there was times he’d call us up in the middle of the night and he would compare something to Duran Duran or Depeche Mode all the time. He would talk about teams and, “They’re kind of like Duran Duran.” And he’d have all these analogies. Just the way he saw things was so beautiful and always challenging the way we would approach problems. I don’t know. Dion probably got more stories too. I want to give him an opportunity to share.

Dion Stewart: Yeah, I think, look, we could probably do a full 40 minutes on David, but the thing that immediately comes to mind is David was both very pragmatic. Whatever the complete opposite of dogmatic is, that was David. I think David understood the essence of agility, real agility. And the other thing that kind of goes along with Joel’s point is David didn’t really suffer fools at all. He wasn’t critical. He wasn’t mean to people, but he had a way of sort of cutting through any BS. His music background I think is important as well. That’s one of the things he and I bonded on. My undergrads actually in music and I started off wanting to be a musician. I’m sure many people who listen to the podcast are going, “Yeah, me too.” There’s some affinity, meaning playing music and programming. I think there’s something in the way musician’s brains are wired that actually lends itself well to programming or maybe the way our brains become wired by learning an instrument and learning how to play music.

Anyway, David was in this heavy metal band in the ’80s. They made it all the way to Abbey Road, recording an album. They had videos on Headbanger’s Ball on MTV. He was also Prince’s Guitar Tech for a while when he lived in Minneapolis. The reason I bring all of that up is David really understood the value and sort of the necessity of building communities. So he was really instrumental in building a community in Minneapolis of people who really cared about delivering quality products, digital products. And then even within all the organizations that I coached at with him, a lot of the discussion was around how do we build community within this organization? Yeah, we’re working sort of on a team by team basis when we first go in as well as with leadership and stakeholders, but really we’re trying to foster a community here.

And I think that’s probably the biggest hit to not only the Twin Cities community after we lost him, but a lot of the organizations that he worked with. Before he got sick, he was starting to really try to build up and foster a community around chaos engineering. He saw that as being sort of this next wave of interest or a place to build a community that was really going to take our industry to the next level. There was an event in Minneapolis, Norah Jones spoke at it. I think Casey Rosenthal. I’m trying to remember.

Joel Tosi: Kent Beck was there too.

Dion Stewart: Yeah, Kent was there. Kent didn’t speak. Kent was just interested, right?

Joel Tosi: Yeah. Yeah.

Dion Stewart: And David, now that you’ve reminded me that Kent was there, Joel, David made a comment that he was at some of the very early XP conferences. I think one of the first ones was over in Sicily, and he talked about the community again and the vibe and the willingness to share ideas and experiment among the people in that group. He said that this chaos community that was just starting was the first sort of community that reminded him of that experience and felt like it had the same energy and that it could really become this thing that, again, changed our industry for the better. I think chaos engineering is moving along. It’s certainly not growing in the ways I think David anticipated or hoped. It’s not surprising because it’s one of those things that’s hard and our industry tends to adopt the easy stuff.

Shane Hastie: Thank you. Yeah, just an opportunity to remember somebody who really has had a huge influence on very many of us, and that Dojo, that learning, his generosity in building community, inviting people in.

So that does lead me to Coaching for Learning. So you are technologists, you are technical coaches, you are helping people get better. Now you’ve written it down in a book, so what’s there that can be written about?

Coaching for Learning [10:30]

Joel Tosi: That’s a great question. So as I’m sure some of your listeners could attest to, as well as Shane, some of the ideas around coaching for learning are difficult to codify. Coaching to a process is more how do you follow a playbook? How do you follow a recipe? What are the things you tell people to do. When you’re coaching technologists for learning and how to be aware, it’s definitely more difficult to codify. In the book, we try to go through principles as well as why these principles are important, why the techniques are important, and then we try to give examples to help coaches think about when there are trying to help teams learn what to look for and how to approach it.

So some examples, and I had this conversation this morning with a technical coach that’s trying to help teams learn, we were talking about the hard thing for technologists is to want to go right to the answer. And especially as coaches, we wanted to say, “Here’s the answer, let’s go do this.” And I see a lot of technical coaches struggle with that balance versus, “Let’s capture the problem. Let’s capture the impact the problem is having, but let’s also be open to the ideas that there are potentially multiple ways of solving this problem.” And if we only explore one, but not only are we robbing ourselves of the opportunities of others, it’s really hard for us to say this is the right answer because we can’t say what the drawbacks are. And so when we’re thinking about how to codify this, especially in the book, we’re trying to just give perspective and principles around what you could do and should be thinking about.

Dion Stewart: The only thing I would add at a high level without digging into the weeds on principles and roles that we view coaches should have essential roles, I would say that Joel and I were doing a lot of coaching prior to this Dojo model. And as much as we were trying to help people learn how to have better products, higher quality, more effective ways of delivering, the emphasis was always on delivering, right? So it’s like you’re going to come in, you’re going to do the coaching, and then you’re going to help this team deliver the product. And it seemed like many times there’d be moments where we’d want to take the learning a little bit further and there wasn’t time because we had to get onto the next story or the next sprint and the next increment.

One of the things that Target did that I can’t give them enough credit, it’s amazing that an organization who was sort of experiencing some problems at that time with their technology stacks, that they invested in learning as much as they did and they created this space called Dojo, which we were around at the beginning of and sort of co-created with them, helped them create it. But the credit to them, their leadership and their stakeholders, for saying that, “We’re going to invest in our people. We’re going to invest in developing their capabilities. We know we’re going to take a hit in the short term in terms of productivity, for lack of a better word, or output.”

Making time to learn while delivering [13:18]

One of the principles for coaching for learning is for a time box period of time, the emphasis is on learning over delivery. So delivery takes a backseat that really shows up in cases where we might actually complete something, but maybe there was some differing of opinion on what the best technical solution might’ve been, in which case we’ll say, “Okay, now let’s go build it the other way and then we’ll have two real working solutions and we can have this discussion.” That kind of thing typically wouldn’t happen on a normal coaching engagement prior to this Dojo model, which we’ve been doing for a while now,

Shane Hastie: Tell us about the Dojo model. What’s special about it? I’m guessing it comes from martial arts just because it’s called a dojo, but what does it really mean? And if I think of one of our listeners, somebody who is in a senior technical position wanting to support others, what do they need to know?

The Dojo Model [14:14]

Joel Tosi: Conceptually, it’s learning in the flow of your work. That might sound kind of fuzzy or nebulous, but we’re learning new techniques and we’re focusing on learning while we’re building our product. And so, why that’s important, prior to doing a lot of this type of coaching, Dion and I, we taught two-day courses. We’re going to teach you TDD, we’re going to teach you at DevOps, we’re going to teach you CI. We’re going to teach you all these things. And everybody did great in all of the classes, not because Dion and I are great, but because, look, in controlled environments without the constraints of your organization, learning new techniques are easy. Without legacy code, writing that first test is easy, right? Without learning how to refactor and look for seams and look for ways for decoupling, these techniques are easy.

So the Dojo fundamentally is about learning new techniques with your code base, with your product, with all the challenges it has with all the constraints through your organization. “You want to learn how to do test driven development? Cool. Let’s start with your code base. What’s the simplest test we could do? Do we need to refactor something to get there? Let’s do the refactoring. Let’s try the test a couple different ways. What’s hard about that test?” And then we pause and we talk with the team, “What was hard about that experience? What do we want to try next? What ideas do we have to make it easier next time?”

And so it’s about getting in this way of learning and the way of approaching your products that’s continuously looking at how do we make it easier? What techniques could we learn that we want to try, but in the context of our actual work? If we want to learn how to do automated deployments, we’ll do it a piece at a time, but it’s got to be our deployments and our constraints in our world. Otherwise, the learning isn’t as sticky. So a Dojo is the team learning together within their constraints.

Dion Stewart: Just filling in some of the backdrop for Shane and to answer his questions, yes, it absolutely is a martial arts term. So the story behind Target’s Dojo, and at a certain point in time we had visibility to 50 different companies that were doing these, but let me go back to Target. I think it was 2015, a guy named Jason Walker, a really good technologist who was working at Target at the time, attended a conference and I think it was Adam Jacob, the Chef CEO, gave a talk on Developing DevOps Kung fu. I don’t remember the exact title of his talk. It’s out on the web. You can find it. But the metaphor or the analogy that Adam was making was that this isn’t something you just go to a two-day workshop and suddenly you absorbed, as Joel was sort of alluding to. This takes practice and repetition. And like studying a martial art, you don’t just go learn the form of a particular martial art or the moves. You have to go back and practice and spar and get feedback, and this is something that takes a long time.

So Jason came back to Target. They were talking about doing something to help teams get better initially at DevOps. The other sort of funny little anecdote is I guess there was some debate internally whether or not they were going to call this immersive learning place the Dojo or the sheep dipping farm, because sheep dipping was a term that Nathan Harvey and other people were using it for DevOps, right? I’m personally glad they went with Dojo. Dojo is a Japanese word. It was used for martial arts studios or is used for martial arts studios, particularly Aikido. It’s also used for meditation halls, although Zendo is probably more common than Dojo.

One thing I want to say right now while we’re talking about this, the question of whether or not using the word Dojo, whether that’s cultural appropriation or not, has come up several times. Joel and I are pretty sensitive to that. We don’t go beyond using the word, so we don’t use any symbols of torii gates or anything like that. We don’t use other words associated with Dojo. We’re certainly not going to create any stickers like, “You’re a sensei now” kind of thing. We’ve had some of our clients elect to call their dojo something else. At American Airlines, it was The Hangar. What was John Deere’s called, Joel?

Joel Tosi: The Combine Store

Dion Stewart : I think Stellantis, Fiat Chrysler was fast track, if I remember correctly.

Joel Tosi: Flywheel.

Dion Stewart: Flywheel. Flywheel. Thank you.

Joel Tosi: Yeah.

Dion Stewart: Yeah. So I just want to call that out for listeners in case anyone is starting to feel a little tingle of irritation. Joel and I have even talked about renaming Dojo and coat it to something different. It’s a possibility in the future. The other thing I’ll say about it is there is no English word equivalent, and it literally means place of the way, which is one of the reasons it’s a little bit hard for us to sort of give it up because it is so unique and because there isn’t really an English word equivalent.

At Target, there actually was a place, so they carved out part of their campus and teams would go into that space for six weeks at a time. I think there was something really powerful about even if you were just on the floor above in the same building normally about moving down into this different space where other teams were also focused on learning over delivery for a period of time and there were a lot of coaches there working with your team, and even if they weren’t working with your team, you could grab them if one of them had a specialty and one technology or another, there was just something really powerful about that space that I think is aligned with what a real Aikido dojo is.

Shane Hastie: You mentioned that there are some key principles and you touched on one. Tell us a few more.

Key principles of this approach to learning [19:51]

Dion Stewart: I think we’ve actually touched on a few of them just sort of in passing without necessarily calling them out. So we definitely touched on learning over delivery for a period of time. Joel mentioned it’s always doing your own real world work. So it’s learning in the context of doing your own real world work. It’s team learning instead of individual learning. So one of the problems that I’ve seen over and over in my own past with some of the two-day workshops that I’ve taught is organizations will send one, maybe two team members, to training with the instruction that, “Not only do you need to learn this, but you need to come back and teach the rest of the team,” right?

There are a few examples that I can refer back to where people came in and took a two-day test driven development course from me. When they went back, they tried to teach the rest of their team test-driven development. They couldn’t get it to stick. And as a result, if not everyone on the team is practicing it, but it’s a shared code base, you’re not going to end up with automated test suite for your unit tests. So it’s full team learning. We rely on, I’ll call it ensemble programming, right? Some people might know it as mob programming. We’re moving away from that term. Emily Bache’s really prodded us to move away from that term. She’s a great technical coach if people are unfamiliar with her, but she pointed out in Sweden, mobbing means bullying. So that’s not the connotation we want to have for collaborative teamwork,.

But I think there’s something really powerful about learning together as a group. It requires some vulnerability, but I think we can safely say that we’ve seen many times where junior developers realize that senior developers don’t know as much as they thought they did, or maybe another way of putting it is they don’t know everything. At the same time, we’ve seen less experienced engineers ask really amazingly pointed questions at just the right time that make some of the more experienced people stop dead in their tracks and say, “That’s a really interesting question. We should work through that.”

Another principle, and how this sort of stacks up against traditional training is, we try to make the learning as holistic as possible and span multiple practices. Another way of saying this is if you think about the development process as being your product development value stream, we’re trying to address as much of the value stream as possible. So Target started with DevOps. They eventually did the shift left thing where they started getting into, “Okay, well what happens before code commit and what are things that we can improve upon there, including their agile processes or their lean processes?”

And then we extended all the way back into product discovery. And what we found is if you go back to DevOps, the light bulb for engineers who were new to DevOps, really seeing the power of DevOps came when they made the link that, “Hey, if I have this product idea and I can get a very bare bones implementation of it out to a subset of our users, maybe A/B testing, and I’m able to do that quickly because of my DevOps pipeline and my other practices at the right end of the value stream, that’s where the value of DevOps really comes in.” It’s this really short feedback time and being able to test your product ideas out.

Yeah, there’s a ton of value in automating infrastructure and removing air from automation that comes when humans are doing deployments at 3:00 in the morning on Friday nights and that kind of thing. All that’s good, but what we found is when you really connect a lot of these ideas across the entire value stream, that’s really very powerful. It goes back to one of the early agile principles as well about not delivering things you don’t need. It’s the principle of delivering sort of essentials and how do we figure out what’s essential? Okay, some of the other principles, there are coaches there the entire time. So you’re getting feedback.

Joel and I like to say we don’t have a content problem in the world today, right? If you look at all the sites that are offering video content, books, all this material we can consume on technology, the problem is not the amount of content. I think the problem is we consume that content, it’s one way. We think we’re learning it and we start implementing it, but we don’t really have an opportunity for feedback for someone to say, “Yeah, you’re on the right track or not.”

A couple more principles. The other one is there’s time for repetition. So we’ve talked about six weeks being a typical duration for a lot of these dojos quite a bit. The idea there is, again, this isn’t something you’re just going to learn in two days and then hopefully it becomes part of the way you work. By having this six week time period where you’re focused on learning over delivery, we found that, just sort of through experimentation, was a sufficient length of time for ways of working to change and actually stick and stay with the team.

The last principle is we want to ensure learner safety, which I’m sure is of interest to your audience. I’m sure many of them are already familiar with this principle, but the basic idea there is that Dojo has to be a safe place to learn. So if we try an idea out as an experiment because we think we’re going to learn from it, if it leads to nothing, so we think we’re going to write some code, but we realize, “Boy, this was a rabbit hole and we got to throw the code away and start over,” one of the questions we have for people who want to do this dojo model is, “What happens then?” Is the team or is someone going to start griping that they just spent days or a week trying out some new technique that didn’t pan out, that didn’t lead to fruition?

So that’s the seventh principle. That Dojo has to be a place that’s safe for people to learn, both kind of within the team, showing vulnerability to each other, and kind of admitting you don’t know certain things as well as outside the team with stakeholders and other people who are interested in the performance of the team long term.

Shane Hastie: I can certainly see those principles and how they weave together. The other thing that you did mention was there are some essential roles that need to be present. Let’s explore that.

Joel Tosi: When we’re thinking about roles, we’re thinking about the coaching hats. What book was that from?

Dion Stewart: The Silsbee?

Joel Tosi: Silsbee? Yeah, there you go.

Essential Roles [26:29]

Dion Stewart: So Doug Silsbee wrote Presence-Based Coaching, a couple books. That’s one of them. And I believe that’s the book where he had seven roles for a coach. We kind of looked at that and modeled our approach on that. There’s overlap. We didn’t copy his roles exactly, we tweaked them a bit. That was the inspiration for ours.

Joel Tosi: And so obviously one role is a teacher. If you’re coaching for learning, you have to be able to teach. So when we’re working with teams, sometimes teams aren’t familiar with the new technique or they haven’t tried enough. So by all means at a very critical role is the ability to slow down and teach a new technique for teams. Another important one is we call it like a mirror. A nice role for a coach is this idea of a mirror. And so what that means in practice is teams are used to working the way they’ve been working and they might not be thinking about what’s actually happening. And so a very important role is being this mirror and taking a pause and playing back to the team. “Are we all aware of just what happened?”

To give you an example of that, I was working with a team. An engineer came in and said, “We have this defect. I have an idea, and here’s my proposed solution to this defect.” Then he walks through the team in about five minutes and he asks everybody, “What do you think?” And they all said, “Yes, that seems like the right idea. That’s the best implementation.” I go, “Okay.” I go, “Can I pause for a second here with the team?” And they go, “Sure, what’s up?” I say, You all agreed it’s the right implementation and you all said it’s the best implementation. I’m not disagreeing on that. What do you all mean right now by best?” And so we talked about it and I said, “Share with your peers what does best implementation mean to you.” Seven engineers, seven different answers.

One person said, “It’s solved. If it’s solved, it’s the best answer. I want to get to the other items.” Another person said, “It looks like it’s easy to implement.” So I had, “It’s done.” I had, “It’s easy.” Another person said, “I think I know how to test it.” Okay, so it’s testable. Another person said… I just don’t want to talk about it. You get where we’re going here. So this idea of playing back to the team, are we talking across each other or are we building dialogue together? It could be something like that. It could be playing back to the team, “Our deployments are failing nine out of 10 times. We’re getting them done, but let’s pause and say, are we all seeing the same things? Should we do something about it?” So being this mirror.

Sometimes we also talk about of course being the evangelist for the teams, being the champion. It might be hard to believe, Shane, but some problems are outside the team. So sometimes we have to be the champion. We have to say, “Hey, we’re in this. We’re here for you. We’re in this for you. And we’re also want to talk upwards and outwards around why this is hard for teams.” And so we want to be the champion and the evangelist for the teams. Dion, I know I’m missing four more there.

Dion Stewart: I don’t know if we need to rattle through every single one of them, but one I do want to call attention to and one thing I’ll point out, we don’t have facilitator as one of the roles. Nothing against people who are highly skilled at facilitation, but we think that’s a role that’s been overly stressed in the agile space over the last 20 years. And it sort of goes hand in hand with Scrum, which I’m actually a fan of Scrum as long as you’re coupling it with technical practices, which is also the way that I was taught Scrum by Ken Schwaber somewhere around 2003. He was adamant that if you were going to apply Scrum to software development, because it’s a project management framework, not a software development methodology, if you’re going to apply it to software development, you had to do the technical practices from XP. Too much of our industry has leaned towards, “We’re going to have someone come in and teach you Scrum and facilitate the Scrum ceremonies.”

So this leads me to what might be contentious. To a certain extent, Joel and I say, you have to be a practitioner if you’re going to be an effective coach for learning. Now, does that mean that every coach has to be a programmer or technical? Not necessarily. But if you are not and the team is trying to learn technical skills, you have to pair up with another coach. So it was quite common at Target for teams to have two coaches. One would be sort of the process, the agile lean coach, and oftentimes those people would learn enough product discovery practices and develop enough skill in that that they could introduce those practices to engineering teams. So sort of an agile product coach, if you will. The hardcore product coaches are cringing right now, but I’ll come back to that. So an agile product coach as well as a technical coach, someone who’s really heads down in development, current with technology.

The other thing that was really interesting for me to observe at Target was many of their technical coaches would cycle in and out of a coaching role. So it wasn’t necessarily a long-term career move for them. They would come work with teams in the Dojo for six months, maybe nine months, and then they would go back to being a contributor on a team or maybe a couple teams as a developer, an engineer, an architect, whatever their role was. But the point is, and we firmly believe this, you cannot coach something unless you are a practitioner yourself. I think that’s one of the reasons we’re seeing kind of a backlash against agile coaching these days. Organizations have spent a lot of money on agile transformations. They’ve hired all these, in theory, agile coaches that are going to help their teams deliver better. But at the end of the day, the coaches really only know the process practices. And if anything, they’re more facilitators than they are coaches.

Old guy rant warning here, I mentioned, I started kind of coaching in the aughts. At that point in time, I didn’t even call myself a coach. I was extremely hesitant, because to me, coaches were people like Michael Feathers and Kent Beck and Rebecca Wirfs-Brock and these people who had vast experience developing software and systems. Something happened at a certain point in time. I mean, I went to one event, Shane, where it was a partner event for one of the tool vendors, one of the agile project management tool vendors, and they had just released a new version of their software, so they wanted partners to come and learn about it so when they’re working with their clients, they know it.

I was in a room with about 25 people, about 20 of them were all from one consulting firm, which we’ll go unnamed. But about 15 of those 20 people when we were introducing ourselves said something to the effect of, “I graduated from university in the spring. I got hired as a business analyst. I just finished a two day yada yada yada certification course, and now I’m a coach.” And I was just kind of both horrified and in shock. But I think we’ve sort of done this to ourselves, if you will, as an industry. I know there are groups, I see agile and other groups that are trying to put meaning behind the term coach and make it so that when organizations are hiring coaches, they know they’re getting a person of skill and value. But it’s been a problem and I think it’s why we’re kind of where we’re at today.

Shane Hastie: I have to say I’m with you there. And my work among others on the agile coaching ethics and one of the key points of that is do not say that you have a competency that you don’t. Gentlemen, thank you very much. Really interesting stuff. If people want to, first of all, find the book, just to remind us, what’s it called and where can they get it?

Joel Tosi: The book’s called Coaching for Learning: The Art and Practice available on Amazon.

Shane Hastie: And if people want to continue the conversation with yourselves, where do they find you?

Dion Stewart: dojoandco.com or we’re both on LinkedIn. A lot of people reach out to us via LinkedIn.

Shane Hastie: Thank you so much.

Joel Tosi: Thanks, Shane.

Mentioned