Agile Testing with Lisa Crispin

I’ve been writing a lot on SearchSoftwareQuality and Techwell (aka Stickyminds) lately, no time to blog. I have lots to say so I hope I have blogging time soon! I’ll start by reporting back from Belgium Testing Days.

There is so much goodness to report from last week’s Belgium Testing Days! I’ll be writing all that up, but I wanted to start with the great ideas that came out of my session on “Speaking their language: What testers can learn to work more effectively with programmers”. My slide deck will give you a bit of a feel for the talk, but as I’m going with simpler slides these days, you had to be there to know what I said. However, much more interesting are the ideas generated by the participants, who divided into small groups and made lists of what testers should learn to help them communicate and collaborate better with programmers. I asked them to go beyond the ideas I described in my talk. Each group gave their top choices, and I wrote them on a flip chart.

The last group to go had the one we all agreed was most important – have fun!

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.

This afternooon, I joined Mike Sutton’s Improv session. My takeaway: “It doesn’t hurt to collaborate”. The exercises were fun and funny, and gave insight into how teams worked together. I particularly liked that Mike used a task board to keep track of his session.

Mike Sutton moving cards on talk task board

We did a lot of fun exercises, and had lots of opportunities to do the “failure bow” (similar to “How Fascinating” in Language Hunters) we learned from Tobias in the warm-up this morning. We encountered so many things that happen on software projects. For example, when we had to draw a picture by committee, each person had a different viewpoint on the picture and a different idea of what we were drawing.

Ball Flow Game

Next, I joined the Ball Flow Game facilitated by Olaf Lewitz and Gerry Kirk. This turned into a hilarious example of “too many cooks in the kitchen”, in my opinion. Just try to get a bunch of agile coaches together and get something done! We started out really well, producing the inventory of “magic balls” efficiently, in just over one minute.

Then, naturally, since we had done pretty well, we changed everything at once and came up with a totally new way to “deliver” the magic balls. My personal estimate of five minutes was not too far off the real result. It was a good opportunity to reinforce the fact that it is better to do small experiments and only change one thing at a time than to do a drastic reorganization.

Attempted Game Development

Paul Boos, one of the ACCUS organizers, was kind enough to let me take a slot in the agenda to get help in trying to develop a game that would teach tester-developer collaboration. My goal was a quick game that would teach testers that it’s not a bad thing to test early and often, and teach programmers that it’s valuable to have testers involved throughout development. I can’t afford Legos and I don’t like to check my bag when I travel, so I wanted to do something with a construction kit that uses plastic straws (similar to drinking straws) and connectors.

Some participants created works of art!

A wonderful group of people came to help. They started throwing out ideas, and it first, it seemed there was no way I could create the kind of game I wanted with the straw kit. While they brainstormed, participants built some awesome straw constructions, proving that using our hands does help us learn and think!

It turned out that you can build a lot of two-dimensional shapes with the straws: squares, rectangles, circles, arches, hexagons, lips. The group proposed that the first part of the game would be for each team to build all the shapes. These could be “tested”. In the second phase, each team would put the 2D shapes together into 3D shapes, and try to build the biggest structure that could hold its own weight when picked up. This also would encourage incremental testing.

An additional idea was to throw in “hidden requirements”. For example, when the facilitator comes around to verify the 2D shapes, she could say, “That is indeed a square, but I forgot to tell you, all the straws in the square must be blue.” This would simulate a real-life project.

This isn’t the quick game I envisioned, but it has potential, and I think it’s worth trying out. Thanks to everyone who helped me, I’d never have thought of this on my own! Collaboration rules!

I’m looking forward to Agile Coach Camp and more learning, insights, and friends.

I have been doing some writing in the past six weeks, in addition to rehabilitating my broken-and-now-healed ankle. But it’s all been published elsewhere. Here are some links:

Software Quality Connection, “How to Improve Communication between QA and Development“

SearchSoftwareQuality.com, “Agile development: The whole-team approach”

Also on SearchSoftwareQuality.com, “The whole-team approach to Agile development: Examples and benefits“

I’ve got a bunch of tips and Ask the Expert Q&A on SearchSoftwareQuality.com, please check them out! I’d appreciate feedback.

My review of Uncle Bob Martin’s The Clean Coder is up on my Techwell blog. If you’ve read the book, I’d love to hear your thoughts on it. If you haven’t read the book, please do so!

My summary of the WAT2 conference this past May, in Durango, appears on the SearchSoftwareQuality.com website (you have to register to see content, registration is free, I apologize that it’s a bit of a pain to have to register). I was inspired by this year’s theme of style and grace, as well as the amazing participants, leading testing practitioners from the U.S., Europe and Israel.

If you think conferences aimed at programmers are only for them, think again. I wrote about my experiences at ACCU 2011 on TechTarget. Take a chance and try a conference that doesn’t seem tailor-made for you!

I’m grateful to the Software Testing Club for asking me to report my experiences at StarEast. It was fun to do and will help me remember what I learned and what I want to try now as a result!

I’ve just been struggling with a title for this post. Some of my ideas were: “Visibility Taken to New Heights”, “Yes, There Are Teams Who Do This Just Like In the Books”, “A Real Commitment to Continual Improvement”, “Inspiration”, but none of them really capture my amazement at what I saw visiting the team at Energized Work in London. Finally it struck me that this team embodies the Whole Team approach to software development in a way that I’ve rarely seen.

I’ve just updated this post with links to photos of the Big Visible Charts in the Energized Work Lab, accompanied by explanations from Simon Baker. Check ‘em out, they will give you ideas for your own team to use.

What a Team!

I’ve always maintained that I work for the coolest team on the planet, and most of what I try to help others learn are things I learned from and with my own awesome teammates. I don’t want to be disloyal, but the team at Energized Work raises the bar for cool. Simon Baker (@energizr on Twitter) invited me to visit while I was in London earlier this month (and he gave me permission to write this post about it). I love to visit development teams wherever I go, and learn what other practitioners do to improve software quality, so I was happy I could make the time. Mohinder Kohsla had breakfast with me that morning, and was kind enough to guide me to the Energized Work lab, as he already knew some of the folks there.

Big Visible Charts

What blew me away right off the bat at Energized Work was the creative ways they use whiteboards. One whiteboard had personas, complete with photos and bios, and assumptions. That’s not too unusual, but it’s still nice to see someone actively using personas in real life.

What intrigued me most was the way they represent their backlog for their current project as a site map on a big whiteboard. They start drawing site map for the web application they’re working on on a big whiteboard, with placeholders for each screen, and arrows showing how the navigation flows. Since this is on the whiteboard, it’s easy for them to evolve the map as the project proceeds. They overlay cards with user goals so they can identify which journeys deliver value. Screen prints of completed pages are stuck to the board over the original placeholder, along with the cost to develop it.

The team starts with minimum functionality delivered to achieve a goal, working in fast, tiny iterations. As Simon explained to me, the customer can decide based on that functionality and what it cost whether to invest more in that user goal, for example, to “enrich the feature with more functionality”. The site map / backlog is part of the team’s mechanism which allows the customer to decide “just in time” whether to “go deep or broad” every week in response to user testing.

The Energized Work team has experimented with different ways to do story/task boards as well. Instead of a traditional Scrum task board or Kanban board, they represent each story with a big square on the whiteboard. In the middle of the square is a story card has some high level acceptance tests written on the back. Surrounding it is plenty of space to draw mock-ups, prototypes, write questions, write down test cases, whatever they need to discuss or do. A team member only has to look at the board to see story requirements.

Instead of moving cards from column to column, eg. from “Work in Progress” to “Verify”, they represent the vertical slicing of the story with different colored dots, representing feedback from different activities including customer review, UX reviews, and manual exploratory testing. Some cards may cycle through coding, testing, reviews, and back to coding several times before they’re done. Gordon Conroy, the tester, keeps an eye on the “big picture” as new functionality is created slice by slice. He was so knowledgeable about all aspects of the project, it’s clear he works constantly together with the rest of the development team. If companies with separate test teams could see this in action, they’d get why testing can’t be a separate phase or done by a separate team!

My own team uses a fairly standard task board with rows for stories and columns for status, and we write high-level requirements and questions on a separate whiteboard. We also work in these fast, tiny iterations with multiple slices of each story, and I am wondering if we can borrow some of these ideas to better represent that visually. We put more details about slices, test cases and specifications on the team wiki, but developers don’t always look at the wiki. Of course we also do specification by example with executable tests, but whiteboard drawings and notes would make a good, quick-to-access supplement during development. I’ve told my team everything I’m writing here, and we’re ruminating on how we might experiment to improve visibility, while keeping our remote teammate involved.

Another Big Visible Chart in the Energized Work lab lists usability heuristics. Clearly, no aspect of software quality is neglected here, and there were so many visual reminders to keep the team on track. Just about every problem my team has experienced, we solved by making it more visible, and seeing how well another team accomplishes this is affirming.

Driving Development with Tests

The Energized Work team are clearly expert practitioners of TDD and specification by example. They showed me the continuous builds in Jenkins for a couple of different projects, it looked a lot like what my own team does. I’ve personally met few teams that have as sophisticated a build job set-up as ours. I found it interesting that they’ve used different test frameworks and tools on different projects, they are clearly committed to finding what works best for each situation, and experimenting with new approaches. Some of the tools they use are new to me, such as Spock for unit testing Groovy and Java, using a BDD-style syntax.

All database changes and data migrations are automated, kept under source code control and managed with Liquibase. This is one area where my own team could improve, so it was helpful to see this in action.

Gordon Conroy showed me some clever solutions they’ve come up with to test having many concurrent users testing realistic situations, and how they can monitor these scenarios as the automated tests run.

Customer Collaboration

They explained how they work with their current customer. He comes in several days a week to collaborate with all team members, including developers and testers, and answer questions. The customer’s goal is to have a website to show potential investors, so a lot of effort goes into the look and feel and showcasing the functionality. The customer gets continual feedback from tests and from the backlog site map, and in turn is able to review the work completed so far and give feedback to the development team on what changes are still needed. I wish I could have met the customer because I’m betting he is truly delighted (as we want all of our customers to be!)

Continual Improvement

Most of all, I admire the Energized Work team’s obvious commitment to always finding better ways to work, even though they are already functioning at such a high level. They had just experimented with using causal loop diagrams for their retrospectives, to help them identify behaviors and invisible work. They told me that they aren’t just trying to improve the process within the system, but better understand the system itself. As a result, they’re able to make real improvements in effectiveness, not only efficiency. Here’s another example of output from a retrospective.

It was exciting to meet a team of people who are passionate about software quality, love what they do, and clearly have a lot of fun. They obviously have time to learn, innovate and experiment, which is reflected in some incredibly creative solutions to some tricky testing problems.

I’ve been telling my own teammates the ideas I brought away from my visit, and we’ll see what experiments we can think of trying. Some of our best ideas were “stolen” from other teams, and I expect in another six months I’ll be able to tell you what has resulted from my inspiring visit to Energized Work.

Everyone Focused on Quality

Janet Gregory and I, and our teams, have been practicing the Whole Team approach to delivering high-quality software for years, and working hard to explain this concept to others. It was affirming to see a team commit to a high standard of quality and then work relentlessly to keep raising the bar.

I highly recommend that you and your team visit other teams, in your own area or when you are traveling. Every team can teach you something, even if it’s “what not to do”. Visiting a team who has found good ways to produce great software shows you what’s possible in real life, and leave you enthused about trying something new to do better work.

The latest issue of Agile Record is out, and includes some terrific articles by Gojko Adzic, Jurgen Appelo, Ellen Gottesdiener, Johanna Rothman, Linda Rising, Catherine Powell and several more – what an incredibly talented and diverse group of contributors! My “Agile Testing in Real Life” column is about practicing our software development (that includes testing) skills. I like to lead by example, so in this article I recount everything I’ve done so far this year to grow my own skills and become a better software tester.

To what are you devoting  your 10,000 hours of practice?