Posted by: Shilpa Venkateshwaran
agile, Change Leaders, The IT Files
An agile testing coach and practitioner, Lisa Crispin is the co-author, with Janet Gregory, of Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009), and a
contributor to Beautiful Testing (O’Reilly, 2009) and Testen in der Finanzwelt (2009). She also co-wrote Testing Extreme Programming (Addison-Wesley, 2002) with Tip House. Lisa specializes in
showing agile teams how testers can add value and guide development with business-facing tests. For the past ten years, Lisa has worked as a tester on agile teams developing web applications in
Java and .Net. She teaches Agile Testing courses and tutorials worldwide. Lisa regularly contributes articles to publications such as Better Software magazine, Software Test &
Performance Maazine, IEEE Software Magazine, Methods & Tools, Agile Journal, Agile Record, She enjoys sharing her experiences at conferences and user group meetings around the world. Lisa
was named one of the 13 Women of Influence in testing by Software Test & Performance magazine. For more about Lisa’s work, visit www.lisacrispin.com.
What is your definition of Agile (how would you explain it to someone who doesn’t know what agile is)?
I like Elisabeth Hendrickson’s definition of agile. I’m paraphrasing here, but it goes like this: Delivering value to the business frequently (production-ready code delivered at least once a month) while maintaining a sustainable pace. The sustainable pace won’t happen without good practices such as TDD, ATDD, refactoring, pairing, feedback, all the things that keep technical debt at a manageable level. Software projects succeed when they are done by good people who are allowed to do their best work.
Any advice for new agile adopters?
The company needs to decide what their commitment to quality is, and what it means. If management wants the development team to deliver the highest possible quality code, they will have to make an investment. They will have to get the right people, give them time to learn and experiment, and tolerate mistakes – we can’t improve if we’re afraid of making mistakes. Understand that this is mostly a cultural change: everyone has to learn to work in a new way and get out of their comfort zone. It’s easy to teach a new process, but really tough to teach a new culture.
Quality – what is your definition or understanding?
In XP Explained (1999), Kent Beck talked about two kinds of quality: Internal and external. Internal quality belongs to the development team. We do test-driven development and use refactoring and other clean code practices to produce robust, maintainable code and keep technical debt low. The business cannot interfere with that. External quality belongs to the customers. They decide what business value they want from each feature or user story, and articulate that with examples that can be turned into tests that help the development team understand their quality needs. The business may decide to trade off some quality for other business priorities, such as speed. This means reducing focus or removing functionality – not hacking quick fixes unsupported by tests into the code.
Both kinds of quality depend on a real business commitment to quality. The business must value quality over speed and quantity, and make investments that may slow team velocity in the short term, but allow it to succeed over the long term. If the business is not on board, the development organization will not be able to deliver a quality product.
What are some lessons you have learned about agile that you wish you had known long ago or you wish someone had told you about?
Number one is the importance of learning the business, even the parts of the business that are outside of what is automated by the software. When my current team had been doing agile development successfully for three years, we felt we had good code architecture and design, a team commitment to quality that really meant something, mastery of practices such as TDD and ATDD. Yet there were still issues in production – not technically bugs, but problems that required attention. We divided up the business and each of us took a different part to learn well and teach to the rest of the team. Understanding all aspects of the business at a deeper level helped us help our customers and cut down significantly on “production support requests”.
Did you adopt agile or did agile adopt you?
Nice question! In the web start-up era, I was frustrated that no matter how disciplined we were with our waterfall process, we couldn’t get features out fast enough to stay ahead of the competition. Some coworkers who went to found their own startup gave me Kent Beck’s _XP Explained_ to read. It was a revelation – all about quality! What if the whole development team cared about quality, and testing were not a separate phase? I had to join this XP team and try it.