Agile purists argue that either you’re agile—often written with a capital A—or you’re not. Either your development organization is rigorously adhering to one of the named methodologies (like Scrum or Extreme Programming), say the agilists, or you’re no better than a legacy waterfall shop.

Perhaps we’re overstating the point, but in reality, many agile enthusiasts believe that to be agile is to be pure. What’s more, it’s been said that the goal of every organization should be to become more agile—that is, there should be a conscious effort to adhere ever more closely to a chosen agile methodology.

Pragmatists, by contrast believe that software development isn’t a binary choice between waterfall and agile, and there’s no implicit notion that “more agile” is inherently better than “less agile.” Instead, every development organization should find its own way, picking and choosing the aspects of every available methodology, agile or not, that improves productivity and quality.

Both sides have their arguments. Much thought and experience has gone into today’s leading agile methodologies. For unstructured development teams, adherence to a methodology will have tremendous benefits. Not only that, but the named methodologies have a wealth of training material, best practices documentation, consulting expertise, preconfigured tool chains, and more. If you’re getting started with agility, or if you’re trying to make major improvements in your development processes, you should adopt a major methodology and adhere to it as best you can.

However, for experienced, mature development teams that are already operating efficiently with their own best practices, we don’t believe purity is the answer. In such organizations, study the methodologies and experiment with the parts that will add value. It may be that your own processes can benefit from some new thinking, but don’t reinvent your processes. A hybrid approach combining the best of many ways of thinking may be best for you.

We believe that, in most cases, agile is better. But we also believe that a pragmatic approach is the best approach.

And then there were two
While it’s popular to decry a dominant market player, we are pleased to see the convergence of the mobile applications universe around two players.

The fact that those players are Apple, with its iPhone handset, and Google, with its Android platform, is beside the point. When it comes time to build enterprise mobile applications, development teams benefit from having a small number of targets. Knowing that they’ll likely be targeting iPhone and Android lets developers shorten the learning curve. It minimizes the cost of having to write applications for dozens of different platforms, or of placing a bet on one phone platform, and then having to rip-and-replace if and when that platform fails in the marketplace.

CIOs, CTOs and development managers are risk-averse. There’s no ROI in building the wrong software; instead, you’ve wasted time, human resources and precious budget.

Thankfully, the mobile world has solidified into what for now is basically a two-horse race. There are still a half-dozen other platforms out there, to be sure, but in the mainstream in 2010, only two matter. The days of testing applications on dozens of handsets from another dozen manufacturers are over.

Whether you like the iPhone or not, Apple has changed the way developers build smartphone applications. The iPhone SDKs set a higher standard for building GUIs on a mobile phone—and raised everyone’s standards in the process. That’s why only the Android platform can really compete: It’s the only other phone platform that, in our opinion, offers an SDK of comparable quality.

Will new players enter or re-enter the market? Sure; RIM, Microsoft and others are still in the game. But they’ll find it an uphill battle. For now, developers can stay focused on two platforms, and that’s a win for the enterprise.