I’m a “little a” type of guy. I don’t care much for the branding and commercialization of Agile methods. Aside from some industry de facto standard practices like continuous integration, test-driven development, or refactoring, I don't care much for process-specific lingo, either. Instead, I find that gluing together proven practices and techniques offer the greatest chance to deliver superior software.
So what's the difference between "little a" and "Big A", you ask? The "little a" crowd cares about software delivery. The "Big A" crowd cares about software process. The "little a" crowd doesn't care how you develop software, so long as you deliver a quality product. The "Big A" crowd tends to get caught up in software process improvement efforts and lose sight of developing the product. The "little a" crowd cares about developing better software. The "Big A" crowd cares more about developing software better. "Little A" is about software delivery. "Big A" is about software process.
It’s not that Agile methods such as Scrum or XP don’t hold tremendous promise, but instead that adoption of these methods by many software development teams is flawed. True agility is not something that you can simply adopt, but instead is something you aspire to. Unfortunately, it’s easy to get trapped by “Big A”. To the unsuspecting team, “Big A” makes many wonderful promises – speedier delivery, higher quality, reduced risk, and more. New breeds of tools claim to support “Big A”, as well. Add it all up, and “Big A” results in little more than varied manifestations of the same problems that have plagued software development for decades. Don’t misinterpret the message here. The practices espoused by Scrum and XP are a step forward in terms of process evolution. But blind adoption of an Agile process does not guarantee increased agility. “Big A” methods exist to help you discover “little a”.
“Little a” is a pathway to increased agility paved with practice. “Little a” is embodied in the Agile Manifesto and its twelve principles. While “Big A” may be black and white (we use Scrum vs. we don’t use Scrum), “Little a” is measured by ability. The ability of your team to respond to change. The ability of your team to frequently deliver functional software. Large process improvement efforts typically fail, often resulting in methodology wars that place process improvement efforts above software delivery. In fact, I suggest we banish the phrase software process improvement and replace it with software delivery improvement. Possibly the change in perspective will yield more positive results.
"Little a" is always a good thing. Why would we desire to be anything other than nimble and responsive to change? Slow, brittle, and inept are not defining characteristics of success. Going forward, I’ll be posting entries that build upon and embellish these ideas. Stay tuned.
Comments