« Could a Newspaper Succeed Completely Online? | Main | Why I Work at Microsoft »

April 08, 2007

Agile Panic

One of the courses I teach in EE is called "Scrum and Agile Project Management". The topic of doing "agile" development is something that is discussed a lot at Microsoft these days. Because I teach the course, I have looked at a lot of Microsoft teams that use agile techniques, Scrum in particular.

The topic seems to naturally inspire disagreement. Steve Yegge, a blogger at Goggle, had two somewhat rambling posts last fall entitled "Good Agile, Bad Agile" and "Egomania Itself" in which he criticized the agile movement. And recently on Mini-Microsoft, someone posted the comment"Go work in live.com or MSN, agile is everywhere. Every dev hates it, it kills productivity, it leads to endless meetings and most importantly, it absolves PMs of any up front thinking." This is concerning because I do think agile has something to offer Microsoft, and it's discouraging to here people bag on it in general, and report that it is harmful at Microsoft in particular.

First of all, it should be pointed out that "agile" is not a software development methodology; it's a branding exercise. Back in 2001 a bunch of people who were pushing what they felt were progressive techniques for software development--Extreme Programming, Scrum, Crystal, DSDM, refactoring, etc--got together to create the Agile Manifesto, in which they summarized their feelings into four main values. The same kind of meeting of the minds produced the term "open source"; creating a single brand allowed people to combine their weight. So when people talk about "agile" they could be talking about many things, and saying "my team adopted agile development" doesn't really mean anything; they have to specify exactly what they adopted.

The other thing is that proponents of agile, for whatever reason, are astonishingly easy to make fun of. The combination of earnest passion and dubious terminology makes the genre essentially self-parodying, and when someone says "the agilistas used a spike story to convince the chicken that our project velocity was impacted by the scrum smell" the temptation to stuff them into a gym locker can be overwhelming.

Furthermore, agile proponents don't help themselves when they are dogmatic about aspects of agile (which would seem, both on the surface and in the gooey interior, to be self-contradictory). For example, consider this post about how bad it is to embed a 4-week Scrum sprint inside an 8-week overall milestone, which has a followup comment "Of course, they will probably blame Scrum when it fails, even though they are not doing anything remotely related to Scrum." Embedding a 4-week sprint inside an 8-week milestone....heaven forfend! Don't they know that children might be reading this? Meanwhile nobody really explains why this is so bad. I mean, you know, it says in the book...meanwhile I actually know the team he is talking about, and they were using this process to ship live code every 8 weeks, with high quality, empowered teams, high morale, etc. and furthermore think Scrum is wonderful and credit it for all their success. It's ironic that a team using Scrum is supposed to be self-directed, yet if they do something like replace their daily meeting with a three-times-a-week meeting, they are cast as heretics who just don't "get it" when it comes to Scrum. The notion that agile has to be hard, and if you find it too easy you must be doing something wrong, leads you to wonder if the goal of agile is to ship high-quality software, or just to suffer for the process (and you wonder why people call these discussions "religious arguments").

The net net is that it is very easy for Steve Yegge to find aspects of the agile "movement", whatever that is, to pick holes in. And he can easily construct a surface-credible argument that it is an onerous methodology that detracts from writing good code (and his argument that agile is bad because "Agile Manifesto" is an anagram for "Egomania Itself" doesn't stand out as much less fact-free than a lot of other claims made in this corner of the software development world).

This is a shame, because the agile folks really have come up with some great ideas. For example Scrum is about just a few things: work off a prioritized list, don't assume you can plan too far in advance, put your code in front of the customer often, discuss progress with the team on a daily basis, and improve your process whenever possible. Is there something in there that sounds wrong? Agile is fundamentally about taking a process that has gotten too heavy and burdened, and making it simpler and more productive. When you read Steve Yegge talk about how Google works, what he describes is (modulo the free food and million-dollar bonuses) the way agile should work. So it's a bit depressing that he is able to construct a reasonable argument that agile is harmful, and to hear Microsoft people say that agile is hurting their work in MSN.

Anyway, I posted a request on Mini for more details. After some struggle I managed to excise the word "flock" from this next sentence...suffice it to say that there are some disgruntled Microsofties out there who feel agile is bad, and hopefully I can convince them it isn't all that bad.

Posted by AdamBa at April 8, 2007 10:37 AM

Trackback Pings

TrackBack URL for this entry:


Agile is something that can both unite and divide people and teams. My experience is that it can only work when you have executive support and a team which believes in what they are doing. At the same time, the team needs to *want* to do it a certain way. To that end, any process, agile or not, should be developed by the team using it and adopted to fit their needs.

I like Scrum, TDD, and some aspects of eXtreme Programming. However, I know many other engineers in MSN and Windows Live who do not. That's fine, but I do not think they do their careers justice by staying in a team that they don't believe in. If people really do not believe in the way a team is doing things, have brought up concerns with their management, and feel that things are not changing, they can always head over to the open jobs listings. There are plenty of other teams at Microsoft who do not use any kind of agile ideas.

The endless supply of purely negative comments on Mini-Microsoft have caused me to stop reading them. I read Mini's posts but find I don't have the time or energy to go through those posts. Really people, if you are that disgusted with your current job, do your team a favor and switch groups or leave the company.

Posted by: Phil at April 9, 2007 12:02 AM

My issue with agile is that most of the agile methodologies doesn't scale beyond a team of about 10 people, which makes it great for small teams but a disaster when applied to a division.

Posted by: Larry Osterman at April 9, 2007 06:39 AM

Phil, I completely agree that techniques need to be adapted at Microsoft...that's one of the reasons why I am annoyed by people who scoff at anything other than a "pure" methodology.

A top-down mandate "you must use process X" is a recipe for disaster, that is widely acknowledged. But I really am curious about the people who don't like, say, Scrum. What specifically bothers them, and why can't they change those parts (since this is one of the main themes of Scrum)? Do they feel powerless, or are they explicitly told not to, etc?

Larry, I wouldn't say agile doesn't scale. There are teams that use Scrum with 60-80 people. What is true is that the bigger a team, the more complicated things get...that is a basic fact about anything. But I think almost every team at Microsoft could be more "agile" than it is now.

- adam

Posted by: Adam Barr at April 9, 2007 07:22 AM

Hi all,

Scrum is something you should not be afraid of. It is one way of doing things, and it is not for everyone.

If your goal is develop working, shippable software... it may be a way for you to go.

If not... hmmm. There are other things out there to use.

Check out www.implementingscrum.com for real world thing I see when implementing scrum at different locations throughout the world. On teams from as small as 5 to teams within large large enterprises.

- mike

Posted by: Mike Vizdos at April 9, 2007 01:58 PM

I've met people who dislike Scrum. This sounds bad, but they have all been developers. I have not met people from the PM or Test disciplines who dislike Scrum. This doesn't mean too much since my sample size is so small. I do find it at least a little interesting though.

These people told me that they hate the daily meetings, they hate the planning sessions, and they hate they review meeting. I view these as integral points of the process, but my friends have told me the think the process interferes with work and innovation. I would disagree with them though, as our team has produced some great stuff using Scrum.

Again, I think it goes back to the team coming up with the solution. Maybe Scrum works best in a new team where you hire into it explaining how things are going to work. That way you are more likely to have buy-in from everyone.

Posted by: Phil at April 10, 2007 11:49 AM

Larry Osterman wrote: "My issue with agile is that most of the agile methodologies doesn't scale beyond a team of about 10 people, which makes it great for small teams but a disaster when applied to a division."

Feature Crews (just search internally for it) do a pretty good job of addressing this concern. The trick is not to try to apply all the agile techniques at the larger level, but to use it at the level it works - a small number of developers, testers and PMs working on a single, well-defined set of functionality - and use a different methodology at the higher level. You get the benefits of agility at the feature level, but still have the managability of the overall project.

Posted by: Mike Kelly at April 11, 2007 05:58 PM