25

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.

superM
  • 7,363
  • 4
  • 29
  • 38
Martyn
  • 599
  • 6
  • 11
  • 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 Jan 03 '13 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 Jan 03 '13 at 11:12
  • The first link you cite seems to already contain all that you're looking for. – Michael Borgwardt Jan 03 '13 at 11:13
  • Just watching Fred George's presentation (2nd link in post). He's had a lot of experience with Agile and I'm tending to want to hear what he has to say - pretty sure he's done proper agile before as he's worked with the likes of Kent Beck, Ron Jefferies and Robert Martin. – Martyn Jan 03 '13 at 11:14
  • @MichaelBorgwardt You're right that the first link has some good info, but I'm looking for additional resources. I don't fancy putting all my eggs in to one basket. – Martyn Jan 03 '13 at 11:17
  • 2
    What a lovely buzzword! – CesarGon Jan 03 '13 at 11:20
  • 1
    @CesarGon: Buzzwords are easier to invent than methodologies that are really new. ;-) – Giorgio Jan 03 '13 at 11:30
  • The tasks "requirement analysis", "testing", "project management",... have to be done in each project. I guess "Dev Anarchy" means that you let your team of developers split up those tasks informally among them (instead of adding a lot of specialized non-devs for those tasks to the team who try to tell the devs how they should develop the software without really knowing what they are talking of). This will make your team very flexible (call it "agile" if you like). Of course, you will at need at least some broad qualified devs to work this way. – Doc Brown Jan 03 '13 at 12:48

1 Answers1

47

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!

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • 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 Jan 03 '13 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 Jan 03 '13 at 13:40
  • Gahhh... that cycle sounds accurate and depressing. – Graham Jan 03 '13 at 14:25
  • 23
    ["Tim was a talented developer working in a company filled with talented developers. Pretty much any methodology you care to think of was going to work with these people. "](http://www.ckwop.me.uk/Meditation-driven-development.html) – AakashM Jan 03 '13 at 15:14
  • A more verbose and entertaining version of my comment. :) +1 – asthasr Jan 03 '13 at 15:29
  • @AakashM MDD, ingenious! I'm going to start today!!! /s – Evan Plaice Jan 03 '13 at 18:09
  • They want to take away the private office I never had? That is anarchy. – JeffO Jan 03 '13 at 18:10
  • Yep, remember this when you next go to hire someone, that 25 yr old kid that you think will be dynamic and energetic and filled with the latest, greatest technologies.. will be a huge mistake when you could hire the old dinosaur who is bitter and twisted watching said kids screw up things that the oldie could have done in no time. (not because old is good, but because old means experienced) – gbjbaanb Jan 04 '13 at 12:57
  • 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 Jan 04 '13 at 14:03
  • @AakashM: that's why I gave that link, it describes the 3 levels of skill and what aspects of a methodology is required for each. Cockburn isn't just a pretty beard, Crystal is a good set of methods. – gbjbaanb Jun 12 '13 at 12:05