I was watching the gymnastics competition at the Olympics on Sunday night and on more than one occasion heard commentators applaud competitors for their agility. As I watched these gymnasts move swiftly and with exacting precision across the beam, floor, vault and bars, I could not help but marvel at their abilities and at how appropriate a descriptor “agile” was for them.
Long before businesses tossed around the term “Agile” as a method of technology project management, it stood as a word that often affixed to people and objects that displayed a certain set of characteristics. People earning the moniker “agile” almost invariably were both fast and nimble – not just one or the other, but both. These people were quick, clean and to the point. They operated with not only a swiftness, but also a high degree of accuracy.
Jack Be Nimble
There’s no question that when business enables agile to be both quick and nimble, it can succeed and limit a company’s technical debt to a workable levels. As Microsoft’s Bryan Group points out on the Microsoft Developer Network’s ALM and Beyond Blog, “Some may say being Agile will always sustain TD but I disagree. If you look at Scrum’s three pillars: transparency, inspection, and adaptation it’s clear that abiding by these principles will help ease or for that matter eliminate TD.”
Notice, Group’s focus is on the characteristics of Scrum that deal with achieving accuracy in project management – transparency, inspection and adaptation. What all three of these elements have in common is the taking of time to communicate during the build process and to work quickly and effectively toward a definitive goal. It’s a speed and nimbleness that does agile development proud.
As an avowed Scrum advocate, Group proudly proclaims:
“Beating the Scrum drum even harder, if used properly it’s such an elegant solution to the TD problem. As mentioned, all the members of the project team have visibility into one another so if by some reason a Sprint occurs and TD rears its ugly head, it will most certainly be shown in the Sprint Review and/or Retrospective phase.”
Jack Be Quick
Unfortunately, Marketing Departments today too often hear “agile” and think fast…and only fast. Pushing a product to market before its time, though, almost always has disastrous results. Witness all the instances last year of when it appeared Marketing favored speed over quality. There was Apple admitting just one week after the release of the iOS 5 operating system that a bug in the system caused a major battery drain. That same week, Google pulled its iOS Gmail app from iPhone App Stores due to a bug that causes a “notification error” or any of a myriad of others.
These decisions to place time to market ahead of quality cost businesses money and increase their technical debt. Not only that, such thinking is short sighted.
As Group notes:
“…say that TD is a necessary evil when entering an emerging market because the ability to be first is paramount. Meaning: ship a v1 product at all costs (read: quick and dirty) and worry about fixing any defects, feature enhancements and other items in v2. While being first may help you garner attention and potential market share, if the application quality suffers then you’ll never have the chance to produce a v2 product and your competitor who understood the ramifications of TD will reign supreme. Not to mention if you're a consulting company who continually does not meet milestones and/or creates an inferior product, the contract with that customer may not be renewed.”
Agile done right – that is agile development that is allowed to be both quick AND accurate – can be highly successful. Agile that just tries to be quick comes up short and whether it’s a gymnast going over a vault or Jack going over his fabled candlestick, coming up short is a painful prospect.