Microsoft and tools
One of the interesting things during my year here at MSFT has been seeing the amount of time and effort that various teams put into building additional tools. A lot of times this is building power toy like extensions to existing environments or filling in gaps we haven't gotten to yet but there are also numerous attempts around a manner of development proces issues. In some ways it seems like a very frivolous way to go about business but we do get tremendous input from these projects and there is an ample audience that will try and comment about why your tool sucks. This helps drive, in a slow fashion, new functionality to market. Unfortunately it is slow and rather random because a lot of the tools that are created are too special case and they don't have the design, testing, and UX work that is needed to get them out the door.
A lot of the tooling and thought is around agile methods. The ability to go faster is a big concern at MSFT. It is an incredible challenge given the constraints in the business around support, legal issues, integration across products, volume of products and teams, and the complexity of platforms that we must support. I think our team has made good progress on this front but we have had a few special conditions that help: our baseline code--VS whidbey--is a finished product; we have few external dependencies; we have no customers to support, we have a solid focus on an incremental approach to market.
Key long term is not just can we "go faster" it is about can we be transparent, can we be agile in the adpative sense, and can we deliver software in pieces. This last piece, getting to more of a subscription and delivering value over the life of a product will be critical to can we go faster and that will continue to drive this team as well as the rest of team system.