Agile Testing with Lisa Crispin

The first day of Agile Coach Camp began with each person introducing him- or herself and his-or-her superpower. There were some clever ones. I said mine was getting people to write on the whiteboard, because whenever I do, magic happens, but then Tim Ottinger tweeted his disappointment that my superpower didn’t involve donkeys.

The first open space session I attended was on Systems Thinking, facilitated by Ken Furlong. I didn’t understand a lot of this, and there were some skeery formulas, but some folks tweeted some links to me to learn more about it.

Net-Maps

Net mapping is my biggest takeaway from ACCUS so far. Eva Schiffer, whose background is in things like working with GMOs in Ghana and not IT, created net mapping to identify different people or organizations that influence a project. You identify the players: people, departments, groups. You draw connections with color-coding between them, for example, hierarchies, funding, conflicts, adversaries, being in it together. People can do the maps together.

Stacks of checker-like objects piled on each influencer denote the amount of influence. This is a great visual. If you’re doing this with a group, rather than denote “positive” and “negative” influences, you could choose two more neutral goals, such as “stability” and “change”, so that people feel safe. Eva noted that the “average view” of who influences what doesn’t do anything for you, you have to let each person explain their viewpoint.

I’m such a fan of mind mapping, and this seems to take it to another level. I am eager to try this.

One of the participants, who is from the education profession (not IT), suggested it would work well for kids, for things like exploring peer pressure. It was so interesting to get perspectives from people outside of IT, both leading and participating in ACCUS sessions.

More than Agile

George Dinwiddie facilitated this session on what agile coaches need to know besides agile. Many skills we talked about were what Isabel Evans calls “thinking skills”, other people call them “soft skills”: facilitation, creating space for the development team, PR, team dynamics, teaching people outside the team to support the team rather than trying to “drive”. We talked about ways to help teams learn to self-0rganize: providing gentle direction, helping form the team, helping them take on achievable challenges. One tweetable quote from this session was “Trust goes in, pride goes out”.

I was lucky that our team had Mike Cohn for our manager/coach for the first year of our agile transition. First he helped us decide on our commitment to quality. We committed to delivering the best quality software that we possibly could. Mike helped us make this commitment mean something. He exhorted us every day to write code that we’d be proud to take home and show our moms. He told us over and over, “I don’t care how much you get done, or whether you meet some deadline. I only care that you produce the best quality that you can.” It took a long time for the team to trust this message, but once we did, we invested a lot of time to learning valuable practices such as test-driven development and specification by example. This investment paid off in the ensuing years, as we built up a good base of re-usable code and test code. We have always kept our technical debt at a manageable level, and as a result we have a good steady velocity.

QWAN: Providing basic agile knowledge online, for free

Olaf Lewitz explained the idea of a free interactive course to teach agile basics, called QWAN (Quality Without a Name). This effort was partly inspired by the Kahn Academy. We brainstormed the what, how and why of this community effort, and came up with both ideas and questions. Check out the photo.

Today I was lucky to hear part of the Thomas Jefferson Hour as I drove down to the ranch to work the donkeys. Thomas Jefferson, channeled by the actor and scholar Clay Jenkinson, quoted from his first inaugural address: “Every difference of opinion is not a difference of principle”. Jefferson believed that our elected officials should respond to moments of tension (and as he says, there was just as much rancor in political debates back in his day as now) with politeness, good humor and respectfulness. He recommended that our current elected officials, if they can’t find common ground, should adopt “artificial good humor” and assume the best about their opponents.

TJ and I might both have our head in the clouds, but I’m a big believer in civility. I’m not recommending that we all walk around on eggshells and worry about offending people. But I do think we need to all work hard to make sure that everyone on our software team feels safe to express opinions, and conversely, is willing to accept the team consensus or majority rule, and work to make whatever approach is taken successful.

This is something I want to take to heart for myself. Here’s an example. I’m trying to explain an issue to the programmer who is on production support this sprint. I’ve analyzed the problem and think I know how it should be fixed. He seems not to understand, gets impatient with me, throws up his hands and tells me I am mistaken. I could feel mad and hurt by this, or I can remember that being the production support monkey is frustrating and stressful. I’ve given him the information I wanted to convey, and I can leave him to process it. He’s smart and motivated to take care of our customers, so I know he will find a good solution. He shouldn’t be rude to me, but if I can avoid escalating the tension, we will have a good outcome.

Indeed, later the programmer comes over and apologizes, says now he understands what I was trying to say, and appreciates the research I did into the issue. We talk about the fix and how to test it.

I’m lucky to work on a team that, though there is lots of joshing and joking, is composed of people with a deep commitment to providing a quality product, and open minds willing to consider anyone’s ideas. I’ve been on teams that didn’t provide this atmosphere of respect and civility, and I must confess, I hightailed it away from those toxic environments.

The “agile” movement was built on principles and values. “Every difference of opinion is not a difference in principle”. Give your team time and space to agree on principles and values. Going forward from there, each team member will feel free to float their ideas and opinions, and have healthy discussions. That’s what makes a project successful.

News!

Janet Gregory and I have an article, and are interviewed in, this month’s Software Test and Performance Magazine, devoted to “Women of Influence in Software Testing”. Please check it out, it’s a great issue with lots of meaty articles.

I have a sidebar in Dawn Cannan‘s terrific “Be the Worst” article in the inaugural issue of Agile Record.

Matt Davey wrote a wonderful thumbnail summary of our book in his review of it, we are grateful.

Agile Coaching, in my opinion, isn’t only for people who coach agile teams. If you’re in the software business, you’ll learn something valuable from this book. Start with the last chapter – “Growing You”. The only way to succeed in our industry is to continually learn and improve, and this chapter gives great suggestions how to do that.

This book is a model of concise, clear writing. It’s packed with information in the form of narrative, bullet points, graphics, photos, stories of real teams and projects, exercises, tips and examples. The authors have been walking their talk for a long time, so you can feel confident about following their advice. Their flair for language makes the book fun to read. It could be a quick read, except you’ll find yourself stopping to reflect on your own experiences, and thinking about how you could apply the technique you just read about on your own team. Each chapter includes hurdles you may face, and a checklist summarizing action items for you, the reader.

I particularly enjoyed the little vignettes with dialog from a typical team illustrating topics such as “Not Quite Done Yet” and “Getting Ready to Demo”. The authors have insight into all aspects of coding, testing, and managing software teams. You’ll find advice you might not expect in a software-related book, such as “Be kind to yourself”. The focus on people and teams will make you a better person and team member.