Agile Testing with Lisa Crispin

Ellen Gottesdiener (at least, I think it was Ellen – whoever it was, thank you!) recommended Anne Lamott’s book Bird by Bird: Some Instructions on Writing and Life to me. Though it is more about creative writing, and though I found the author to be a bit of a kook at times, I’m taking away a lot of advice from it.

Lamott highly recommends participating in a writing group. This was good affirmation about our writing-about-testing group. But she cautions about criticizing others’ work: “you don’t always have to chop with the sword of truth, you can point with it too.” Having been chopped down before, I appreciate this advice. We need criticism, but we also need civility.

She also talks about the joy of having a writing partner, and I can attest to the value of that! Janet Gregory is the best writing partner anyone could want, whether we are writing something together or helping each other with individual projects.

Here are some more tips from the book that stick in my head:

“Short assignments” – if you have an anxiety attack trying to start a project, write down as much as you can see through a one-inch picture frame. Tell a one-inch piece of your story. I think this applies well to our kind of writing too.

“Shitty first drafts” – All good writers write them. That’s how they end up with good second drafts and awesome third drafts. I put this to use already on my Agile 2010 proposals and so far I’ve got some shitty first drafts, yay!

Get over your perfectionism. (I think this is particularly difficult for us Type A testers).

Quiet your negative inner voices, and get out of the way of your subconscious. At first I thought this was not applicable to technical writing, but all writing comes from within us, doesn’t it? We figure problems out while we’re thinking about something else or zoned out in the shower. Who knows what might be locked up in my subconscious, if I could just quiet my brain down enough to hear it?

There’s a lot in the book about characters and dialog that I didn’t find all that relevant to my writing, but it was still interesting.

Lamott writes about keeping at least one index card and a pen with her at all times to jot down notes, ideas, observations. She wrote the book in 1994, so maybe now she uses an iPhone, I dunno. But, I know at times I’m out walking the dog or something and have an idea – like this morning I had an idea about my proposal while I as out walking – it would have been good to have a way to note it down so I didn’t forget.

Another interesting chapter was on jealousy – being jealous of other writers (especially of your friends) when they have a huge success and you don’t. I don’t think I feel jealous about others’ success, at least not in the field of writing (I am envious of my former neighbors who retired to Hawaii, but at least I get to visit them), but maybe I just don’t admit it to myself because I know it seems bad? I do get envious when other people get fabulous jobs in fabulous locations, but why? I have a fabulous job in a fabulous location!

I think my wonderful writing-about-testing community as well as the other agile and testing communities in which I participate will help me avoid wasting time on envy and take advantage of every resource that can  help me write well. I write because I have something to say that I think could help someone else. I’m grateful for the opportunity to pay forward all the help I’ve received over the years as I’ve learned better ways to develop and test software.

Chris McMahon has blogged about our Writing About Testing group. I’m so grateful to Chris for starting this group. We have a wonderful bunch of testers/writers. I really enjoy helping members who are new to writing get published for the first time. I also really appreciate the great help and advice I get about my own writing.

Now, if I can just find the time to write! Check out my News page to see why I’m so busy. (I’ve also been on vacation for nine days! Back to work soon, hopefully with lots of new energy and ideas after this nice rest!)

Last sprint we had a half-point story, which in our world should be about a day of coding and testing, to do some “simple” text content changes on a wizard in our web application. It’s been a year since we had updated this part of the application (it mainly gets used from late January to mid-March). While we were planning our sprint, we didn’t think too hard about how the wizard worked, and how many permutations it involves over the span of time that our end users are using it.

First Try

Our product owner asked me for screenshots of some of the pages, and had his mockups of the changes ready to go in a Word document before the start of the sprint. We wrote test cases on our wiki accordingly.

Second Try

One of the programmers started working on the story and realized the code had a lot of different cases that depended on dates and statuses of various items. He printed out some of the code and went over it with the product owner to get the appropriate text for each of the cases. The original mockups we had were no longer useful.

Third Try

When I started to test the updates, I kept getting confused. There were subtle differences between the different permutations, and several different target and deadline dates involved. I showed the new pages to the product owner, and he got confused himself, and kept making more changes to the text and even to the logic behind what text is displayed when. The programmer patiently updated the code over and over again, but I could tell he was losing the will to live.

I finally cut and pasted paper mockups myself for each possible condition with the text I thought was correct, went over it with the product owner who made his changes, and the programmer worked from the paper mockups. This did the trick, but by now, the half-point story had taken eight days instead of one.

What We Learned

In hindsight, we think that we should have started by researching all the different possible permutations before we started on the story, giving the PO a screen shot for each one, and having him give us paper mockups for each condition. This would certainly helped me test, as I tend to be more visual, rather than being able to mentally interpret what the code should produce.

When we showed this to more of the stakeholders, they asked if anyone besides the PO and us had reviewed the new text. We had been depending on the PO to do this, so we didn’t show it to anyone else until the coding was finished. Next time, we’ll ask the PO if other stakeholders have reviewed his changes.

Sometimes stuff just happens, but if we always remember to get a mockup for each change needed and each case, it might save us time in the future.

News

There’s a lot going on – I have new articles published and lots of tutorials, workshops and other events coming up. Please check out my News page for details.

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.

It’s that time of year for resolutions. One important agile principle (to me, at least) is the idea of continuosly improving. We are always looking for experiments to try, ways to work better. (There’s discussion on Twitter right now about the label ‘agile’ – maybe it’s time to drop it and just let it be the way we develop software! But that’s another post!)

Recently I wrote a Sticky Minds blog post about being nice. On New Year’s day, I read one of those newspaper articles you see every year that gives advice on sticking to resolutions. It suggested that rather than resolve to “being nicer”, set specific goals, such as, “I will compliment one of my co-workers each day on one of their accomplishments”. That seems smart.

So, instead of resolving to act nicer, I will resolve to notice and appreciate each day at least one of my teammates’ contributions. I also want to pair for some period of time with a coworker at least a couple of times a week. It would help me improve my skills, and I think it helps the team improve.

I have lots of other ways I’d like myself and my team to improve, watch this space. Meanwhile, I’m more interested in what other people are doing to improve how they work or behave. Please comment and share!

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.

I wrote a blog post on StickyMinds about my views on the importance of being nice. I particularly like some of the stories that commenters have shared about how they were able to get a good working relationship with difficult coworkers. Please share your stories!

It’s that time of year where we may have a chance for extra socializing and pleasant distractions from the short, dark (at least in this hemisphere) days. Here’s a bit of holiday cheer from me, my husband Bob Downing, our dogs Tango and Bruno, and our donkeys Ernest and Chester.

Happy Holidays!

Eric Willeke, Liz Keogh and Jean Tabaka have inspired me (and many others, I am sure) with the following, which they produced when they got together in Boulder last Friday.

I’m currently reading some draft chapters of Jurgen Appelo’s upcoming book. His work is affirming my belief that successful software projects are the result of getting good people and letting them do their best work. There are so many aspects to this – reading Jurgen’s work, I am starting to understand that people are the most complex component of any project! Everything hinges on our ability to innovate, to be creative. So, we must be a community of thinkers.

One item in this list urges us to embrace newcomers. I was welcomed into the agile community 9+ years ago. I work hard to pay that nurturing forward, so that others may experience gaining knowledge that in turn drives their creativity. And besides all that – why not always be nice to each other? I feel another blog post coming on.

A Community of Thinkers

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Beautiful Testing, with a wide variety of fascinating chapters contributed by leading software professionals, is available. Not only will it inspire you and your team to improve your testing and your product, but all royalties go to a good cause. I’m honored to have written a chapter. Please see the page on my site for more details and a free copy of my chapter – to whet your appetite for the rest of the book!

I love conferences – I get to meet so many smart practitioners and come home bursting with new ideas. I’m back from Agile Development Practices and I learned a ton. One thing that’s on my mind both from the conference and other reading I’ve done this week is the importance of a culture that enables and even promotes learning.

It’s easy to forget that failure is good – if you can fail fast enough. That’s one reason agile works so well – short iterations and work transparency let us fail fast, and everyone knows when we fail. But failure shouldn’t only be seen as negative. We learn a lot more when we fail.

I recently read a great post titled “Are you building a learning suppression system by Daryl Kulak from his upcoming book. Here’s an excerpt.

What happens in organizations is that people get punished for committing sins of commission but they do not get punished for sins of omission. This shapes the mind of a person into saying “No, we better not try that,” attempting to avoid the nasty results of commission errors while ignoring the problems of omission errors, which don’t seem to cause as much havoc.

We don’t want to suppress innovation. Mistakes should be tolerated, not punished. We want a learning organization so our teams can always adapt to change, and thrive.

More on Learning from Linda Rising

Linda gave an enlightening talk Wednesday at ADP about retrospectives, and she talked a lot about having time for thinking and learning. These are my notes on her talk, so I hope I haven’t misinterpreted anything she said. You can find more material direct from her on her site.

When confronted with practices such as pair programming or retrospectives, some managers have this reaction: “We don’t have time for thinking”.

But we aren’t trying to stop, analyze the root cause of all of our problems, and fix them all. We need to do little experiments to see if they solve some problem we’re having. If the solution works, we don’t even have to know why, we can just use it. Linda compared this to tuning a musical instrument – we can make tiny changes, and these give us lots of value.

Linda quoted Tom DeMarco’s book, Slack. You can’t learn or change if you have no slack. Linda cited research showing that not being able to express feelings and thoughts in the normal course of business weighs us down, slows us down. It sounded a lot like technical debt to me! We fret about things that aren’t going well, and if we don’t get a chance to experiment with ways to improve them, we become less and less productive, more and more unhappy.

Going back to that idea that we must tolerate failure, it’s important that we don’t criticize or blame our teammates. Every team member should feel safe to raise issues and propose ideas. Linda cited Norm Kerth’s prime directive for retrospectives: We must believe that everyone did the best job he or she could, given what was known at the time. Everyone used their skills and abilities, the available resources, to their best advantage, given the situation at hand. When we start from there, we can avoid pointing fingers, and simply try to learn: what’s going well? What’s not going so well? How can we improve? What still puzzles us?

Linda advises us to watch for stereotypes: “These people are just no good at…” She was talking in the context of retrospectives, but this is good advice for everyday work. We even stereotype ourselves. We have to believe, instead, that we can get better. Then we will.

Focus on experiments. Identify the next experiment, and ask the three questions about it at the next retrospective. Share knowledge. Look for patterns.

Time to Learn

As Linda noted, everyone says they want to learn, but few take the time to do so. Take some time to learn something new today. See what you can do to promote a learning culture within your organization. Show your manager the Google 20% rule, and the value that Google has derived from that! Lots of companies, big and small, have something similar: Wiki Wednesdays, Engineering Sprints, one hour per day devoted to professional growth. People on agile teams love learning, and it makes us happy. When we’re happy, and when we are always learning and experimenting, we can do our best work. To me, that’s what agile is all about.