The Agile methodology has come a long way since it first peered out at the turn of the century and behaved like a David to the accepted methodology – the mighty Waterfall, the Goliath of methodologies, the benchmark for every technology shop in the IT universe. Walk the halls and sit in any meeting of every Financial Services firm at the time, from the behemoths on Wall Street to the Web startups, and you’d hear from business executives, “When can we get these changes done? They seem trite and should not be a major issue.”
The answer, inevitably, was often along these lines, “Well, we don’t have the requirements documented. Therefore, there have been no reviews and sign-offs, so I can’t give you a date.” Now on the odd chance that the requirements were published, the answer usually manifested itself as, “We have to fit your changes into other known requirements since we only do releases twice a year,” and so on.
The curse of the Waterfall – living in an IT silo of technicians who coded for IT victories and not solving the business problems at hand, had to go – or at least be supplanted by a nimble, integrated business and technology model. Today, that model is known to the world as Agile.
To most IT historians, Agile got its wings in 2000 when a consortium of seventeen like-minded professionals met in Oregon. Coincidentally, this took place at roughly the same time that our founders, John Polito and John Crocker, were launching Enterprise Iron on the East Coast.
Led by Bob Martin, or “Uncle Bob,” who is recognized as the Pied Piper of Agile, the Group of Seventeen had two major goals in mind: minimize the time a working software model gets into the hands of the user community and respond to those users as rapidly as possible. That’s it! Seems easy, no?
However, the climb to modern-day Agile was a road fraught with resistance by most everyone in the legacy IT divisions. Some of the loudest cries came from the Financial Services community, including the owners of the siloes, “All our quality gates have just been run over,” the regulatory and compliance people, “Hey, I can’t tie back the published requirements to the output,” and often the loudest calls, “We are going to get sued to no end and the SEC will have our backsides in a sling!”
The Group of Seventeen plowed ahead in determined fashion, and their next summit, the now famous 2001 Snowbird meeting, resulted in “The Agile Manifesto.” I suspect that Luther and Marx (Martin and Karl), the authors of the two most famous manifestos to date, did not lose sleep over the significance of this new manifesto. For us IT soldiers, the document would soon become the basis for our new marching orders.
The four pillars of the manifesto read something like this:
- People and their inputs and interactions are significantly more important than the rigid processes, rules, and software that have defined the existing environment. AKA, silo walls are coming down.
- Working pieces of software must be developed and demonstrated as soon as possible. The delivery packages of the day were bound to be rendered obsolete by this bold commandment. No longer is the user demonstration one of the last pieces of the development process. Now it is required that the user community be involved and continually provide feedback in real-time.
- The new paradigm demands that IT technologists and representation of every possible business stakeholder all huddling in the same room. Totally verboten before Agile! IT staff quaked in their boots over this, and some still do not believe in this ‘radical’ concept.
- As soon as a change is agreed to start the development as quickly as feasible. AKA, what we lovingly refer to today as “sprints.” Change is good! The rigid legacy project plans of yesteryear live no more. Let’s show the users what we can do, especially since the languages, tools, and processes that technicians had to work with were changing. The COBOL mainframe world, the legacy platform that our founders grew up with, was also changing. New tools like C++, Java, platforms like .NET, and something called “The Web” were maturing simultaneously.
Software Development, as we knew it in 2000, was going the same way that landlines, VCRs, and beepers were – straight to the recycle bin. My next article will discuss the uphill battle that the Agile Army fought to make it into the IT mainstream and become recognized as the ‘de rigueur’ method of building software. Contact us today for Enterprise Iron’s Agile expertise and staffing capabilities.