I’m a big fan of agile. I find it’s faster, more flexible, higher quality, lower cost and lower risk than traditional software development. I also find it a refreshingly honest and adult way of dealing with people. But I didn’t always think this way.
When I first started developing software in the late 80’s for a global IT company, most big software projects used a strict step-by-step methodology. We used an approach called Method/1. It came in 20 white binders and was commonly known as methadone because it put everyone to sleep.
Lightweight agile software development methods evolved in the mid-1990s as a reaction against these heavyweight waterfall methods. Kent Becks “Extreme Programming Explained” came out in 1999 but my first exposure to agile was not until 2000 when an evangelical XP coach talked my ears off at a party. His fervor made me skeptical.
A few years later in 2004, I worked at an online jobs company with a gentle, intellectual software architect who thought agile was a good idea and persuaded us all to give it a go. After training we implemented Agile Development on an online project using all the XP and Scrum practices we knew. We had a cross-functional team of developers, testers, a business analyst and product owner, daily scrum meetings, a feature backlog, progressive elaboration of requirements, automated unit testing, continuous integration, a project wiki and burn down charts. To my surprise and delight this was by far the smoothest, easiest and most successful project I’d ever worked on!
Ever since then I have been reading as much as I can about agile, lean and systems thinking and implementing an agile approach whenever I can.
Over the next few years I worked on larger and larger projects sneaking agile methods in when I could. In 2007 I worked on a series of large projects with a Telco using a very heavy Prince 2 based methodology. I had a picture of the methodology’s process map on my cubicle wall which showed a large number of process boxes converging on one single build step. Much to the amusement of the technical people I drew a circle around the build step and wrote “Magic Happens Here” to highlight the main problem with this approach.
During this company’s large and costly IT transformation program, the business and technical people became very unhappy with their heavy methodology. I joined a handful of internal agile enthusiasts to advocate agile and in 2010 we persuaded the COO to adopt the Agile Manifesto. This change led to one of the clearest working examples of the benefits of agile I’ve personally experienced.
Prior to the agile announcement my group spent nearly two years using the old methodology to deliver three large multi-million dollar projects which transformed the company’s online platform for Enterprise customers. As usual these projects took longer, cost more and delivered less than expected. In this case it was mainly because infrastructure was delivered very slowly and a large number of defects were found in the code delivered by the offshore provider.
After these projects were deployed in one big bang, the business asked us to deliver the most important things that had been de-scoped in the next three months before they lost their remaining budget. The vendor and I worked out that with the usual methodology none of these projects could be delivered in three months. In fact it would take more than a month just to get them started! Since time was short I asked the business, the vendor and IT management to let me use an agile approach to deliver as much as we could in the time remaining. The result was spectacular!
On the first portal, we delivered the features requested in half the time for 10% less than originally estimated. On the second portal we delivered the features required in 30% less time and 10% less cost than estimated with half the functionality deployed early. On the third portal we reduced the time it took to place a business order from 10 minutes to three minutes for 80% less than it had taken to do a similar project two years before!
One of the main reasons I joined Kiandra IT was because the software development team were committed to implementing an agile approach. If you’re one of our clients, I am convinced that this will give you a much better outcome than the traditional software development approaches you’re used to.