Josiah Renaudin: Welcome back to another TechWell interview. Today I’m joined by Bob Galen, an agile methodologist, practitioner, and coach, as well as a speaker at this year’s STAREAST conference.

Bob, thank you so much for joining us. First, could you tell us a bit about your experience in the industry?

Bob Galen: Well, something I’m quite proud of is my affiliation with TechWell. I’ve been speaking at your events since 2000. I started talking about software management and development, then sharing on testing topics at the STAR series. I consider myself a “partner” with TechWell and really have enjoyed the ride.

My experience is relatively broad across testing, development, project management, and leadership. I’ve served in senior leadership positions for over twenty-five years in development and testing roles. You could say that I’m seasoned and some say that I’m fairly salty.

I think the breadth of my experience, both in the trenches and in leadership, distinguishes me from many consultants. There literally are very few situations and challenges that I haven’t seen and overcome over the years.

As agile unfolded, I’ve was an early adopter and champion of those approaches. Both as an inside leader and an outside consultant. The people-matter focus of the agile approaches is what resonates with me most, as it aligns with my own leadership style.

Josiah Renaudin: Your keynote is about leading in a way that promotes the growth of your team and not just yourself. Do you find software testing has been a pretty singular, almost selfish career up to this point? Have testers been taught to be more focused on the tester, rather than the test team?

Bob Galen: I think all roles in software teams have been focusing on the role (organization structure, silo) rather than the team, the business, and the results. It’s a side effect of our waterfall approaches, which placed an emphasis on role-by-role or activity-by-activity work planning with handoffs as the model for delivery.

While you can approach things this way, it didn’t foster teamwork across the silos. Instead, it reinforced "us versus them" behavior all along the delivery pipeline. From that perspective, thank goodness that agile emerged as a different approach.

Nowhere can this be seen more clearly than the divide between “developers—them” versus “testers—us.” And this divide is still alive and well today, even after twenty years of experience with the agile methods. It’s certainly a testament to the resilience of waterfall structure and thinking in our organizations.

So yes, testers have been focused on the tester, then the test team, before thinking of a broader notion of team. Sure, we’re slowly evolving away from that, but far too slowly for my taste. And this keynote is intended to try and nudge us all along this evolutionary path.

Josiah Renaudin: Can it be difficult for testers to strengthen both themselves and their teams, since you often can’t take that team with you if you get a better offer at another company or want to create a startup? By focusing on yourself, you’re investing in your own future. By focusing on your team, aren’t you just investing in your current job?

Bob Galen: I don’t think so. There’s an old adage or quote that says, “To be a good leader, you have to be a good follower first.” And I believe it’s true.

The ability to work well in teams, collaboratively and successfully, has become the new normal for most technical workers. No longer is it the case that you stand out simply on your own skills and merits. Sure, you count as an individual tester or test leader and you should develop yourself. But the real differentiator is how you work in groups, in teams, and how you contribute and influence those teams towards excellent delivery, delivery of results—not your results, but their results.

Even in a startup mode, it’s not simply about the brilliant founder. Sure, they get the ball rolling. But sooner rather than later, they have to scale their organizations and they need to start forming highly performing teams. Another aside here is that, if you’re a solid team member, often you establish a network of colleagues who respect you. Often, you’ll run into these folks again in new companies, or as referrers for other position.

The reality is: Software development and software testing is now a team sport, whether you like or accept it or not.

Josiah Renaudin: What are some techniques you’ve learned throughout your career to help trust your team? As a leader, can it be difficult to put trust in other people and not just want to do it yourself?

Bob Galen: I don’t know if there’s a specific technique or not. I think there’s a fundamental shift that needs to occur in every good leader from: You’re doing things yourself or directing, towards delegating, mentoring, and coaching others to do those things. Trust needs to be a part of this shift. I honestly think that trust is a choice for each of us. Sure, it’s hard to trust others. We have to show vulnerability. We have to be willing to allow for different approaches. We have to be open to failure. In a word, we have to “let go.”

Using an agile team example, I’ve seen that there are two phrases that are incredibly hard for developers, testers, teams, and leaders to say. They are "I don’t know" and "I need help." Trust is wrapped around the cultural safety that exists for someone to admit to those two statements, and by so doing, activating others to help.

Josiah Renaudin: What are the qualities of a good storyteller in the world of testing?

Bob Galen: The initial goal is to simply share your experience. Don’t try to copy someone else’s storytelling. Find your own style and leverage your own experiences.

I think one of the challenges is mining your day-to-day experiences for stories. Often, we’re just going through the motions and not really observing and learning from what is unfolding around us. Good storytellers are observers who like to share.

The second quality is practice. Essentially, you can improve on anything, so if you want to become a good—great storyteller, then you need to tell your stories. Often!

Next, I think, is the ability to visualize. You want to paint pictures with your narrative so that your audience can get connected to your story and visualize what you are saying. One great way to do this is to connect the stories to your audience’s lives.

For example, if you’re trying to communicate a Severity 1 bug to your senior VP of sales, you might want to describe the bug with a story. Share how the customer can experience the bug. Under what business circumstances. And then describe the impact to them. If the bug is in end of month reporting, and it’s the end of the year, then your CFO customer is exposed organizationally. It’s not just a bug, it’s relates to their credibility within their company. Share that as a way of amplifying priority and lighting a fire under the team to fix it.

Josiah Renaudin: How difficult can it be for a leader to adapt to new technologies in the testing world? I’m sure there were some hard transitions when mobile was first coming into prominence.

Bob Galen: I don’t think it’s that difficult. Well, it might be. Let me start this way.

I think there are two parts to change, technical learning and then simply being willing to put in the time. One is related to new technologies and may require extra effort by dinosaurs like myself to fully understand and grasp the implication to me, my teams, and my organization. But I sometimes view that as the easy part.

The harder part, at least to me, is viewing yourself as a continuous learner. Making it a part of your DNA to constantly, relentlessly, and curiously learn your craft. I think if you have that mindset, then adapting to change, while hard, is a natural process in your own personal journey.

Josiah Renaudin: Can you explain how stepping aside in your own leadership journey is necessary to empower your teams?

Bob Galen: Well, first of all, you don’t have to step aside. If you want traditional teams who follow your lead, then don’t change. You’ll get the same results you always have. And you might notice that the capacity of your teams to deliver is directly proportional to the amount of time and energy you have to lead them.

But if you want teams that exhibit: more initiative, empowerment, accountability, engagement, self-direction, and fun; then stepping aside usually allows for this. These are among the attributes of high-performing, self-directed agile teams. And being these attributes, these teams typically deliver more results, far more, than their directed counterparts.

And stepping aside does not mean that you’re not leading. To the contrary, I’ve always felt that this style of leadership requires more of you. It’s situational and subtle. Often you have to decide when to step in and when not to. If you step in too often, then you’re not going to get the self-directed attributes that are so powerful. But if you don’t step in at all, then the results are impacted as well. It’s this balanced leadership approach that we’ll explore in the keynote.

Josiah Renaudin: More than anything, what central message do you want to leave with your keynote audience?

Bob Galen: First that leadership isn’t just for folks with “leadership” in their title. I contend that in team environments, we’re all leaders—from the most senior of executives to the individual testers on teams. There are opportunities presented to us every day to provide leadership. So, we all have to make positional choices. When do we lead from the front, side, and back? How often and in what situations? And the ultimate measure, are our colleagues and team members growing as a result?

You hear the term servant leadership used quite often to describe the style of leadership best suited to develop agile teams. Here’s a quick quote from Robert K. Greenleaf that describes it: “The servant-leader is servant first … It begins with the natural feeling that one wants to serve, to serve first.”

The funny thing is that Bob Greenleaf was a CEO in the 1960s. We all think of this leadership style as being new. But it’s not. It’s simply hard to do.

An agile methodologist, practitioner, and coach, Bob Galen helps guide leaders and teams in their pragmatic adoption and organizational shift toward Scrum and other agile methods. Bob is often called “a Coach of Coaches” because of his deep and broad experience in the agile arena. He is director, agile practices at Zenergy Technologies; president of RGCG, LLC; and a frequent speaker at international conferences and professional groups on topics of agile software development. Bob authored Three Pillars of Agile Quality and Testing, Scrum Product Ownership, and Agile Reflections. A prolific writer, blogger, and podcaster, Bob can be reached at [email protected] or at LinkedIn.