Well, I was just reading ex-MSFT guy Moishe Lettvin's entry about how the start menu put together. In brief, there was a lot of wasted time in meetings (my interpretation), waiting for code to arrive, thrashing due to dependencies, and not a lot of writing actual code. It sounds like the feature ended up missing the vision, too.
That's got to be a pretty miserable year.
There are big differences between different teams here at Microsoft in terms of culture, process, productivity, etc. Of course there are some shared advantages/pain points, as well. Making Vista has definitely spurred changes to a number of these areas, because there are real issues. Improving the speed with which changes are reflected in the builds is important (although there's a trade-off between things moving quickly and too many changes to investigate to understand a regression - I don't advocate a single branch for a team the size of Windows), and there are a number of process changes underway. These are issues that will affect every team to a varying extent. But there are a lot of other issues as well that individual teams can fix.
I worked on Welcome Center and we had a lot of people interested in what was happening in the feature (execs, etc). But most meetings involved two or three people. And I use the term meeting loosely. Basically, we called each other on the phone (most calls lasted under a minute). Initially, we had two or three meetings with most folks present but there were really only 3 people working on it (all of them part-time). I imagine that our PM had more work to do than I did, because there was a lot more deciding what to do than deciding the best way to do it. It's a pretty simple feature to implement.
So here are two examples of a simple feature: one with tons of overhead, and one that was run more efficiently. Were the features intrinsically different? Were the partner teams unduly burdensome? Something else?
(Yes, this isn't a discussion of Agile adoption at Microsoft, I just mean agile in the general sense)