You know how some topic will come up, and suddenly you notice it’s coming up over and over in different contexts? Lately, for me, that topic has been collaboration among roles on software teams.
My own team practices a “Whole Team” approach to development, and we testers work closely with the developers on a daily basis. Still, testing and support (all three of us testers do both) are, organizationally, a separate team with our own manager, who reports to the same director as the development manager. On top of that, our company didn’t even have testers before it hired the first tester on our team. Except for our team, which works exclusively on a software product, our company builds software for clients. The teams all do test-driven development, and automate tests all the way up to the GUI level. The clients’ testers help with acceptance testing. Testers have been hired on a contract basis, but not as permanent team members. So, there hasn’t been a culture of having testers, or really any people in different roles, on the project teams.
The developers on our team often express their appreciation for having testers on the team, we feel welcome. We generally collaborate well. And yet, there are impediments. Like all teams, we’re juggling many priorities. What’s important from our tester perspective might not match the top of the list for coding or for the product owner.
We continually think of experiments to work more closely with other roles on the team. For example, I got to pair with developers to write and automate customer-facing tests to drive development of our new API version. I found it hugely productive, but the team decided it was better overall to have me specify the tests on the wiki, and have the pair coding the story automate the functional tests. That’s why we experiment, to learn quickly what works best for the team.
More recently, we testers met with the designers on the team to brainstorm ways we could help each other. We now have some collaboration experiments underway that we think will improve the user experience while helping us think of more test scenarios.
I meet many testers who feel isolated from other roles on the team. They want more collaboration, but organizational or physical barriers get in the way. How can these testers find ways to work more closely with programmers, analysts, designers, business experts, and others? I think one component is finding better ways to share knowledge and help people learn so they can communicate. For example, testers with technical awareness, who know programming basics, understand their product’s architecture at a high level, and use an IDE and source code control daily, find programmers much more willing and able to communicate with them. As Rob Lambert has pointed out, these T-shaped skills help us overcome a phased approach to software development. Jesper Lindholt Ottosen recently suggested ways testers can organize and recognize our skills.
If you have testing problems you’d like to solve, think about who else besides the testers might be able to help you solve it. Though everyone gets involved in their own problems, you all have a common goal: deliver software that delights your customers. You’ll probably find that if you ask someone in another role for help that they’ll be eager to brainstorm possible solutions with you. At the same time, find ways you can help with other peoples’ problems, even if it means stepping outside of traditional “tester” activities. Pete Walen recently pointed out some non-traditional ways testers can understand business needs better. I personally think that blurring the boundaries between roles and bridging the gaps is the best way to advance the art and craft of testing.
I’d love to hear how other people have bridged the gap between different roles involved in producing software. Please add a comment here, or email me! Janet Gregory and I would love to have stories about this to include in our new book. Examples of how testers can collaborate with other roles will give those testers who feel isolated ideas they can try.
I hope this topic will come up in my “Advanced Topics in Agile Testing” workshop at Agile Testing Days. We’ll have a great group of people who will forge some new frontiers in testing!
5 comments on “Advancing collaboration”
Great topic. I’ve just finished a round of one-on-ones with my test team at Datacom, and this month a topic I’ve explored with them all is our relationships, understanding we don’t just have a relationship with developers which involves “here are some bugs for you to fix – you got stuff wrong again”.
We’ve been exploring what that relationship with Business Analysts, Programmers, Project Managers should be – what do we need from them? What do they need from us?
Like my surname there are three core methods for collaboration – 1) talking, 2) talking and 3) even more talking. And it has to be two way – you speak I listen, I speak you listen.
But to have meaningful conversations I think we need to junk email. We’ve got fixated on using it because it CYA, giving a paper-trail of who said what. But whilst email is great for sending out complex technical details, it really fails as a communication tool – how many “flame wars” do we see when we do down that route?
If you’re on the same floor, just go and talk. If you’re in different buildings book a meeting. If you’re in different cities, pick up the phone (oh okay there’s Skype as well). If they’re not in, send them an email, but use it just to say “can you phone me when you’re free”.
Conversation happens in real time – you can listen and enquire as I talk, and visa versa. And the great thing is – NO BACKLOG. No striving for INBOX(0) …
I agree wholeheartedly! Thank you for making that point
I think a lot of us who work in software are on the shy or introverted side. Emailing can seem appealing – especially if it’s a difficult conversation you’d rather avoid! We have to be disciplined and use the most direct and complete communication we can. Then, we can write up notes from that conversation and stick it on the wiki or note it on a user story card.
Testers find problems – they analyse them, investigate them, maybe even suggest solutions. However typically on project they don’t fix them. That means they have to “sell” those issues to someone else to persuade them they’re important enough to address.
So to me, communicating is the core of testing – it’s getting over how the problems happen, and how important they are.
The fact that “developers on our team often express their appreciation for having testers on the team” means you’ve addressed two HUGE hurdles – 1) the whole “one team” that testers and developers feel like they’re fighting for the same thing rather than against each other and 2) that you are demonstrating that there is a specific skillset that tester have which “adds value” and isn’t a mindset “just anyone” untrained could deliver.
If you can determine how you’ve managed to pull these two things off, congratulations, you’ve found a method of Agile Alchemy!
[…] 1) Advancing Collaboration […]
[…] of the ways to get this is to have a Whole Team approach in which everyone writes and runs the tests. The business facing people can define test […]