Cindy Yuill explains how workplace book clubs can benefit yourself and your team as software testers and developers. In a workplace book club, members get together to form a connection with others, hear different points of view, debate, learn, and get advice and support from each other.
I’m sure most of you are familiar with “book clubs,” in which participants talk about an assigned book for a short time, enjoy some food—perhaps a little wine—and then get to the heart of why they had gotten together: to form a connection with others, hear different points of view, debate, learn, and get advice and support from the participants.
These are exactly the same reasons you might form a book club at work, and doing so is not only valuable but also relatively easy. While I have yet to work at a company in which the discussions happen over wine during work hours (maybe I need to move to Europe), the “rules” of forming a book club are otherwise much the same with a work group as they are outside of work. Here are some ideas to get started:
1. Get the support of “management,” whether it be it the “boss” at home or the boss at work. Having management support gives people “permission” to take time away from their daily jobs to read the material and participate in the discussions.
2. Pick a common theme. For example, at work you might have the theme of quality assurance, agile practices, or business analysis. Outside of work, a theme might be Oprah’s book-club picks or Pulitzer Prize winners.
3. Identify participants. Don’t just invite those with similar interests; also invite those with a different perspective or an opposing point of view.
4. Give people a reason to come. You might be able to rely on scintillating conversation as the only motivator for a few people, but I’ve found that free food works pretty well in motivating those who might not otherwise come.
5. Create an environment of non-judgment. Make it clear you value everyone’s opinion and that having a diversity of opinions and conversations is the point of the meeting.
6. Encourage conflict. Instead of a book, consider starting your meeting with two articles detailing conflicting views on a particular subject. Call on people who you know who have different perspectives on the topic in order to provide their opinions. If a blow-up should happen, it will be at a place and time reserved for it, and it won’t interrupt workflow.
7. Appoint a coordinator. Appoint someone who is organized, passionate about the subject, and who can do the administrative work to keep the book club going on a regularly scheduled basis. Initially, I recommend you find a manager willing to kick-off the book club by scheduling the initial meetings and facilitating the first few discussions to show that the book club has support at the managerial level. Once it’s running smoothly and there is active participation, it’s time to hand the baton to an individual contributor who is well-versed in the subject and has a good relationship with other attendees.
8. Rotate who selects the topics. Give each participant a voice and make sure he understands his role in facilitating and moderating the meeting. When the participants finish a book or paper, end the meeting by asking for a volunteer to pick the next subject and be the next moderator.
9. Choose relevant topics. It is particularly effective to choose topics that are already the subject of hot debate in the department. People will come for the “fight” and leave having a better understanding of the differing points of view.
10. Keep it simple. For a work-based book club in which free time is rare, keep the selections short, concise, and easy to understand. If the book is long, consider covering only a chapter per meeting. Also, consider varying the content delivery method; you might consider webinars or discussion group postings.
11. Encourage, but do not require people do the reading. Although conversations are generally better when everyone has read the material, consider allowing people to still attend the meeting even if they haven’t done the reading. I’ve found that most still have something to contribute based on experience even if they haven’t done the prep work.
12. Shout it from the rooftops. Announce the upcoming meetings and topics any way you can, whether it be by email, Yammer, newsletters, shameless plugs in daily stand-ups—whatever it takes to drum up interest and participation. Also consider micro-blogging during the meeting so that those who were not able to attend can still participate in the discussion.
Back At the Office
When I started an IT quality assurance book club at IDEXX Laboratories, the biggest hurdle was not getting people outside the QA team excited about talking about quality (as I would’ve expected), but rather getting a group of introverts to come together and interact with one another. Initially, QA carried much of the conversation. However, by picking hot topics that were relevant to everyone in IT and creating a non-threatening forum for debate, attendees soon felt comfortable sharing opinions, experiences, and ideas; participation grew as attendees recounted their experience to others on their teams. We’ve been meeting for more than a year now and have had some fantastic, energizing, eye-opening conversations.
Given that most of the QA team originally came from a traditional waterfall background and were somewhat new to agile, several of the discussions focused on attempting to figure out the role of quality assurance (QA) in this new environment. For example, we questioned if QA should have a role in code reviews and unit testing, we discussed the blurring lines between testers and developers, we debated if we should report defects on agile projects, and we reviewed best practices for writing user stories and conducting effective retrospectives. We also covered developer-centric topics such as static code analysis and test-driven development.
One of the most robust book club debates was when we discussed if detailed test cases belong in an agile environment, something we on the QA team had been debating among ourselves since we formed several months earlier. For this discussion, I looked for articles that presented differing points of view on the subject and selected the following StickyMinds articles:
Taking the Risk: Exploration over Documentation by Matthew Heusser. This article describes how the loudest voice in the room might push for a stable, predictable, repeatable test process that defines itself up front, but each build is different. An adaptive, flexible approach could provide better testing in less time with less cost, more coverage, and less waste
Do You Need to Write Test Cases? by Vu Lam. Lam discusses how writing test cases can be a time-consuming activity, and approaches vary from comprehensive test plans to more casual and exploratory cases. What factors should influence your approach?
In this discussion, as well as in many of the others, I could see the insistence for adhering to traditional approaches starting to wane as the doors opened to how we might all do things differently. We wouldn’t always leave with a definitive path forward, but would walk away with many new ideas we couldn’t wait to try.
Perhaps you, too, are looking to connect with others, share ideas, and consider new approaches. Why not start a book club today? You’ll be glad you did when you discover how transformative these conversations can be! If you have already started or participated in a work place book club, what advice do you have for others just starting out?
