External requests might have motivated the initial foray into supporting agile processes, but it's internal users that make it worth a damn, IMO. My view is th

External requests might have motivated the initial foray into supporting agile processes, but it's internal users that make it worth a damn, IMO. My view is that you can't develop effective general purpose application software without an internal customer, because until you have that internal customer, you can't meaningfully dogfood it, and you can't get the feedback loop tight enough. Take, for example, WPF. WPF addressed a real need, I think; developers wanted a decent GUI stack (which Win32/WinForms/MFC/whatever just ain't), and long term, Microsoft wanted something amenable to 3D acceleration and DPI increases. Great. Except that for the longest time, WPF was deeply problematic for any major application. Problems around text handling and performance were the biggies. Microsoft had no real internal customer for WPF. Some of the Blend apps used it, but they (now discontinued) were never a critical part of Microsoft's day-to-day operation. When did WPF get good? When an important application (Visual Studio 2010) started using it, and made clear that hey, something needs to be done about that text rendering and performance. I think there are quite a few little corners of Microsoft's software in a similar boat. The new-to-Vista sound card/audio APIs were plainly not fit for purpose in their original form, but nobody in Microsoft noticed, because nobody in Microsoft was actually using them. Late in the development cycle the APIs were updated (adding notifications when a buffer was nearly empty) to make them usable, but it created a troublesome driver situation for a year or more post-release. With the internal customer, the feedback becomes much more immediate. Microsoft's customers don't get to see every 3 week cycle. Internal customers do. When the developers are using the very product they're developing, this becomes better still; there's an implicit understanding of what the thing should do, and how it needs to be better. This becomes institutional knowledge, and it likely never even manifests as an explicit request. It doesn't have to. The implicit understanding of how customers are using the software and not just what they want but _why_ they want it is sufficient to ensure proper and effective implementation of their requests.