Rowly Emmett, a test consultant who lives here in Queensland, Australia, recently dismissed agile software development in a blog post titled “Agile Recipe“.
“…there is no difference between Agile and Waterfall”
“The thing is, if people followed the (rigourous software methodology or waterfall) process correctly, then they wouldn’t need to try out Agile.”
Rowly says it’s not really about your software development approach, but how rigorous you are in your chosen approach. One of the things that Rowly wrote that stood out to me was:
“I believe the process should adapt to the conditions of the project and the needs of the application.”
But that’s what agile is about isn’t it? Adapting and evolving solutions through collaboration.
Rowly finishes by listing some of the conditions for a project moving to agile, which included:
“Is the domain ABSOLUTELY clear (does the customer really know what they want?)”
But I’d actually say that’s one of the reasons I have seen agile work over other methods, in that customer needs can evolve iteratively, rather than having to be specified upfront which is more likely to produce something not needed at the end.
I would say my biggest criticism of Rowly’s article, and why I disagree with it, is he’s looking at it from a pure methodoligical viewpoint, rather than what it does differently and what that can ultimately deliver. Sure, a project will fail if it’s done poorly, no matter what methodology is used. An agile project will probably fail sooner, but if done correctly can ultimately deliver better outcomes. Not just that, it’s increasingly anti-competitive to use non-agile methods to deliver software. So it’s no longer a choice, but a mandate. I’ll explain in a bit more detail using a case study.
Google Docs and how they deliver software
I have no idea what methodology Google uses to develop its Google Docs product, but I know they must use iterative agile techniques. How do I know this? Because I am a passionate Google Docs user and I subscribe to the Google Docs blog. Every couple of days Google Docs releases some new functionality into Google Docs, and they write about it on their blog. They couldn’t do this using a waterfall methodology. They’d release new functionality every few months, or years. Compared to Microsoft who bring out a new product with lots of bundled enhancements every couple of years (Office 2003, Office 2007, Office 2010), Google release some enhancements every couple of days.
How does this make me feel as a user? Passionate. I love that there’s new functionality every couple of days, as it allows me to master it and kick ass. As I recently tweeted:
Which is exactly how you want your users to feel. As Kathy Sierra explained during her great Business of Software presentation: you don’t just need users who think you’re company is awesome, or your product is awesome, but rather that they’re awesome, when they’re using your product. Like when I showed the expenses app I built with Google Spreadsheets and forms to my wife, and because she was so impressed I felt awesome. Like all the tweets I saw about the Gmail Priority Inbox, something that was delivered immediately, iteratively, not through an ‘upgrade’.
If Google Docs was developed using a rigorous software methodology, it may have only just been released, or it may have not even been released yet. And I certainly wouldn’t have had an opportunity to get excited about all the incremental improvements I have seen over the past years.
Moving beyond the Project into Continuous Delivery
The Google Docs case study highlights a bigger point, that Google Docs is a product, and not a project. As Evan Bottcher (a Thoughtworker from Melbourne) recently wrote on his aptly titled blog post: Projects are evil and must be destroyed, we need to move beyond looking at things as a project that are eventually handed-over to BAU, and move towards “form(ing) long-lived teams around applications/products, or sets of features”. Like the Google Docs team, who continually develop and deliver functionality to Google Docs users (and write about it). There’s a name for this concept, it’s continuous delivery, and a fellow Thoughtworker Jez Humble recently published co-published (with Dave Farley) a book about it, titled Continuous Delivery.
My bugbear with Continuous Delivery
The only downside I see to continuous delivery is when it’s used in an environment that needs to be actively upgraded by users; it’s no point pushing out new functionality daily if your users have to do an upgrade daily. One place I see this happen prevalently is iPhone apps, how many apps need updating every time you check? Too many in my opinion. In a web environment, such as Google Docs, continuously delivery rocks! In a non-web environment, such as iPhone apps, browser, firmware and OS updates, it sucks. As Michael Neale recently pointed out on Twitter.
Firefox are doing some work in this space around passively delivering (minor) updates, but there’s still a lot of work to do in this space if we’re going to have continous delivery of non web applications.
Wrapping Things Up
I started off by disagreeing with Rowly in his views on agile software methodology in that it doesn’t matter. I believe we no longer have a choice, we’re at a point where it is increasingly uncompetitive not to be agile, as we need to deliver soon and the way to do this is through iterative and incremental development and continuous delivery. This is even more important for environments where the domain is unclear and the customer doesn’t know what they want. Delivering software this way is also great for creating passionate users who feel they can master what you give them and kick ass.
