From Waterfal to Agile - A Journey (Pt 1)

The company I work for tends to be somewhat conservative. It's fantastic in that it's a company who's primary reason for being is the creation of awesome software; it's been pushing out software for many years with a lot of success. Which is where the conservative culture comes in... We didn't need/use/want shiny X back then, why do you need it now?

As an internal observer, it pretty much seems like the prototypical organisation distrustful of Agile referred to in books and blogs (though we probably only fit four of the six signs in the link - as one colleague commented "it's like they're watching us"). However, to the company's credit, things are slowly starting to change. Granted, sometimes it can feel like two steps forward, one back; but I think the momentum might be starting to push things ahead.

The kind of development my team is traditionally involved with falls roughly into two categories:

1. Large Enhancements - Traditional Waterfall delivering new features with big up-front design; massive coding efforts; then a concentrated testing effort trying to mop up all the bugs before eventually shipping out the door.
2. Bug Fixes - Code & Fix on shipped software with priorities driven by whichever fire is burning brightest & no-one being particularly happy about the lack of strategy behind the fixing effort.

The deficiencies of these approaches are well understood and Agile (any Agile) seemed like it would be a better place to be in. However the trick always seemed to be finding the right project to trial a new methodology in order to demonstrate the benefits that could be achieved. Well, if you can't choose, then one will be thrust upon you. So, we got our project... but it sure wasn't the right one. The project didn't fail (we still managed to ship), however there were some things that definitely didn't contribute to a smooth-running project.

Lessons Learned:

• Ensure everyone on your shiny new agile project has a shared understanding of what agile is, and the nuances of the agile flavour you are adopting. There were some big assumptions made that people across all disciplines were talking the same language.
• Don't try to maintain the same artefacts from your old process. Accept & embrace the change.
• Avoid cross-team dependencies for your first ever agile project like the plague. Different teams have competing priorities and deadlines that may not be compatible with your project.
• Give people on the project the power to be 100% dedicated to the project. Don't saddle them up with multiple competing projects to be delivered within the same timeframe.
• Ensure the team sits together - the daily standup shouldn't be the only time everyone talks with each other throughout the day.
• Ensure that you customer is able to engage with you in the manner & frequency that Agile methods require.

The pain and frustrations that this project brought about lead to a brief period where Agile was only talked about in hushed tones with averted eyes. Thankfully, we didn't get to the point where Agile was completely dismissed (we all knew the mistakes that had been made). However, this again put us in the position of trying to find the "right" project to Go Agile.

To be continued in Pt 2...