AGILE Enough is Enough !
During the week Computing Magazine, one of the best freebee computer magazines I know, dropped through the front door. All was going well until I reached the analysis section and Fig 1 :-
Fig 1 Government versus non-government adoption of AGILE
It states that AGILE another “No Pain High Gain” methodology is on the ascendance, and appears to be taking the intellectual high ground.
However, it looks to me like a suffocating fish trying to trash about in a useless attempt to find the next potential life saver. This trendily named method is nothing new, as I have come across it at various points throughout my IT career. However, in those days it was referred to as the SOP (Seat of the Pants) or JFDI (Just F***King Do It) development method. These names don’t sound so good do they? Such approaches to system development only work in a limited range of circumstance for systems of a particular type /level of complexity. In my view AGILE is nothing more than a posh word for hacking together software.
The interesting fact to bear in mind when considering an AGILE implementation is the fact that most IT project surveys state that, IT projects which are less than 6 people and 6 months in duration make up the large majority (over 90%) of the 10% to 30% of successful IT projects delivered. Websites are an excellent example of how small scale IT projects can be delivered successfully. Also, development of some of the worlds most famous software applications fit this category i.e MS DOS, PKZIP and believe it or not NETSCAPE.
The reason why small projects turn-up, irrespective of method used, is because:-
- The requirements and technical design can be visualised in the mind of one person.
- Requirement changes at any point in the design /build phases are quick and easy to make, and tend to have small impact on the project drop date /costings.
- They tend to be applications which are visual based (easy to prototype WYSIWYG), negating the need for detailed requirements
- Contain few lines of code and thus less “buggy”.
- Usability & Maintainability issues tend to look after themselves, especially when many of these apps are regarded as disposable with short life spans
- Low requirement for reusability in terms of any future migration path.
You don’t need a book, or employ a management consultant to tell you about this rebranded (AGILE) collection of resurrected paradigms. Just do what EGG.com has successfully done for years – employ young talented system developers, give them high level feature based requirements, shut them in a room and time box them on an “or else basis”. Then, providing you give them on demand, super gulp drinks, pizza and Mc Dee ready meals, and allocate space for sleeping bags then MAGIC happens. Steve Jobs from Apple built his empire on working practices like this.
The problem with AGILE /SOP or JFDI is that the world has moved on since the Alto and MS DOS. Today’s enterprise level applications, and even desktop software like VISTA, are hugely complicated with 10s of 1000s of lines of code and dependence on other layered proprietary software products, which often have unknown latent system defects. It is these types of applications which are the source of most of the 70% + annual IT project failures (CHAOS Standish Group).
It is clear from fig 1, and from my experience of working along side one of the leading AGILE software houses, that AGILE is being mistakenly considered /pushed as a viable development method for large scale software engineering projects. The strange thing about this is that some of the founding fathers of AGILE, such as Martin Fowler, have in the past recognised the limitations of AGILE –
Here are some of is his words of wisdom :-
“If you want to build a doghouse, you can just get some wood together and get a rough shape. However, if you want to build a skyscraper, you can’t work that way – it’ll just collapse before you even get half way up.”
The thing I would like to know is whether people like Martin are willing to make the same statements today, with the fees juggernaut running at full pelt?
Today’s PLC’s /Governemnt Departments aren’t in the business of building Dog Kennels, and the large scale systems they do want need to have the following characteristics:-
- Functionality capable of giving a clear competitive advantage - This nearly always involves complexity
- Ability to constantly upgrade Functionality overtime - Release programme of enhancements to meet changing business needs
- Maintainability
- Reliability – Low number of software errors combined with high levels of availability.
- High standards of usability.
- Clear future migration path
- Predictable and reliable development costs
To name but a few!
It is clear that AGILE is not the “Holy Grail” of System Development Methods and, as with everything, it does have its place, even if it seems to be reinventing the wheel.
I suggest you keep looking for the Holy Grail because it is out there, but always “be suspicious of any methods that just look too dam good to be true (No Pain High Gain), because the sad truth is they usually are !”
This entry has been viewed 11358 times.
READER COMMENTS:
All contents copyright © 2006, Kingsmead Internet Investments. All rights reserved.
Hi Kevin, I’m sure I don’t have as much experience as you but my own experience is all I can go by.
My understanding, from reading and experiencing what I’d describe as an ‘agile’ philosophy is that the following elements are valuable contributions to any project:
- early, regular and tangible visibility of true project progress in a way that business owners can understand (it could be working software, but it won’t be a skin-deep prototype as this sets very high expectations)
- high level of flexibility when it comes to changing priority or even presence of items
- focus on high quality communication—colocation is one very effective way
I’m both a ScrumMaster and a PRINCE2 Practitioner and I’ve worked in a wide variety of environments. If you inject the above concepts then you’ll almost always be better off than not, IMHO.
Posted by Julian on Tue 18th July 2006 at 10:24 AM | #