Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Thoughts on the Decline and Fall of Agile

If you haven’t already, go give this post from Jim Shore a read.

I’ve seen a lot of commenters on this post so far, and their thoughts generally mirror my own.  You can’t take the “desserts” of Agile practices like working incrementally or the all important adaptive planning and scheduling without quite a bit of engineering practice vegetables.  You wanna work adaptively instead of the ol’ fashioned plan driven method?  Fine, but you’ve got to make that adaptability safe.  You need rapid feedback cycles to know when you’re getting off the rails (customer demos, TDD, Continuous Integration, automated acceptance tests, static code analysis or some sort of equivalent).  You need to take steps that make continuous design methods safe and effective (simple design, a constant attention to design fundamentals like the SOLID principles, and an intolerance for technical debt).  And your team needs to be retrospective about its work to make adaptions as they become necessary.

In the early days, XP was roundly criticized because every practice only seemed to be safe due to the existence of the other practices.  Take one out, and the others weren’t that great by themselves.  I think that’s more or less a fair criticism, but my response is simply to adopt, and effectively apply, everything you need to make Agile development successful.  You can’t just pick and choose the easy things.  If you take something off the old XP practice recipe, you probably need to find an analogue solution to add something else back into your practices.  Regardless of which practices and how you do those practices, there are project needs that have to be filled (planning, quality assurance of some sort, feedback cycles, etc.).

Of course, it’s always going to be easier to get it wrong than right, but that’s why we’re paid the big bucks.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • New Jordans 2011

    True happiness… is not attained through self-gratification, but through fidelity to a worthy purpose. Unless we form the habit of going to the Bible in bright moments as well as in trouble, we cannot fully respond to its consolations because we lack equilibrium between light and darkness. Until the great mass of the people shall be filled with the sense of responsibility for each other’s welfare, social justice can never be attained. Walking with a friend in the dark is better than walking alone in the light. We can do anything we want to if we stick to it long enough.

  • http://http://agileconsulting.blogspot.com Jeff Anderson

    “it’s just my bias I suppose,…”

    I think we are trying to get to the same end goal here. This just more than one route, I typically start with the project management practices because the first conversation I have with my client is typically with a VP or some CxO type.

    trying to explain the value of TDD at this level is like trying to explain the value of air to a rock, at least IMHO

    To lot easier for me to start with talking about things like iterating, multiple levels of planning, and getting everyone together for daily standups.

    I’m pretty happy if I can get even these things adopt, but of course never being satisfied, once they are, I immediately start shifting the conversation to the technical practices, because at that point I’ve actually had sufficient exposure to the people who are actually responsible for getting stuff done.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    My advice to you would be to stop worrying about whether someone else thinks your “Agile” and maybe start thinking about what type of software engineering practices will make your little Scrum project management work better.

  • http://www.noop.nl Jurgen Appelo

    I wrote my own reply to all agilists who are preaching that certain agile practices are required to be called ‘agile':

    The Decline and Fall of Agilists

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    “iterative development forces teams into a mode that makes it necessary to start adapting the other best practices just to survive…”

    Sure, but how do they even know that they need these things? It’s just my bias I suppose, but I’d rather start with the engineering practices first.

  • http://http://agileconsulting.blogspot.com Jeff Anderson


    While I agree that the value of agile grows exponentially with the adoption of each additional practice, I find it really hard to get my clients to digest and transform using all of the practices in one go.

    I find it better to start with the easy stuff, and evolve to the harder stuff. I usually start with iterative development, because the business usually sees incredible value at being involved in the process at the beginning and end of every iteration. I also start with daily standups, because it’s another easy one and the value is immediate.

    Of course, iterative development tends to go off the rails without all of the other good stuff like TDD, continuous integration, good code standards, etc., the velocity starts becoming slower and slower. I’m usually okay with things going off the rails a little bit, this allows me to start introducing some of the other practices depending on the situation.

    I think I read in one of Scott ambler’s articles that iterative development forces teams into a mode that makes it necessary to start adapting the other best practices just to survive…

    it seems to be working out that way in my experiences anyway…

  • http://colinjack.lostechies.com Colin Jack

    “Jeremy… it seems like agile (even TDD) must have support from the top or all the middle manager types revert to command and control tactic”

    Agree completely, the problem is even if an upper manager does “buy into” agile they don’t necessarily think that it affects them and their role in the process. Some managers love going out and making promises, the thought of going back and discussing things with the developers just doesn’t appeal.

  • Brad Mead

    Colin said:

    “Couldn’t agree more. I’ve certainly seen what happens when only half of your development team buy into the agile principles, I’ve seen what happens when management don’t hold up their end, I’ve seen what happens when principles are treated as a pick and mix. None worked.”

    Colin you took the words out my mouth. I was lured to my latest job with the promise of XP style dev but when the owner marched in a declared everything HAD to be done by X date, it just fell apart — Devs who were lukewarm to TDD easily revert to comfortable “I will do it my way” cocoons.

    So now I embark on journeys in defense of “irrelevant” tests (which in cases be true – but at least there ARE tests).

    Tests in assemblies already created but now being worked on by other devs. Tests that saved my butt on more than one ocassion.

    Jeremy… it seems like agile (even TDD) must have support from the top or all the middle manager types revert to command and control tactics. What’s more I’m in an org than doesn’t even have faith in key working groups understanding and coordinating domain concepts. Had to pull teeth just to get some notion of observable “contract” points established between different groups of the respective value chain. Historically, these have occurred as ad-hoc, rushed and debt heavy integration points.

    Suffice it to say that I now realize the the value I represent as someone committed to better ways. Somewhere out there Agile/TDD will win and those wins will slowly compound until a critical mass of jobs are out there for committed agilists… Hope to see some of you there.

  • http://blowmage.com/ Mike Moore

    This isn’t surprising to me at all. I have long thought that Agile was fundamentally misunderstood. So I fully expect that many of those teams that think they are Agile but aren’t to fail.

    Also, I love Uncle Bob’s response as well.


  • http://colinjack.lostechies.com Colin Jack

    Couldn’t agree more. I’ve certainly seen what happens when only half of your development team buy into the agile principles, I’ve seen what happens when management don’t hold up their end, I’ve seen what happens when principles are treated as a pick and mix. None worked.

    More importantly where are these big bucks?

    Oh and you might be interested in Robert Martins response:


  • http://www.dynamicalsoftware.com Glenn

    I recently reviewed a great IEEE article (see http://www.dynamicalsoftware.com/cgi-bin/ViewBlogEntry.pl?id=15) that was originally written in 2001 but looks to be just as relevant today as it always has been. It’s too bad that some rally around the Agile banner because they see it as a justification for abandoning sound software engineering practices which, by the way, it does not.

  • http://www.rasmuskl.dk Rasmus Kromann-Larsen

    Thanks for the heads-up – good read.

  • http://neildoesdotnet.blogspot.com/ Neil

    I agree with what you’ve written, for me it comes back to the twelve agile principles. If we as a development team lack the discipline to ensure that each of these twelve principles are adhered to then we invite issues of the sort that Scrum’s (and Agile’s) accusers make reference. For me, Scrum provides a framework that makes the introduction of Agile into an organisation easier. But it is only ever a starting point, a way to get the first four S’s of the 5-S model established, before the fifth S, Shitsuke, can be applied.

    I have written a full post on my blog about this as a reaction to your post, James’s and the recent post on the Uncle Bob blog, which I hope you won’t mind my linking to: http://neildoesdotnet.blogspot.com/2008/11/defending-scrum.html