I’m home after a weekend attending the DeepAgile Embedded professional pevelopment seminar held at Harvard University and hosted by AgileBazaar.org.
Many people put a lot of effort into producing and running the seminar: the speakers (Jack Ganssle, James Grenning, and Russel Hill), the host (Nancy Van Schooenderwoert), and many volunteers.
I never realized there were so many embedded software developers interested in understanding agile development practices. Nancy was brave to suggest this and she and the speakers organized an effective presentation of how such practices can be used in the somewhat longer-lived combined hardware/software development cycles typically seen on embedded projects. Russel Hill totally impressed me in how he embraced software testing and simulation of hardware failures in software. (We recorded the talks, so if the recordings come out well, we hope we can share these with you.) Both Russell and James seem to have completely nailed the art of acceptance testing. (I loved hearing that Russell was his own customer/product-owner. He used fitnesse tests to document and understand the current state of their software/hardware project and used tests to describe the project from the inside-out.) Before this weekend, I felt alone in taking that view myself. On the many projects where I’ve worked, I used this inside-out approach as a way of understanding the software I needed to release or test. I’ve used this approach to describe existing functionality and then I’d communicate that to the project owners and see if what they got is actually what they wanted,
Yes, this is a little backwards, but there are a lot of projects in the real world where order needs to be made out of chaos. You need to start somewhere. If you don’t do this on such projects, they never stand a chance of getting better. Russell took these ideas to an extreme and built a software model of the upcoming hardware under test. The result was a set of functional harware tests written in fitnesse in advance of having actual hardware. This gave everyone on their team a common understanding of what they were building. Achieving this common understanding of the product under test is what acceptance testing is all about. Russell’s success is inspiring me to continue on my quest of using tests both as tests and as documentation. I’m hoping the recordings come out well, and that we’ll be able to share a lot more of what was taught during this seminar!
Once again, I give a big thanks to the presenters and Nancy for compiling and sharing this information.
–
Bob Clancy
http://agiletester.net
