Sunday 19 February 2012

From Waterfal to Agile - A Journey (Pt 2)

Our first attempt at agile shook a few nerves. So with our confidence rebuilt after getting a number of retrospectives under our collective belt (analysing what worked, what didn't and what we could do better from our first foray into agile) a new development period brought with it a new opportunity to Go Agile.

This time, instead of changing processes for one test project the decision was "let's change process for all of them". After I'd unclenched my buttocks, I saw the wisdom in this approach - following different processes for different projects will just confuse people. The twist however is that rather than going all-out agile, we would use this development period to iterate towards agile in a manner that doesn't require the team to change everything that they've become accustomed to when developing software.

So instead of a methodology big-bang, we're dipping the toe in the water with Rational Unified Process (RUP). Generally speaking, it couples big up front design to an iterative development approach. To me RUP isn't Agile, but if you structure things just-so you can introduce the team to elements of Agile so that taking the next step of adopting a process like Scrum (hopefully) becomes a little easier. You can also start to get pointy-haired boss types used to various tools and artefacts that will come with a more complete Agile adoption.

Whilst tools do not define the success (or otherwise) of an agile project, the right tool can certainly make life easier. Initially, we had planned on using Telerik's TeamPulse instead of the more traditional mix of in-house tools + MS Project + Excel. However, for various reasons we have instead gone with the open-source Redmine project management tool along with the Backlogs plugin that provides sprint management and card-wall functionality.

It can be a little odd using an agile tool in a non-agile manner. One of the key differences for how we are using the tool is that sprints are filled with "stories that are being worked on" as opposed to "stories that will be completed" during the sprint. As a consequence, stories roll over from sprint-to-sprint. To me, this is fine for where we are on the agile journey, and is an improvement over how we previously managed projects. We get the agile-ish benefits of early feedback, iterative planning and an ability to change directions and priorities as required, married with the waterfall-ish aspects that the project stakeholders know & expect (design up-front and a somewhat detailed schedule with distinct sign-off phases).

So while attempt #2 was never intended to teleport the team into some kind of agile utopia, the approach of taking baby-steps towards that vision appears to be paying dividends. I'm still setting my sites on that utopia - it just might take a few more iterations to get there.