Agile Testing with Lisa Crispin

Sometimes I’m the most helpful when I just sit there and mainly keep quiet – assuming I’ve gotten the right people together to talk.

Today was a good example. One of our stories this sprint is an algorithm to calculate internal rate of return on a 401(k) account. This is pretty complex (especially for me, given that my math education topped out at algebra). The product owner has done a lot of research and experimentation to come up with the formula. He documented the formula on the wiki, and created a spreadsheet with numerous real examples from production data. The developers have done their own research as well. They wrote code to do the figuring and a couple of FitNesse tests based on the spreadsheet examples to check the results, and their answers didn’t match the PO’s answers.

The developer came over and started asking me questions about the PO’s formula. I thought we ought to be discussing it with the PO, who fortunately showed up right at that time. We had the “Power of Three” going. I didn’t participate much, other than to ask an occasional question. I don’t grasp the details of the formula well enough to make suggestions. My main contribution was to have made sure the three of us got together and talked.

We worked through some examples, and the PO decided the dev’s ideas were good and agreed to change the formula, but brought up a suggestion from another dev that would make the formula more ‘elegant’. They talked about this for a few minutes, obviously neither totally understood this other idea, so I went and got that developer. After more discussion, the decision was to proceed with the current formula, see how it works, then later on, see if the more elegant solution is appropriate. I’m not even the main tester on this story, so I made sure that the person who is got filled in on what happened.

I didn’t contribute hardly anything to this discussion, other than to make sure the right people talked, that they reached a consensus, and that appropriate action was taken to document the new formula on our wiki. But let’s say we were a team without testers. Maybe the developer would have gone directly to the PO, but would they have gone and gotten the other developer? Would the decision have been made and documented? It’s possible, but the number of times that I’ve been the instigator in getting the right people together to discuss and decide is pretty high. I’m also often the first person to say “Let’s work through a real example”. And back when we first started Scrum, and direct communication between customers and developers was new, these kinds of impromptu discussions sure didn’t happen naturally.

I recently joined the KanbanDev mailing list, and there’s been a discussion there about whether testers should be involved with the dev team and how they would add value. As simple as it sounds, getting people together to talk has always been one of my major contributions. The Power of Three, as Janet Gregory calls it, is truly powerful.

This month’s issue Dressage Today had some articles about the two-time Olympian dressage rider and trainer, Steffen Peters. He talked about the role of discipline in turning dreams into reality. For him, this means keeping himself mentally and physically fit through a thoughtfully planned exercise and diet routine, as well as understanding the capabilities of each horse and how it can learn best.

My own dressage trainer tells me all the time, “It takes a million repetitions to change a bad habit.” That’s only a slight exaggeration in my case. I remind myself (and she reminds me) about 50 times a ride to correct each bad habit, for example, to put my hands closer together and keep them centered over the horse’s withers. Some of my bad habits are 50 years old, so they’re hard to fix, but I’m slowly getting better.

Discipline is a critical component of delivering high-quality software, too. We need to thoughtfully plan to use the right practices for us. We need to remind ourselves every day, via big visible charts, information radiators, retrospectives, any means that works to learn new good habits and reinforce the things we do well.

During a recent estimating meeting, our product owner (who normally knows better) asked, “About 6 weeks ago you estimated this XYZ story at 5 points. Is there any cheap, hacky way to do it for one point?” One of the developers responded, “Possibly, but we are not going to do a cheap, hacky solution”. It’s tempting to cut corners to meet a business need, but hacking in a quick fix that increases our technical debt down the road isn’t the way to do it.

Another example where discipline and good habits came into play occurred in this morning’s Scrum. A couple of the customers brought up a significant piece functionality that they had accidentally omitted from a story we’re already working on. It was tempting to say “OK, we’ll add that in too.” But it was too big a change to put into the story at this late date. We discussed possible workarounds, and one of the customers came up with one that would do the job. They will write a new story, and if we can, we’ll pull it in this sprint. If not, they’ll get it two weeks later.

Sometimes we do make compromises about quality, and implement a solution that is less than ideal. There are always business trade-offs to consider. But we don’t make these lightly. And even after more than five years of agile development, we spend time on a serious retrospective every iteration, and work hard to keep improving the way we work and the quality of our code. Some of our bad habits have been hard to fix, but we keep working at it. Our business continues to grow, which to me is the best feedback about our disciplined approach to keeping up good habits and eliminating bad habits.

Janet Gregory and I had the pleasure of participating in a discussion related to our book this week on Java Ranch in the Big Moose Saloon forum. There were some really good questions and resulting discussions. Take a look.

An article by Janet and me just got posted on InformIT – “Testers: The Hidden Resource“. This was an idea that popped in my head one day when I was driving to work, after we had just finished the book. Testers have a lot more to offer than most development organizations realize. See what you think, I’d love to hear your comments. Are we too optimistic or do you agree?

I’ve been enjoying podcasts and screencasts from various people in the agile and testing world, it’s a nice quick way to pick up new ideas. So it has been especially fun to get to be the person delivering the podcast on a couple of occasions lately.

I did a longish interview with Tom Cagley of SPamCAST - Software Process and Measurement Podcast. You can also get this on iTunes. It came out really well and I make what I think are some pithy and useful observations about agile testing!

As noted a week or two ago, Janet and I did a 5 minute podcast with Željko Filipin at AWTA. This was a lot of fun and all the podcasts from AWTA are worth a listen.

Phil Kirkham had the interesting idea to ask authors of different testing blogs the same five questions about blogging. I was honored to be asked, and Phil has posted my responses to 5 Questions for Lisa Crispin. I especially liked the photo he used. (I have more donkey photos on my old website.) It was interesting to read Matt Heuser‘s responses to the same questions, and I look forward to the responses from other testing bloggers.

I have a lot of links to testing blogs now in my Favorite Links section. Am I missing some good ones? Please let me know, I’m sure I must be.

Zeliko Filipin has posted a bunch of podcasts with AWTA workshop participants, including yours truly and Janet Gregory. I knew at the time that I wasn’t grasping all the information in every presentation, and listening to the podcasts reminds me of what didn’t quite register at the time. There are so many possibilities for test automation, and I need to make sure I learn about as many new frameworks and tools as I can, as more and better ones become available.

I invested a lot of time over the past few weeks upgrading to the latest version of Watir and getting the scripts and suites working in Vista. The silver lining was getting a bit familiar again with Ruby. We don’t do a lot of new stuff with these scripts, so my skills (such as they are) were rusty. It’s personal technical debt to let that happen, on top of the technical debt of scripts that weren’t updated to work properly with new code. But now my technical debt burden is lighter.

Next on my personal task board is to upgrade to the latest FitNesse. We’re on a very old version, and I know Uncle Bob Martin has made a lot of improvements lately, including the ability to use Slim instead of Fit underneath. I get overwhelmed trying to keep up with tools (someone asked me at AWTA about the overhead of using multiple test tools, and it’s true) but I have to invest time in that. The ROI demands it.