A developer I know recently told me that he wasn’t interested in any new opportunities in the short term because his team were about to adopt Fred George’s post-agile concept of Programmer Anarchy. Having piqued my interest, I started to explore and thought I would share my findings.
From what I’ve found I think he’s a bit mad, but he thinks it’s a good idea and at least 2 major UK companies are using it, so there must be something to it.
* Frequent visitors to this blog will notice that I use the term “Programmer” here a lot, as opposed to the usual “Developer” – that’s simply because Fred George uses that term, and he probably uses it because he’s American.
WHAT IS this Programmer Anarchy?For those of you who don’t have their ear pinned to the techie ground, Programmer Anarchy is a concept that has been around for about the last year, is considered “post-Agile”, has so far been evangelised by Fred George and says that software development is more productive when programmers are “self organised”.
So Programmer Anarchy is…
- 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
For more detail here is link to a presentation Fred George gave, and a link to the slides.
What has Fred George done with it?
Fred George’s experience of Programmer Anarchy has been at an internet advising company called “Forward” where they got “40 geeks together” and instituted the new methodology. They work for a number of high profile clients, including “Search” a big energy company. And they report not only happy programmers but also some impressive statistics:
So this “programmer’s Nirvana” is going to be the next big thing then?
I don’t think so. I think it’s a great idea, but ultimately I can’t see it being a game-changer.
Agile is a big tent concept that allows lots of different implementations under the same name and has been widely adopted for different reasons. On the one hand it’s a good PR tool that breaks down the wall between producer and user, and on the other hand it improves productivity when correctly implemented. I also don’t think it’s any co-incidence that the popularity of Agile really picked up at the same time that the big tech reliant companies started to make their offshoring models work successfully. Paired programming can produce higher quality code when people work collaboratively, but it takes up two developers’ time and that can be hard for some projects to justify.
Agile is implemented in a wide variety of ways, from a kind of religious dogma, to a model that is fairly close to waterfall but with stand-ups and scrum masters through to the “Thoughtworks approved” approach. One thing I have found as a recruiter is that it takes a team of very high quality developers to make a truly Agile methodology work successfully. I know a team at Credit Suisse that have successfully implemented something fairly close to this (a team of 20 developers, one BA and one PM) and they took a long time to recruit the team because their entry criteria was so high. You don’t just need a good programmer, you need one with good communication skills, one that understands the business enough to work with it productively and one that is savvy enough about why tactical and strategic decisions are made.
And so, I suspect, it is with Programmer Anarchy. Fred George’s experience of Programmer Anarchy was probably so positive because he was working in a team of high performance programmers, who, like him, could cope with the demands of self-organized development. The advantage of Waterfall and the less purist versions of Agile is that they can accommodate lower performance team members and still be productive. Take the example of a tester, or a 3rd line support analyst – in the main their ranks are filled with the below-par programmer. They help the process by reduce the programmers’ work load and don’t cost as much to the CFO’s bottom line. So if you get the division of labour right, you can produce the same result for less money and spend less time recruiting the team in the first place.
But I guess the real problem with Programmer Anarchy is that it takes away the central “leader” figure. Often in big projects not everyone contributing has dedicated their lives to the success or failure of this project. Programmer Anarchy presumes that everyone in the team is totally passionate about the project’s success, but in reality it’s often only a few members of a team who wholeheartedly take on the successful delivery of the project as a top priority in their lives. You find that many other members of the team prioritise their private lives more when it comes to spending time in the office, or that their minds are somewhere else when they are sitting at their desks. I wonder if Programmer Anarchy presumes everyone on the project is a natural pig and forgets about the chickens.
With a central leader figure you also get one person who has staked the next part of their career on the success of the project and they become the driving force behind it’s delivery. Programmer Anarchy presumes everyone is their own leader, but again not everyone is like that. Lots of people don’t want to take control or drive through the delivery, they just want to do a day job.
Finally I suspect that Programmer Anarchy has a tendency for “perfectionism-by-the-back-door”. On the face of it it has a kind of hacky feel, where programmers produce lots of work because they are all developing at their optimum rate. In practice I suspect there’s a bit of a bun fight for the best bits of work, with the least interesting bits going to the least outspoken members of the team and without a central “leader” figure no-one to enforce tight deadlines. And who organizes the stand-ups in the first place? In an environment where formal power has been removed, anyone with some measure of control over the process will start to exert their power. With a central leader there is someone who divides up work and ensure that deadlines are hit.
I also bet “Programmer Anarchy” is exhausting as 100% effort is expected all of the time, when in fact normal development isn’t like that. As with any job there is an ebb and a flow at busy times and slow times. I would like to see a comparison between the productivity statistics that Fred George gives for his “Programmer Anarchy” team, and the same criteria for an Agile team who are working flat out to hit a tight deadline
I suspect that Fred George’s experience of Programmer Anarchy was successful because it’s the right methodology for him, with his level of professional and commercial experience and with his independent mindset. And I think that some teams will take this up and it will work very well for them, but in general its not right for everyone.
So I don’t think we need to start learning the words to any Billy Bragg tunes just yet.
OK, so what would you do then?
I think the most powerful idea in Programmer Anarchy is the idea that programmers take personal responsibility for the success of each project, the rest of it feels to me like a mix of good intentions, some feel-good Californian vibes and a heavy dash of Marxism. I think that any kind of team will always need a division of labour, a leadership structure to organize and motivate the team and a support function to allow the core part of the team to focus on doing what they do best.
Martin Jee's blog 
