big

NOOP.NL | The Creative Networker

The Decline and Fall of Agilists

05/02/2009

Ant
There once was a time when being agile was being a visionary.
Agile experts wrote books on how adaptive software development is about managing complex systems (Jim Highsmith), why agility is a cooperative game (Alistair Cockburn), and how being agile (or lean) requires a new way of thinking (Mary & Tom Poppendieck). The Agile Manifesto itself was a visionary masterpiece. So simple, so powerful, and so… Well, I wanted to say 'perfect', but nothing is perfect. Not even me.

Then came the agilists…

Nowadays, agilists are telling me that in order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary. They tell me that everybody needs unit tests, and that Scrum makes things worse by ignoring important (but hard) agile engineering practices, and that you're not agile if you don't have a build integration at least once a day. According to these agilists, being agile is not about being adaptable and doing whatever it takes to make your project a long-lasting success. These days, agilists simply claim that agile is about following practices X, Y and Z. Extreme Programmers often joke that Scrum is just XP without the technical practices that make it work.

And my feelings of inspiration changed into guilt…

We have fully adopted Scrum in our organization, but our adoption of XP practices is still far from completed. Are we now inferior to others? The agilists keep saying that Scrum without XP practices will result in a build-up of technical debt, lower productivity and failed projects. Every time I was reading this, I felt there was something not right about the picture that was being painted. I felt I had to respond, but I didn't know how.

Until today…

Today all our project managers agreed that the introduction of Scrum has increased the success of our projects. I've heard our software developers confirm that (because of Scrum) they now finally have at least a chance to keep technical debt away. A chance they didn't have before. Our customers tell us that our projects are now of higher quality. And last week our CEO complimented everyone in the organization on the measurable progress we've made. (Actually, I'm still doubtful about those hard figures, but who am I to complain when the gold medals are handed out?)

And all that without XP. How?

Why is it that every agilist and their uncle are warning people not to adopt Scrum without XP practices, while our organization seems to be quite successful doing exactly that? Well, to understand what's going on we need to do what the average agilist hasn't done in many years… which is to THINK, and go back to the roots of agility.

I am referring to complexity theory

The Edge of Chaos

Agile software development has some of its roots in complex adaptive systems theory (also called complexity science). One property of complex systems is that they find themselves at the edge of chaos. That name is so badly chosen, one might think that Microsoft had something to do with it. You see, the edge of chaos is also the edge of order. It is actually the narrow edge between order and chaos. These days, scientists prefer to use the name complexity for that specific part of the spectrum.

Edgeofchaos

In biology, psychology, economics, and other scientific disciplines, complex systems are the most creative, most adaptable and therefore most successful systems of all. In software development it is no different. Agility is about moving software projects to the area of complexity, right between order and chaos. And bla bla bla, there's nothing new about that. Jim Highsmith and Ken Schwaber already wrote about that years ago. So far, so good.

Now, software companies that are used to producing software in an orderly, structured fashion, will find that agile methods push them from the left side of the graph to the right, in the direction of chaos, but (if all is done well) not into chaos. This is probably what most agilists mean when they say that "Scrum is not enough". If you don't adopt a properly balanced set of practices, including technical ones, trying to be agile can harm your organization by moving it to far, from the ordered to the chaotic regime. Some parts of the system (like quality) might go out of control.

But…

Many organizations don't find themselves in the ordered regime. Most organizations that I know find themselves in the chaotic part of the spectrum. (Don't ask me why, either I am attracted to chaos, or it finds me wherever I am.) In these cases, agile methods will push them, at the very least, from the right side of the graph to the left, in the direction of order. Again, this shift must come to a halt when the projects have become complex instead of chaotic. Going too far into the ordered regime is equal to adding needless rigid structures and practices to a system that needs to stay adaptable. A requirement of having to follow practices X, Y and Z, without consideration to environmental context, would be an example of adding such needless bureaucracy. Less elegantly, context is king, and I don't give a rat's ass about Ron's lovely blue convertible. I already have a nice and shiny black monster.

So you see, for chaotic organizations, adoption of Scrum will be good, even without the XP practices. And that's what happened in our organization. We came from the chaotic part of the spectrum, and Scrum helped us to become complex. Sure, Scrum is not enough, but it's much better than nothing at all!

But, wait! I hear you say… in the end the absolute perfect process for a software project would be a combination of Scrum and XP practices, right?

Well… no!

Enter game theory

Evolutionary Stable Strategies

An evolutionary stable strategy (ESS) is any combination of practices that enables a system to be successful and survive, in some environment. The ESS is a concept defined in game theory, but it applies just as well to economics, biology, psychology, and software development. Evolutionary stable strategies depend on their environment, and on any other ESS-es in that same environment.

With the possible exception of adaptability, there is no other single property that every ESS needs to have in order to survive. Yes, organisms benefit from having eyes and feet, but plants and bacteria seem to be thriving well enough without them. Many companies benefit from marketing and advertising, but some simply don't bother with that kind of stuff. Many software development projects benefit from Automated Tests, On-site Customers and Pair Programming. But there are plenty of others out there who are doing well enough without them, thank-you-very-much.

(Twenty years ago, long before XP, I wrote a bookkeeping program of 100,000 lines of code. I still use it almost every day. And in all these years I have found only two bugs in it. Required XP practices, My Foot!)

Game theory teaches us that there cannot be one best strategy for all participants in an environment. There is no such thing as one specific string of genes that every organism on earth must have. Because, if there was, it would be a weakness that could be exploited by other ESS-es (viruses and parasites, for example). There is also not one business model that beats all others in a capitalist economic system. If there was, everyone would be using it, which would make everyone's behavior predictable, which would be a weakness… Likewise, there is no such thing as one specific sequence of practices that every software project on earth must have to be successful.

If there was one best set of agile practices, it would be a weakness of the system!

In environments full of complex adaptive systems, the weakness of one system will be exploited by the other. That is how these systems co-exist, and co-evolve. When you know exactly how other systems (competing businesses, competing projects) are working internally, they will be predictable, and exploitable, and you can find ways of using that information for your benefit. This is why there will never be one best way of doing software projects. The idea of "required agile practices" borders on the naivety (or arrogance) of thinking that the human genome is the only best possible DNA string in the world. (See: why ants rule the world.)

Agile vs. Agilists

Agility is about staying successful in ever-changing environments. That's it. There's nothing more to it.

This includes defying any expert who claims that practice X is essential for your organization. Because, quite likely, practice X happens to be something this expert is very good at, and is willing to assist you with, for a considerable consultancy fee. (Remember, I was talking about viruses and parasites…)

Some agilists are saying that perhaps we should start by giving up on the "Agile" brand name. It's never been clearly defined, which has allowed a lot of dysfunctional projects to call themselves "Agile." But what these agilists mean, is that it has never been clearly defined which practices are the core of agile. And rightfully so, because there are none! If there were, it would mean prescribing one evolutionary stable strategy for all systems. Which would defeat the very purpose of being agile. Agile has never been some specific set of practices. Nowhere on the Agile Manifesto does it say that you have to do automated testing, pair programming, refactoring, or whatever. In fact, an "agile practice" should be considered a contradiction in terms as soon as people consider it to be mandatory!

It would be reasonable for us to expect from agilists that they understand the basics of complexity theory and game theory. That stuff has been at the very roots of agile software development. If they knew that stuff, they wouldn't be telling us silly things like "do practice X or you won't be agile" and "doing just Scrum will only make things worse". Unfortunately, that is not how things are these days. The glory days of agile visionaries seem to be gone. The agilists squabble over xp vs. scrum, lean vs. scrum, kanban vs. scrum, fdd vs. scrum, and who-knows-what-else-and-my-mother-in-law vs. scrum. Scrum is the norm. So if you find some faults with Scrum, people will probably think you're very smart. Or something.

Oh well, the agilists are not what they used to be.

We are faced with a global armada of agilists who know absolutely nothing of complexity theory and game theory. Yes, they know words like emergence and self-organization, because everybody's using them. But do they know where those words came from? And do any of them know what a phase transition is? Or a fitness landscape? Or an adaptive walk? Or an attractor?

I do. (And I bet most of them don't.)

Some of them are even thinking of dropping the agile name. Well, I couldn't care less, because it doesn't matter if you call it rapid, adaptive, agile, lean, or gobbledegook software development.

The agilists will fade away. But complexity is here to stay…

OK, now it's time to sit back, relax, and enjoy the comments section of this post. Actually no, I will not relax. There's still plenty of stuff to do. Like, for example, figuring out how to introduce those bloody XP practices in our organization. Because I believe that some of them could actually be quite useful for us as well.

(picture by jurvetson)

Follow me on TwitterSubscribe with a readerSubscribe by email!

Latest, greatest and favoritest posts:
Simple vs. Complicated vs. Complex vs. Chaotic
Eat Chaos, Poop Order
A Theory of Everything for Software Development

This article is written by on in Adaptation & Improvement. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://sebastien-arbogast.com Sébastien Arbogast

    This is just BRILLIANT! That’s your best post ever, man! Enough with the zealots and other fundamentalists. Back to values and adaptability.

  • http://blog.dhananjaynene.com Dhananjay Nene

    Just wondering how many different titles this post could’ve taken. Also wondering how much time would it have taken you to actually write this post (likely to be quite a bit)
    Coming back to the topic, this is a great post and probably serves to be a “finally clause” in any agile book – thou can choose to stop reading the book at any point, but you still must read this post.
    Have done XP without Scrum to know it works. Your experience shows Scrum without XP can work (hmm .. still digesting that). I guess the moral of the story is not what “works for everyone” but “works for you” and finding and refining that is an exercise in staying agile.

  • http://www.XProgramming.com Ron Jeffries

    Yes, teams get benefit from Scrum without XP practices. Scrum’s inventor, Jeff Sutherland, says that he has never seen a high-performance Scrum team that didn’t use XP-style practices. My experience is the same, and my business is helping software teams increase performance.
    The point on refactoring is logic, Jurgen, not a command to refactor. I don’t give commands. I really don’t care if you refactor or not. However, if you are really going to do Scrum then

    • You must start delivering software in the first Sprint;
    • You must continue to deliver the software in every Sprint thereafter;
    • If you deliver software in the first Sprint, then the design you have will be small and feeble because there is no time to get it all right;
    • Since a small and feeble design will not carry your project to the end, you will have to improve the design;

    Refactoring is the name given to improving the design of existing code.
    You have to refactor — improving the design — not because I say so but because there’s literally nothing else to do but improve the code or have the project die. And you’re too smart to let it die.
    Regards,
    Ron

  • http://profile.typepad.com/ewanmcp Ewan

    Second the first comment – only been following you for a few months, but this is first post to really grab me and make me want to forward it on to teams. Thank you.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Ron, your logic is incomplete. Let me add some to it…
    Refactoring, like unit testing and other XP practices, is an investment. It is something you do in order to get some benefit back *in the future*. It’s true that a small and feeble design is unsustainable over time. But the essential thing is *when* the return on investment is going to happen.
    For example: If I work on something that is only going to be used for one month, and it takes me three weeks to build, why should I refactor? If proper testing guarantees a fine working product, then I have no need for refactoring. It would never pay itself back!!
    Other example: If I know my competitor is doing Scrum *with* refactoring, I have an incentive to do Scrum *without* refactoring. I will enable me to finish my product earlier. Yes, the design will be crappy, but *I* would win the contract!! Not them! And then *with* the new contract, after the first release, I would finally have the money to spend some time refactoring.
    These are just 2 examples, and I could give more, whether it’s about refactoring, unit testing, pair programming or whatever.
    You’re talking about “you must this, you must that”, but you’re forgetting that it’s a complex world out there.
    NOTHING is required.
    EVERYTHING depends on context.
    Jurgen

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Dhananjay Nene: I spent two nights (of 4 hours each) writing this post. Glad you like it! :)

  • Suresh R Iyer

    Excellent article, Jurgen, but can’t agree with the message. I am with Ron above in this. Just because your team shipped software on time and with quality doesn’t mean that you are doing the best you could. Without trying TDD and Refactoring (TDD/R), is it fair to say that it is not important or it might not yield the benefit the proponents claim? No, I am not an agilist, and don’t even do TDD enough, but whatever little I have tried and read and whatever thinking I can do on this, makes me see the light and reason in TDD/R. I agree that if someone says that you CANNOT be successful without TDD/R and looks down upon you when you say you don’t do TDD/R, yes, you have a point. But having read Beck’s work or Fowler’s work or James Shore’s work, I don’t think they are saying that you cannot succeed if you don’t listen to them. What they are saying the chances of your succeeding will be heck of a lot more, if you follow those practices. I have worked in legacy and modern projects, and I can vouch for the confidence with which I can approach the code in a project that has automated unit tests. The discussion is happening here as well: http://tech.groups.yahoo.com/group/extremeprogramming/messages/148524?threaded=1&m=e&var=1&tidx=1
    If anyone sees this in FriendFeed, please post the link here. Thanks.
    To reply to your reply to Ron, what comes to my mind is this comment from my friend Arun: “Even if maintenance and 2nd version are going to be difficult later on, you anyway charge the client for the mess you have created.” [http://protoiyer.wordpress.com/2008/12/22/how-to-be-a-better-programmer-the-redux/#comment-2422. Sorry, didn’t want to put a link to my blog, but after reading your comment about NOTHING is required, couldn’t think of a better answer. I will the first to admit that I am nowhere your level or Ron’s level (and so I might be ignorant or wrong), but still couldn’t help wondering whether your message is for the good or for the bad for say a 5-10 member project that lasts for an year or more.

  • Suresh R Iyer

    Excellent article, Jurgen, but can’t agree with the message. I am with Ron above in this. Just because your team shipped software on time and with quality doesn’t mean that you are doing the best you could. Without trying TDD and Refactoring (TDD/R), is it fair to say that it is not important or it might not yield the benefit the proponents claim? No, I am not an agilist, and don’t even do TDD enough, but whatever little I have tried and read and whatever thinking I can do on this, makes me see the light and reason in TDD/R. I agree that if someone says that you CANNOT be successful without TDD/R and looks down upon you when you say you don’t do TDD/R, yes, you have a point. But having read Beck’s work or Fowler’s work or James Shore’s work, I don’t think they are saying that you cannot succeed if you don’t listen to them. What they are saying the chances of your succeeding will be heck of a lot more, if you follow those practices. I have worked in legacy and modern projects, and I can vouch for the confidence with which I can approach the code in a project that has automated unit tests. The discussion is happening here as well: http://tech.groups.yahoo.com/group/extremeprogramming/messages/148524?threaded=1&m=e&var=1&tidx=1
    If anyone sees this in FriendFeed, please post the link here. Thanks.
    To reply to your reply to Ron, what comes to my mind is this comment from my friend Arun: “Even if maintenance and 2nd version are going to be difficult later on, you anyway charge the client for the mess you have created.” [http://protoiyer.wordpress.com/2008/12/22/how-to-be-a-better-programmer-the-redux/#comment-2422. Sorry, didn’t want to put a link to my blog, but after reading your comment about NOTHING is required, couldn’t think of a better answer. I will the first to admit that I am nowhere your level or Ron’s level (and so I might be ignorant or wrong), but still couldn’t help wondering whether your message is for the good or for the bad for say a 5-10 member project that lasts for an year or more.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Suresh: “I don’t think they are saying that you cannot succeed if you don’t listen to them”
    If agilists didn’t say that, then I wouldn’t have written this blog post. But they do! They keep saying “you must”, and “or else you will fail”. (See the references in my post.)
    There wouldn’t have been a discussion if they had said “Yes, you can succeed your way, but you can possibly do even better doing it my way.”
    I am of course in *full* agreement with Ron when he backs down and says “Yes, teams get benefit from Scrum without XP practices.” Like he’s doing above. But that’s *very* different from the message he gave earlier: “in order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.”

  • Jason Gorman

    And that’s where you lose me, I’m afraid, Jurgen.
    1. When in the history of the world has it genuinely transpired that a short-term tactical solution ultimately turned out to be just that? It very, very rarely happens in reality.
    2. I’ve seen teams in training exercises being slowed down on the second day (very severely) by code they wrote on the first day.
    What Ron is trying to say is that ongoing efforts to keep your code “young” are an inevitable consequence of writing any non-trivial body of code. You quote complexity theory, but then completely disregard the inescapable reality of ENTROPY on code.
    Code ages. It ages for exactly the same reason we do. We have a metabolism. We ingest order to build and maintain structure, but we cannot help ingesting some disorder in the process.
    Writing code is a similar process. As our software grows, we inject order as best we can, but cannot help injecting some disorder in the the process. I am constantly surprised at just how frighteningly quickly code can age until it is effectively decrepit – often before the first small release.
    Ron is saying – rightly on this rare occasion – that you have to combat increasing entropy if you want to be productive even after just a few weeks of development.
    BTW, my final year focus at university was on statistical mechanics (for solid state applications), and I suspect my grasp of complxity and chaos is serviceable, at the very least ;-)

  • Jason Gorman

    That’s good point, actually. Who are the agilists who say that if you don’t listen to them you will fail? Could you point us to some examples to support your thesis?

  • http://blog.iljapreuss.de Ilja Preuß

    Jurgen,
    the refactorings I do pay back *hours* after I’ve done them, if not minutes. Try to beat me by neglecting refactorings – good luck!

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Jason, of course I know about entropy. Entropy is why we clean our house regularly. But Ron is saying that you *must* clean your house, and he even prescribes a frequency: every sprint!
    I beg to differ.
    It depends on the house. And the family. And the environment.

  • Jason Gorman

    In the “Context My Foot” blog post you cite as an example of an Agilist saying “XP or bust”, Ron actually writes:
    “XP and Scrum are the best ways we know to work well together. They are not necessary — there might be other ways — and they are surely not sufficient — there are a million things we must do to be successful, and they’re not all written down in books.”
    I mean, sure, Ron Jeffries might be one of the more militant XP advocates, but he’s never proposed that XP or any XP practice is the only road to Nirvana – just the best road he peronally happens to know. I seem to know of more roads than Ron, it seems. But I’m with him all the way on te need to continually fight entropy – that’s Physics! And is Jeff Sutherland any less militatant about Scrum? Have you seen the guy speak (I’m guessing that you have)? Ask him if it’s okay skipping the daily stand-ups :-) I can tell you from experience that you can certainly succeed without having stand-ups.

  • http://blog.iljapreuss.de Ilja Preuß

    Jurgen, according to your logic, it would be silly to insist on using a goalkeeper when playing soccer. Surely a team that exploited that weakness by not using a goalkeeper should beat them all.

  • http://blog.mendeltsiebenga.com Mendelt Siebenga

    Great post. I think its only part of the story though. More down to earth I think quality of developers is very important.
    If you do scrum instead of lets say waterfall your actually only changing what you ask of your developers. You drop most of the BDUF requirements and you ask them to “embrace change”.
    If you have good developers they will deal with this and deliver what you ask for. They might not be doing XP but they’ll probably evolve the design anyway, do some refactoring for code that causes pain, use lots of asserts instead of unit tests and modularize their code, not because you ask them to do XP but because these are the things they naturally do and because with scrum you’ve given them a chance to do them. They’ll probably do better when you turn up those practices to 11 like XP does but as you say it pays to be able to turn those dials down again to get ahead of a competitor for example.
    If you have inexperienced and bad developers you’ll probably fail a bit harder with scrum than with waterfall. They need the added “security” waterfall and BDUF gives them. You can still get scrum to work but you’ll have to be prepared to micromanage them, tell them exactly what practices they need. They’ll probably have trouble recognizing what done looks like.
    Not every team has the ability to self organize. But I think teams “not doing XP” is more of a symptom of that problem than a cause.

  • Jason Gorman

    Indeed, I think quality of developers is the deciding factor!

  • Suresh R Iyer

    Hello Jurgen, Thanks for the reply. I re-read that Ron post again. IMHO, the only place where your perspective would succeed is a) the project is something you finish in 2-3 months, and so you don’t need to bother about TDD/R; b) the customer has no idea how well or how better this can be done/run; c) there is no incentive to work faster or code better (perhaps because the more time we quote, the more money we get). If it is not one of those three, then it beats me to imagine how the “code as you wish” strategy will succeed. Even if you win the contract with this strategy, and you keep refactoring optional, you will surely have to pay a heavy price in the later versions when it comes to the all imporant “what else you can do” or “how fast you can do it”. I am not sure you would have said the same if you were a products company (I don’t know what kind of house yours is) as against a services company. If I am running (or is in charge of a project in) a products company, I would rather have great quality code with unit tests so that I have the leverage in future. Lastly, yes you are right about what Ron said, and I think what he says hold good for any non-trivial project. I have seen far too many projects suffering to ignore what he says. If a project fails with XP, it might be in spite of the best efforts of the team, and not due to crappy work/code. Just my two cents. Thanks again for the thought provoking — albeit slightly controversial — post.

  • Suresh R Iyer

    Hello Jurgen, Thanks for the reply. I re-read that Ron post again. IMHO, the only place where your perspective would succeed is a) the project is something you finish in 2-3 months, and so you don’t need to bother about TDD/R; b) the customer has no idea how well or how better this can be done/run; c) there is no incentive to work faster or code better (perhaps because the more time we quote, the more money we get). If it is not one of those three, then it beats me to imagine how the “code as you wish” strategy will succeed. Even if you win the contract with this strategy, and you keep refactoring optional, you will surely have to pay a heavy price in the later versions when it comes to the all imporant “what else you can do” or “how fast you can do it”. I am not sure you would have said the same if you were a products company (I don’t know what kind of house yours is) as against a services company. If I am running (or is in charge of a project in) a products company, I would rather have great quality code with unit tests so that I have the leverage in future. Lastly, yes you are right about what Ron said, and I think what he says hold good for any non-trivial project. I have seen far too many projects suffering to ignore what he says. If a project fails with XP, it might be in spite of the best efforts of the team, and not due to crappy work/code. Just my two cents. Thanks again for the thought provoking — albeit slightly controversial — post.

  • http://blog.iljapreuss.de Ilja Preuß

    Jurgen, a responsible chef will keep his kitchen clean and tidy all the time. That doesn’t depend on the circumstances, it’s simply a necessity for doing a good job.
    When I learned to be a precision mechanic, one of the most important things we learned was to clean up the working place every afternoon. Not doing so simply wasn’t an option, it didn’t depend on circumstances. Not doing so simply would have messed with us being able to do our work.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    IMO, your analogy fails.
    This might apply to professional chefs in Western Europe, but not to kitchens in other parts of the world. You’ve probably never seen the kitchen of a Chinese restaurant.
    Again, we’re talking about the *requirement* of applying some practice in order to have a favorable outcome for the customers.
    I’ve eaten good food in many restaurants where the kitchens might have been a big mess.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Again, this is a bad analogy. Why would two projects in different competing companies share one and the same project manager? Because that’s what happens in soccer: two competing teams with one judge.
    Please pick another analogy. You cannot use this one against me. It doesn’t make sense.

  • Josh

    @Suresh R Iyer
    In your post you comment, “IF the project is X, it’s ok” or “IF the project is Y, it’s not okay”… but isn’t that exactly the point Jurgen makes? That there is no one true answer to things since every system of development is complex?

  • http://www.kasksoftware.com Steven T Cameron

    Ilja, you are making the exact logic jump that Jurgen is arguing against. You are saying that if a chef doesn’t keep a neat and tidy kitchen, they *cannot* do a good job. This is entirely wrong. It might make doing a good job easier or faster or more reliable, but not doing it doesn’t make it automatically a bad job.
    It’s the same with refactoring or any other process. It may make it easier or faster or more reliable, but it is not *required* to produce good software.

  • Howard May

    When discussing whether refactoring is or isn’t mandatory and whether Jurgen’s product is coded well, I would point people to Steve McConnell’s excellent posts on Managing Technical Debt. In brief, poorly factored code can be compared to financial debt, if you have it then you have to pay interest on it. If you have code which is poorly factored then there is a cost you pay for that – higher maintenance costs. At any time you can choose to pay off some of that debt by refactoring the code to make it more maintainable. The decision as to whether to do this or not is not trivial and should not be treated as such. Steve discusses how carefully managed technical debt can serve a valuable business purpose just like financial debt. The key is to take on debt carefully and manage it.
    Also note: if Jurgen’s product does not take off then he can kill off the product and kill off the debt with it.

  • http://protoiyer.wordpress.com Suresh R Iyer

    Hi Josh, I didn’t say it is ok. I said “not following TDD/R will succeed if a) or b) or c), and won’t be a-great-idea/succeed if you are developing any non-trivial system involving multiple programmers (not 100s, say 10s)”. Even if it appears you succeed in shipping the first one or two version(s), eventually the entropy will catch up with you. This leads us nicely to this: http://bit.ly/zAWb.
    On another note, what the Fowlers and the Jeffriess and the Shores are arguing for is that “please don’t call yourself agile if you are not following the agile practices”. Here _why_ is the important question one should ask. As far as I can tell, because of these: a) they are the pioneers of this field and they played a part in the creation of the agile manifesto and early development of agile, and according to them TDD/R is central to the theme of being agile.. b) anyways you are not following what they laid out (not doing TDD/R), so why do you still want to call yourself agile?.. c) There have been lots of failed projects that blamed it on being agile, where as they were not doing TDD/R in the first place. So, why do your own stuff, and then finally blame it on agile (when and if it fails). If you want to do BDUF or create a BBoM (big ball of mud), or do Scrum without TDD/R, go ahead and do it, and you might even succeed. But let us not please call it agile. Create your own practice with your own name if you want to. Why are we hell bent on labeling ourselves agile if we don’t do TDD/R?

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Please note that there are *17* signatories of the Agile Manifesto. It is not just up to Jeffries or Fowler to say that we’re not agile if we’re not doing TDD.
    Maybe you could ask all 17 of them if they agree.

  • http://protoiyer.wordpress.com Suresh R Iyer

    Hmm..your reply tells me that perhaps I have crossed the line. I didn’t really mean to irritate you, and I will be the first to admit that I am far less ignorant than you. Was just trying to put across my thought, hear others out and seeking to enhance my knowledge in the process. I really don’t care whether all the 17 agree or not. What I wrote was the result of reading the Beck books (Edition 1 and 2), the Cockburn book, the Fowler books and numerous articles on the web over the years (some written by these stalwarts and by many others), plus the really huge projects I have worked in (each the result of years of development and not weeks) over the years – some having tests and some without. It appears proper to me to use TDD/R for any non-trivial development, that is all. However, none of the references mentioned above make me feel that TDD/R is or should be an after thought for creating solid non-trivial software. With that I rest my case. Thanks again for the great blog you maintain and those great lists. I mean it.

  • http://agilefocus.com/ William Pietri

    Hi! This post is nicely written, and I’m a big fan of the work done by the complex adaptive systems folks. Thanks to your mention of it, I’ve already pulled my ancient copy of Waldrop’s book off the shelf and put it in my reading pile.
    That said, I think a lot of this is based on a misunderstanding and some straw men you’ve built from that. I started to write you a comment explaining the misunderstanding, but it turned out to be too long for a comment. You can now find it as a blog post: “Agile” versus “agile”. I hope that helps!

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Hi Suresh,
    No problem, I am not irritated. I just don’t believe in absolutes, or agile practice fundamentalism. There are no practices that should always be performed.
    I also think that “non-trivial development” could be interpreted as demeaning.
    There can be very good business reasons for not doing TDD. Somebody else already noted that Steve McConnell once wrote that technical debt can be treated just like financial debt. There can be good reasons for going into debt, and paying off the debt much later.
    “non-trivial development” would indicate that anyone who is not paying off his debts immediately is not doing serious software development.

  • http://kirkwylie.blogspot.com Kirk Wylie

    Hi, Jurgen,
    I actually posted this yesterday before I saw this, but I think we’re thinking the exact same things (though from different angles): the Agilists/Big-Agile crowd are making agility seem like a bad thing, and that needs to change.
    Great article.

  • http://www.jroller.com/sebastianKuebeck/ Sebastian Kübeck

    Well, I don’t quite see where your point is. If you find a way to replace XP practices with your own practices that address the same issues equally well or better, no “Agilist” would ever come over and tell you: “don’t do that. It’s a practice not approved by the Agile Alliance”. The XP practices are not meant to be dogmas but rather a survival kit for programmers that allows them to safely change their code. Take refactoring for example: How can you prepare your software for a change and keep it tidy without refactoring? Most people cannot foresee changes and refactoring makes sure that they don’t need any clairvoyance superpowers but can instead safely change their software towards new features using refactoring. How can you do refactoring without tests? If you do it without tests, you run a high risk to introduce bugs. Pair programming makes programming and refactoring easier as you have a always a second brain around. Agile is not about command and control thinking. However, XP practices have proven to address the problems mentioned. If you have found others that do the same, you are certainly free to do so.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Sebastian: I don’t understand that you don’t see what my point is. I think it’s very clear from the references in my article that some agilists *require* some specific practices in order to be called ‘agile’.
    I think there can be very valid reasons (technical reasons or business reasons) for *not* applying those practices, and still be agile, with happy customers.
    You seem to agree with me.
    Then what is it that you don’t understand from my article?

  • http://protoiyer.wordpress.com Suresh R Iyer

    Thanks for the reply, Jurgen. Just to clarify.. by “non-trivial development” I meant the development of some system that would take years instead of weeks. This is in contrast with some of the web development projects out there that get over in a few weeks time (say 12-24 weeks). Perhaps for such a small project (small compared to years of development) you can decide not to do TDD/R, for the same reasons McConnell mentions (and you write about in this post). With all due respect, I am still not convinced whether we should plan creating huge projects without the scaffolding that it really really needs (“scaffolding” as in the protection the tests provide against future code and design changes). Its value might not be that evident during the first year, but the team would be more than thankful during the subsequent versions and years.

  • Tungano

    Hey Jurgen,
    Being a developer in one of your trenches and seeing your closing statement I can only suggest to maybe start with an audit to see how many XP practices have already been or partially been adopted ;-)
    The adoptation of scrum has created urgency in improving our process. Having to be able to deliver quality code within short iterations is quite a challenge!
    In support of your blog’s statement: We pick and match the practices and methologies that make sense from a practical point of view. I think this settles well with the concept of self-organising teams.
    If you are puzzled with how YOU should have your teams adopt certain practices I would say: Inspire them, give them room to experiment, educate them on what’s out there (something you do very well I must add) but in the end let THEM select and pick what makes sense to THEM.
    The way I read it this is exactly the context Ron Jeffries is giving it’s foot. For developers to be able to meet the requirements of Scrum iterations the context in which they happen must sometimes change to accomodate.
    Without true team responsibility it would be you that comes up to the team and say “You must adopt practice X, or you will fail!”. Sound familiar?
    Excellent post, beware of the TDD inquisition! ;-)

  • http://kirkwylie.blogspot.com Kirk Wylie

    @Tungano:
    I think you really get what agile methodologies mean to a conventional development team: you pick and choose amongst the various options available to you to get a methodology that matches your team and skills.
    What Jurgen has problems with (and I agree) is that many Agile practitioners now say “if you are Agile you have to do X, Y, and Z”. We disagree. We believe you can be agile and not do every single thing that’s in vogue.
    Good to know that there’s another face in the firmament that understands this!
    Kirk

  • http://kirkwylie.blogspot.com Kirk Wylie

    @Jurgen: 100% agreement.
    @Sebastian: The whole point of this is that Jurgen and I agree that you can be agile and not do every single thing that the Big Agile peeps say you need to.
    Read my article on the subject, and re-read the original post. I think you actually agree with us, but are so innured to the “Agile Is Always Right” crowd that you aren’t actually reading what Jurgen has to say.
    You can be pro-agile and anti-Big-Agile at the same time. Makes for a much more agile methodology. :-)
    Kirk

  • http://agilefocus.com/ William Pietri

    Just to be clear, some people are trying to set minimum standards for the term “Agile” not “agile”. The former is a proper noun referring to specific approaches to software development. The latter is a general-purpose adjective, open to use by all. It’s sort of like how only some sparkling wines are Champagnes.
    There are certainly valid reasons for not using an Agile process or a given Agile practice (as well as a variety of invalid ones). Nobody is saying that it’s impossible to have happy customers using some other process.

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

    Jurgen,
    for the most part, I have to say I agree with you. TDD, continuous integration and refactoring are really important. But they are not the things I tend to lead with when I’m trying to fix broken development organizations.
    I think the agile community needs to take a hard look at how dysfunctional some organizations are. You can get an incredible amount of value by simply getting them to start doing short, 1 to 2 week iterations, and making sure that business users are present at the end of each iteration to check value, and monitor progress. Just by doing that you probably have optimized your average large organization IT shop by 1000%, I swear to God I’m not joking.
    Take a sniff around some organizations where legacy mainframe is the order of the day, and you’re dealing with systems that are 20 to 30 years old. Some of these organizations have development lifecycles that are several months long even to fix the smallest bugs. Even getting these organizations into an iterative mindset is a miracle unto itself.
    Iterative development is starting to be a requirement for anybody who’s taking any kind of development seriously this is thanks to the agile community. I would take a victory for what it is, and not try to force everything down everyone’s throat.
    I personally make sure that TDD, refactoring and other development practices are more or less present on any project that I am part of to the most of my ability, but it’s certainly not a requirement to be “agile”. Not that any senior IT executives actually care about being agile, they just want to make improvements.
    Jeff

  • http://yuwantitwhen.com Bill

    After reading all this, it’s no surprise to me that the industry is still plagued with low quality and cost overruns.
    It’s interesting that the very people who have minted the term analysis paralysis are some of its worst offenders.
    The software business can benefit from a lot less zealotry. I’m afraid there is no silver bullet to building great products. Passion is often the enemy of the good.
    Successful products happen for a multitude of reasons, and sometimes they happen in spite of the methodology, and sometimes they happen in spite of the quality of the team and sometimes in spite of both.
    Sometimes passion get’s in the way of clear thinking. There’s too much passion in the Agile world and not enough clear thinking.

  • http://www.jroller.com/sebastianKuebeck/ Sebastian Kübeck

    > some agilists *require* some specific practices in order to be called ‘agile’.
    I am sure that they didn’t mean that as dogmatic as you interpret it but I may be wrong. As I wrote before: Agile is not about dogmatism! I think that’s a part of: “Individuals and interactions over processes and tools”. That’s why there are so many variations of Agile processes.
    Out of curiosity: how you address the problems with changing code without XP practices?

  • http://gnufoo.org Shane

    Someone asked for evidence to support the author’s supposition that agilists say “you must do this or you will fail.” I don’t know who the author was directing that at exactly, but it’s evident from some of the comments here that that’s the case.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Shane: Did you read my article? The evidence is in the second paragraph, the one that starts with “Nowadays, agilists are telling me that…”
    Agilists claim, quite literally: “In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.”
    And that’s just one of the quotes I refer to.
    What more evidence do you want?

  • http://ekenosen.net/nick nicholas a. evans

    You make some very good points. But because this post seems to be primarily oriented towards discrediting people (agilists), and you seem to have missed some key points of the people you are arguing against (even in the very same articles you link to, for example the paragraph that Jason Gorman quotes in his last comment), then I can’t help but feel like you are unproductively swinging at strawmen and stirring up contention rather than productively taking part in the conversation.
    On another point, if refactoring slows you down (as you claim it might), then fine, don’t do it. I do it because it speeds me up. But somehow I think that your definition of “refactoring” is less encompassing than Fowler’s and Jeffries’s.

  • http://blog.sprettur.is Guðlaugur S. Egilsson

    We mostly speak from our own experience. My experience is that without TDD/R, code bases deteriorate (rot, to use Uncle Bob’s terminology), build resistance to change over a course of couple of years, and become a financial drain. For a small product company, like one where I used to work, this leads to decrease in income, and from there to layoffs and unpleasant life experiences. At this company, I was introducing TDD, but unfortunately neither soon nor quickly enough. The maintainability of TDDd code vs non TDD code was like day and night. So for me, it is quite natural to advise people to do TDD, because, in my experience, it can help avoid such unpleasantness.
    That being said, there is no proof, or absoluteness in the agile practices. I’m gonna say yes, it is probably possible to be agile in the long run without the XP engineering practices. For the average team though, I think it is highly unlikely to happen. The one claim to such success I have seen, and take somewhat credible, is from an israeli team which claimed that taking one of the SOLID principles to the extreme (Open Closed Principle) actually enabled them to be very agile without much unit testing. They did refactoring though, one first sign that a component in the system was not really adhering to OCP.
    I would like to add, if your approach is repeatable by others, by all means share those with the community. I always love to hear about alternative approaches and broaden my horizon.

  • http://blog.sprettur.is Guðlaugur S. Egilsson

    We mostly speak from our own experience. My experience is that without TDD/R, code bases deteriorate (rot, to use Uncle Bob’s terminology), build resistance to change over a course of couple of years, and become a financial drain. For a small product company, like one where I used to work, this leads to decrease in income, and from there to layoffs and unpleasant life experiences. At this company, I was introducing TDD, but unfortunately neither soon nor quickly enough. The maintainability of TDDd code vs non TDD code was like day and night. So for me, it is quite natural to advise people to do TDD, because, in my experience, it can help avoid such unpleasantness.
    That being said, there is no proof, or absoluteness in the agile practices. I’m gonna say yes, it is probably possible to be agile in the long run without the XP engineering practices. For the average team though, I think it is highly unlikely to happen. The one claim to such success I have seen, and take somewhat credible, is from an israeli team which claimed that taking one of the SOLID principles to the extreme (Open Closed Principle) actually enabled them to be very agile without much unit testing. They did refactoring though, one first sign that a component in the system was not really adhering to OCP.
    I would like to add, if your approach is repeatable by others, by all means share those with the community. I always love to hear about alternative approaches and broaden my horizon.

  • http://www.allaboutagile.com Kelly Waters

    I’ve added my two pence worth over on my blog. I’m with Jurgen…
    http://www.agile-software-development.com/2009/02/decline-and-fall-of-agilists.html
    Kelly.

  • jlivesay

    From working in a shop that has tried, and struggled, in applying its own interpretation of agile I think the reason prominent agilists use such absolute phrasing is to prevent the inexperienced from diving head-first into failure. Conversation becomes utterly exhausting when every sentence has to include the caveat of “yes, it could work without doing this, but.”
    For the agile novice, following the practice by the book provides a road-map to at least a moderate degree of success. Can more success be achieved by tailoring those practices to fit? Absolutely. Does the agile novice have the ability to do this effectively? No. That’s why they are a novice.
    Your advice resonates loudly to those of us who have hard earned agile experience and the war stories to prove it. Perhaps the agilists are overly reactionary to teams practicing psuedo-agile and failing. However, I am certain that there will be more than one person who reads your writing and uses it as incentive to tear out some pages of the agile play-book, for which they will likely be worse off.
    I wish I could go back about three years and tell myself that same thing.

  • http://www.agilekiwi.com John Rusk

    Jurgen,
    Your post reminds me of Alistair Cockburn’s Crystal Clear: an empirically-derived agile process which doesn’t look much like XP(*). Alistair set out to find the key things that correlate with project success. Considering the things he found:
    - about half are in XP
    - about half are not
    - much of XP didn’t make his list at all
    I also heard a great quote recently, via the Crytal Clear newsgroup: “XP = self disciple; Scrum = self organisation; Crystal = self awareness”. Very thought-provoking, and a reminder that agile is intentionally an umbrella term to cover several _different_ ways of building software.
    Also, James Bach posted a good post, along similar lines to yours but from a different perspective, here: http://www.satisfice.com/blog/archives/45 and Alistair posted on there being no one-true-agile here: http://alistair.cockburn.us/No+center+to+agile
    (*) P.S. While the First edition of XP seemed very different from Alistair’s work; the differences are noticable less in the Second edition of the XP book. I feel much of the common perception of XP is very much in the mold of the first edition; rather than the second.

  • http://www.agilekiwi.com John Rusk

    PPS This is good too http://www.satisfice.com/blog/archives/174 and is also in agreement with your post.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Thanks to Kelly Waters, James Back and many others for agreeing with me. I’m glad I’m not alone in this!
    I’m sorry I cannot find the time to reply to each and every single comment. There’s just too much. I need time to work on some new controversial material. ;)

  • http://haxrchick.blogspot.com abby, the hacker chick blog

    Jurgen, this is a really wonderful post – thank you! I have also noticed a lot of talk recently that Scrum won’t work without XP , and have found it equally disconcerting. The thing that attracted me to Scrum in the first place is that it’s a wonderful recipe for creating high performance teams –those fast paced teams that are so much fun to be a part of. And part of this recipe is that the team is in the best position to determine what technical practices to follow, and thus they should be able to decide, rather than having it dictated to them. So, now hearing that Scrum implementations must follow XP seems to be in conflict with one of the very things that makes Scrum great.
    You make an excellent point for why XP can’t be considered the “end all, be all, final word” on best technical practices. In fact, your post made me finally realize why we’re no longer supposed to say “best practices.” The thing that makes us so great is that we’re constantly adapting and evolving and finding better ways of doing things.
    That said, I do believe that – as Lean teaches us – we want to aim for a sustainable pace (not just fast today, but sustainably fast) – and the only way to do this is by paying attention to quality. If we write crappy code, we might be fast this month, but we won’t be next month. And so, while I don’t agree that we need to follow all of XP’s technical practices to achieve this quality, I believe we do need to select technical practices that will inject this quality. I think that XP, perhaps because it took such an extreme stance as to make people stand up and listen, made some great technical practices very visible in our industry. But, as I believe was Scrum’s initial intent – I think the people on the team should be able to pick & choose what works best for them, in their particular situation. And, as you infer, the religion has to die.

  • http://www.davenicolette.net/agile Dave Nicolette

    “…every agilist and their uncle…”
    Is that a reference to Bob Martin? ;-)

  • http://www.pab-data.blogspot.com Paul Beckford

    This type of nonsense is why we aren’t a profession. Any responsible profession has developed a broad consensus on proper practices and minimum standards. The fact that the software community is now developing a firm opinion is a good thing. Call them Agilist all you want, but without people who care about professional and ethical standards Barbers would still be performing surgery in unsanitary conditions still today. Who says you need to go to medical schools? Who says you must keep your surgical instruments clean? Who says that your patients will get infected?
    It was people like the ones you call Agilists who strove for ethical practices, that got together and formed guilds leading eventually to regulatory bodies like the BMA.
    The software industry is finally beginning to grow up and adopt professional norms, something that is long overdue, and you decide to bitch about being told what to do?
    I think it is you that is missing the point.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Paul, while you would prefer to focus on the rules, I would focus on the patient. When I have *proof* that other (simpler) practices have an even better effect on my patient than your practices, I couldn’t care less about your guild and profession.
    Your type of nonsense leads to bureaucracy, and is the reason why healthcare is so expensive, than only the rich can afford to pay for all the rules that you impose on people.

  • http://www.pab-data.blogspot.com Paul Beckford

    Jurgen,
    You insist on making a straw man argument. I’m sure that some of the Barber Surgeons thought that they did a good job too. Who knows even one or two of their patients where upset about their demise. Society as a whole however is glad we finally got shot of them.
    Software is failing. Scrum without technical practices is failing. Professionalism means reliably delivering on our promises. Which means adopting professional practices.
    BTW. Healthcare in the UK is free :)

  • http://www.pab-data.blogspot.com Paul Beckford

    Sorry. Let me rephrase my last sentence:
    Professionalism means reliably delivering on our promises. Which means adopting reliable practices.
    Peace Paul.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Paul,
    Your one example of the Barber Surgeons does not refute my argument. I could cite contrary examples where the makers of rules and guilds were the cause of people’s suffering. Therefore, these analogies will get us nowhere.
    Rules are never universal laws. Show me any man-made rule and I can show you a counterexample of why that rule is not applicable in some cases.
    BTW, healthcare in the UK is definately not free. Or are you suggesting that people in healthcare in the UK get no salaries? And all equipment is donated by volunteers? Of course not, taxpayers are paying through their nose the keep healthcare running. (Just like here in The Netherlands.)

  • http://www.pab-data.blogspot.com Paul Beckford

    Hi Jurgen,
    I agree, that there is always the exception to the rule, its called the fringe. I think the analogy is a useful one. In other professions that are a lot more mature than ours, there is a broad consensus amongst practitioners about which practices provide reliable results. Fringe practices are viewed as “unprofessional”, and customers are warned to be wary of them. So for example I can choose non-conventional medicine to cure my acne, but most people would recommend that I go to a professional doctor.
    Personally, I wouldn’t trust any group of programmers with my own money.
    I talk more about this on my blog:
    http://pab-data.blogspot.com/2009/02/post-agile-beyond-best-practice-and.html

  • Paolo Perrotta

    Your ESS comments only hold true if software development happens to be a zero-sum game, where if I win, somebody else loses. In my experience, it doesn’t work that way.
    Still, thanks for the post – it was a very nice read.

  • Jeff Santini

    Actually I would like to hear more about the success of your organization, and how the adoption of scrum might have contributed to it. But it would be much more enjoyable without the negativity that is directed at something called an “Agilist”.
    Is it possible that any reader of your blog is not able to construct their own theoretical scenario of a successful project without refactoring? I think we all get that refactoring and TDD are not essential ingredients to a successful project no matter what anyone else may say. You don’t need to prove it to us.
    On the other hand(here I show my stripes) isn’t it really about maximizing possibilities rather than discussing absolutes? If refactoring increases your chances of success, though doesn’t guarantee it, isn’t that still a good thing? If it doesn’t increase your chances of success, then let’s forget about it.

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    @Jeff: I’m regularly blogging about Scrum and our organization, so if you’ll just subscribe to my feed you will get to know all about it. :)
    And yes, you’re right. It’s about maximizing possibilities.

  • http://one-shore.com Aaron Evans

    “Rafactor” is the magic fairy dust that makes everything good. I thought “Agile” was the magic fairy dust. Guess I don’t practice Agile any more, I practice Refactor. I’m going to write a book about it and sell you consulting “services”. Get on the bandwagon everyone. We can all be “Refactor” consultants.
    Shark meet Fonzie. Fonzie, meet Ron. And yes, I’ve already got the domain extremerefactoring.com registered.

  • http://yuwantitwhen.com Bill

    “practice X happens to be something this expert is very good at, and is willing to assist you with, for a considerable consultancy fee.”
    I’ve been away from this debate for a while, and I can’t say I’m surprised with this article. I believe you hit the nail on the head with the above quote. Agile has always been about making money. (have you noticed all the books, tools, magazines, and consultancy sold under the agile banner?) No one really cared whether it worked or not. And the genius of the business model was its ambiguity. Being a consultant is rarely about having an expert opinion and being sought for it. The successful ones find out what you want to hear and then proceed to give you exactly that even if it’s bad for you. What can I say? People love to be flattered, even when they know it’s happening. It’s good for business.

  • CarryAnne

    Being Agile should be more Art than Science, agreed. But if technical debt and distractions during the Sprint result in failure to complete everything committed to Sprint after Sprint, then that’s taking your team into the chaotic realm. It indicates one or more practices is missing. Whatever it takes for a respectable, sustainable and predictable productivity needs to be included, and rather than flubbing around guessing at it, perhaps looking at both the process infrastructure and the XP practices would be a good place to start.

  • http://www.greiterweb.de/spw/Agile_is_not_Manifesto.htm Gebhard Greiter

    I like (and fully agree with) your statement “Agility is about staying successful in ever-changing environments. That’s it. There’s nothing more to it.
    You may want to read http://www.greiterweb.de/spw/dox/The_New_(2011)_Definition_of_Agile.pdf

  • orbfish

    Interesting that while I agree with you on the major points (XP orthodoxy sucks, Scrum is useful by itself when you are in chaos/have no process at all), I still find a lot of the things you’re saying incredibly irritating. Maybe it’s just the touch of arrogance? (oooh you know what a phase transition is, guess they haven’t read Jurassic Park)
    The need for refactoring and unit tests are what I think of as Agile technical practices, not dogmatically XP practices like pair-programming and strict test-first. If you don’t test and refactor, you’re living in fear, whether you adopt XP or not. You are, as Michael Feathers said in a definitively non-dogmatic book, “creating legacy code.” Scrum is just a project-management framework, sure you can do it without knowing how to program.

  • Eric Roberts

    Great post!