Excerpt from a recent Podcast with Jon M. Quigley PMP CTFL a principal and founding member of Value Transformation, a product development training and cost improvement organization established in 2009. He has nearly twenty five years of product development experience, ranging from embedded hardware and software through verification and project management.
From the podcast:
Joe: Well you’ve actually used Agile in verification and interface it with conventional projects, how did you do that?
Jon Q: Well what we did is in that instance that was a regulatory project. The talent on deck was fairly seasoned. In this case, we put the specs out, as in we knew what the specs were for the scope of the project, and then assigned — I actually had the team pick based on their talent area the pieces of the specifications that belonged where. There were a hundred different requirements and documents; it was more than 3,000 different test cases. For example, you have a guy testing on a truck, you have a lady testing on the hardware and the loop rig, those kind of things.
They would divide the specs up according to what was best for what spot and here’s the concept of self-directed work team; I did not dictate that. I was more like a scrum master. Okay, here’s what’s on deck. Here are the most important parts, the highest priority things we need to verify. Let’s divide this up and let’s start working it. And we actually had a burned-down chart of the number of test cases per each spec. It didn’t quite work out like a burned-down chart in that it was not over two or four weeks, it was more like a six-week period based on the amount of time we thought it would take to do the entire system.
They got divided up, they ran the test cases, we convened every morning and talked about the three things: what did you do yesterday, what are you going to do today, and what’s in the way? I tracked down, they tracked what they did for test cases, and we plotted that on our burned-down chart, that’s like a burned-up chart I think in that the slope was positive and not negative, instead of ours it was number of test cases conducted.
But they were all kind of elements, stolen if you would from Agile. And this part, this part of the project interfaced with a conventional, more staged gate, definitely a Waterfall kind of project. And every day or two, I would give them, the chief project manager the result of the test cases. As in, here’s our planned course, our ramped up test case per day executed, here’s what we actually did, and here’s what we found in terms of problems and that’s not necessarily an Agile thing, that’s just a test thing.
Related Podcast or Transcription: Discussing Project Methods
Lean Sales and Marketing: Learn about using CAP-Do