Hack Day at REA is something that started very small in IT 4 years ago and has grown to become the showpiece of culture, collaboration and innovation for the whole company. It took us a while to get there but we’ve cracked the formula for awesome Hack Days and now have an ever growing roster of visitors coming to see how we do it. We put together a little video that showcases our Hack Day story. We hope you enjoy it and it sparks some ideas on how to do it in your own company. Share your own Hack Day story in the comments below!
In my first post on distributed agile I described how our teams are structured. That’s a foundation piece, but a more interesting aspect of our distributed agile model is how we communicate.
Communication is at the heart of a healthy IT delivery team. And at REA we believe in the value of face-to-face communication, so much so it’s enshrined in our operating principles. But isn’t that the very thing that becomes difficult with distributed teams?
Well, If you’ve worked in traditional distributed teams you may have seen the signs of a break down in communication – long overnight emails, long lists of issues and actions, frustration, missed goals, misaligned expectations, poor quality, the occasional stilted video conference call for project updates or to fight fires, etc.
So at REA we practice extreme communication. In this post I’ll describe some of our practices, but it’s important to understand that good communication is based on strong relationships and trust, and achieving that in a distributed team is difficult, I’ll describe how we do that in another post.
Validation to encode our business rules. It’s a different way of thinking. It uses the Scalaz library.
Over the last few years of maintaining code old and new at REA, it has become abundantly clear that the neglect and misuse of type-systems has had a sharply negative impact on our codebases. Here we address the concrete causes and consequences, and propose concrete and achievable solutions.
Types at REA
Every week, AWS credentials leak into the wild and are used to mine bitcoins or worse.
In April 2014, DrawQuest closed down after a security breach in which their Amazon Web Services credentials were used to create hundreds of EC2 instances, probably for mining bitcoins. DrawQuest decided they could no longer trust that their core data wasn’t compromised, and closed their doors.
Wouldn’t it be great if there was a tool that could help prevent this sort of thing happening? Well, now there is — enter Credulous.
Our IT teams have been working in a distributed agile way for about 3 years now, we’re really pleased with the results. Distributed working is a challenge, so I’d like share what’s worked for us, I’m confident these can be repeated in many other organisations.
Here’s the basic set up:
We have 2 delivery centres. Centre #1 is at our headquarters in Melbourne. That’s our largest centre with many cross functional teams, each team here including IT delivery, IT operations, product managers, sales and other business folk. Centre #2 is in China, it is owned and operated by our partner ThoughtWorks, with a focus on software delivery but increasingly other functions too.