5 ms·

[author here] You know, I should have written about that a bit more. It makes sense in retrospect, I didn't even think about it at the time, even after leading

by DrPizza 12y ago

[author here] You know, I should have written about that a bit more. It makes sense in retrospect, I didn't even think about it at the time, even after leading off with the problems of the VS2010 cycle. But, yes. If one looks at how VS and TFS have evolved, it's been very clear that there must have been some internal customer who really wanted to use them for scrum (no external customer would ever be that influential). The last few releases, not to mention the VS2012/2013 quarterly(ish) updates have all had an emphasis on improving this aspect of the products. Accordingly, they seem to have become pretty decent, and this has no doubt helped teams change how they work.

keithnoizu 12y ago
I don't know. My understanding is that external customer requests on TFS are ranked higher than internal requests. As in internal feature requests related to agile and scrum that would have made other teams life much easier have in the past been explicitly refused because they were unsure of how well it translated into the needs of the retail consumers.
- DrPizza 12y ago
  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.
ethomson 12y ago
I would argue that you were right when you wrote: > Even as Microsoft stuck to its waterfalls internally, Visual Studio was used by third-party developers who themselves wanted to use agile methods, creating pressure on the Developer Division to build better support for these approaches. These features are definitely being driven by external customers. (Disclaimer: I work on the TFS team, in particular on the Version Control team, so I can speak to the changes in version control throughout the years.) TFS was initially conceived as a mix of the tools for software development (version control, issue tracking, continuous integration) that were heavily influenced by the tools already in use at Microsoft to build (say) Windows and Office. That's why the version control component in the first version of TFS was a checkout/edit/checkin model. Clunky, yes, but scalable to the sizes of the codebases that we wanted to support internally. That's also why the work item tracking is crazily flexible in ways that are barely comprehensible to mortals, it was meant to adapt to the different development practices that go on around these parts. So TFS 2005 looked a lot like the development tools that existed within Microsoft at the time, and it was really aimed at "influential" internal customers. And that's great, but most of our customers outside of these walls don't have crazy multi-gigabyte source trees and the same checkout/edit/checkin model that's so useful for a code base the size of Visual Studio is an unnecessary annoyance if you've got a much smaller or more modular code base. And if you have a dodgy network connection or you travel alot, it's downright problematic. So bringing an edit/merge/commit model ("local workspaces") and a DVCS (Git) to the party were truly about growing and adapting TFS for our customers, who tend to be a little lighter weight and more agile than we are.

by DrPizza 12y ago

keithnoizu 12y ago

I don't know. My understanding is that external customer requests on TFS are ranked higher than internal requests. As in internal feature requests related to agile and scrum that would have made other teams life much easier have in the past been explicitly refused because they were unsure of how well it translated into the needs of the retail consumers.

DrPizza 12y ago
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.

ethomson 12y ago

I would argue that you were right when you wrote: > Even as Microsoft stuck to its waterfalls internally, Visual Studio was used by third-party developers who themselves wanted to use agile methods, creating pressure on the Developer Division to build better support for these approaches. These features are definitely being driven by external customers. (Disclaimer: I work on the TFS team, in particular on the Version Control team, so I can speak to the changes in version control throughout the years.) TFS was initially conceived as a mix of the tools for software development (version control, issue tracking, continuous integration) that were heavily influenced by the tools already in use at Microsoft to build (say) Windows and Office. That's why the version control component in the first version of TFS was a checkout/edit/checkin model. Clunky, yes, but scalable to the sizes of the codebases that we wanted to support internally. That's also why the work item tracking is crazily flexible in ways that are barely comprehensible to mortals, it was meant to adapt to the different development practices that go on around these parts. So TFS 2005 looked a lot like the development tools that existed within Microsoft at the time, and it was really aimed at "influential" internal customers. And that's great, but most of our customers outside of these walls don't have crazy multi-gigabyte source trees and the same checkout/edit/checkin model that's so useful for a code base the size of Visual Studio is an unnecessary annoyance if you've got a much smaller or more modular code base. And if you have a dodgy network connection or you travel alot, it's downright problematic. So bringing an edit/merge/commit model ("local workspaces") and a DVCS (Git) to the party were truly about growing and adapting TFS for our customers, who tend to be a little lighter weight and more agile than we are.