I recently attended a discussion about Agile, and I realized there that I’m pretty spoiled as a software engineer. I entered into this profession at a time when I can complain about the Eclipse IDE because it is not as good as IntelliJ and when I can submit code changes via Perforce rather than by paper. And my first industry experience is at a company that practices Agile and TDD, utilizes separate code branches for active development versus stable, maintains a huge test infrastructure of unit tests and automated UI test scripts, and has a cubicle-free open office setup in which founders sit next to new hires.
Like a fish never knowing air, these are all second-nature to me and I only realized that they are not ubiquitous until I experienced how difficult it is to pick up someone else’s (broken) code that is totally devoid of tests, or learned that a company like Google only has one code branch… so that any other engineer working on something completely unrelated could break your piece of functionality. I’ve surprised engineers at other companies by telling them that our test infrastructure is completely automated, prompting them to ask, “So what do your QA do?” “…. They write the automated scripts!” And I’m really glad that my projects are prioritized and defined a la Agile rather than by spec writers or sales & marketing professionals or, worse yet, government bureaucrats. Things could be better at my company, but then they could also be much, much worse.
As for all this discussion about Agile this and XP that and Scrum somesuch, I used to wonder what all the fuss was about. Agile (click for “manifesto”) is basically about maximizing collaboration within a software team and being flexible enough to absorb changes in requested features. Actually, I believe that XP and Scrum fit that description, too, and I don’t care what you call it as long as it works for the team. I also thought it was all fairly commonsensical, until I realized that it was only in recent years and in certain circles that people started talking about Agile or XP or Scrum. For example, software team management at Microsoft is definitely not agile. I’m not saying that’s good or bad for a company like Microsoft, but I have to believe that large corporations and government contractees do not naturally think in terms of product releases with adjustable feature sets. Works well for the typical smallish Silicon Valley software company, though. Mehran Sahami once described computer scientists as akin to geometers in the time of Euclid, and to a lesser extent the same could be said about Agile practitioners.
The question I’d like answered next is, What is the maximum team size at which the team can still be agile?
