Summary As of July 2011, there is one documented example of a Facebook team that uses a Scrum pracMce (Daily Scrum). It is not clear to what extent they follow the Scrum Guide. (End of short version)
Rugby as a metaphor for a style of development h/p://hbr.org/1986/01/the-‐new-‐new-‐product-‐development-‐game/ar/1
Rugby as a metaphor for a style of development
From Takeuchi and Nonaka’s paper • The tradiaonal sequenaal or "relay race" approach to product development [...] may conﬂict with the goals of maximum speed and ﬂexibility. Instead, a holisMc or "rugby" approach -‐ where a team tries to go the distance as a unit, passing the ball back and forth -‐ may be/er serve todays compeaave requirements.
From Takeuchi and Nonaka’s paper • [...] the product development process emerges from the constant interacaon of a hand-‐picked, mulMdisciplinary team whose members work together from start to ﬁnish. Rather than moving in deﬁned, highly structured stages, the process is born out of the team members interplay [...].
From Takeuchi and Nonaka’s paper • [...] the team may be forced to reconsider a decision as a result of later informaMon. The team does not stop then, but engages in iteraMve experimentaMon. This goes on in even the latest phases of the development process.
From Takeuchi and Nonaka’s paper • Top management kicks oﬀ the development process by signaling a broad goal or a general strategic direcMon. It rarely hands out a clear-‐ cut new product concept or a speciﬁc work plan. But it oﬀers a project team a wide measure of freedom and also establishes extremely challenging goals.
From Takeuchi and Nonaka’s paper • Fuji-‐Xerox located the mulMfuncMonal team building the fX-‐3500 -‐ consisang of members from the planning, design, producaon, sales, distribuaon, and evaluaaon departments -‐ in one large room.
From Takeuchi and Nonaka’s paper • The self-‐organizing character of the team produces a unique dynamic or rhythm. [...] they all must work toward synchronizing their pace to meet deadlines. [...] the team begins to work as a unit.
From Takeuchi and Nonaka’s paper • Because members of the project team stay in close touch with outside sources of informaMon, they can respond quickly to changing market condiaons. Team members engage in a conMnual process of trial and error to narrow down the number of alternaMves they must consider.
From Takeuchi and Nonaka’s paper • They also acquire broad knowledge and diverse skills, which help them create a versaMle team capable of solving an array of problems fast.
From Takeuchi and Nonaka’s paper • Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos.
Scrum is at its core what Takeuchi and Nonaka described
Announcement of ﬁrst release InfoWorld / Feb 21, 1994 h/p://books.google.com/books?id=BzsEAAAAMBAJ&pg=PA19&dq=%22easel+preps+development+tool%22
Announcement of second release InfoWorld / Aug 29, 1994 h/p://books.google.com/books?id=jjgEAAAAMBAJ&pg=PA30&dq=%22easel+to+ship+object+oriented+tools%22
The product is sall under acave development h/p://www.cincomsmalltalk.com/main/products/products-‐objectstudio/
Achievements • The ﬁrst sopware Scrum team did not only produce sopware fast • It created highly innovaMve features that deﬁned a product for years to come
Fun fact • Scrum is the only Agile process/methodology/ framework with roots in product development • All the others came out of internal projects or consulang projects
Back to Facebook … Thesis: While there is lile or no evidence for “prescripMve Scrum” at Facebook, there are striking parallels to Scrum as described by Takeuchi and Nonaka. This may be called a variant of Scrum, just as Jeﬀ Sutherland referred to the process used on the Borland project as a variant of Scrum.
Julie Zhuo We believe in really small teams,so, you know, we have, at thispoint in time, like, a team forSearch, a team for Newsfeed, ateam for the Profile, a team for,you know, ads, and generally,those teams are pretty tiny.
Julie Zhuo Like, we have generally one PM,one designer, who is responsiblefor the whole feature or even avertical, in some instances, wehave a handful of engineers and …
Julie Zhuo … as much as we can, we like to,you know, have everyone worktogether but keep sort of atight-knit kind of community sothat each team can sort of feellike its one small company in andof itself.
Julie Zhuo So Im a designer, I actuallymanage half of the product designteam, and right now the productdesign team is about eighteenpeople.
Julie Zhuo … the way that we think ofproduct design at Facebook is its!- you know, some companies havea segmentation of like, visualdesigner, interface designer, designstrategy –!and for us its really just onerole …
Julie Zhuo ... and traditionally weve also triedto hire really technical designersand people who can go into thecodebase and, you know, write upthe front-end …
Julie Zhuo … or at least have some familiaritywith the front-end layer so theydont have to sort of go in, youknow, always ask an engineer totweak something by five pixels.
Adam Mosseri, Product Design Manager h/p://www.youtube.com/watch?v=bKZiXAFeBeY
(Chief) Product Owner: Mark Zuckerberg h/p://www.youtube.com/watch?v=DfN1YaYdgRg
Mike Schroepfer, Vice President of Engineering h/p://www.guardian.co.uk/technology/blog/2010/nov/22/facebook-‐developer-‐life-‐inside
Mike Schroepfer How many projects do you have going at once? Its hard to tell, because we have them running all the ame, but they might be just a singe person or two. The answer I guess would be somewhere between several dozen to 100 at once.
Mike Schroepfer How do you know if theyre running to plan? The big problem as organisa=ons like Google or Microso@ get larger is keeping what theyre doing synchronised. Well, intuiMon is what gives us the ideas for what to do, and data tells us if were ge_ng it right. We iterate to ﬁnd out if a projects doing it right. Or you might make something live and then you look at whether people are using it frequently, or whether they use it once and dont come back. If they dont come back then we probably didnt get it right. Its a constant process of iteraMon. The longer it gets before you get in data from the outcome, the worse its going to be if its not right.
Mike Schroepfer As companies get bigger, they face the problem of decisions having to ﬂow up and down management, and inevitably things ossify -‐ its been like that for Microso@, and there are signs of it at Google. Is there a way to avoid that at Facebook? (laughs) Yes, we dont have the layers of management approval! We dont pass things up and down the chain. The team working on the product development makes the decisions. If theres a problem or if they think it merits it then they will talk to Mark [Zuckerberg] directly. We try to do a good job of se_ng out the context of the task and release people to get on and do it. People are pushing new features and code to the site every day. Its really about trying to remove barriers and reduce fricMon in development.
HipHop Team h/p://www.youtube.com/watch?v=DfN1YaYdgRg
Facebook Video Team (Hackathon) h/p://vimeo.com/6220145
So what do you think? Thesis: While there is lile or no evidence for “prescripMve Scrum” at Facebook, there are striking parallels to Scrum as described by Takeuchi and Nonaka. This may be called a variant of Scrum, just as Jeﬀ Sutherland referred to the process used on the Borland project as a variant of Scrum.
Roles • Mark Zuckerberg as (Chief) Product Owner • Role of product managers and teams • Hackathons as a way for developers to get their ideas on the “Backlog” • Role of project managers and engineering managers
Organizaaonal pa/erns (Jim Coplien) • Community of Trust • Unity of Purpose • Holisac Diversity • Few Roles • Producers in the Middle • …
Flow principles (Don Reinertsen) • The Principle of Mission • The Principle of Peer-‐Level Coordinaaon • The Principle of Regeneraave Iniaaave • The Principle of Face-‐to-‐Face Communicaaon • The Principle of Colocaaon • The Trust Principle • ... (see h/p://www.limitedwipsociety.ch/en/case-‐study.html)
Forces shaping Facebook’s culture • How would you organize development if your engineers were themselves users of your product? • How would you organize development if your team got realame feedback from actual users?
Joe Kinsella’s retrospecave h/p://www.hightechinthehub.com/2010/10/8-‐lessons-‐from-‐the-‐ﬁrst-‐scrum-‐team/
Joe Kinsella’s retrospecave The team grew over the years, but never during my Mme exceeded 6-‐8 people. For a while we had Mike Morris from our San Diego oﬃce, Dave Hoag from Easel consulang, and Jeﬀ McKenna, an external object oriented consultant. We also had several developers from a Danish consulang ﬁrm working with us. But throughout the Mme, we maintained a moMvated and high performance team with a real passion for the crah of sohware engineering.
Joe Kinsella’s retrospecave #1: Work With Integrated Cross FuncMonal Teams #2: Engage in Constant CommunicaMon #3: ConMnuously Demonstrate Your Product #4: Hire ConMnuous Learners #5: Work Directly With Customers #6: Invest in Code ConsolidaMon #7: Create Mentoring OpportuniMes #8: Build Social Bonds
Joe Kinsella’s retrospecave #1: Work With Integrated Cross FuncMonal Teams The Easel team was a Mghtly knit group that included development, quality assurance, and product management. One day our product manager, Don Roedner, took me aside to tell me how diﬀerent this was from his previous experience. The Mght cross funcMonal integraMon allowed for a more rapid product development process, increased agility, and eliminated the need for more formal communicaaon.