In a recent scan through Google I came across a number of the articles comparing the “waterfall” delivery approach to the “agile” delivery approach. Paraphrasing, the one article described “agile” as a fad – the other article praised “agile” as the next best thing since sliced bread. The more I read of these articles, the more obvious it became that something in the IT lore had been lost somewhere along the way – the industry as a whole appears to be in a conscious effort to forget what was learned yesterday only to reinvent it again tomorrow. What seems to have been lost in both articles is the reality that the whole “waterfall/agile” discussion/debate has been going on for over 50 years.
Though proponents of these (“waterfall” versus “agile”) delivery approaches differ in perspective, the ardent advocates of each frequently fail to recognize the whole “waterfall/agile” debate is merely an extension of the ever present and necessary exercise every organization undergoes to assess and verify the value and contributions of their IT assets (staff, hardware, software). Put another way, the discussion gets down to determining how much formality and structure an organization requires to ensure its IT assets are effectively contributing value to the delivery of its products, services and internal operations. We need look no further than a couple of examples. Citing NASA of the 1960’s, the Apollo missions required a great deal of rigor to send the first space craft to the moon – a formal methodology was mandatory to ensure the astronauts were able to reach their destination and arrive home safely. Citing the teens of the early 1980’s when building games on their newly purchased Commodore 64’s - functionality was created without restriction – to them, formal methodology was a derogatory term viewed as a harness encumbering their creativity and productivity. Though we may have recently been lulled into believing the fundamental question is about "waterfall" versus "agile" we somehow have forgotten that these discussions (structure versus non-structure) have existed and been ongoing between IT practitioners since the inception of IT.
At the risk of stating the obvious, it is important that IT users and practitioners always remember there is a difference in the term” IT methodology” and how it can be applied. In one sense, “IT Methodology” is a “noun" - a path that can be used to get from a starting point to a destination (road from Boston to New York) - the road is constant and unchanging (in this context “IT Methodologies” include RUP, PMI, QAIassist, etc). In another sense, “IT Methodology” is used as a "verb" - how a project team uses the path (noun) to get to its destination (delivery approaches include waterfall, agile, spiral, RAD, etc).
For the sake of the IT industry, I can appreciate and promote the need to have an ongoing debate/discussion on the merits (pro's and con's) for each of the various delivery approaches (verb - waterfall, agile, RAD, spiral), however, the reality is that if one (waterfall, agile. etc) of these delivery approaches was ever proven to be more beneficial and successful than any of the other delivery approaches it would be being utilized by every project manager on every project by every organization. That stated, we must not ever forget that each and every one of these delivery approaches as its own merits but must remain subservient to the business and the business need (applying waterfall or agile for the sake of applying waterfall or agile must always remain a non starter).
Reflecting back on the early days of my IT career, I remember the various organizations I had the privilege to work for. On the one hand there was the "structured organization" that required a formal and structured delivery approach (ie documentation, formality, formal deliverables, etc) - a formal repeatable IT methodology (noun) was required and relied upon to consistently deliver quality applications on time and budget, it was a predictable repeatable process in and of itself. On another hand, there was the "let’s get the application out the door yesterday organization" that had a need to complete applications to meet the timeliness to market expectations on an ongoing basis (ie no time to complete documentation, no deliverables, no ongoing application support, no formal testing). My point is not to promote which of these delivery approaches or organizations was more successful, but rather, that every organization has various business needs and those needs (as part of the culture) will influence and define what delivery approach (waterfall, agile, RAD, etc) can and should be used and whether or not a formal “IT methodology” (noun - RUP, PMI, QAIassist, etc) would bring additional increases to the IT value equation.
All that said, I am hoping this article can provide users and IT practitioners a context and backdrop they can reference to continue discussing how IT tools, techniques and practices can best be leveraged to deliver increasing IT value to our ever growing client base.
Cameron Watson
Cameron Watson is the President of QAIassist. QAIassist helps
organizations increase and optimze their IT delivery and support
efficiency. QAIassist's Integrated Methodology incorporates the
disciplines and deliverables required for organizations to consistently
deliver quality applications on time and within budget.