Agile

Walt, I think you make a good point.  In a traditional software shop, there would be a product owner that would be someone intimately familiar with the customer (or a customer), who would typically be a homogenous group of folks doing the same thing.  This person would put each feature through the paces right after a developer/team have made it and give it a thumbs up or down.  Typically there is a rapid interaction.  

Our customers are very diverse and each of the groups exercise very different parts of the radio.  But we have to test all the parts before we make a release and we rely heavily on our Alpha team to test different parts of the radio.  I feel like we are already wearing folks out at the current rate of releases and increasing it would make that worse.  These dedicated folks that help us test their favorite mode/style/etc are not on call 24x7 so we have to work around their schedule.  We often get our best test time on the weekends rather than throughout the week.  It does take a lot of work to get a release out in the field, both on their part and on ours.

We do continually deliver software to our Alpha team.  They typically get a release every 2-4 weeks.  But while they are testing, we don't sit on our hands.  We are developing new things.  So we apply fixes to the old things already shipped plus add the new functionality.  Remote audio in the LAN is a perfect example where things may work great in our office, but then we deploy to customers that have very different network topologies and they find issues.  It may take weeks to examine the issues, try things out and find solutions that work well for everyone.  It doesn't typically take our whole staff to work on one feature so the other guys are off working on something new.  And consequently, you end up with more things in the software.  

Jim, I assume when you mention the DAX issue, you are saying that you think we could have tested it more from the start and ended up with the correct solution in the first release rather than add something later.  The point is a good one and this has been the case on some features.  In the case of DAX, though, we worked it pretty hard in the office and were pleased with the capabilities.  Our Alpha team was as well and we felt good about what we had.  Only after it had been in the field a while did we put the pieces together and see that there are very real, but not consistent, issues that arose.  Setting up DAX was the #1 or #2 thing we were getting calls about on the phone.  Only when we heard several people explain issues they were having did we realize that we could give them the information to make understanding and using DAX easier and so we promptly did that.  Our intuition about what will work well is not always right and sometime we misjudge how people will do things, use things, etc. and when we learn from customers we make changes that help them.

To this end, we've actually considered asking our customers during install if we could collect anonymous usage statistics and patterns that would help us see things we could improve.  This is a project for another day ;-)

Anyway, the points made here are all well taken and I assure you our management team reads all these types of comments.  We routinely discuss the best ways to develop and deliver software and the entire software team works very hard to make sure we're getting you the most value we can.  Thanks for all the comments.