Agile is never ‘no process’

David comments that agile is about discipline. I could not agree more.

Having encountered organizations that failed in a previous attempt at agile, one consistent story seems to be that agile was  brought on board as a developers initiative in response to ‘lack of process’ complaints. However, agile seems to have been chosen by those developers as an answer not to up their game, but to give them an excuse for continuig with a low discipline approach to development. It’s the agile as a pseudonym for “we don’t want no stinking engineering practices paradigm”. It is for me, a big reason why agile has a bad name with some CTOs.

It is usually a shock for developers at those organizations when they encounter genuine agile, with a high-discipline approach to software engineering. That is not what they believed it to be. A lot of them balk, commenting that the high-discipline approach cannot be agile, because it seems to involve them in a lot more software engineering than they were used to. A lot of them resist BDD style approaches as taking time which they could use to deliver, at planning and retrospective sessions as getting in the way of ‘writing code’. For them agile means ‘everyone gets out of my face and I hack code as fast as I can’. There is often a corollary here with developers who have a background in waterfall projects that get handed over the fence once live. They never had to support the project once delivered, so only care about ‘time to market’ over ‘cost of owneship’ so cannot see the value of these practices.

The problem here is usually predicated not by classical waterfall approaches but organizations with homebrewed approaches to software engineering. (By homebrewed by the way I don’t mean the adapt the methodology to fit the project approach of the Crystal family, I mean the voodoo like approach of a collection of rituals to software delivery whose purpose or origin is usually shrouded in time or some incident).  The term agile refers to the ability of the methodoligies to react to feedback, not their process cost by contrast to those homebrew approaches to development.

The problem her eis often that the term agile (or even lean) don’t recognize the fact that these homebrew methodologies are usually lightwieght and that agile practices seem heavywight by comparison. Some term that implies high responsiveness to feedback might well have been better, because it is more honest at describing their benefit.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • tom rose

    I tend to run as far as possible from “passionate exponents” of any development method or means of organising projects and especially from “passionate exponents” of OO and Agile. They have a habit of assuming that what they are passionate about is right for everyone in all circumstances, for ignoring criticism, and for ignoring alternatives.

    In 35 years as a software engineer my aim has always been to deliver good quality software that meets the needs of my employer or client. I am happy to organise my work in whatever way will achieve that FOR ANY PARTICULAR DEVELOPMENT PROJECT. Unfortunately some organisations (generally the bigger ones) force me to use Agile when it gets in the way and to produce OO designs and code when any of half a dozen other ways of thinking about a program and coding it would be better (quicker to write, faster to run, smaller footprint, easier to understand, more reliable, … ).

  • Mikhail Opletayev

    Bohemian comment is inflammatory, but I think he is on the right track. Agile is not a silver bullet, far from it. While it might be helpful for some companies that lack ANY discipline it may be hurtful to some other companies. Of course, these companies are then accused of being not “right” Agile. Scrummerfalls. Waterscrums. You name it.

    Discipline has NOTHING to do with being Agile. If you want to be a successful in anything you have to be disciplined, be it software development or cake baking.

    Developers make all the difference, even though people hate to admit it. Take a look at this:

    “Hire an agile coach”. Interesting, how many successful start ups hired agile coaches to get their products to the market? Google? Facebook? Twitter?

    Process is not a viable substitution to talent. Not in software development, not in any other creative industry. While an orchestra requires discipline, each individual member must be a master of his/her own instrument.

    Just my 2c.

  • PM Hut


    From your experience, are companies who had a bad first experience with Agile willing to give it another chance? Or do they immediately revert back to Waterfall (or whatever methodology they’re initially using).

  • symptoms of diabetes

    I really liked your blog! You have some great content. Please visit my site diabetes symptoms type when you got time.

  • fibromyalgia pain

    This article was extremely interesting, especially since I was searching for thoughts on this subject last Thursday. Please come visit my site fibromyalgia symptoms when you got time.

  • Mike Schmidt


    Like Ian, there’s an interesting viewpoint under the covers here but I what I’m perceiving is that you’re of an opinion that the only decent project manager is a technical one. It’s here that I’d have to disagree.

    Without getting into the discussion of the “fads” (which I generally agree with you on), it really comes down to the bureacracy that a company imposes upon their people to follow their prescribed notion of what Agile represents.

    We still are contending in a world where companies are literally crippled by acheiving SOX compliance and the old timers that consider a design document more fundamentally sound over working software.

    I think the Agile Manifesto for all the brillance in its simplicity is probably the more problematic piece of the puzzle. When people are left to making their own judgements and intrepretations of things, we get what were presenting seeing in the world…a completely bastardized view and implementation of what Agile means with a cascading feature set of failures.

  • Ian Cooper


    It’s an interesting viewpoint, but one that is pretty meaningless without hard facts.

    Working in an organization where both waterfall and agile processes ran side-by-side until the waterfall was proven to have left behind it a trail of failed projects and agile then became the standard, I think I can say that adopting agile does the opposite of what you suggest.

  • Bohemian

    If you are doing Agile (AUP) right, you are probably doing Software Development wrong…

    And are probably wondering why with all these great Agile Processes, Methodology, etc., why your company went out of business, and you can’t find a job…

    In this Economy the guys/gals that are working and companies that are hiring are the ones that are not caught up in Agile or other fads, written about in books by guys who write books for a living and not code in the real-world for a living…

    The most successful Project Managers in Software Development, are those that still code or have a strong background in coding…

    The most Successful Software Developers are the ones that “Absorb What Is Useful” to them and ignore the rest…

    The most Successful Software Companies are those that are noted for having remarkably little or no established processes or mandated “Agile” or other methodologies…

    They are truly agile because they are not burdened by “Agile” fads, and the latest processes being marketed, or “Project Management Departments”, “Executive Directors of Software Development”, Q/A Departments of individuals whom have little or no Software Development Experience, Managers whom have Managers, Project Managers whom have Project managers, individuals, departments whom have either never coded or have not coded in ages… Bureaucracy ad nauseam.

    These companies do not care about some stinking burn-down chart, superfluous project plan that shows each individual is currently at 60% utilization, etc., they care about what matters; being the First to Market and the ones getting Paid…

    These companies epitomize the true “Adapt & Overcome” Entrepreneur spirit…

    They do not get caught up in the latest fads written by individuals whom write books/blogs for a living…
    And they are not “Google Coders”…

    Anybody whom wants to “Agile” themselves out of a job or fast track their companies demise without further help from the Socialist Obama’s Tax & Spend agenda, feel free to do so…

  • Mike Schmidt

    I think the problem primarily revolves around most CTO’s and PM’s inability to come to a level of understanding about what necessary documentation. I agree that some “agilists” try to use it as a way of nevering creating documentation to support anything they develop. I’m struggling with this concept now in that management seems to think that we need to detail every last method and stored procedure with input/output parameters. This type of documentation isn’t necessary and this is really where the perception of Agile goes off into left field.

  • Steve Kaschimer

    I would agree that agile takes a lot of discipline to do right. And it takes a lot of faith on the part of PMs, business owners, and developers alike, especially when all are so ingrained with waterfall. The worst is when a PM decides to do something to the effect of “half agile, half waterfall” and then doesn’t understand why things are out of control.

  • Kevin Hunter

    I had a disagreement with a manager at my current job over the meaning of Agile, there idea was changing backlog items in a sprint was agile development. I find people often confuse the meaning of the word with how malleable the process should be.