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.
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.