Cameron Philipp-Edmonds: Today, we have Bob Galen. He is an agile methodologist, practitioner, and coach based in Cary, North Carolina. Bob helps guide companies in their adoption of Scrum and other agile methodologies and practices. He is a frequent speaker on software development, project management, software testing and team leadership at conferences and professional groups, including our very own STARCANADA, which will be April 5 through April 9 of this year. Now Bob, you are speaking several times at STARCANADA this year, including “Team Leadership: Telling Your Testing Stories.” That harps on the ability of being an effective communicator. My first question is: storytelling is a key component covered in this tutorial, why is that?

Bob Galen: First, thanks for having me Cameron. I really appreciate you doing the interview.

Storytelling. I think as leaders we’ve gone from … I started leading teams in the mid-80s and we didn’t tell any stinking stories all we did was tell people what to do and we expected them to do what we said without any context. I want you to do an interview with Bob Galen and do it now. I think, that context, over time, maybe, it motivated people back then and it was good enough. I think today it’s not good enough to drive people to understand what we want. It’s not a very good vision setting and a mission setting.

I think leaders today—test leaders—we need to not only tell people what to do, but we need to provide the why behind it. Why are we doing it? What’s the goal? What are we trying to achieve? What does success look like? What does done look like and what does success look like?

A really good vehicle for doing that I think is stories. You can tell, for example, stories of what does success looks like? From your point of view—what does a successful interview look like? It looks like this, Bob Galen didn’t stutter. He didn’t fall—he wasn’t surprised. He had a compelling set of descriptions to tell, et cetera. You can have a story of failure. You can also look at the anti-pattern side and say this is not what we want to do.

We don’t want to produce a magazine like Better Software—we don’t want to produce a version of Better Software that doesn’t sell any or it only has one reader. That would be the anti-pattern. I think storytelling is a really good practice nowadays for leaders to really drive their teams. Drive is wrong. To compel their teams, to lead their teams, and to inspire their teams is probably a better term—in the right way, towards where we want to go as an organization.

CP: No, that makes perfect sense. Are there any famous people in the industry that do a great job exhibiting those qualities?

BG: I don’t know about industry… Jobs… I don’t know if you’ve ever seen any keynotes. Everyone jumps on the Steve Jobs bandwagon, but I do think if you ever watch his product—his announcements from an Apple point of view. He was a great public speaker, he was a great storyteller, he was a great presentation artist of being. Simple presentations that were compelling. I think he is a great example out there, that you can actually go on YouTube and look at some of the ways he handled himself.

Not trying to be too political or a partisan but President Obama strikes me as great. If you remember when he was running—whether you are a republican or a democrat—I don’t care. He could weave a tale. He had passion, he had examples, and at State of the Unions, very often, he would do that. He does a nice job of painting a picture, or painting a landscape of where we are now and where do we want to be? I think those are two examples that we can learn from.

CP: Those people are very charismatic. Is it possible for someone who is more introverted to be a good storyteller and be able to have a position of power and influence without being a good storyteller?

BG: I don’t know if it’s a requirement to be charismatic or to be an extravert or an introvert, I think you just want to try.

CP: The other tutorial, “Seven Keys to Navigating Your Agile Testing Transition” is about adopting and staying with the decision to go agile.

BG: Not that I’m trying to turn developers into testers but it’s that whole team mindset of knowing. It’s what can I do to get the job done? What can I do to get high quality software out the door as a team member? That’s one of those transition mindsets. It’s a hard one to get, but it’s really crucial to get it. You’ll know it when you get there because it produces results. It really produces cohesion and teamwork and it gets the right results.

CP: Can you give us another one of the seven keys to navigating?

BG: There is one of those I forget them in the Agile Manifesto, there is this manifesto, in one of the manifesto points it alludes to working code is more important than comprehensive documentation. People have looked at that and said: “we don’t need to write any stinking documentation, all we need to do is produce code.”

A lot of teams get that balance wrong, particularly testers in agile teams. They start feeling pressure to—what—not plan. We don’t write any test plans, or we don’t write test scripts and test cases—things like that. What I try to influence in the workshop is—while we want to lean the documentation—we want to be lean in our planning and we want to be lean in our test case development. We want them to be valuable, just enough documentation, and just on time.

It doesn’t mean that we don’t do it at all. In fact it’s incredibly important to write things down, believe it or not, and I think it’s agile to do that. It’s almost un-Agile not to write things down if your context says to write it down. I’ll give you an extension context, let’s say you and I are working on a distributed team and we have some team members in India and we are twelve hours away from each other. I think our job is to write more down as a communication mechanism between the both sides of the project and there is nothing wrong. In fact it’s healthy to do that from an agile point of view.

We don’t want to over document, if you will, and we don’t want to over rely on the print—the documentation or the phone. Or we want to get on Skype like you and I are. We want some face-to-face communication. We want to be balanced in that. That’s one of those patterns that I try to put to rest in the workshop.

Actually while I’m here it’s not seven keys, I kept the old title, the original title was seven I’m up to fifteen now.

CP: Oh wow that’s much better.

BG: For the attendees: if you are looking for more bank for your buck you—are getting almost twice, in fact more. You are getting slightly more than twice your keys for your dollar. Please come to the workshop and we have at least fifteen keys to go through.

CP: That’s fantastic. You also have a book out. Scrum Product Ownership: Balancing Value from the Inside Out. And that focuses on putting the Scrum team first, putting a strong emphasis on collaboration. Is it really possible to have a great product without that collaboration?

BG: I think there are cases historically where folks have produced great. The original IBM PC predates a lot of the agile activities and folks were communicating via documents and things. That was groundbreaking. The early Macs were groundbreaking.

Is it possible? Out of a thousand projects—to deliver a few compelling projects without this dynamic agile collaboration? I think yes, but it was uncommon. Those were uncommon teams and uncommon projects and uncommon companies. I think what you are trying to do is to create more successes and collaboration, I believe, is the way to do that.

It’s collaborating across functions and across silos, it’s having respect for the product and the product owner. It is that voice of the customer. That balances against the team, the owner of the design and what problem are we having. How do we solve the problem? The product owners—they are in charge of the “what are we trying to do and what problem are we trying to solve?”—from a customer point of view. The team comes in from that point of view of how do we solve it?

How do we deliver a high quality product? How do we deliver a high quality design, that balances? Using Scrum terms, the ScrumMaster is the conductor, if you will, or the coach to make sure that there is this healthy tension between product and team.

Then you get, I think, those best sharpened products. The emphasis there was healthy tension as opposed to historically there were those unhealthy tensions. That I think is behind us. Hopefully that’s starting—that dynamic—that unhealthy threatening dynamic is behind us and we are getting much more of a customer centric, and very lean. Just enough of: what problems, what does the customer and what are their challenges and how do we creatively solve them?

CP: That’s very good. There is a lot of fantastic great points you talked about. Anything else you would like to say to any people who are looking to go to STARCANADA this year?

BG: I say come and collaborate. All the STAR conferences, or SQE conferences, I think they are very—well the speakers are—approachable. We want to be approached. It’s boring if no one talks to us. We are people too, we are not machines. We are people, so talk to us. We are there to network and we are there to help.

All of the speakers that STAR brings in are some really top-notch speakers and we really have that mindset of being servants, I think, to the attendees and trying to do whatever we can to help folks out. I would encourage attendees to come to my workshops—or to any workshops really—and engage the speakers. Engage your colleagues there.

Network and learn as much as you can. Really the value is on you. It’s sort of as if there is this wonderful landscape of things and opportunities but you have to do it for yourself—for the opportunities.

Going back to one of your early questions, even if you are an introvert and you hate walking up to someone and you are concerned about bothering them. Overcome that, at least for the three days of the conference, and overcome that. Leave that fear behind you and just put yourself out there and see what you can learn.

CP: All right. Thank you Bob. Once again, that was Bob Galen of Velocity Partners and he will be at STARCANADA, which is at April 5 through April 9 of this year. Thank you so much Bob.

BG: Thank you Cameron. Bye now.

 

An agile methodologist, practitioner, and coach based in Cary, NC, Bob Galen helps guide companies in their adoption of Scrum and other agile methodologies and practices. Bob is a principal agile evangelist at Velocity Partners, a leading agile nearshore development partner; president of RGCG; and frequent speaker on software development, project management, software testing, and team leadership at conferences and professional groups. He is a Certified Scrum Coach, Certified Scrum Product Owner, and an active member of the Agile and Scrum Alliances. In 2013 Bob published Scrum Product Ownership–Balancing Value from the Inside Out. Reach him at [email protected].