1 ISTM_6204 Google AdWords: The Art of Scrum && QuintupleConstraint Alexander J. Singleton The George Washington University School of Business MSIST 10/25/2015
Dec 03, 2015
1
ISTM_6204
Google AdWords: The Art of Scrum && QuintupleConstraint
Alexander J. Singleton The George Washington University
School of Business MSIST
10/25/2015
2
Table of Contents 1. Project Abstract…………………………………………………………………………………………………...3 2. Strategic Objectives……………………………………………………………………………………….....…..3 3. Project Objectives……………………………………………………………………………………….………..4
3.1. Scrum project management experimentation for two projectready GADW applications………..4 3.2. Debrief and evaluate of Scrum administration, or any adjustments………………………………..4 3.3. Implementation therefore, including any variations for the greater good of Google,....................4
companywide, as the bonafide deliverable…………………………………………………………..4 4. Participating Organizations……………………………………………………………………………………...5
4.1. Google Corporate………………………………………………………………………………………..5 4.2. Google AdWords………..……..……..……..……..……..……..……..……..……..……..…………...5
5. Project Beneficiaries & Stakeholders……..……..……..……..……..……..……..……..……..……..……....5 5.1. Scrum Team……..……..……..……..……..……..……..……..……..……..……..……..……..……..6 5.2. Scrum Manager……..……..……..……..……..……..……..……..……..……..……..……..………...7 5.3. Deliverables……..……..……..……..……..……..……..……..……..……..……..……..……..……...7
6. Strategy, Structure & Execution | Project Actors, Inputs & Components……..……..……..……..………..7 6.1. Project Financing……..……..……..……..……..……..……..……..……..……..……..……..…….....7 6.2. Project Implementation Structure, Structure Execution……..……..……..……..……..……..……..7 6.3. Release Backlog & Expression of Project Story Points……..……..……..……..……..……..……..8 6.4. Sprint Execution & Burndown Chart……..……..……..……..……..……..……..……..……..……....9 6.5. Commencement/Evaluation……..……..……..……..……..……..……..……..……..……..……….. 9 6.6. Execution……..……..……..……..……..……..……..……..……..……..……..……..……..……........9 6.7. Observe | Project Supervision, Reporting and Monitoring……..……..……..……..……..…….…..9 6.8. Orient | Decide……..……..……..……..……..……..……..……..……..……..……..………...……..10 6.9. Decide | Angle of Attack……..……..……..……..……..……..……..……..……..……....…………..10 6.10. Act | Obstacles……..……..……..……..……..……..……..……..……..……..………..….…..……..11 6.11. Schedule | Project Scope Extension……..……..……..……..……..……..……..……..….…..….…11 6.12. Google && Scrum | The Next Iteration……..……..……..……..……..……..…….…..……..……...12
7. Project Outcomes……..……..……..……..……..……..……..……..……..……..……....……..……..……...14 7.1. Achievement of Project Objectives & Overall Project Rating……..……..…….……..……..……..14 7.2. Project Financing……..……..……..……..……..……..……..……..……..……...……..……..……..14 7.3. Project Risks, Challenges & Lessons Learned……..……..……..……..……...……..……..……...15 7.4. Risks & Mitigation……..……..……..……..……..……..……..……..…………...……..……..……...15 7.5. Lessons Learned from Implementation……..……..……..……..……..…………....……..………..15
8. Project Outcomes……..……..……..……..……..……..……..……..……..……..……..……..……..……….15 8.1. Overall Project Rating……..……..……..……..……..……..……..……..……..……..……..…..…...15
9. Appendix……..……..……..……..……..……..……..……..……..……..……..……..……..……..………..…17 10. Bibliography……..……..……..……..……..……..……..……..……..……..……..……..……..……..…....….20
3
1. Project Abstract: Google AdWords: The Art of Scrum && Quintuple Constraint
Introducing Scrum to Google AdWords | Google is especially proud of maintaining a unique, quirky startup
culture in spite of becoming one of the most powerful companies in the history of capitalism. Roughly 90% of
Google’s business is driven by AdWords (GADW), a subsidiary offering advertising services and analytics as a
platform. Although their ubiquitous corebusiness of Search facilitates 3.5 billion queries per day, Google is
celebrated for much more from Google X and Google Ventures to Nest Labs and DeepMind. Evidently,
Google devised a process for exceptional product development while maintaining the culture of a
quirkystartup. Contrary to popular belief, AdWords, Google’s breadandbutter business, submit to the
liberatingshackles of process and procedure afforded by Agile project management methodologies, more
specifically with “Scrum,” only eight years after incorporation. This paper will cooperatively examine GADW’s
adoption of Scrum and affiliated stakeholder guidance to preserve strategy, structure and execution governed
by cost, scope, time, quality and reliabilitythe “quintuple constraint” of contemporary project management.
SunTzu said, “Every battle is won before it is ever fought,” which was recently substantiated by a study
concluding that “alpha” managers (in the statistical construct, not in psychology) spend more time in the phase
of planning than actual execution(Appendix:9.1.1). Google commissioned Agile pioneer Mark Striebeck to 1
experiment. Although Striebeck’s administration wasn’t a categorical success, it was anything but a failure, as
Google continues to outperform market expectations to this day, boasting a $5.1B stock buyback in 3Q15. 2
2. Strategic Objectives
The classical principles and standards of “waterfall” project management are simply not conducive to the
iterative nature of software development. Writing software, isn’t all too far from like writing this reportmany
drafts or iterations were produced before the final release, or publication in this case. Borrowing a concept
from programming, these productions aren’t a “linear sequence,” or a “plug ‘n chug” of operations if it were,
waterfall management could and should be applied, which is to say classical project management will endure
as an alternative to Agile frameworks, like eXtreme, LEAN, FeatureDriven Development (FDD) and in this
1 Schwalbe, Kathy (20130101). 2 (Clark)
4
case, Scrum. Agile methodologies gradually garnered industry acclaim shortly after Google’s embrace. Tech
projects, let alone the stateofthe art, are born mired in risk and uncertainty dynamic and everchanging, an
iterative framework like Scrum, enables workgroups to prioritize objectives in a series dynamic of workflows,
allowing change by discovery or upon request, committing to subset features ideally delivered in each two to
four week iteration, known as a sprint. As the Chief Product Owner at Yahoo observed, “[Scrum] is the only 3
softwaredevelopment process that has demonstrated linear[scalability] when adding resources to large
projects.” According to industry research, virtually every project manager ever studied encountered 4
unpredictable changes and none of the projects were completed exactly as planned.” Traditional project 5
management, or any managerial rigidity whatsoever, was intentionally devoid in the early days of Google in
fact, the company prides itself with the overall mindset of maintaining as little to no management standards as
possible. Reiterating the criticality of AdWords as a core business segment, 95% of Google’s aggregate 6
revenue was driven by Google AdWords (GADW) at the time concerning the subject case. In 2005, just eight 7
years after incorporation, the growing complexity of the AdWords application systemically outgrew relaxed
product management standards, missing deadlines due to operational inefficiencies. Though unconventional, 8
Google corporate strategists, including the original founders, had some sense of basic structure, strategy and
execution. Necessitated by the aforementioned and increasing concerns, Google executives engaged now
industryexpert and pioneer of Agile Scrum, Mark Striebeck, for process and structural retrenchment; he was
commissioned to execute the following objectives:
3. Project Objectives
3.1. Scrum project management experimentation for two projectready GADW applications. 3.2. Debrief and evaluation of Scrum administration, or any adjustments thereof. 3.3. Implementation, including any variations for the greater good of Google, companywide,
as the bonafide deliverable.
Strategic objectives coincidentally required project management, as the actual project, to ensure the longterm
viability of GADW business segment in conjunction with their corecompetency of Search, to guarantee
3 Cooke, AGILE IN A NUTSHELL 4 Sutherland, Chapter 1: Introduction to Scrum 5 Reinventing Project Management, Chapter 1 6 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 7 S. Mark, “Testing: Automation,” in The 11th International Conference on Agile Software Development, Feb2010. 8 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
5
effective execution with quality and reliability efficiency standards. Contemporary project management
accounts not only the “tripleconstraint” of cost, scope and reliability constituting traditional “waterfall
management” but additive are quality and reliability, comprising the “quintuple constraint." Apropos, a 9
stakeholder map identifies related interests directly and indirectly involved with any project undertaking for
strategic intercourse; in this case, from the upstream corporate strategists, businesssegment managers and
the actual software engineers (Google’s guineapigs for the Scrum experiment)and downstream to ancillary
interests including businesstobusiness customers, all risked adverse impact triggered by protracted
application release cycles, or even system outages. A comprehensive stakeholder survey will identify all 10
Google affiliates and interests imperative to the GADW Scrum project on frontend applications, to reveal the
constituents of the quintuple constraint governed by corporate strategy, structure and execution.
4. Participating Organizations 4.1. Google Corporate
4.1.1. Corporate Executives & Strategists: Eric Schmidt, Larry Page, Sergey Brin, et al. 4.2. Google AdWords
4.2.1. Newhire consultant, Mark Striebeck, as Project Implementation Manager
5. Project Beneficiaries & Stakeholders According to Agile practitioners, representative stakeholders actively engage with realtime input and handson
participation during the beginning and end of each Scrum iteration. Typically, an ordinary project will require 11
a program director, program manager, project manager (family), sponsor and customer. However, in Scrum, 12
there are only three parties: the product owner, the development team, and the role of the product manager,
which is effectively replaced by the ScrumMaster, who, to be clear, is “not the manager of the Team or a
project manager” but rather a “project referee.” A brief description of each role previously mentioned, within 13
the context of the GADW Scrum experiment demonstrates stakeholder interests.
5.1. Product Owner
5.1.1. The product owner typically represents the needs of the business and is commissioned
for “documenting and prioritizing highlevel requirements as input into outgoing
9 Carayannis, Dr. Elias. 10 Schwalbe, Kathy (20130101). 11 Cooke, AGILE IN A NUTSHELL 12 Schwalbe, Kathy (20130101) 13 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
6
planning.” Concordantly, most Agile processes reserve this role solely responsible for 14
an individual outside of the development (dev) team to monitor “features, prioritization
and scope vs. release date decisions” but at both Google and AdWords, preScrum, this
was a job only for “teamleads,” who often had more than 10 projects, thereby limiting
time and attention to details required for Scrum.” Ostensibly efficient, at least to 15
Google, the opaque operating environment began complicating managerial awareness
of project statuses, stalling development release cycles. Installing Scrum required a 16
careful balance to avoid upsetting trust, or disrupting Google Dev culture, while
organizing chaos inplace. Typically, the product owner and Scrum manager should be 17
separate and independent of each other, but as the broker of process, Mark Striebeck
was forced to fulfill both roles.
5.2. Scrum Team
5.2.1. A Scrum team is a crossfunctional software development team, or “dev” team,
“undertaking the required work in each sprint and enlisting input from the Product Owner
when requirements need to be clarified.” The GADW engineering team was 18
distributed in 5 offices worldwide with 1520 major projects for continuously integrated
applications, pushing over 500,000 lines of code (500KLOC) growing digitally and
physically. Predating Scrum, GADW rate of attrition was considerably high due to 19
continuallychanging feature specifications. Though initially favored at Google, 20
particularly for the allowance of 20% “working freetime” promised to all employees in
order to foster innovation, the adhoc management structure wasn’t suited for a
burgeoning application like GADW, given the high rate of turnover; employees were
spread thin, compelling the need for a regimented system, like Scrum. Striebeck’s
14 Cooke, AGILE IN A NUTSHELL 15 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 16 Simplified Guide to Mastering Scrum, section 760 17 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 18 Cooke, AGILE IN A NUTSHELL 19 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 20 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
7
experiment included two subject GADW teams concerned with the frontend of
applications, studied as “Project A” and “Project B.”
5.3. Scrum Manager == Project Manager
5.3.1. Mark Striebeck is currently an engineering manager at Google, responsible for testing
infrastructure, tools and adoption but spending his Google “20% time” working in an
internal usergroup chartered to further the adoption of Agile practices. Prior to joining 21
Google, he was one of the pioneers of Scrum project management, discovering Agile
development while working at VA Linux Systems and Research; he holds two master’s
degrees in computer science and mathematics. As the new head of Agile at Google, 22
Striebeck would need a set of methods and metrics to track progress, identify and isolate
behavioral impediments, so Scrum could be comfortably suited for software development
at Google. He began with four basic tools briefly abstracted within the proceeding 23
section (6.2.1.1 | Execution): 24
5.3.2. Deliverables
5.3.2.1. Release Backlog
5.3.2.2. Expression of Project Story Points
5.3.2.3. Sprint Execution & Burn Down Chart
5.3.2.4. Checkpoint Meetings (modified Sprint meetings)
5.3.2.5. Commencement/Evaluation
6. Strategy, Structure & Execution | Project Actors, Inputs & Components 6.1. Project Implementation Structure, Structure Execution
6.1.1. Release Backlog & Expression of Project Story Points 6.1.1.1. As the visionary, the product owner has an idea to be “shipped” as the final
product, fit for userconsumption. Again, like writing this report or forming a
sculpture, a technicalconcept is subject to the constant addition and subtraction
of code, ideas and frameworks. The “preplanning” process in Scrum, is known
21 S. Mark, “Testing: Automation,” in The 11th International Conference on Agile Software Development, Feb2010. 22 S. Mark, “Testing: Automation,” in The 11th International Conference on Agile Software Development, Feb2010. 23 Simplified Guide to Mastering Scrum, section 763 24 Simplified Guide to Mastering Scrum, section 770
8
as “grooming,” which is reduced into sets of features collected for a prioritized list
known as the “product backlog.” This prioritized list of features will require more 25
than one sprint, so a subset list, partially derived from the complete product
backlog, is the dedicated “sprint backlog,” detailing how the team plans to
“design, build, integrate and test the selected subset of features from the product
backlog during that particular sprint” constituted by tasks. Each task is 26
individually reduced to hours estimated until completion for “justintime” delivery,
whereby feature assets occur or become available as needed. Upon 27
commencement of “Sprint 0” (position 0 is the technical definition for the physical
address for the first position located in an Array class collection(e.g.[0,1,2...]]), a
minimumviable product (MVP) is subject to review, priming the next iteration for
the second sprint.
6.1.2. Execution KeyPerformance Indicators (KPIs)
6.1.2.1. The US Navy SEALs regard knowing the target(s) as the most important rule of
engagement, or defining “mission success”and so it is with every Scrum. For a
sprint, the target is known as the “sprintgoal,” that “defines what the upcoming
sprint is supposed to achieve” that is “timeboxed” in a set amount of time
dedicated to each feature, which upon expiring is shelved back into the “product
backlog” for reintegration into another future sprint, if deemed realistic and
relevant. Each day within a sprint, only the development team and 28
Scrummaster assemble for a timeboxed “preday” meeting in the morning,
timeboxed to exceed no more than 15 minutes as to assess what was completed
yesterday and what remains outstanding for that day and tomorrow(in point of
fact, serious practitioners require the audience to stand as a reminder to observe
25 Essential Scrum, Rubin, Kenneth S. 26 Essential Scrum, Rubin, Kenneth S. 27 Essential Scrum, Rubin, Kenneth S. 28 Essential Scrum, Rubin, Kenneth S.
9
brevity) forbidding “chickens” and “pigs” (a joke I’ll invite you to Google). Recall 29
that one sprint should last at least two but no more than four weeks. Accordingly,
on a given sprint, the team members “manage the flow of work by conducting
synchronization, inspection, and adaptive planning activity known as the daily
scrum.” Improvement is impossible without metrics to improve, so “Burndown 30
Charts” are monitored daily, “to update the estimate of how much effort remains
for each uncompleted task”(Appendix:9.2.1) as a continuously updated forecast
for both product release and current Sprint. 31
6.1.3. Commencement/Evaluation
6.1.3.1. The Scrum team completes the sprint by performing two inspectandadapt
activities. In the first, called the “Sprint review,” the stakeholders and Scrum team
inspect the product under development In the second, called the “sprint
retrospective,” the Scrum team inspects the Scrum process employed to create
the product. The outcome of these activities could be adaptations that will make
their way into the product backlog or to be included as part of the team’s
development process. At this point the Scrum sprint cycle repeats, beginning
anew with the development team determining the next most important set of
product backlog items it can complete. After an appropriate number of sprints has
been completed, the product owner’s vision will be realized and the solution can
be released. 32
6.2. Execution 6.2.1. Observe | Project Supervision, Reporting and Monitoring
6.2.1.1. Mr. Striebeck’s version of Scrum was appropriated to coax the majestic nature of
Google Dev into domestication, for the greatergood of the Google stable of
companies. His angle of attack began with “Scrumlite,” his abbreviation utilizing
29 Essential Scrum, Rubin, Kenneth S. 30 Essential Scrum, Rubin, Kenneth S. 31 Essential Scrum, Rubin, Kenneth S. 32 Essential Scrum, Rubin, Kenneth S.
10
only the “release backlog” and “burndown charts” tools, intending to clarify
visibility into the development progress for the project team, and outside
stakeholders, within the organization. The backlog was populated by engineers 33
in wikipages(wikis), or individual statusupdates for progress reports and
tasktracking. Recall the GADW “guinea projects,” monikered as “Project A” and
“Project B;” Project A was integrating new functionality that didn’t overlap with
existing features, comprised by recentcollege graduates and companyrookies
working remotely. Project B was primarily composed by experienced, seasoned
Google engineers designing a simplified version of the AdWords product, heavily
integrated with existing features. 34
6.2.2. Orient | Key Performance Indicators (KPI) & Metrics
6.2.2.1. In both projects, Mark chose to measure the product and release backlogs KPIs
with a burndownrate chart as the preferred tools of choice, measuring
taskscompleted, not featurecompleted, careful not to avoid stressing the
developers.
6.2.3. Decide | Angle of Attack
6.2.3.1. Upon initiating the Scrum premeeting, defining success and objectives with a
“preplan” for the entire product release, the team begins the first sprint.
Userinterface (UI) wireframing, or mockups, were already sound in process
and Agilefriendly at Google, easing the start of the experiment. Reporting 35
statusupdates was somewhat alien to both teams, but adopted as
communication increased and clarified. The burndown chart was modified with 36
a variablefloor, adjusting for scopecreep, which became the first obstacle
impeding the sprint. Striebeck adapted the process, stripping 37
33 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 34 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 35 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 36 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 37 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
11
testingprocedures to maximize flexibility as this obstacle became more obvious;
engineers struggled to accurately estimate time required to complete outstanding
tasks.
6.2.4. Act | Obstacles
6.2.4.1. Although initially championed, it is fair to attribute laissezfaire management as a
failurefactor enabling managers to spread themselves too thin, which limited
opportunities to contribute actionable feedback necessary for projectdevelopers,
inturn yielding inefficient project micromanagement. Moreover, they ignorantly
concluded that “gameplanning” was an exercise in futility as the game of
development always changed in spite of trustworthy mockups, so
featuredecisions were avoided during the Scrum preplanning meetings,
distorting proposed objectives, protracting engineering development. 38
6.2.5. Schedule | Project Scope Extension
6.2.5.1. Since the Scrum process intrinsically accounts for scope, in both product and
release backlogs, the burndown charts are an outstanding tool for extrapolation
and forecasting. Cumulative scope increased greater than 30%, on both 39
projects; interestingly, the delta didn’t result from additional feature requests, but
was in fact due to managerial oversight and misguidance. The engineering team
missed features in the mockups necessary for the release, leading to several
postponements in both projects. The aforementioned substantiates the 40
assessment presented herein the notion of defining targets or releasecritical
objectives was an unfamiliar practice at Google, so Mr. Striebeck should’ve
modified his administration or perhaps observed careful attention to estimates,
challenging each member to secondguess their estimates during the sprint
preplanning phases. On the first sprint, the frequency of daily sprint meetings
38 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 39 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 40 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
12
decreased to weekly meetings, which became a recap of weekly task
productivity, along with frequent weekly retrospectives altogether, or UI
walkthroughs, a “live demonstration of the system with the whole core team to
gather feedback and uncover usability issues.” Weekly retrospectives were 41
eventually dropped altogether, but weekly checkin meetings were maintained. 42
Project engineers skipped daily standup meetings, regarding them as
“unnecessary overhead.” However, cardinal Googlerules of testdriven 43
development (TDD) became the final straw breaching criticalmass: “tests were
not written, code was not reviewed (which is mandatory at Google) features were
not completely integrated,” so this prompted Mr. Striebeck to add dimensions to
the burndown chart, to indicate how many tasks were initiated, started and
finished, indicating suboptimal taskcompletion velocity because of too many
partially completed features outstanding.(Appendix::9.3.1.) The 44
multidimensional burndown chart triggered a collective epiphany; both
workgroups were shocked by the number of features merely indevelopment (a
staggering 80% awaiting completion during the first sprint) prompting engineers
to mitigate taskstarts. Striebeck concurred the multidimensional burndown 45
chart revealed misperceptions in estimating a release date with hipshot
guesstimates instead of extrapolating progress derived from the release data
recorded. 46
6.3. Google && Scrum | The Next Iteration
6.3.1. In order to remediate task scheduling discrepancies, a “spike,” was created as an
investigative “subtask” of a featuretask to accurately determine all of the mechanics
underneath and thus time required for a given feature; spikes were especially
41 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 42 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 43 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 44 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 45 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 46 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
13
appreciated during scopecreep, as “everybody realized the value of getting a better
estimate of implementing a feature before actually starting to work on it.” Nearing the 47
end of the first sprint, productivity in both projects quickly recovered to a point of
inflection. After the first run, the engineers developed a newfound respect for the
process, specifically valuing the burndown charts and backlogs, ability for early
qualityassurance and testing on applications in stagingenvironments, and the bakedin
teamwork via scheduled collaborations; the overall takeaway was encouraging
maintaining backlogs was finally worth the overhead. Several concerns remained: the 48
consensus vacuum on feature prioritization, inaccurate scheduling estimates and the
consequent bottleneck created by debugging. To address these concerns, Mr. 49
Striebeck decided to debrief the project engineers by hosting a presentation on Scrum,
apparently appreciated then clearly understood by the engineers (a puzzling maneuver
begging the question why he refrained from doing this in the beginning). On matters of
prioritization, Striebeck merely provided an example on how to organize requirements. 50
How do you eat the elephant? One bite at a time. The feedback regarding missing
deadlines and too many bugs signaled obvious reasons to practice iterative
development. Realizing these advantages, planningmeetings became a focus of the
weekly checkpoints in the second sprint, which was partitioned into twoweek release
cycles, allowing a highpriority feature to be prepared without any disruption. Stribeck 51
began the next iteration with a conventional retrospective meeting recapping the
previous progress reportedly more productive. Familiarity granted the team with more 52
comfort and confidence in the process, minimizing feature timeboxes or freezecycles
bottlenecking productivity. Concordantly, the team “could see how these process
changes would address the negative feedback from the postmortem meetings..both
47 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 48 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 49 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 50 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 51 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 52 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
14
teams did not fully understand how these practices would work together but agreed to
give it a try,” and so overall Scrum earned Google’s trust. The second sprints for both 53
projects were completed in due time with both deliverables.
7. Project Outcomes 7.1. Achievement of Project Objectives & Overall Project Rating
7.1.1. Striebeck’s introduction of Scrum wasn’t a categorical failure, as the project successfully
graduated Google into the “liberating shackles” of controls, process and procedures
afforded by Scrum. While the second sprint was inprocess, Mark Striebeck took a
threeweek vacation from the projects, appointing a substitute for his role; although the
appointment was unorthodox by normal Scrumstandards, the process accommodates if
need be. Upon returning, Striebeck was elated to observe both project engineers
utilizing his methodologies with eagerness and rigor. If Striebeck precisely 54
implemented Scrum, the practice may have been abandoned, and perhaps Google
might not have prevailed as the marketleader today.
7.2. Project Financing
7.2.1. Google accounting for return on investment (ROI) since Striebeck’s implementation are
sparse, forcing inference. Industry intelligence reveals that the median ROI derived from
aggregated internal rate of return (IRR) compiled from a population of 300 scholarly
reviews amounts to roughly +2,633%, respectively weighted within the quintuple
constraints of cost, schedule, productivity, quality and reliability. By comparison, 55
traditional waterfall methodologies aggregated total return within the same quintuple
constraint parameters amounted to roughly +470%, a difference of 2,163%. Suffice it to
say, when correctly applied or adapted, Scrum is immensely beneficial for engineering
operations, and so it is at Google.
53 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 54 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google) 55 Franco
15
7.3. Project Risks, Challenges & Lessons Learned 7.3.1. Risks & Mitigation
7.3.1.1. A recalibrated execution of Scrum was necessary in order to preserve the
crossfunctional freedom at Google. Naturally, the continuous collision of
different ideas fosters innovation at Google, so too much structure would stifle
development and cripple the culture. Scrum introduced a newfound respect for
testing, siring the first Google “Grouplet” created by Bharat Mediratta, “to drive
adoption of developer testing,” noting the shift in attitudes towards testing with
“building better tools and giving informal talks to different technical groups” and
curating engineeringdocumentation. 56
7.3.2. Lessons Learned from Implementation
7.3.2.1. Though the Scrum experiment was successful and “Grouplet” feedback
receptive, Google Grouplets continue serving as crossfunctional focus groups
commissioned to discover and explore ideas allotted by the Googleemployee
“20% time.” Grouplets host demonstrations, guestspeakers and presentations 57
to educate anyone challenged by the process, effectively mitigating development
freezecycles and delayed releases. 58
8. Project Outcomes 8.1. Overall Project Rating
8.1.1. In conclusion, this study only offers one improvement for Mark Striebeck; instead of
“cowboying” the experiment, he should’ve hosted a presentation about the process
before introducing a Scrumtrial by fire confusion probably would’ve been avoided,
which would have smoothed the process. Regardless, his twist on Scrum has ensured
the longterm viability of GADW since inception, demonstrably profitable yearoveryear,
accounting for nearly 90% of Google's total revenue. The annualized return of the
GADW businesssegment averaged 34.85% per annum, from 2001 to
56 Cohn, Succeeding with Agile: software development using Scrum, 2010 57 Google Grouplets: Shared Groups Of 20% Time. 58 Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
16
2013(Appendix::9.3.12 Google: Advertising Revenue 2014 | Statistic.). Since 2011, 59
Google AdWords retains the lion’s share of advertising revenue derived from Search,
amounting to a robust 74% of marketshare, while Microsoft maintains in second with
13.2% of market, over Yahoo, lagging to 5.9%, leaving 1% scraps to AOL. Google is the
most dynamic company in the industry avoiding the rigidity mistakenly espoused by
competition, and quite surprisingly by Yahoo, currently under the helm of former
Googler, Marissa Mayer, who relinquished remote working privileges favored by the
guard. So long as Google stays dynamic in culture, they will remain one of the most
powerful companies in the history of capitalism.
59 Google: Advertising Revenue 2014 | Statistic.
17
9. Appendix
9.1. Alpha Managers
9.1.1. 9.2. Burndown: Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
9.2.1.
18
9.3. Modified Burndown: Sutherland: Chapter 7: Case Studies | Ssh! We are adding a process...(at Google)
9.3.1.
20
Bibliography
9.5. Carayannis, Dr. Elias. "Introduction to IT Project Management." Session 2. The George Washington
University School of Business, Washington, DC. 1 Apr. 2014. Lecture. 9.6. Clark, Jack. "Google Hits Record as Results Top Estimates on Web Clicks." Bloomberg.com. Bloomberg.
Web. 26 Oct. 2015. 9.7. Cohn, Mike. "Iterating Toward Agility." Succeeding with Agile: Software Development Using Scrum. Upper
Saddle River, NJ: AddisonWesley, 2010. 72. Print. 9.8. Franco, Dr. David F. "What Is the ROI of Agile vs. Traditional Methods? An Analysis of XP, TDD, Pair
Programming, and Scrum (Using Real Options)." 8. Print. 9.9. "Google: Advertising Revenue 2014 | Statistic." Statista. Web. 26 Oct. 2015. 9.10. "Google Grouplets: Shared Groups Of 20% Time." Search Engine Land. 22 Oct. 2007. Web. 26 Oct. 2015. 9.11. J. Sutherland, “Chapter 1: Introduction to Scrum,” The Scrum Papers: Nuts, Bolts and Origins
of an Agile Framework, vol. 1, no. 1, pp. 5–5, 2012. 9.12. J. Sutherland, “Chapter 7: Case Studies | Ssh! We are adding a process...(at Google),” The
Scrum Papers: Nuts, Bolts and Origins of an Agile Framework, vol. 1, no. 1, pp. 185, 186, 187, 188, 189, 191–185, 186–189, 191–194, 2012.
9.13. J.L. Cooke, “AGILE IN A NUTSHELL,” Agile Principles Unleashed, pp. 106, 122–106, 122, 2010.
9.14. Rubin, Kenneth S. (20120720). Essential Scrum: A Practical Guide to the Most Popular Agile Process (AddisonWesley Signature Series (Cohn)) (Kindle Location 6846). Pearson Education. Kindle Edition, ss. 1320, 1334, 1390, 1424, 6845, 7382.
9.15. S. Mark, “Testing: Automation,” in The 11th International Conference on Agile Software Development, Feb2010.
9.16. Schwalbe, Kathy (20130101). Information Technology Project Management (Page G.8). Cengage Textbook. Kindle Edition. pp. 510, 512; ss. 84.