Agile software, continuous delivery and passionate users

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 software development methods 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.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

4 thoughts on “Agile software, continuous delivery and passionate users”

  1. I like what you are saying about continuous delivery. I want to point out that one way to not “push out bugs” as @michaelneale mentions above. Agile teams need to have a comprehensive approach to test driven development and continuous integration. When you are writing test from inside the code and you don’t see a few failing unit test and integration tests when you add new code, your not catching the defects at implementation time. That is ok, because hopefully you have scenarios and examples for your web application that you run from outside the code in your continuous integration regression suite. If you don’t have either of these setup then you will be pushing the bugs out faster.


  2. Actually Jez Humble and I wrote ‘Continuous Delivery’ but I am not bitter ;-)

    Continuous Delivery isn’t about releasing every single change live immediately, it is about being in a position to release. I agree with you that for some projects a process of what Jez and I would term “Continuous Deployment” in contrast to “Continuous Delivery” may not be appropriate. The difference is really that in C. Deployment every commit by a developer flows through and is deployed into prod automatically if it passes all tests.

    On my current project which is a big complex financial trading system, we defer releases until the end of each iteration, 2 weeks, but every commit is potentially capable of release providing it passes all of it’s automated testing. We have been in development for some time but have not yet released this application live to the general public, but it has been running and been in use for many months in our production systems. This provides a degree of control over when we choose to release, but the discipline of keeping everything working as it should in-line with my view on continuous integration and continuous delivery.


    1. Thanks Dave, and please accept my apologies for my omission; I’ve fixed it now.
      Thanks also for your clarification regarding continuous delivery and continuous deployment. That makes sense in some different contexts.


  3. Actually I don’t think this needed a rebuttal.

    Having worked in rigorous SW Eng environments, then experienced ‘IT development’, the only thing that makes sense in the latter environment is Agile. Sounds like it didn’t come across.

    RSM works where the domain is really well defined and the language and technology that is used to address the solution is contextually close to the problem. I know this. I’ve seen it. BUT it is a rarified air a project breathes that works in completely fixed, clear, unambiguous requirements.

    The real problems occur because the customer doesn’t appreciate the cooking process, and they aren’t sure about the menu

    Agile picks this up far sooner, and I far prefer a more iterative process where the maturity of the organisation is unaware of its own maturity, or where the problem space is sufficiently ambiguous, and requires clarification as soon as possible.

    For engineering projects it would be nice if an RSM could be employed; if the organisation is at a sufficient maturity level (domain, process & tech expertise) but the reality is that you have to tailor your process for the lowest common denominator. (Ahem . . . .BAs, customers, actually whatever the weakest link is).

    And that is the reality. Managing customers through BAs. I love RSM but where the organisations core function is Banking, or Travel, or Chocolate, engineering is the last thing on their mind and quite reasonably so.

    I dream of RSM but I push for more Agile to keep the course heading correct. The TTM pressure will increase as customer’s (read ‘market’) needs are going to be the biggest driver for innovation, leading to greater and greater pressure on communicate with your customer.

    Where 2 year projects were the norm in telecomms, look at how innovation is currently delivered? Unless you really know what the customer wants, you have to work Agile.

    My point still stands. Companies move to Agile thinking it will fix their ills. Agile requires the same level of commitment and effort to ensure delivery. I see only lip service paid to the Agile Manifesto by many organisations. Epic Fail. Status Quo on SW Dev maintained.


Comments are closed.