I've been reading about Developer (or Programmer) Anarchy, which seems to be billed as a post-Agile development methodology. I found a few resources on it (1, 2) but it doesn't seem to be a lot out there.

I was wondering if anyone had any good resources where I could find out more about it _ how to implement it, pros and cons, comparison with other methodologies etc.

  • 1
    I haven't heard of it before but it seems a bit contradictory to me. They say "... formality and rules are constraining to creativity and productivity" but at the same time they have regular stand up meetings (as part of the methodology?). I cannot believe that the description of such a methodology starts by setting a rule.
    – Giorgio
    Commented Jan 3, 2013 at 11:09
  • Reading about it for the first time, it seems to me it was done by person or people who only had experience with half-assed Agile. Because this "Developer Anarchy" is textbook example of "agile done right". Eg. properly implemented agile.
    – Euphoric
    Commented Jan 3, 2013 at 11:12
  • The first link you cite seems to already contain all that you're looking for. Commented Jan 3, 2013 at 11:13
  • 2
    What a lovely buzzword!
    – CesarGon
    Commented Jan 3, 2013 at 11:20
  • 1
    @CesarGon: Buzzwords are easier to invent than methodologies that are really new. ;-)
    – Giorgio
    Commented Jan 3, 2013 at 11:30

1 Answer 1


I can point you to Alistair Cockburn's thoughts on this aspect of 'true' Agile projects:

One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words:

“Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone.”

I did, in fact, describe Crystal Clear in those words to a savvy project sponsor. He followed those instructions and reported five months later, “We did what you said, and it worked!”

I interviewed the team leader some months later and his report was about as short as my instructions:

“Following your suggestion, the four of us took over this conference room, which has network connections. We kept it for all four months, drawing on the whiteboards over there, delivering software as we went. It worked great.”

that's what agile was about, and it seems this is the approach taken by the Anarchy methodology - the point is that, if you have experienced guys, then you can tell them to "sod off and make it work" and they will do just that. (this doesn't work with less experienced people, you wouldn't let a team of juniors do it without at least some supervision).

All the guff about agile that's built up over the years, like daily standups and scrum boards, product backlog grooming sessions, pre-meeting meetings about the product backlog scrum board grooming session planning meetings.. are all heavyweight project stuff that should be seen as overheads to successful product delivery.

Too much today though, these things are seen as mandatory and the 'agile' methodology descends into a system that has more process than the old methods!

  • 14
    "Too much today though, these things are seen as mandatory and the 'agile' methodology descends into a system that has more process than the old methods!": You hit an important point (+1). I have been working with SCRUM in a team of experienced developers and our feeling, after two years is that ... we were more agile before, when we did not have daily meetings (we used to meet twice a week) and many other activities happened "when the team decides they are needed" instead of "when the methodology prescribes them".
    – Giorgio
    Commented Jan 3, 2013 at 12:41
  • 10
    +1. Ultimately, I think these methodologies are indicative of an ongoing cycle: heavy methodologies fail repeatedly, (some) people realize that the programmers are smart enough to handle things, shave off the process, and generally things work--but the light process is tried with poor or inexperienced teams, it fails or misses estimates, process is added to increase "certainty" and "predictability," and the cycle continues.
    – asthasr
    Commented Jan 3, 2013 at 13:40
  • Gahhh... that cycle sounds accurate and depressing.
    – GHP
    Commented Jan 3, 2013 at 14:25
  • 23
  • 2
    @syrion: You may be right. I read somewhere that the agile practices worked for experienced programmers. Then such experienced programmers who had been coaching unexperienced teams had to write down rules for them (because continuous coaching costs a lot and it is better to have some rules written down in a book). In this ways new methodologies like SCRUM and the like developed: so people can now sell books or certifications. But the real spirit of agile is to apply your own common sense instead of rules written by others. Rules are guidelines but are considered by many like a religion.
    – Giorgio
    Commented Jan 4, 2013 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.