Have you ever imagined what would happen if you let software developers work on what they want? Well, we did it. For one day. And here is what happened…

How it all began

“OK, listen: there is no backlog today.”

When we first heard these words from Megan instead of the usual beginning of standup, we didn’t know what to expect. Further explanation wasn’t elaborate either: there is only one rule: you need to demonstrate something at the end of the day.

We had different reactions: we were happy (“Great! A break from the day-to-day tasks!”), shocked (“What did they do with my safe and predictable to-do column! Help!”), insecure (“Can I really finish something to show in just one day, with no planning, estimating and design?”).

So that was it: for one full (work) day, all developers in our team at Shutl were supposed to forget about ongoing projects, deadlines and unfinished tasks from the day before. We could work on whatever we wanted. We could pair or work individually. We could work on a DevOps task, on a working feature or just on a prototype. We could develop a feature on an existing application or create a brand new project.

The first thing we did was a small brainstorm where we describe our first ideas. It was not obligatory but helped in forming pairs and getting some encouragement for our little projects; and then we just started coding.

Developer Anarchy

Now, let me give some background behind this idea. You may have heard about “programmer anarchy” in context of development processes and company culture. In a few words: letting engineers make decisions on what and how they develop in order to meet critical requirements. Getting rid of “managers of programmers” from your development process. Fred George, the inventor of the idea implemented it in a couple of companies. There was also a big buzz about how Github works with no managers (or rather with everyone being a manager).

These are great examples to read and think about. There are different opinions about this philosophy. Certainly, developing a culture and process that leaves all decisions to developers requires courage, time, money and a certain kind of people in your team. You have to think very carefully before applying developer anarchy as a day-to-day rule.

We asked ourselves if there was anything we could do without changing our processes and getting rid of our managers but still gain inspiration from the concepts of developer anarchy? We reckoned we could and Developer Anarchy Days were born!

How to start

Introducing Developer Anarchy Days required very little preparation or changes in our organisation, no planning or product management before should be required. We did have some discussions prior to the event on whether it should be a spontaneously picked day or a planned and scheduled action. We decided for mix of both: the team would get a ‘warning’ email some days in advance so that can start thinking about it, but the actual day was a surprise.

Is it suitable for my team?

The concept is very lightweight and open to interpretation. The premise is simple, give your developers a day without a backlog, without predefined tasks and let their creativity take over, and this has benefits to whatever team composition you may have. Less experienced developers get a chance to expand their skills and their self confidence as they gain experience in owning and delivering something in a short time frame. More experienced developers get a chance to try out some new technologies they’ve been itching to experiment with. And as always, pairing is always an option (and encouraged) so there is always someone to help and learn from.

What if the team is not an agile team at all? Well, that’s actually a great opportunity to taste a bit of agility. What can be more agile than delivering in just one day?

Isn’t it a waste of time?

It depends on how do you define wasted time. If you see it as any time not spent directly on delivering pre-defined business requirements/stories – then yes, it is wasted time. You could say the same about avoiding technical debt, working on chores, organising meetings, playing ping-pong after lunch… Like with any other culture-related thing, it is hard to say: you may “waste” one day on building software no one will ever look at again. Or you may learn something, make developers more motivated, invent internal tools that improve efficiency or develop some great new innovations that do help the business goals.

Is one day enough time to develop something?

Yes and no. It’s probably not enough time to develop something production-ready, but that’s not the intention. It’s more about trying something new, developing a prototype, creating a small internal tool or just presenting new ideas to the team. For that, we’ve found that one day is enough.

You can make it longer and spend a couple of days on building small projects in small teams. This may be more effective in complex and usable projects, but also requires more preparation: some planning considering ongoing project roadmaps and probably announcing it earlier so everyone can prepare potential ideas for the projects.

Isn’t Developer Anarchy Day just another name for hackathon?

Developer Anarchy Days have a lot in common with “hackathons”, “hackfests”, “codefests” or “hack days”. They’re all about intensively developing and presenting creative ideas. The main difference is that hackathons are usually bigger events in form of competition, very often involving participants from outside of the company. They require proper event organisation including marketing, proper venue, food and infrastructure. And usually the promotional aspect of it is very important. You don’t need all this to organise Developer Anarchy Day.

What engineering teams can get from this?

• Developers can show that they are able to make decisions and have creative ideas
• Engineers often have ideas from a technological perspective – something that businesses may sometimes miss
• Motivating feeling of doing something of your own
• Developers can feel how it is when they have to not only deliver something on time but also limit the project to something they can show and “sell” to others
• Developers can feel like a product manager and understand their job better
• It breaks the routine of everyday (sometimes monotonous) deliveries
• It gives an opportunity to finally do stuff that we thought would be nice but doesn’t bring any direct or indirect business value (e.g. internal tools)
• Finally, there is time to try some new technology or “crazy” idea!

How did it end up?

OK, let’s go back to Shutl and our very first Developer Anarchy Day. It was a busy day but definitely a fun one. Everyone felt responsible for finishing what they began on time – after all we all had to present something. Some of us were pairing, some decided to give it a go by themselves (although we love pairing, it is good to get away from it from time to time…).

Next day, first thing in the morning we presented our work. The variety and creativity of our little projects was beyond all expectations! Here are couple of examples:

“Easy login”
As Shutl has a service oriented architecture, our everyday work (as everyone’s DevOps) involves logging into multiple boxes. One of our engineers spent Developer Anarchy Day building a super useful command line tool that automates the process of logging in to specific environments without having to ssh into multiple boxes and remember server names. We’ve used it every day since, making our lives easier.

“Shutl mood”
Every day we gather lots of feedback from our customers. The stars they give in their reviews though are a bit impersonal. You can learn much more by analysing the language of the feedback comments. A pair of Shutl developers spent a day building a language sentiment analyser allowing us to get a sense of the general mood of our customers, based on the words they used.

“Immutable deployments”
Another Shutl engineer decided to be more DevOps for that day. He experimented with some new tools and demonstrated immutable deployments with CloudFormation and Chef.

“Pre-defined order”
Looking for common or possible use cases of our services, we realised that it would be really convenient to use Shutl to pick up and deliver items sent by private sellers on Gumtree or eBay. We have Shutl.it  which allows customers to deliver items from point A to B. The idea was to create a shareable link that pre-fills Shutl.it with pick up information so any retailer or private seller can offer Shutl as an easy delivery option.

We definitely had fun and learned something. Actually, we now use “Easy login” every day and “Predefined orders” evolved to an idea which we have now on our roadmap.

What was the feedback from developers? No surprise here: it was genuinely positive. What can be better for us, nine-to-five workers than a little bit of anarchy, especially when it lasts only one day, after which we quickly revert back to comfort and security (prioritised backlog and product management…). We all agreed that we want to repeat anarchy on a regular basis. And we do. It became an important part of our work culture.