Jon M. Quigley PMP CTFL is 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. He holds multiple degrees, seven patents, has authored and contributed to numerous books and magazine articles as well as teaching and speaker at technical schools, universities and conferences on a variety of business and product development topics. Jon is my podcast guest tomorrow and below is an excerpt from the podcast.
Joe Dager: When would you recommend that type of — when you use Scrum versus let’s say a Waterfall, is there a good rule of thumb where one fits? Not everything should be done in Scrum, should it?
Jon Q: I think you’re right there. I would say definitely not everything is Scrum, just like definitely not everything is Waterfall. And it kind of irks me sometimes when I read that on blogs or hear people say that Scrum is the bomb or the thing to replace Waterfall. It’s not true, no more than Waterfall could replace Agile. There are certain attributes of your organization and your project that tell you whether you should use Agile or conventional. For example, if I’m working an automotive project that has a lot of tie-ins with heavy capital and manufacturing, distributed all over the world and regulations, I probably would consider that I might consider using a Waterfall approach. The logistics around that are kind of high, the regulations on those are very specific, and proof of conformance to those regulations are very specific, and if something goes wrong, you’re going to have to have some track record to traceability, and that might be a little difficult to come by in an Agile incarnation. If you have a team that’s a bunch of experts, they’re very seasoned that’s probably a good time to have an Agile project.
Joe: So you’re saying that Waterfall would provide more structure of things for the inexperienced team, can I take that out of that or –?
Jon Q: Yes, that’s one of the things you could take out of that and then the other would be the fact that it’s so structured gives you in theory a traceability and so at the end of the day, if the government came to call on you because your product may have harmed somebody, you have some track record or some traceability that you may not quite have that level of detail if you’re doing Agile. By definition, you forego detailed documentation.
Lean Sales and Marketing: Learn about using CAP-Do