On 21 November 2016, I joined Redbubble as a web intern. My first surprise was meeting two other interns, Kirsten and Nick, who were starting their internships on the very same day, and Xinyi, who jumped on board as a data science intern the following week. At Redbubble, diversity is celebrated and individuals are welcome. Over the last few months, I have met people from all walks of life who work towards a common mission: to support independent artists and bring more creativity into the world. It is my personal belief that software is our most powerful means of achieving these goals. Through software, we are building more than just another online marketplace. Redbubble has grown into a community for
Image: sand clock by valeo5 Let’s assume you’re working in an a team. An Agile team (of course). Chances are you’re doing daily stand-ups. Perfect, right? Not quite. Here’s why: 4 out of 5 times you don’t need daily stand-ups in your team. Disclaimer: Lots and lots of other team leaders / scrum masters / engineering managers / etc. think like me, which means there’s hundreds of articles out there covering this particular topic. So if you’ve been reading about stand-ups for a while, a lot of what follows might sound familiar. When to try stand-ups In my opinion, there’s only two situations a stand-up is worth trying and might add some value, at least for a little while. (Almost) every
How to survive the consultation process when everyone has an opinion You have been charged with getting two proposals off the ground. The first proposal is for a Nuclear Power Plant. The second is for a new Bike Shed. Way back in 1956, a gentleman by the name of C. Northcote Parkinson described the above scenario to illustrate a concept now referred to as Parkinson’s Law of Triviality. The thing is, nuclear power is complicated. It requires a lot of specific expert knowledge. So much so in fact, that the average person cannot really understand it all. Consequently, when faced with a proposal for a power plant, most stakeholders will assume that someone else has checked all the details before
Image: A Look Back by Michael McClendon This post comes from Iran Rajakaruna, a junior engineer who came to us through the Tin Alley Beta internship program. Last summer was a big turning point in my life. I still remember the day that I came for an interview with Redbubble the same way that I remember any other first days in my life. I was excited, anxious and happy at the same time. My first impression of Redbubble was a beautiful experience, like love at first sight. I loved the funky office with bean bags, foosball table and free beers. Let me go back a few months and start from where it all began. Last November, I was at RMIT University
Image: “Surfing kangaroo and friends” by pixbyrichard The Australian-English dialect is unique in many aspects, with a large number of colloquial terms that are often impenetrable to non-Australian English speakers. This phenomenon extends to technical terminology as well. This document is an attempt to assist non-Australian English-speaking technical professionals when communicating with their Australian counterparts. For a guide on pronunciation of Australian English, see https://en.wikipedia.org/wiki/Australian_English_phonology bludger, n. a sleep command (suggests a sub-optimal practice) e.g.: “Bugger cron for a joke – sling a bludger in there” meaning: “I do not believe that scheduling a command will be worth the effort. Let us instead call sleep.” bordit, v. draw something on the whiteboard e.g.: “Bordit, mate!” meaning: “My friend, I am struggling to comprehend your
Most of us have come across goal setting in one way or another, be that at work when your boss comes over and tells you that you have to reach a certain sales target this quarter, or when we make a new year’s resolution to learn a new language. But why do we constantly set goals? Does it even work? Can’t we just all try our best and be much happier? Turns out that setting effective and meaningful goals can have a tremendous effect, not only on your performance, but also on other aspects of your (work-)life. Why set Goals? Research on the topic of goal setting has been done for more than 50 years and a lot of it
Last Wednesday, we hosted a meet-up of the Agile Product Owners and Business Analysts group. The title of this meetup was “Validated Learning and Outcomes Using Lean Startup and Agile“. At Redbubble, we believe that sharing the knowledge and the experience we have is important for the community. We are grateful to have such capable and keen people around us and hosting an event like this would allow us to make the world a better place. We also wanted to talk about how we practice Lean Startup and Agile principles to achieve our goals of increasing value to our customers.
Some time ago, we stumbled on a way of looking at organising development teams courtesy of Spotify. According to this paper (PDF, and also an excellent read), Spotify organise their teams in several orthogonal ways. Redbubble is quite similar.
A couple of weeks ago we were honoured and excited to welcome Alistair Cockburn, one of the authors of the Agile Manifesto, into Redbubble HQ. It was a hastily arranged, last minute opportunity, and we were thrilled that Alistair could spare the time for us out of his busy trip to Melbourne. Alistair took over Level 2 (none of our meeting rooms were big enough for the occasion). He told us a bit about himself, his views on Agile Software Development (he describes it as a “co-operative game”) and ran an exercise with us.
I recently had cause to reflect on the fact that our engineering teams regularly release code changes into production multiple times within a single day and felt it worthwhile to elaborate on what that means and how it has changed the way we work as a business. This practice is known as Continuous Delivery. Continuous Delivery is a logical extension of the Agile philosophy especially the practices of Extreme Programming. It requires a high degree of automation and a trivial deployment process. It also requires courage and the willingness to not take the easy way out in your overall processes. Most deployment mechanisms can actually be run multiple times within a single day – it would be rare that a