What is "Developer Anarchy"
I've come late to agile development. Actually I must be very late because "post-agile" is already a thing. One of the is "developer anarchy" or how Fred George explains it to business people "Extreme Agile". On the Software Engineering podcast he explains the concept. Martin Jeen has written a nice overview in his blog:
- At the start of the day the programmers choose their own work during daily stand-up meetings
- There are no PMs, Iteration Managers, BAs, QAs / testers or “managers of programmers” – all the normal rules of managing software development in a professional environment are gone. This is on the basis that formality and rules are constraining to creativity and productivity
- It runs on the concept that with no managers to give power to their programmers to go ahead and develop (managers “empowering” their teams), programmers go ahead and take total responsibility for the success of each project in a form of self-organised “anarchy”
- Integral to this is the adoption of the mindset “what if you were guaranteed not to fail” and the idea that disagreement and failure is expected, and both are ultimately productive outcomes. They want programmers to lose the “fear of failure”
- Programmers work directly with the customer, which builds more trust and understanding about how the SDLC is affecting delivery
- And to top it off Programmer Anarchy is still Agile Manifesto compliant:
o Individuals and interactions over processes and tools
o Working software over comprehensive documentation
o Customer collaboration over contract negotiation
o Responding to change over following a plan
Should we all become anarchists?
On this stackoverflow discussion someone goes off on an interesting tangent. They argue that any development process is going to work with experienced developers and linked to a post of fictional "Meditation Drive Development". There's a lot to be said about focusing on people over processes. IMHO processes often decide how engaged teams are. This often decides a project's success. As everybody knows who played telephone -- or "stille Post" in German -- information gets lost in the transfer. Any method that puts developers in closer contact with customers is going to help. Some thought should go into guaranteeing the team has some quiet time to do their work.
In the end it's difficult to evaluate a method. Somehow Scrum has managed to sneak agile practices in the enterprise world. Of course a lot of successful experiments with a method help. Like any social experiment reproducibility is a real concern.
In the life of a software project we always reach a similar issue eventually. Should we rewrite the whole thing or refactor it piece by piece? Posters on HackerNews often claim the big rewrite in another language "changed everything". Then others wonder if a rewrite in the same language would have had the same effect.
Would any different more agile method yield the same success? Teams gather experience with every project and become more and more independent. At my own work we managed to get by without a Scrum Master for over a year because the method was so well established.
Cutting out middle-men and giving autonomy to developers seems like a good idea. Letting them work directly on business cases instead of vague user stories seems a useful refinement. Excluding business experts who don't want to program might isolate a team from the "real world". I would be happy to teach any team member to program, so maybe this can work. I do hope more experiments are done and we'll get a useful new impulse on what post-agile could mean.