From what I have learned over my life thus far, is that we need not think of things as either-or, at least not all of the time.  Heavy metal guitar player’s use pick slides to make interesting screeching sounds, but bass players can also use this contrivance – to make a different yet similar if not so eerie sound.  This applies to much more than just to music.

We posted a discussion on LinkedIn at the Defense and Aerospace group about using the same techniques we use for generating a WBS in conventional projects, to generate the sprint backlog from the product backlog in scrum.  In both the case of creating our sprint backlog, and breaking down our conventional project scope, we are disaggregating a higher level of abstraction to a level upon which we can take action.  This is not the only place we can employ conventional techniques in an agile project, or the contrary, agile techniques in conventional projects.  We have applied these agile approaches within conventional projects and even the line management function with great success.  But this brings up other questions, for example:

• How can these practices fit into the larger product development process?
• Are there limits to when we can either use agile / scrum to product development?
• Should we focus on employing specific agile philosophy into our conventional approach or find ways to move toward agile entirely?  Does our industry allow this transition (high risk or legally regulated)?

With quick prototype hardware techniques and approaches, we can build iterations or mock-ups along the way even when it comes to articulating the system level concept.  I have used an agile approach at the front end of the project to create detailed specifications and have them reviewed and delivered just in time for the software developing group.  At this point, the system was largely known and prototype hardware iterations would be available.  However, the details of the system interaction were being developed in these detailed specifications.  Sub-system engineers wrote the specifications with reviews from systems engineering before being sent to the software group that developed.  I was part of the specification writing team, and what could arguably be referred to as the scrum master for the software development team.  The specifications were listed, prioritized, and then written and delivered in blocks according to this prioritization.  After 2 weeks, a batch was delivered and the software development commenced.  The specification writing would continue, delivering a portion from the prioritized list in each increment.  

All of this agile or scrum-like activities happened inside a conventionally ran project following APQP type approach.  I am not sure how close to the start of the project we can employ these agile approaches, but I know we can learn considerably from experimentation and observation.