It seems so long ago now, but the 1990s where awash with innovation, change and achievement. It was a boom period; rising global financial markets (the bull was certainly at play!) fuelled by increasingly outrageous stock valuations for intangible, mainly ethereal, DOTCOM firms. There was growth everywhere; economy, markets, business and technology.
The desire for innovation and achievement encouraged rapid and flexible responses to change. The desire to “lead the field” or be “first to market” stimulated transformation in many sectors and areas.
Software development was one such area. Previously deeply regulated, often micromanaged, waterfall models of software development became cripplingly slow for the needs of businesses in the “new economy”. These firms demanded time-boxed iterative approaches with evolutionary development / delivery and adaptive planning. So Agile methods were embraced like a “long lost relative”.
New Agile methods were released seemingly every year. Such as Rational Unified Process (RUP) in 1994, Scrum in 1995, Dynamic Systems Development Method (DSDM) in 1995, and Extreme Programming in 1996. There were many others too.
Between 1993 and 2001, I was fortunate to work as a consultant for two global systems integration firms, plus a period as an interim/freelance consultant. During this period I become adept at using a several of the Agile methods as the firms I was employed by and the clients who engaged my services had embraced these Agile methods to impel delivery.
I’m a little hazy on the timelines now, but the Agile methods I used went along the lines of 1) RUP, 2) Scrum, 3) DSDM, 4) XP, 5) RUP again, 6) some form of hybrid RUP with DSDM. All these firms sought to deliver business value by accelerating project delivery, whilst providing flexibility to changes, and embraced these methods accordingly. In the majority of cases it worked. Certainly a vast improvement over the previous waterfall methods.
Compare this to 1990 to 1993; I worked at National Westminster Bank (NWB), a traditional stalwart of those deeply regulated, micromanaged, waterfall models. Following extensive training (at a time when training budgets seemed endless) in Structured Systems Analysis and Design Method (SSADM), including the version used by commercial organizations called LSDM (by the SSADM creators, Learmonth Burchett Management Systems) I spent years working on major systems development. Projects that had life-cycles of 12 to 24 months, deliverables delivered towards the end of those life-cycles.
SSADM is a waterfall method for the analysis and design of information systems. It encompassed aspects of the system life-cycle from the feasibility study stage through to the production of a physical design. It was generally used in conjunction with other methods, such as those used to cover of project management (I used PRINCE at NWB). SSADM represented the pinnacle of the rigorous document-led approaches to systems analysis and design. It was extensive and meticulous, and if I recall correctly, the overall process was painstaking, even with the support of Computer Aided Software Engineering (CASE) tools (I used LBMS Automate and LBMS System Engineer and recall the process being long and drawn out). Certainly a contrast to those Agile methods in use later that decade such as DSDM.
Contemporary Agile methods, like DSDM, have been proven to deliver business value by accelerating project delivery, provide flexibility to changes in business requirements, and ultimately increase customer and employee satisfaction. Unlike SSADM and similar methods (these were akin to changing the direction of an oil tanker!)
We are in another decade and amazingly the methods that I was using in the nineties are still in use. They have evolved though. Often the methods can “interoperate” with other methods. Such as PRINCE2 can be used quite effectively with DSDM Atern, the latest version of DSDM. It affords organisations needing the rigour of a project management environment (PRINCE2) but requiring flexibility and benefits of early delivery of business benefit (DSDM Atern).
A methodology assists with the processes it is designed for; rarely does it go beyond that. It is very dependent on the environment you operate in and this has a tendency to change with time. So methodologies need to be adapted accordingly.
A major success factor is the people element. It’s imperative to have the right blend of skills, knowledge, and experience to fully utilise the method and facilitate a successful project outcome.
What I have learned over the last twenty-odd years is that methodologies are critical. However, having a methodology is not the complete solution, nor does it guarantee a successful outcome.
NOTE: You’ll be happy to know that I didn’t have to endure SSADM for three years. In 1992, NWB had the foresight to create a specialist group focused on Rapid Application Development (RAD) of two-tier (traditional client-server) solutions for enterprise level customers, exploiting Object-Oriented tecniques (the methodology part evolved into the Rational Unified Process (RUP)). So an interesting “stepping stone” into Agile for me.