- and code development helps keep participants more in touch with the reality of the trade off between features and schedule.
- The frequent delivery of working code can clarify discussions that often otherwise degenerate into unhelpful abstract debate.
- Development gets a head start because it goes on in parallel with other discussions
- The agile iterative process provides a framework for marketing and engineering collaboration.
What about after formal design controls begin and design documents have been formally created? Do you go back to waterfall development? The funny thing about waterfall development is that, unlike agile development, it doesn’t actually give you guidance on how to do the actual development that goes on between phase reviews. Typically the next time the waterfall process weighs in is would be when code is handed off to the Vamp;V group for test. So my expectation would be that at the end of the research phase iterations would continue unabated as if they phase never existed. If everything is working well, the development group will have settled into a rhythm where they’re working with marketing and a product manager to produce regular releases. I can’t imagine at this point that anyone involved will want to stop and go back to the old way where marketing and engineering only talk to each other at the beginning of the project and at the end once code is delivered.
Because in this phase you will have the traditional set of documents expected by waterfall development, the typical QA department will be satisfied. Although that documentation is at risk of needing updating, the amount of updating you can expect will be much less than that in a typical waterfall process because you have invested in an upfront iterative development period where marketing, engineering, and the code have oriented themselves in the same direction.
When QA hears that you want to start coding before formal specifications have been generated, they’re going to think the engineers are planning to run wild and start hacking. A well run agile project couldn’t be further from this. It is a methodical process designed to addresses some of the realities of software development. Its goal is to make higher quality code that better meets the customer needs. This is as applicable to medical device projects as any other projects.
About the Author
Mike Dobbles is the Senior Software Manager at Cardiac Science and is a Certified Scrum Master.