Part 1: The beginning

A year or so ago, agile was one of those words that I heard often but didn’t really understand. I’d certainly not worked in an agile environment before, unless you could call lurching from one deadline to the next without catching a overdue bullet from management. I wanted a change…

I currently lead a small software team and like many people who write software for a living I’m all too used to the mad dash towards a release date where working hours become blurred into a never-ending stream of late nights; and the insurmountable to-do list is …well always insurmountable. These agile teams whose experiences I began to read about that espoused working ‘in an agile manner’ seemed to not be always be one step from disaster, producing buggy code and never quite making all the planned features. Instead, they produced high quality code with few bugs and not only made their deadlines, but made them with exactly the features they had planned to include. Clients were happy, the team was happy and late nights were for spending at home or out on the town.

These agile teams used terms like user stories and made quips about post-its on boards. They said they were things like XP, AUP, Scrum, Lean or Kanban and practiced test driven development [TDD] or behaviour driven development [BDD]. They had stand ups, iterations or sprints and held retrospectives. Releases were never a problem because of their continuous integration and build automation. Their agility or velocity was consistently high and sustainable. They also did pair programming and created documentation only when there was a clear need for it instead of the big design up front [BDUF]. They talked of the benefits of refactoring code smells, unit testing, component testing, integration testing and database sandboxing. It made my head hurt quite frankly!

This series of posts is about my journey in moving towards agile principles of software development including both the mistakes made and the successes, and later in the series, the things I’m still working on. I’m not an expert on this subject and am still making mistakes every day, but as long as I can learn from the mistakes and not repeat them, I know I’m moving in the right direction.

Where I was…

All these terms I’d come across but didn’t really understand or know where to start. My previous experience had been more in the traditional waterfall style of project management, creating reams and reams of highly detailed requirements and software specs before even a line of code was written. We would get sign off from the client and agree any milestones/payments and off we would go merrily into a new project. Months would pass and we would begin to grapple with all the things we hadn’t anticipated in the planning stage, deadlines would overrun and we would be under pressure to get it out the door.

So we cut as many corners as we could, sometimes tried to negotiate with the client for more time or a reduction in spec, and all the time was pressure, pressure, pressure. The testing time was usually the first sacrificial lamb. Finally after an exhausting effort we would ship it out the door for the client and pat ourselves on the back for having ‘pulled it off’.

Then came the problems…

The client wasn’t happy, the software was buggy and this or that feature was missing. Where was the feature that he had talked about. Often we would refer him to the 400 page specification document, page 284, Section 31, Heading 4. After all, we did this for a living, of course our documentation would back our side, and there on the last page was the clients signature. So we would spend far too long finding and fixing the bugs and the client would usually pay just to get the whole ordeal over with.

I knew I was pretty sick of it and wanted to change, to improve, to not have these kind of problems anymore. If this sounds familiar, it is probably because sadly it seems to be norm rather than the exception in the software industry, at least in my neck of the woods. The exceptions are the ones who deliver stable feature-complete software on time, on budget to satisfied clients, those seem all too rare.

I should point out at this stage though that any project run badly, whatever methodology is used, will usually end in circumstances like the one above. My main problem with the waterfall approach though was that even a well run project could run into some of these problems. It made sense to me that if the client wasn’t involved in the process and couldn’t see the software evolve, then of course we would miss-out altogether or misinterpret their requirements. Also the effort required for the final integration and rollout always seemed to be epic; months or even years of development had to be rolled up into a neat package ready for production use.

Going even further than that, rarely do clients actually even know what they want in a software application, they usually know exactly what the problems in their business are that they want some software to solve though. Finally they never really read the war and peace sized documents properly before they signed them either.

Part 2 – Time to change >>