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 
exhausting… possibly, but then I would hope that each team worked on a single project at a time before moving to a different one, with enough ‘downtime’ between them (ie there’s always time when you stop coding and do some testing, deployment, delivery etc, and start looking at requirements for the next one). To think that programmer anarchy means a load of programmers continually typing away at code like monkeys working on Shakespeare, is probably falling into the trap a lot of programmers might fall into – less experienced programmers I mean. You’d probably want really experience guys doing this, mature people who know there’s more to life than tapping away at a keyboard all day and night, drinking jolt to keep awake. If you had that, then all this stuff would fall into place, but just like you wouldn’t do this if you only had a team of junior graduates, you *need* maturity to make it work.
As a bonus, mature devs are the ones most likely to be pissed off at the restrictive methods used by most corporates, they can do better (probably have done in the past) and want to do better. This kind of thing allows them to do so – so get that team together and let them do it 🙂
Reading though your essay, I note that all of the points you make against Programmer Anarchy are prefaced with a qualifier like “I suspect” or “I think” or “I bet”. In other words, you lack both experience and data. I don’t have any real data, either, but I do have some experience, and in my experience, none of the problems you mention actually happen.
In fact, the scenario you outline, where most people don’t actually care about the thing they’re working on, presupposes a completely dysfunctional team. I would tend to agree that Programmer Anarchy won’t fix that problem. But I would also note that if you’re starting out that way, no amount of “leadership” will help, either.
One final point. You write: “In practice I suspect there’s a bit of a bun fight for the best bits of work.” I’m not sure who you’ve worked with in the past, but this is the complete opposite of what happened in our case. Senior developers typically have areas of interest that determined what they work on. A frontend developer would not work on the database layer, for example. Seniors pick what to work on by topic and expertise and product need, not by “interestingness”.
New hires, who don’t have any kind of specific expertise, get to pick the most interesting stuff, because that’s how you gain expertise. We often have “new hire project ideas” meetings where we specifically try to come up with ideas for cool stuff for new hires to do, to help them get up to speed.
Pingback: What is Developer Anarchy? | Question and Answer
The idea to call this “Programmer Anarchy” and then go on to define rules on how it should be implemented is kinda absurd.
Understand that anarchy is self organization. So let it be.
But obviously you don’t believe that this would work, and you have to go on and create rules(anarchists don’t like rules, remember?) like daily meetings while at the same time getting rid of managers because it’s bad for “creativity and productivity”.
Getting rid of rules for the sake of getting rid of rules is not necessarily a good thing. Anarchy isn’t chaos. It’s self organization, which means everyone gets to make decisions for themselves and together as a team. If you as a team want to get a project manager, get one. If you want to have daily meetings, so be it. But the idea is not to force anything top-down.
And if someone isn’t dedicated to a project anymore, forcing him to do it anyway just leads to bad code and unhappy developers.
That’s quite like the environment that I’ve been working in for the past three years. Let me tell you how this has gone.
In the beginning, it was a message of self-empowerment led by the previous CTO. Developers and DevOps people were allowed maximum flexibility and in many cases were in full communication with the customer base.
In reality, it became a recipe for technological debt — most of which is still being paid off right now, with accrued interest.
It is a rule in software development that there is always more to do than there is resources with which to do it. There is always one more feature that can and should be rolled in, there is always one more thing to polish or one more test to write. Self-organization, or anarchy, allowed us to pursue the things that specifically interested us, to the detriment of things that needed to be done to keep the platform stable. This resulted in a lot of late-night work when one of the less-loved portions of the codebase went kablooey, usually at the worst time possible, like when critical batched data for the next day’s business was being processed. The boring parts simply did not get enough attention. No matter how conscientious a developer team, there’s always going to be something that will fall off the bottom.
Yes, it is exhausting. 100% is required at all times. It’s a fallacy that 110% is possible, but you’ll still see eighty hour weeks as the norm. You’ll think nothing of waking up because you had an idea at 3:30 in the morning and having it result in a code commit. You’ll joke about cutting off the access of an employee who has not taken a vacation in a while during his honeymoon. When you actually do it, because you promised his bride you would, it will turn into a good penetration test; said employee went absolutely apeshit. Sure, a twenty year old can do it. A twenty-eight year old can keep up, but his or her forward progress as an individual will stop — they will simply cannibalize the time that they would spend learning new things and having relationships with people that make them richer individuals.
Customer access was a two-edged sword. In our case, it ended up cutting us, because our customers pushed for us to meet their time deadlines and developers did not have the customer management skills to deflect or defer those expectations. It became difficult to balance development time against customer support time against the sales teams’ willingness to smooth over the bumps for the fifty thousandth time.
But we’re still paying off that technological debt. We have it all over the place, hiding under rugs and in cabinets and under chairs that haven’t been moved in a while because no one’s had the time to dust under them. The accrued interest comes from decisions that have haunted us throughout our entire existence because if we redesign X, it means a total redesign of Y because it has expectations that a redesign couldn’t meet. So we’re stuck with a decision that would be right at home on a 1980’s IBM mainframe (but we’re supposed to be an agile, cloud-oriented company!) and the engineering challenges that brings with it. Those engineering challenges usually come looking for their payment at 3am, with a lead pipe in one beefy fist.
People burn out. At least half of the original engineering base of the company is gone, and those that are left are older and wiser and more likely to make better decisions about what technological debt we acquire.
And we have project managers.
I’ve worked on a project that was managed like that. It was called Windows Vista. Yeah, there were lots of managers and PMs and testers and writers attempting to keep up with what was ultimately a bunch of anarchist anything-goes developers who were in charge. We all know how that worked out.
The strongest predictor of a software project’s fate is how you measure its success. You get what you incent: lots of commits and deploys? Sure thing, but don’t expect them to be beneficial, non-regressive changes. Bugs fixed? The devs who produce the most bugs generally win there, and the ones who fix the really hard issues lose.
This dev philosophy fails to live up to its claim to be “agile-compatible” in two obvious ways. First: no accountability for test-driven development. If you aren’t proving your code works to spec before you commit, and you aren’t assuming an active role as a tester for your entire project, you fail that agile tenet. Second: no accountability to really meet the customer’s needs. It takes real time and energy to establish the empathy with your customer necessary to truly understand what they need you to build. Talking to them occasionally and throwing code over the wall is about as likely to work as monkeys writing Shakespeare on a handful of typewriters. If your development team is not invested in and measured on their meeting the customer’s needs, your project will fail.
In my experience the most successful software projects have nothing to do with following a rigid methodology, whether it be command-and-control or anarchy. The most successful projects are ones that hold themselves to the right standards – meeting the customer’s needs – and where everyone is willing to pitch in as needed to make sure the right thing is built, that it is built well, and that it is deliverd on time. Abdicating the eye on the prize for destructive metrics like number of commits had never worked a single time in my experience as a developer or a customer.
At Jurisoft/Lexis-Nexis our president imposed “Core Teams” per Covey’s book, The Wisdom of Teams. Our 32 person R&D group that had been so productive that Marketing had asked us to “stop releasing so fast” went to zero output. Anarchy. Management by committee. Nothing at all shipped. In desperation, he re-imposed line management. Output resumed. Software development requires management.
You might want to define Anarchy, or Anarchism, so people don’t immediately assume Programmer Anarchy is a about wearing all black and smashing windows (the media’s definition of Anarchy).
First, let’s examine the Greek roots of the word An-archy. “An” meaning without and “Archy” meaning rulers. Thus Anarchy is the state of having no rulers, not necessarily no rules (again what the media would have you think). Anarchism is the political philosophy of An-archy, which argues that hierarchical systems are inefficient and ultimately harmful to their (un)willing participants. Anarchism argues that decisions should be made collectively (instead of at the top), and those that didn’t agree could opt-out to test an alternative approach (which might end up being better and later adopted).
>> Anarchy. Management by committee. <> Nothing at all shipped. In desperation, he re-imposed line management. Output resumed. Software development requires management. <<
I can't dispute your experience, but I strongly dispute the generalisation you draw from this anecdote (the plural of "anecdote" is not "data"). You might have a point if the add something like "software development *among people who would happily quit their job if they weren't debt peons* requires management". Without such a qualifier, hundreds of successful community-driven open source software projects prove you wrong.
Re the open source comment, this just shows that programmers have the ability to self-manage, not that there’s no management at all. This is the difference between senior and junior devs, in that the “senior” guys know there’s more to development than typing away. I guess it also shows that FOSS code comes from guys who know what they’re doing.
That said, Linus is an example of the worst kind of management, if my boss verbally abused me like Linus does we’d be in a tribunal faster than you can say “you moron” 🙂
“Take the example of a tester, or a 3rd line support analyst – in the main their ranks are filled with the below-par programmer”.
I don’t know if that’s complete ignorance, or whether you’re trying to prove a point!
They have different skill-sets: they are not programmers. In any (decent) company these are standalone, highly-trained roles; not just something that failed programmers do!
Which means, this whole anarchy thing hinges on having a whole team of people who can think in many different ways about projects, products, hardware and software. Unlikely. More likely is that someone in the team has enough knowledge and/or arrogance to pull that off, bullies the rest of the team, and acts as a centre-point to all decisions. We’ve all see that on supposedly level-playing-field teams before. Despotism rather than anarchy.
I am working in the development field for more than 22 years.
I want to say simply that their should be a designer whether you name him [ programmer – lead programmer – PM – BA – may be an intelligent end user – architect – or even simply designer]
As much as that designer is powerful and exposed to the bushiness the project will be successful whether you use waterfall, agile (with its different understandings) , Anarchy or Whatever one of this big names; all of these approaches and their success factors are just dependent on the nature of the project, nature of the people working and their interests and the management (I mean the business management encouragement).
and as general rule moderate approaches are the best [ not too many fear of failure, but some .. ] [ minimize layers of coordination only if their involvement are not really technical (group manager , project manager , scrum master, QA department, testers,.. ). In my opinion some programmers may feel psychologically that they are doing the difficult & core work and obviously all these other names (group manager , project manager , scrum master, QA department, testers,.. ) are just supervisors bugging them and putting them under stress. This can be true to some extent only . But also moderate approach to have leader and tester to assist is not bad or even a scrum master to solve non technical issues. Having such roles can be beneficiary from the point of view ( that we need an eye to watch the product different than the programmer and the end user to resolve conflicts between programmers if it happens.)
Concepts like “programmer anarchy” really have no sense.
To say that somewhere there’s “anarchy” is just like saying that in a certain room, at a certain time, each of the objects inside has not a real position. It is false. Like it or not, each object has its own position at any time. Then, the positions may be changing, objects may be moving, the position may be confusing or impossible to know, but that doesn’t mean there is not. Just like in a programming environment there will be a power hierarchy, relationships, individual tasks, and that doesn’t mean that they are freely chosen by the individuals inside.
I’m not sure that your argument is the best counter-attack; you mention a few aspects that aren’t agile as your defence of agile: a central leader figure to enforce tight deadlines, working flat out to hit a deadline rather than working at a consistent pace, having a leader figure to divide up the work.
My agile teams (with testers, a ScrumMaster, and even an agile coach) work at a consistent pace, split the work as a team and interact with our customers on a regular basis, etc. But they also have a ScrumMaster who helps them improve on a continuous basis, who protects them from over-eager change requesters, helps remove impediments, etc – they smooth the flow of the work going through the team.
Would the team work as well without this help? I don’t think so. Would they be more innovative? Maybe. Would they have more freedom? Possibly. But would this freedom lead to continuous improvement? Probably not.
So, my summary is that it’s important to think what it is that the business wants/needs: freedom & innovation or focus on business needs/value & continual improvement. And what would the debs prefer? I’m not convinced they’d always opt for freedom and innovation.
Pingback: Webtorque » Blog Archive » “Irregular Verbs” in Software Design
Ugh. I love how half of the comments here describe waterfall projects and claim that it failed because they did “programmer anarchy”. No. No you didn’t. You just worked on projects that were poorly managed with people who made mistakes and didn’t act responsibly about it.
If you actually watch his talks (the second one being http://vimeo.com/78808365 ), you will notice that fixing bugs is #1 priority, because it prevents you from finishing a story. If it’s buggy, it’s not finished. Mature developers don’t rush after new features, they take care of their project.
Also, having large, intertwined projects (Windows Vista? No way.) is also incompatible with Programmer Anarchy. Try making microservices like he advises to.
And deadlines? Are you kidding me? Deadlines are the staple of waterfall. (Sure, they can’t be avoided sometimes.) They generally go against everything that is agile – feedback, communication, respect, trust, sustainable pace? If you work 80 hours a week, that’s not agile, that’s just clusterfuck.
Wah! Sounds a lot like “Mummy, mummy, they won’t make me the boss!”
I work for a high-profile UK group that hired Fred George as a consultant a few years ago. Following his advice “developer anarchy” was introduced into the group’s larger dev team. As far as we devs were concerned it was a great success: the whole team was happy and productive and the company attracted some really good developers. There was a buzz in the air: people were everywhere trying out exciting new ideas. Unfortunately the support for the new approach from group’s management soon evaporated when technical problems (which actually originated from bad decisions made in earlier years) appeared. The CTO left and a new big cheese with an antediluvian pre-Agile hierarchical approach was brought in. Fred George was seen no more. Now, developers are not encouraged to have opinions: they’re just expected to follow orders.
That office is now a sad place to work. All the brightest developers have left (some to join the former CTO at his new company), and the only people remaining are uncreative yes men.
While this was going on the smaller team I belong to (working for one of the group’s less important brands) adopted developer anarchy partly by accident. Our tech leader left the company, and was not replaced. He was brilliant and dynamic, a fluent talker, but also slightly domineering. After he left we devs collectively assumed his role. It was like uncorking a bottle. We expanded to fill the gap. The people who liked presenting were usually the ones who do it best: so they naturally took it on. The planning types enthusiastically did planning. The ones with an interest in analytics did analytics. The coding grunts carried on coding. Over time, almost by natural selection, we settled amongst ourselves who would do what. We’ve all taken collective responsibility for our projects. Everyone’s entitled to express their view about the product and what we should do to improve it. We’ve been working like this successfully for a year now. Sometimes we miss having a combative clever talker to defend us against corporate nincompoops, but in general we far prefer the way we’re doing things now. We’re all energised and committed, and we’re all loyal to the group effort.
More and more organisations are going to discover the truth Fred George is pointing to: that individual leaders hold back progress. However superficially brilliant they are, a single leader only has one perspective. He (or she) has less brainpower to bring to bear on solving a problem. His view is limited, so he will make more mistakes. The more brilliant he is the bigger his mistakes will be, because he’ll eloquently persuade everybody else to waste 9 months on a fruitless task. Group responsibility is the way to go.
“antediluvian pre-Agile hierarchical approach” still laughing, and great insight.
Why is it that when there are examples of teams working well together and the lessons learned are shared, naysayers are the first to claim, “Marxist!” Individuals using their unique strengths in support of a common vision isn’t Marxist, or even idealistic. A massive, top-down approach mandates conformity for the so-called greater good and punishes individualistic contributions. That’s Marxism. Individuals using their strengths to support each other and cover each other’s weaknesses in pursuit of unified vision is a sign of maturity and strong leadership.
Marxist?? This review by a writer who leans against the practice is the first time I’ve heard the term in reference to a practice like this, and the first time I’ve heard of this particular practice at profit-making companies (government agencies would never do this, they’re based on top-down everything and controlled political drivers).
This kind of “anarchy” as described is the OPPOSITE of Marxism, or socialism. As much as so many tech companies and known technical “pioneers”, like Open Source projects like to call it, projects done with Open Source are NOT even “democratic”.
They are individualist. OSS offers a sort of view into what free-market anarchists (“anarcho-capitalists”) are about. Meritocracy in recognition and often in recompense. There are already attacks on the meritocracy of it with interference from the shaming practices.
Hi Alan, thanks for your comment – I am referring to Karl Marx’s vision of free association of workers. Which, to my mind doesn’t have too many dissimilarities with Proudhon’s vision of anarchy.
I’ve never heard of anarcho-capitalism before, I’ll look it up! M