Sunday, March 13, 2011

Hackathon - How it's done at Facebook

Many companies using Scrum have hackathons. Some once a quarter, some once a month, some every week. Here is a great video from a Facebook hackathon.


The Birth of Facebook Video from Soleio on Vimeo.

Does Facebook do Scrum? You decide. Click here for another video of a daily Scrum meeting.

5 comments:

Lance said...

40 hour sprints. This is like the 48 hour Film Project http://www.48hourfilm.com/

Both examples of lots of rubber meeting the road, people focused, working in groups rather than cubes, and managing super short feedback loops to measure results.

Thanks for sharing that video!

jmeydam said...

This video was recorded two years ago.

With the scale Facebook has reached, Hackathon projects are usually not immediately suitable for a public release any more, as far as I know.

How has that changed the role of Hackathons?

I'm still not quite sure how to best map what Facebook does to Scrum, but one way to look at it is that Hackathons are now a way for Facebook staff to get something on the backlog.

Before an idea is proven in code, it is probably not taken seriously. If Facebook staff manage to create a promising prototype, however, Zuckerberg (the Product Owner) may put this on the fast track (prioritize it in the backlog). Hackathons give an opportunity to Facebook staff to create those prototypes.

Jeff Sutherland said...

Hi Jeff,
Note from Jens Maydem:

By the way, the Facebook Scrum team that worked on the new Profile page is fairly typical, according to a Facebook engineer (see below).

Please note that he is just referring to team size and collocation.

Apparently, product managers have recently become more powerful at Facebook.

Before, teams seemed to have had more autonomy and basically worked directly under Mark Zuckerberg, the "Chief Product Owner," even though product managers may have worked with the team.

See Yishan Wong's answer:

http://www.quora.com/Facebook-Inc-company/Are-Facebook-engineers-impossible-to-manage

During my time, it was pretty hard to be a product manager. Engineers did what they wanted, and many product decisions were made by Zuck. My sources[1] tell me that the product organization has nowadays succeeded in implementing a "product development process" that has given them more control over engineers. If this is true, it may be contributing to engineer dissatisfaction.


You may also find these links interesting:

http://www.youtube.com/watch?v=DfN1YaYdgRg

http://www.guardian.co.uk/technology/blog/2010/nov/22/facebook-developer-life-inside

Life inside Facebook: how head of developers organises 500 people
Exclusive: Mike Schroepfer tells the Guardian how he manages the tiny teams, and why if you haven't changed the site in your first week, something's wrong

Best wishes,

Jens


http://www.quora.com/How-typical-is-the-Profile-team-as-shown-on-www-time-com-for-the-way-development-is-organized-at-Facebook

How typical is the Profile team as shown on www.time.comfor the way development is organized at Facebook? Edit
The video at http://www.time.com/time/special... shows a small, collocated cross-functional team of engineers, designers and data experts. However, most developers at Facebook seem to work in large open plan offices - do they also belong to a team, but do not sit right next to their fellow team members? Edit
Add Comment • Flag Question

Justin Mitchell, user 12800193
9 votes by George Cabrera, Paul Carduner, Olaoluwa 'Ola' Okelola, (more)
Pretty typical (at least for engineering, design, PM, and some data)

First, you're mistaken about us working in offices. We have (and will continue having in the new building) a relatively open floor plan where many teams and roles mingle together. That said, people are generally surrounded by their teammates (of course, with an average team size somewhere below 10, it's easy for everyone to sit together).

In terms of cross-function exposure, PMs generally sit with the engineering team, and designers often sit with the team or have hotel desks. PR, legal, and other functions typically do not sit with a team, since they work across many products at once.

When teams are shipping a product in the near future, they (including design/PM)sometimes move to a "war room" - slightly more secluded from the rest of engineering in order to focus on execution. After a launch, the teams generally move back into big open floor areas.

--- everything below here is my own opinion ---

Having teams in close proximity produces camaraderie amongst the team, a familiarity that typically follows geographic proximity, along with easy access to people for questions/discussions/etc... However, the open floor plan allows for many serendipitous cross-team encounters which often lead to fruitful product discussions. There are some great arguments for each developer having his/her own office (Microsoft style), but I much prefer this configuration.

Arne Evertsson said...

Take a day and write code. So simple and smart. I should do that.

Arne Evertsson said...

Take a day and write code. So simple and smart. I should do that.