Lisa Crispin was voted the Most Influential Agile Testing Professional Person at Agile Testing Days 2012 by her peers, and enjoys working as
a tester with an awesome agile team. She shares her experiences via writing, presenting, teaching and participating in agile testing communities around the world.
She is also the author and contributor of numerous software testing books, including her latest, released in October and co-authored with Janet Gregory, More Agile Testing: Learning Journeys for the Whole Team. You can learn more about Lisa’s work on her site, and follow her on Twitter @lisacrispin.
In this uTest interview, Lisa explains the reality of agile adoption and suggests ways teams can succeed with agile.
uTest: Where have companies or teams gone most wrong when rolling out agile in their organizations?
Lisa Crispin: Many organizations don’t understand that to succeed at software development, we have to focus on delivering the best possible quality, rather than focusing on speed. Too many think that “agile” means “fast.” You need a big investment in time and training so that teams learn important practices such as TDD, CI, specification by example/behavior-driven development, helping business stakeholders identify the most valuable features, and so on. Teams that don’t nurture a learning culture where failure is tolerated, experiments are supported, and the team has diversity, accumulate too much technical debt and fail.
uTest: From your experience, what’s your mix of either backgrounds or personalities that make up the ideal agile team?
LC: Any team needs diversity. It’s essential that each team member feels personally safe to ask questions, bring up issues, and suggest improvements. Each team member must learn to shift to an “agile” mindset and be willing to try small experiments, see what works, continually improve, and build quality into the product.
The downside of diversity can be communication gaps. We have to build a common language to communicate. Using executable tests to drive development helps with that. Sharing knowledge so that we each understand the others’ jobs also helps.
We need to build our T-shaped skills, or as Adam Knight puts it, square-shaped skills. For example, testers don’t need to be coders, but they should be technically aware, having a high-level understanding of the system architecture and some familiarity with the tools and frameworks in use. Everyone should feel safe to ask questions and ask for help.
uTest: Why is agile *the* answer for larger organizations stuck in their ways?
LC: I’d like for us to lose labels such as “agile.” Each organization should identify their biggest problem, brainstorm small experiments to make that problem better, try each experiment and grow incrementally from there. It’s a shame that “agile” has become, for many organizations, the latest in a long line of “miracle cure” methodologies.
I prefer Elisabeth Hendrickson’s agile acid test: A team is agile if it delivers business value frequently, at a sustainable pace. To have a sustainable pace, you have to embrace so many good values, principles and practices. Continuous delivery is the golden ring we’re all trying to grab these days. It takes a long time to achieve it – we have to be patient, try small experiments, sometimes take one step forward and two steps back. I know from experience that eventually we’ll get there. If it takes years, that’s OK – remember how many software delivery efforts fail.
uTest: You joined your first agile team in 2000. Could you talk a bit about the experience, particularly how it drove you to become an agile testing champion?
LC: On my last waterfall team, I was frustrated that despite how disciplined we were at following the waterfall process, we were always behind our competition. By the time we got a feature out the door, it was out of date.
During my first iteration as a tester on an agile team, I was shocked to discover that if two users logged into the product we were developing, the server crashed. “Unacceptable!” I cried. Our manager/coach had to explain to me that the customer didn’t care whether more than one user could use the product — they were a startup who needed features to demonstrate to potential investors. This was a giant mindset shift for me — the customer defines external quality, not the testers.
I had the opportunity to work for a small financial services company from 2003 to 2012. The co-founders knew they needed successful software delivery for their business model to work, but knew nothing about software. After researching who in the area could save them, they persuaded Mike Cohn to come on board full time, and luckily he brought me on board. I got to experience the magic that happens when business executives understand the value of quality, and a cross-functional team works together for quite a few years. Learning to deliver business value frequently at a sustainable pace (to paraphrase Elisabeth Hendrickson) was an eye-opening experience.
uTest: Your new book is a continuation of the first – ‘Agile Testing,’ which came out five years ago. How does this book differ and how is it a natural continuation of the first story being told?
LC: The “basics” we used in our first book, such as the agile testing quadrants and test automation pyramid, still prove useful today. But we’ve benefited from more disciplines joining the agile effort. For example, business analysis experts such as Ellen Gottesdiener and Mary Gorman have shown us more ways to help stakeholders specify how features should work. Longtime agile testing practitioners such as Gojko Adzic have come up with techniques such as impact mapping that achieve similar goals.
And there are new technological problems to solve, such as testing software embedded in so many things we use every day, from automobiles to exercise equipment. We are testing in many contexts: Globally distributed teams, enterprise organizations, business intelligence. We have to adapt and grow our models to accommodate all the new challenges.
uTest: The book is filled with stories – stories from real agile teams and firsthand experiences. What was one of the stories that surprised you the most, or was most inspirational?
LC: Wow, with around 70 sidebars from more than 40 contributors, it is hard to single any out. One that I thought had a unique perspective was Parimala Harisprasad’s story about leading an offshore test team that is working with agile development teams.
She has found a lot of simple ways to make the remote team members feel more connected with each other. She has a wonderful sense of humor, and her team clearly has a lot of fun, which in turn helps them collaborate better. For example, they share funny pictures and videos, creating a “butterfly effect” among the people in different geographical locations. It’s good to get ideas on how to make a distributed team “jell,” since so many of us work in organizations with individuals or teams who are remote.