(Note, speaking for myself, not Microsoft!)<p>Pretty good article, only some minor inaccuracies.<p>Things I noticed:<p>1) Private offices are nowhere near gone. Some teams have "gone team room" (TFS), some have not (Roslyn). I've worked in both and personally don't care either way, but there are a number of people who heavily favor one or the other.<p>2) Visual Studio is technically a team, yes, but there are thousands of devs working on it. I think of my team as Managed Languages (Roslyn), not VS.<p>3) Development strategy is a continuous process and one we're still currently engaged in. We haven't just decided that this is the new process and we're not changing it again.<p>Oh, and some personal feelings: tooling isn't really mentioned in this article but it may be the most important. TFS and other teams have developed some quite good tools that help with the workflow considerably. If every dev is wasting time messing with bad tools, that's a huge amount of dev time wasted as an organization.
The title is eye-catching and the writer has a good writing style, but I see a lot of problems with the headline as well as the content<p>- Microsoft's private offices were an innovation in the 80s/90s, cramming large numbers of worker bees into a single large office is a retrogressive step, not a 21st century innovation<p>- The writers focus is on Visual Studio, but a number of other teams had switched to agile much earlier. I worked in Windows Live Mobile in when we switched to "agile" in 2004. This wasn't being dragged into anything, it was a relatively early adoption<p>- Software projects do often get delayed, but not always. I was one of the dev-leads who worked on Office XP in the 90s and though we had a long ~3year, ship cycle, we did ship on the original planned shipped date (RTM 3/2/1) Steven Sinofsky deserved a lot of credit for that.
Do not be too much impressed by big names and buzzwords.<p>The [very] successful process of developing the Linux kernel with nothing but git, mailing lists and a small set of simple rules (no meetings, no Scrum, no BS) proved to be good-enough.<p>It is not only Linux kernel, there are hundreds of other "decentralized, no-water-fall" projects, notably FreeBSD, OpenBSD, Xorg, LLVM, Golang, CPython, Ruby, you name it.<p>It is much better to consider the differences between a commercial organization (a corporation) with all that bureaucracy obsessed with keeping its positions and budgets, etc. and a team of enthusiastic professionals with their own "inner" motivations and goals.<p>Corporations are producing products to make profit, while teams of enthusiasts are producing (evolving) tools and services for themselves.<p>The difference is the same as between McDonald's and family/home-made-for-themselves food.)<p>Consider, for example, LLVM/Clang (backed by Apple) as high quality and no-cost alternative to VS. Its used as a primary compiler for OS X, iOS and FreeBSD and optional one for Android NDK.<p>And, look ma, no bureaucrats, no meetings, no Scrum.
Like it or loathe it, MSFT has always been a learning corporation. Teams are continually exploring different approaches to software development and trying to figure out what works best for their team and org. To their credit, they also publish a fair amount of this research and it looks pretty interesting, e.g.<p>Transition from Centralized to Distributed VCS: A Microsoft Case Study on Reasons, Barriers, and Outcomes,
via <a href="http://research.microsoft.com/en-us/people/nachin/" rel="nofollow">http://research.microsoft.com/en-us/people/nachin/</a><p>Have Agile Techniques been the Silver Bullet for Software Development at Microsoft?
via <a href="http://research.microsoft.com/en-us/people/bmurphy/" rel="nofollow">http://research.microsoft.com/en-us/people/bmurphy/</a><p>[ $0.02, Scrum or no scrum, for my money having a private office is infinitely better than open plan for getting stuff done. Each to their own, getting harder to find jobs with your own space ]
Seems to be a lot of words to describe what is basically a company adapting to its place in the market.<p>When Microsoft had a dominant market position it could freeze its customer's in-house strategies by tactically leaking details (real or perhaps not) of its future releases. Extended release intervals did not matter because customers waited.<p>Fast forward to today and it is not dominant in markets where it sees growth potential. Customers will no longer wait. Microsoft is seen seen as a laggard by many adopting new technologies. Extended development time would preclude any chance they have of success so they had to change. The outcome is as yet undetermined.
Sometimes I think one of the more important innovations in development technology is the headphone. Open-plan development without great ways to block out noise would be ridiculous.
This article has depressingly little about <i>how</i> Microsoft went about changing the culture from a waterfall to agile mindset. The article is also pretty rosy; I'd expect a little more bumps on the way.
I remember reading about changes to development during the Windows 7 project, which I wrote up[1] for a different lay audience.<p>People underestimate Microsoft. It has enormous inertia, but historically enough introspection to recognise strategic errors and reorient. The most famous being accepting that the Internet was not going away, circa 1998.<p>[1] <a href="http://clubtroppo.com.au/2008/10/20/microsoft-rebooted/" rel="nofollow">http://clubtroppo.com.au/2008/10/20/microsoft-rebooted/</a>
The fact that specification and documentation are abandoned is pretty sad. Software should be adequately specified and specs should be kept up to date with code. Code is not a spec.
Here is a repost of a comment I posted directly to the Ars Technica thread in reply to the author endorsing Agile/Scrum and expressing ambivalence towards telecommuting:<p>"That's 20th century thinking, Peter! Marshall McLuhan would be disappointed! <a href="https://www.youtube.com/watch?v=NNhRCRAL6sY" rel="nofollow">https://www.youtube.com/watch?v=NNhRCRAL6sY</a><p>Spontaneous collaboration can happen just as effectively with a remote staff, but you have to default all your channels of communication to digital ones.<p>Instead of a culture of shoulder taps, use IM.<p>Instead of a culture of hallway conversations, get the entire team on a permanent group chat.<p>Skype is one of the best tools for this, so it's ironic that the company which owns it isn't making the best use of its own tools! ;)<p>The guys over at Basecamp did a great book recently on how to do this remote collaboration stuff right called "Remote: Office Not Required" <a href="http://37signals.com/remote" rel="nofollow">http://37signals.com/remote</a><p>It's a great read. I read it recently while on the plane to a meeting that totally could have been over the internet. The irony was not lost on me.<p>It's also worth noting that Agile/Scrum is not universally well liked anyway. In fact it's incredibly divisive. People who love it seem to <i>really</i> love it and people who hate it seem to <i>really</i> hate it.<p>For example, here's a site parodying the Agile Manifesto, asking the world to adopt something more modern: <a href="http://asyncmanifesto.org" rel="nofollow">http://asyncmanifesto.org</a><p>And here's a much saucier (and perhaps less serious) take on the same idea: <a href="http://programming-motherfucker.com" rel="nofollow">http://programming-motherfucker.com</a><p>TL;DR: Agile/Scrum is a management fad. Collaboration can succeed or fail using any methodology. All the blind praise the media spews for Agile/Scrum is arguably harmful to discussing what is and isn't effective management."<p>Original post: <a href="http://arstechnica.com/information-technology/2014/08/how-microsoft-dragged-its-development-practices-into-the-21st-century/?comments=1&post=27347511" rel="nofollow">http://arstechnica.com/information-technology/2014/08/how-mi...</a>
Also, lock-in tactic [1] is so much last century, but MS is still quite slow on dropping it. With general decline of Windows domination they'll drop lock-in approach even more, but that's still in the future.<p>[1] <a href="https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_lock-in" rel="nofollow">https://en.wikipedia.org/wiki/Criticism_of_Microsoft#Vendor_...</a>