Lisa Crispin has been a software tester since 1995. In this month’s Testing the Limits, she’ll tell us how she fell into the profession, talk about her experience with waterfall and agile development and share some insights about what really makes testing teams work. Plus, we’ll learn about donkey trust.
Next month, Lisa will be participating in Deep Agile 2013 in Cambridge, MA. Lisa will lead sessions titled “Deliver All the Right Things (and Only Those Things)” and “Story Slicing and Collaborative Analysis with Gherkin.” Other session leaders include Jeff “Cheezy” Morgan, Ellen Gottesdiener, Matt Barcomb and Stephen Vance. Deep Agile 2013 takes place November 23-24, register online.
uTest: What got you into software development and testing in the first place?
Lisa Crispin: I needed a job. During a recession in Texas many years ago, I was laid off from my government job doing research for local governments. I wanted to move to Austin, TX, and while job-hunting there, saw a notice in the University of Texas employment office: “Computer Programmer Trainee, No Experience Necessary.” I had little experience using computers (this was in an era where there was still some use of punch cards) so I fit the bill! The Data Processing department hired for domain knowledge and aptitude. I did well on the test and had an MBA so I got the job.
What drew you to Agile over other schools and methods?
LC: In the ’90s I had worked for an excellent team that did waterfall, but also did many good dev practices we now associate with “agile”: CI, automated regression testing at the unit and GUI levels, whole-team style collaboration throughout the life of the project. This was a database company, and we released every 6 – 12 months, it worked great.
Then I moved to a web start-up. We diligently implemented and followed waterfall, but no matter how disciplined we were, we could not deliver any new features fast enough to keep up with the competition. It was so frustrating! Then some of my teammates moved on to another start-up that decided to use XP. They gave me Kent Beck’s book to read. I was so excited, it was all about quality! And it seemed like it might be the solution to delivering new features fast enough! I never looked back.
What do you say to the people who think Agile is just another trend?
LC: On one level, “Agile” is just another trend. Many companies hear about it as the latest thing, so the CTO commands that now they will be Agile, they send their PMs to ScrumMaster school, have two-week iterations and standups, and call themselves Agile. Of course it doesn’t work.
I like Elisabeth Hendrickson’s definition of agile. To paraphrase her, a team is agile if they deliver business value frequently, at a sustainable pace. The “sustainable pace” captures all the good practices needed in order to actually deliver value in the form of high-quality software that customers want, frequently and consistently without killing yourselves.
I wish we could stop using labels such as “agile,” “lean,” and “kanban,” and start calling it “improving how we deliver software.”
If there’s one thing you could go back and tell yourself at the beginning of your career, what would it be?
LC: Interestingly, at the start of my career, we were very much what would now be called agile. We paired with our customers since we didn’t know about writing requirements. When they were happy with what we did, we released it to production. We didn’t know about testing, or phases. But we did a great job, even on difficult projects such as one of the first online library catalogs.
But I’d go to myself in my second programming job, where I first learned about “waterfall,” and tell myself: It’s not methodologies or tools or programming languages that make projects successful. It’s getting the right people, and allowing them to do their best work.
Do you have any advice that can apply to both new testers and people who have been doing this for decades?
LC: The same thing I’d tell my baby-programmer self: it’s all about the people. Both individually and as a team, we should continually identify our biggest problem, make it visible, try small experiments to chip away at it, and continually improve. That gives me the most job satisfaction, and I think that must be true for others too.
You were recently featured in a Q&A in informIT’s ‘Women in Tech’ series. Any words of wisdom for women in the technology field?
LC: Software development is really a creative activity. Work with your team to manage your workload so that you have time to try experiments and innovate. Nurture a learning culture, see failure as a way to learn rather than something bad. And again, it’s all about the people. I think there are lots of other women who, like me, value working with people over the actual technical work. That makes our work rewarding and fun.
You’re part of an upcoming Deep Dive with Agile New England. What is Agile New England and what does the group do?
LC: Actually, since I’m in Colorado, I’m not that familiar with Agile New England, but I assume it is like our own local agile group: practitioners who get together to improve their craft and learn.
Can you give us a sneak peek of what you’ll be discussing at the Deep Dive?
LC: The Deep Dive is focused on how testers and other roles on a software team can collaborate to create better-quality software. It’s about creating a culture of quality. Here’s an overview of what we hope to explore.
What can people expect from the Deep Dive overall and how can they register?
LC: See the overview link for #8, and registration is here.
The weekend will consist of several hands-on, participatory sessions. It won’t be “experts” lecturing the audience. Instead, we will facilitate fun exercises, discussions, role-playing and actual coding where participants will generate new ideas.
We hope everyone will leave with at least a few small experiments to try on their own teams to start improving the quality of the software they develop.
Is there anything about Agile that you think people are getting wrong?
LC: Unfortunately, most teams never really get to experience what Agile should be, because their management continues to impose unrealistic deadlines and over-burden them with work. Most of the teams I’ve worked on succeeded, and the reason was that from the executive level on down, the company valued quality over everything else. They understood that focusing on quality now will lead to speed and ability to respond quickly to change and to the competition later. But focusing on “speed” now means accumulating technical debt that finally brings the team to a halt.
From what I’ve heard, Lisa Crispin is all about Agile and donkeys. Why donkeys?
LC: Hah! I’ve ridden horses all my life, but sort of accidentally got into donkeys. I learned they’re quite different to train than horses. You can bribe or bully a horse into doing things it doesn’t want to do. But donkeys must trust you completely in order to do what you want. Once you earn that trust, they will do anything for you. Our donkeys will gladly follow us into a house, a school, a church, wherever we want them to go. But if you ever violate the trust, for example, put them in a situation where they get hurt, they’ll never forgive you. It’s quite an unusual bond. I’ve learned a lot about trust from donkeys, and I think it applies to software development teams, as well!