In this article, part of my series explaining better ROI from software development, I’d like to look at the Developer Anarchy.
“Anarchy is the condition of a society, entity, group of people, or a single person that rejects hierarchy” Wikipedia
The principal is one of manager-less team given full autonomy to achieve a result (thus the name of “Anarchy”).
And “Developer Anarchy” sounds great as a sound bite and generates a fair amount of media interest.
I first came across this term in a Podcast in which Fred George talked about how he had achieved this state with a team of 40 developers.
From the way that Fred describes it, it sounds as if the team arrived at this state through continual refinement of their development process – ruthlessly removing un-beneficial overhead (lean thinking).
This resulted in the team being given the directive to “make money” (or words to that effect) and left to get on with it. The team then completely self organise on what to do, how to do it, when to do it – if an individual developer feels that something is worth exploring, then off they go.
And in Fred’s example this worked exceptionally well and made a considerable amount of money.
From what I've read, it worked pretty much as I described above.
I've read of a number of manager less organisational structures before. One organisation (Valve Software – a very successful software development company working on games) make a major thing of how they operate. This employee handbook basically welcomes the employee and tells them:
It also goes into describing some of their rational behind the thinking (empowerment, engagement, ownership, enjoyment).
The way Fred describes his organisation it feels rather like that.
In Fred’s case I suspect this worked well because of three things:
As I understand it, the organisation was involved with Google Advertising and making money from efficient and effective use of it. At the time not only was this a very technical activity, it was also largely new territory.
Nobody really knew the correct way to use it to make money – Fred described it as the wild west.
And due to the volume of business they were doing, any change could be assessed very quickly to see if it had a positive or a negative effect (we are talking minutes).
Remember I've described Software Development before as problem solving?
So what happens when you let Software Developers at a problem in which they can experiment and innovate ultra quickly with almost instance feedback?
You get a team that will naturally remove every obstacle to going as quickly as possible.
Why have a BA write up a requirements doc when the developer can just try it?
Why have managers provide approval when a developer can just test it and get empirical results?
Why have a lot of ceremony when what matters is the validation of theory with real-world results?
You then take the results and decide what to do next. If went well, great, do more of it. If it didn't, reverse it out or try something different.
This is what being agile is about.
And in the case of Fred’s organisation this has worked exceptionally well.
I’d suggest not.
In Fred’s organisation, there was a very direct and measurable result from developer effort. Most organisations do not have such a close affinity.
I'm certainly not saying that Fred’s organisation was uniquely suited, but I do think that Developer Anarchy would be an evolved outcome for most organisation rather than a specific target.
“Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
Ri: Now the student isn't learning from other people, but from his own practice. He creates his own approaches and adapts what he's learned to his own particular circumstances.” Martin Fowler
The principal of “Shu Ha Ri” crops up a lot in agile adoption.
Originally taken from martial arts, it described the steps a student goes through to achieve mastery.
The agile movement has adopted this to illustrate the mastery (and maturity) of an organisations agile adoption. It helps to be able to walk before you run.
Developer Anarchy for me is very much in the Ri stage.
The team (and organisation) have gone through the stage of operating a process by rote (Shu), have had success at adapting that process to their own need (Ha) and are now adapting the entire approach.
And listening to Fred, a lot of Developer Anarchy has grown out of the team looking at how best to working within their environment and stripping out everything that no longer provides them value.
The key point is that it is their environment. This where I think it would be difficult to replicate Developer Anarchy directly between organisations.
Rather I think that each team would do better to look at Fred’s example as a collection of ideas. They can evaluate each idea based on their circumstances and decide if it would be appropriate to try. This is very much that transition between Ha & Ri.
So where do the ROI benefits live?
Done right you can remove a level of management. Be that Project Manager, Development Manager or BA resource.
Done wrong, all you are doing is moving those activities to the developers – making them less effective. Ultimately producing worse ROI.
So if you can remove those activities that require that management resource, then you can safely remove that overhead (and yes it is probably correct to consider this overhead in a Lean perspective).
You should be able to achieve all the ROI benefits that you would expect from any Agile process – quicker to market, less overhead, better & quicker decision making. Again, if you are able to remove any overhead then in theory there is an ROI benefit due to the increase in productivity.
You should be experiencing the benefit of happier, more motivated developers (based on the Intrinsic Motivators). With ROI that surfaces in the increased productivity and lower staff attrition. It can also been seen as a positive benefit during recruitment, reducing your recruitment costs.
A fair amount of these benefits are those common with Agile processes & frameworks. The potential is likely to be more due to the refinement and stripping out over overhead – even that provided by the Agile process or framework. But as I mentioned above, this feels like a “Ri” level of mastery.
If you do try it, I would love to hear about how you get on.
Fred George On Programmer Anarchy
SE-Radio Episode 253: Fred George on Developer Anarchy [Podcast]
What is Programmer Anarchy and does it have a future?