In our next heap and helping of combining movie clips with the ideas raised in a white paper (this time co-authored by our returning champion, Johanna Rothman, and Cem Kaner), I’m reminded this week of the prevailing winds in papers Rothman has put together. Some things remain consistent in her writings:
- They’re written with a mind for software-related products that her experience has allowed her to manage
- They’re written with a mind for pragmatism about the realities of a project’s delivery timetable. In essence, slips are going to happen, so set aside the time to manage & address them accordingly
- Ship date is often a critical part of what, exactly, is going to be delivered
This week’s white paper review is no different, as Rothman and Kaner’s 1998 white paper; “Managing Testing Resources: Five Suggestions for the Project Manager” – once again presented on the behalf of Villanova University – brings the realities of resource testing schemes together with the responsibilities of a PM.
FROM THE CASE STUDY
“The testing part of your project plan has serious risks. Some of our favorite risk questions are…
“(9) Is your test group focused on improving the quality of the product or on proving that you’re stupid?
“(10) How attentive to detail and design are your programmers? Can they accept criticism and use it effectively? What has to be done to make them more productive in their dealing with testers?”
PERSONAL THOUGHTS/VIDEO ACCOMPANIMENT
In reading this passage, I’m reminded of something my old man once told me in his observations of the working life:
Tune out the volume, tune in the message
Indeed. If testers come back to programmers with a laundry list of slips to correct, your people management skills may sometimes come in handy as a mediator in their dialogue. Programmers may be shoulder shrugging and un-receptive to parts (or even all) of the list: they’ve got other things to do, the fixes are too menial, whatever; resistance is sometimes eminent. You have to gauge these things effectively, take the temperature, and keep everyone on board and on task. You may not find it necessary to go Full Metal Jacket drill sergeant on them, but as communication can break down within the team because of egos, indifference or through a sheer lack of respect between parties, maintaining group unity may prove to be your most important soft skill.
But don’t lose track of the content of what has to be said or done. Antics and barking noises don’t always work, yet even they can lead to some unexpected leadership moments, as this scene in Bull Durham shows (this clip is not work safe):
Johanna and Cem go on to talk about setting the criteria of what needs to be done upon completion of testing and how to go forth toward the ship date as errors are fixed. Milestone definition, for short. Ultimately, there is no fixed criteria for these definitions (Rothman and Kaner do suggest further reading that includes Chapter 12 in Kaner, Falk & Nguyen’s Testing Computer Software and Brian Lawrence & Bob Johnson’s Coyote Valley website as good places to research and help PMs set proper definitions to their own liking.) By way of a working example from Rothman’s experience, they spoke of a project where she defined milestone criteria through consultation with test management on System Test Entry Criteria, Beta Criteria and Release Criteria (scroll down to Table 1). “The testing group helped me understand whether the project was meeting the criteria, they helped me understand how to word the criteria and what else should be included,” she wrote of the collaborative effort. “They played an important role. But the list was mine.”
She goes on to summarise thusly…
FROM THE CASE STUDY
“The project was a success. We released the beta version two weeks late. We might have released an earlier version, that had been a beta candidate, but it didn’t meet our beta criteria. However, we were able to explain our criteria to our customers who had insisted on beta copies, and to explain our status against those criteria pretty precisely. This level of control made them comfortable and they accepted the late release without protest. We also had disputes with the testing group, who wanted to continue testing in areas that we had made clear were not relevant to the customers’ acceptance criteria. The clarity of the written, approved beta and release criteria went a long way toward keeping those difficult discussions focused and within sensible time bounds. We shipped the product on time and the key customers were extremely happy with it.”
PERSONAL THOUGHTS/VIDEO ACCOMPANIMENT
Rothman’s triumph was a triumph in bringing insistent stakeholders around to the realities of the situation, cajoling them into better appreciating what they’d get for a little more patience.
I think to education when considering stakeholders. Educators, sadly, have to sometimes operate with their hands tied by stakeholders. Some of the most well-meaning people you might ever have their pleasure of meeting have to walk a fine line between combining the full extent of the details of their curriculum with the sometimes unrealistic, frustrating but all-too powerful parents of the students. Here’s an example: remember in Mr Holland’s Opus, when Richard Dreyfuss was asked for a good response to playing rock n’ roll in class, the so-called “devil’s music” at one time in our history? His proposed answer to such thinking made for good strategic stakeholder management:
While not everyone was on board (clearly, the American Frank Gallagher wasn’t keen), Dreyfuss had a backer (Olympia Dukakis), and he sold well to her. They had a planned response, something they could go forth to concerned stakeholders with. In all likelihood, it wouldn’t get them buy in, but you can imagine that anticipation of such moments and addressing the core concerns (“music appreciation”, “teaching tool”) would get a “Yeah, I can understand that” response.
FROM THE CASE STUDY
“First, a clear statement about the minimum level of testing that will be done for every area of the product (program plus documentation plus marketing materials plus associated hardware). Some areas will get more than this, but none will get less. What is that minimum? Do you think it is enough? Too much?
“Second, a description of different levels of depth of testing that will be used in different areas of the program. For example, we often think in terms of four categories:
- “Mainstream or Normal Use testing works the product gently…
- “Guerilla testing involves ad hoc testing done by someone who is skilled at finding errors on the fly…
- “Formally planned testing involves carefully thought through test cases that are intended to thoroughly test that area…
- “Planned regression testing involves carefully thought through test cases that arerun frequently, perhaps every build or every few builds. They are designed to recheck an area of the product that was well tested, to determine whether it is still as stable as it was previously.”
PERSONAL THOUGHTS/VIDEO ACCOMPANIMENT
As we wrap up for the week, I’m particularly excited by the notion of Planned Regression. This goes over what – supposedly – works, and reassures us that it still does, even after several updates. Like checking our homework or shortening the length of our message to meet the demands of a different audience, as things regress we have to tailor the product to make sure its still up to code.
Which reminds of a great example of planned regression through a wonderful film of my youth, A River Runs Through It:
Cover image courtesy _nickd @ Flickr, re-used with permission
