The author worked on a medical technology product development project at an R&D house, working as a team lead for software in multi-disciplinary project, for an overseas corporate client.  The usual mundane challenges of a highly technical software project ensued - aggressive timelines, fixed price contract, a remote and demanding client, no dedicated business analyst, no dedicated software QA, 400 or so abstract software requirements written in a long software specification spreadsheet.

On top of this, as a non-technical agile practitioner your author struggled coming to terms with a highly technical project involving electronic engineers, industrial designers, medical scientists, and a new technical approach to emulating proprietary algorithms to conduct diagnoses on patient samples using a combination of fluid dynamics, surface chemistry, and the emulation of proprietary algorithms designed for use in a previous generation product using a completely different technological approach .  Yeah, I didn't know what all that meant either.

But that's just the context... what I really want to talk about is the challenges and lessons learned from applying Agile in a volatile organisational, compliance and contractually driven context, with the particular challenges of agile for embedded software (firmware).  This poses significant challenges in terms of writing meaningful stories, producing meaningful estimations, what happens when your hardware drivers don't work, rewriting software when the hardware changes, testing device software when you don't actually have a device.   In other words, all you people working in pure software/web have it easy.  

This experience reinforced my faith in agile principles and values, although I did have moments of doubt!   This talk will look at those principles and suggest ways that they can be better applied even in non-embedded software development projects.