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.