Thanks for the lucid reply.
Whilst I would agree that the "agile" approach might be the right one, I think your approach to agile is clearly wrong to end up with such poor quality making its way to the customer. There are some pretty basic, extremely obvious and very easy to fix problems with your shipments. I've documented elsewhere some pretty basic stuff like the Silverlight msi installing documentation for WPF Q2 NOT Silverlight Q3, identifying itself as Controls for WPF etc etc. And all this in spite of those "weekly builds" and the "agile development" that you're so proud of.
Let's take the RadCoverFlow control as an example.
Clearly a LOT of time has been spent responding to the criticism about documentation. The problem is that there's a lot of documentation and screenshots explaining the really simple easy stuff ("Each page for CoverFlow effectively covers a XAML attribute for the control.... Here's what the attribute looks like in XAML. Here's some sample code. Here's what some scenarios of changing this parameter are and here's what the results would look like in the UI").
But get on to the stuff developers really need documentation on eg "I want to make the control look different" and what does the Telerik interpretation of an "agile" approach give us? Lots of warnings that you need to understand the structure of the control (good) with the all important link to "Required Parts" which will explain what these are containing nothing other than a heading and copyright information (bad).
I would argue this is not "agile", this is just poor thought, poor planning and poor understanding of what a milestone release (only 3 a year remember!) should include.
What else are beta's or weekly release cycles for, if not to improve quality?
Another quick example...
Your documentation for the control this is posted under only runs to a few pages (it's just a control after all). It includes the following page about the NavigationPanel: http://www.telerik.com/help/silverlight/coverflow-navigation-panel-visibility.html
which refers to a NavigationPanelVisibility
attribute. That attribute does not exist on the shipped control
. So the whole page is meaningless and drives the customer down a false path.
Again, to say "this is the result of agile development" is the sort of thing that gets agile a bad name and is NOT what agile development is about. After all you have a mere handful of pages of documentation for this control - how hard is it to check these before shipping?
My guess is that either you pulled this functionality because it was not ready, or you changed its implementation and nobody thought to review the very few pages of documentation. What Telerik are effectively saying is "As part of our major release - only 3 a year remember - we won't bother checking a few pages of documentation because we're agile".
What do you think that says about you as a company, your adherence to strong agile tenets and quality? What will it cost you in terms of lost customers, time wasted on support calls and answering questions like this in the forums? A lot more than the hour or so it would have taken someone to have just done some basic QA before shipping!