Transitioning to true agile development

I thought that as long as you can make changes to requirements easily and you have daily stand-ups then you’re agile. In my past projects, I was used to someone giving me something to work on and I’ll happily go about it quietly. When the work was finished I’d go back and let them know it was complete and wait for the next piece of work. Most of the time, the initial piece of work would return with additional requirements. The work could go on for weeks and weeks due to scope creep. That was my understanding of the agile development process.

A few months ago I started working on my first real agile development project and I have to be honest, it took a while for me to adjust. People didn’t give me work, using a lean ‘pull’ system I had to begin pulling work from the queue as I became available. There were 2 week sprints, pilots, backlogs, continuous integrations, definitions of done, work in progress limits, automated testing, retrospectives and of course, and the daily stand-ups. There was a lot to take in and I would be lying if I said I wasn’t overwhelmed.

However, having worked on an agile project now I can truly appreciate how each individual agile practice plays an important part in delivering software with value. Seeing the benefits of continuous integration and automated testing alone was enough. Then to see the added importance of having definitions of done, which help to reduce scope creep by providing criteria to know when a feature is truly complete.

I encourage those who are considering taking things agile to go for it. The transition can be daunting and the learning curve steep. However, the project improvements are very clear and the personal gains of being part of a well-oiled and high performing team are very rewarding. The benefits of agile development are well worth the discomfort of making the change.