1

ISTM_6204

Google AdWords: The Art of Scrum && Quintuple­Constraint

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 project­ready 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

company­wide, 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 start­up

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 core­business 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

quirky­startup. Contrary to popular belief, AdWords, Google’s bread­and­butter business, submit to the

liberating­shackles 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 reliability­the “quintuple constraint” of contemporary project management.

Sun­Tzu 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 buy­back 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 report­many

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, Feature­Driven Development (FDD) and in this

1 Schwalbe, Kathy (2013­01­01). 2 (Clark)

4

case, Scrum. Agile methodologies gradually garnered industry acclaim shortly after Google’s embrace. Tech

projects, let alone the state­of­the art, are born mired in risk and uncertainty­ dynamic and ever­changing, 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

software­development 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

industry­expert 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 project­ready 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, company­wide,

as the bonafide deliverable.

Strategic objectives coincidentally required project management, as the actual project, to ensure the long­term

viability of GADW business segment in conjunction with their core­competency 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, Feb­2010. 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 “triple­constraint” 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, business­segment managers and

the actual software engineers (Google’s guinea­pigs for the Scrum experiment)­and downstream­ to ancillary

interests­ including business­to­business 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 front­end 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. New­hire consultant, Mark Striebeck, as Project Implementation Manager

5. Project Beneficiaries & Stakeholders According to Agile practitioners, representative stakeholders actively engage with real­time input and hands­on

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 high­level requirements as input into outgoing

9 Carayannis, Dr. Elias. 10 Schwalbe, Kathy (2013­01­01). 11 Cooke, AGILE IN A NUTSHELL 12 Schwalbe, Kathy (2013­01­01) 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, pre­Scrum, this

was a job only for “team­leads,” 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 in­place. 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 cross­functional 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 15­20 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

continually­changing feature specifications. Though initially favored at Google, 20

particularly for the allowance of 20% “working free­time” promised to all employees in

order to foster innovation, the ad­hoc 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 front­end 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 user­group 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 user­consumption. Again, like writing this report or forming a

sculpture, a technical­concept is subject to the constant addition and subtraction

of code, ideas and frameworks. The “pre­planning” process in Scrum, is known

21 S. Mark, “Testing: Automation,” in The 11th International Conference on Agile Software Development, Feb­2010. 22 S. Mark, “Testing: Automation,” in The 11th International Conference on Agile Software Development, Feb­2010. 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 “just­in­time” 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

minimum­viable product (MVP) is subject to review, priming the next iteration for

the second sprint.

6.1.2. Execution Key­Performance 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 “sprint­goal,” that “defines what the upcoming

sprint is supposed to achieve” that is “time­boxed” 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

Scrum­master assemble for a timeboxed “pre­day” 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 “Burn­down 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 inspect­and­adapt

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 greater­good of the Google stable of

companies. His angle of attack began with “Scrum­lite,” 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 “burn­down 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 wiki­pages(wikis), or individual status­updates for progress reports and

task­tracking. 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 recent­college graduates and company­rookies

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 burn­down­rate chart as the preferred tools of choice, measuring

tasks­completed, not feature­completed, careful not to avoid stressing the

developers.

6.2.3. Decide | Angle of Attack

6.2.3.1. Upon initiating the Scrum pre­meeting, defining success and objectives with a

“pre­plan” for the entire product release, the team begins the first sprint.

User­interface (UI) wire­framing, or mock­ups, were already sound in process

and Agile­friendly at Google, easing the start of the experiment. Reporting 35

status­updates was somewhat alien to both teams, but adopted as

communication increased and clarified. The burn­down chart was modified with 36

a variable­floor, adjusting for scope­creep, 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

testing­procedures 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 laissez­faire management as a

failure­factor enabling managers to spread themselves too thin, which limited

opportunities to contribute actionable feedback necessary for project­developers,

in­turn yielding inefficient project micro­management. Moreover, they ignorantly

concluded that “game­planning” was an exercise in futility as the game of

development always changed in spite of trustworthy mock­ups, so

feature­decisions were avoided during the Scrum pre­planning 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 burn­down 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 mock­ups 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 release­critical

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 second­guess their estimates during the sprint

pre­planning 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 check­in meetings were maintained. 42

Project engineers skipped daily stand­up meetings, regarding them as

“unnecessary overhead.” However, cardinal Google­rules of test­driven 43

development (TDD) became the final straw breaching critical­mass: “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 burn­down chart, to indicate how many tasks were initiated, started and

finished, indicating sub­optimal task­completion velocity because of too many

partially completed features outstanding.(Appendix::9.3.1.) The 44

multi­dimensional burn­down chart triggered a collective epiphany; both

workgroups were shocked by the number of features merely in­development (a

staggering 80% awaiting completion during the first sprint) prompting engineers

to mitigate task­starts. Striebeck concurred­ the multi­dimensional burn­down 45

chart revealed misperceptions in estimating a release date with hip­shot

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 feature­task 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 scope­creep, 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 burn­down charts and backlogs, ability for early

quality­assurance and testing on applications in staging­environments, and the baked­in

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, planning­meetings became a focus of the

weekly checkpoints in the second sprint, which was partitioned into two­week release

cycles, allowing a high­priority 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 time­boxes or freeze­cycles

bottlenecking productivity. Concordantly, the team “could see how these process

changes would address the negative feedback from the post­mortem 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 in­process, Mark Striebeck took a

three­week vacation from the projects, appointing a substitute for his role; although the

appointment was unorthodox by normal Scrum­standards, 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 market­leader 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

cross­functional 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 engineering­documentation. 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 cross­functional focus groups

commissioned to discover and explore ideas allotted by the Google­employee

“20% time.” Grouplets host demonstrations, guest­speakers and presentations 57

to educate anyone challenged by the process, effectively mitigating development

freeze­cycles 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 Scrum­trial by fire­ confusion probably would’ve been avoided,

which would have smoothed the process. Regardless, his twist on Scrum has ensured

the long­term viability of GADW since inception, demonstrably profitable year­over­year,

accounting for nearly 90% of Google's total revenue. The annualized return of the

GADW business­segment 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.1­2 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 market­share, 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.

19

9.4. Google: Advertising Revenue 2014 | Statistic.

9.4.1.

9.4.2.

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: Addison­Wesley, 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. (2012­07­20). Essential Scrum: A Practical Guide to the Most Popular Agile Process (Addison­Wesley 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, Feb­2010.

9.16. Schwalbe, Kathy (2013­01­01). Information Technology Project Management (Page G.8). Cengage Textbook. Kindle Edition. pp. 510, 512; ss. 84.