Fast or Nimble? Agile Should be Both


Agile-Technical-DebtI 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

Agile-Software-QualityThere’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.

Filed in:
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Jonathan Bloom
Jonathan Bloom Technology Writer & Consultant
Jonathan Bloom has been a technology writer and consultant for over 20 years. During his career, Jon has written thousands of journal and magazine articles, blogs and other materials addressing various topics within the IT sector, including software development, enterprise software, mobile, database, security, BI, SaaS/cloud, Health Care IT and Sustainable Technology.
Load more reviews
Thank you for the review! Your review must be approved first
You've already submitted a review for this item