UsingGoogleVenturesDesignSprintFrameworkforSoftwareProductDe-velopmentinStartupsViktoriiaPoliakovaBachelor’sthesisNovember2017SchoolofBusinessDegreeProgrammeinInternationalBusiness

Description

Author(s)Poliakova,Viktoriia

TypeofpublicationBachelor’sthesis

DateNovember2017Languageofpublication:English

Numberofpages71

Permissionforwebpubli-cation:x

TitleofpublicationUsingGoogleVenturesDesignSprintframeworkforsoftwareproductdevelopmentinstartupsDegreeprogrammeDegreeProgrammeinInternationalBusiness

Supervisor(s)Saukkonen,JuhaAssignedbyRoboTechnologiesGmbH

Abstract

Inthefast-pacedenvironmentofthestartupworld,companiesarealwaystryingtodis-coverandexecutethemostefficientandeffectivewaysofsolvingproblems,developingnewproductsandworkinginteams.Someframeworksthataddressthisissuehavebeendevelopedduringtherecentyears,andtheyareactivelyusedinvariousorganizations.

Thegeneralaimofthisstudywastoevaluatetheeffectivenessofsuchframework,GoogleVenturesDesignSprint,inahardwarestartupcalledRoboWunderkind.TheobjectivesweretoexecutetheDesignSprintinpracticebydevelopingaconceptofasoftwareprod-uct,analyzetheresultsoftheDesignSprintandevaluateitsappropriatenessforthecom-panyanditsproducts.

Thetheoryandknowledgebasepartofthisstudypresentsthegeneralconceptsofsoft-waredevelopmentanditsframeworks,designthinkingandDesignSprint.Thispartfurtherjustifiestheconnectionbetweentheseframeworksandtheirapplicationinthisresearch.

Actionresearchwasusedastheresearchapproachforthisstudy,asitwassimilartothecyclicalnatureoftheDesignSprintframeworkandalloweddeepreflectionontheresearchprocess.Theresearchconsistedoffivecyclesthatcontainedoneactionandonereflectionprocesseach.

Astheresultofthisstudy,aconceptofasoftwareplatformwascreated,thekeychalleng-esforitsfurtherdevelopmenthavebeenidentified,andtheappropriatenessoftheDesignSprintframeworkwasassessedusingactionresearch.

TheresearchfindingscanbeutilizedbyresearchersfromdifferentbackgroundsinordertofurtherstudytheDesignSprintframeworkanditsapplicationinvarioussettingsandfields.Keywords/tags(subjects)GoogleVenturesDesignSprint,designthinking,softwaredevelopment,innovationMiscellaneous(Confidentialinformation)Appendices1,2,3and4(35pages)areconfidentialuntil12.11.2027.

1

Contents

1Introduction.......................................................................................................3

1.1Backgroundandcompanyinformation.........................................................4

1.2Researchproblemandresearchquestions...................................................5

2Researchdesign..................................................................................................6

2.1Researchapproachselection.........................................................................6

2.2Researchmethodselection-Actionresearch...............................................7

2.3Datacollectionandanalysis........................................................................10

2.4Planforresearchethicsandquality............................................................11

3Theoryandknowledgebase.............................................................................12

3.1Softwareengineering..................................................................................12

3.2Softwareprocess.........................................................................................14

3.3Softwaredevelopmentmethodologies.......................................................15

3.4DesignThinking............................................................................................25

3.5GoogleVenturesDesignSprintasanewmethodofDesignThinking.........26

3.6Synthesisoftheconceptualframework......................................................29

4Results..............................................................................................................32

5Conclusions......................................................................................................32

6Discussion.........................................................................................................32

References............................................................................................................33

Appendices...........................................................................................................36

Appendix1. Results(19pages).......................................................................36

Appendix2. Conclusion(4pages)...................................................................36

Appendix3. Discussion(4pages)...................................................................36

2

Appendix4. Thedevelopedprototypeofasoftwareproductduringthe

DesignSprintatRoboWunderkind(8pages).........................................................36

Figures

Figure1.Thespiralofactionresearchcycles(Zuber-Skeritt2001,20)........................8

Figure2.Theimplementedresearchprocessofthestudy...........................................9

Figure3.TheWaterfallmodelofsoftwaredevelopment(SpriteCloudn.d.)..............16

Figure4.Spiralmodelofsoftwaredevelopment(Boehm1988,64)..........................18

Figure5.Extremeprogramming(XP)methodologyofsoftwaredevelopment

(Abrahamsson,Salo,Ronkainen,&Warsta2002,21)................................................22

Figure6.Scrummethodologyofsoftwaredevelopment(Schwaber1995,126).......24

Figure7.GoogleVenturesDesignSprint5-dayprocess(TetuanValley2017)...........29

Tables

Thelistoftablesofthisstudyisconfidentialuntil12.11.2027.

Images

Thelistofimagesofthisstudyisconfidentialuntil12.11.2027.

3

1Introduction

Inabusinesssetting,regardlessofafieldoranindustry,itcanbeoftenobserved

thatusualworkingmethodsandwaysofsolvingissuesstoptobeeffectiveand

efficient,andsimplydonotbringoutcomes.Thisobservationcanbeappliedto

individualsintheworkenvironment,aswellastowholeteamsandsubteamsinside

oforganizationsofdifferenttypes,beitcorporationsorstartups.Ifsomethingisnot

working,thencertainstepstowardstheoptimizationandthewaystofinding

solutionstosuchsuddenlagsofproductivityneedtobesought.Howsuchproblems

aresolved,issolelyuptoindividualsorteams,andattheendoftheday,various

waysofimprovingworkingprocessesarefound.However,whatifonespecific

frameworkcouldsuccessfullyaddressallsimilarissues,improveworkprocessesand

helpindividualsandteamstoinnovate,regardlessoftheenvironmenttheyarein?

Thisstudyexaminestheeffectivenessofsuchframework-GoogleVenturesDesign

Sprint(hereinafterreferredtoasGVDesignSprint,DesignSprintorSprint)ina

contextofonespecificcompanyandaspecificissuethatthecompanyneededto

solve.Thisresearchiscomposedof6parts:Introduction,Researchdesign,Theory

andknowledgebase,Results,Conclusions,andDiscussion.Introductionpartincludes

thebackgroundinformationtothestudy,descriptionoftheassignorcompanyand

researchproblemandquestionsofthisthesis.Researchdesignpartelaborateson

thechosenresearchapproachandmethodandjustifiestheirappropriatenessforthis

study.TheTheoryandknowledgebasechaptercreatesanacademicbackgroundfor

theresearchbyexplainingthebasicsofsoftwaredevelopmentandits

methodologies.Thischapteralsoexplainsthedesignthinkingconceptandelaborates

ontheDesignSprintframework,onwhichtheresearchisbased.TheResultschapter

describestheresearchprocessthattookplace.TheConclusionspartpresentsthe

outcomesoftheresearchandtheanswerstotheresearchquestions.Finally,the

Discussionchapterincludesthediscussionaboutreliabilityandvalidityofthisstudy,

itslimitationsandsuggestionsforthefutureresearchonthistopic.

4

1.1Backgroundandcompanyinformation

TheassignorforthisthesisisthestartupcompanycalledRoboWunderkind,whichis

basedinVienna,AustriaandShenzhen,China.Thecompanyisahardwarestartupin

thefieldofeducationaltechnology:itproducesmodularprogrammableroboticskits

forchildren.RoboWunderkindwasfoundedin2013withthemissionofbringing

roboticsandcodingclosertochildren,andmakingitsimpleandentertainingfor

them.In2015thecompanyhassuccessfullycompletedaKickstartercampaign,

raising$246,000frombackerscomingfrom58countries,subsequentlywinninga

numberofawardsandgettingavastmediacoverageworldwide.Atthemomentof

writingthisthesis,thecompanyisinthepre-orderphaseandhasthreehardware

productsinitsrange,aswellastwoaccompanyingsoftwareproducts.

TheauthorofthisthesishasbeenapartofRoboWunderkind’steamsinceMarch

2017asanintern,andsubsequentlyasafull-timeemployeeinthemarketingteam.

Themotivationtowritethisthesisarose,firstly,fromtheauthor’sdeepinterestand

dedicationtothecompanyanditsproducts,andsecondlyfromtheinterestintheGV

DesignSprintframeworkitself,andthefactthatithasn’tbeenwidelyresearched

yet.

Asacompany,RoboWunderkindoperatesintheextremelyfast-changing

environmentofthetechnologybusiness,thusthestartupisconstantlysearchingfor

newwaysofboostingproductivity,improvinginternalprocesses,anddevelopingthe

bestproductsandsolutionsforitscustomers.Moroni,Arruda,andAraujo(2015)

believethat,inordertodothis,manycompaniesintroducesomeaspectsofdesign

totheirinnovationprocesses,thusmakingthemdesign-driven.Suchdesign-driven

mindsetallowstolookatthesamecontextandenvironmentfromacompletely

differentangle,createnewproductsandserviceswithnewmeanings,and

understandthetargetcustomersandtheirproblemsbetter.(ibid.,2200.)Priorto

thisstudy,RoboWunderkindhasalreadyemployedsomeaspectsofdesignand

innovation-driventhinkinginthecompany’smarketingteam,aswellashasworked

withsomemodernagilemethodsforrapidandinnovativesoftwaredevelopment

purposesinthetechnicalteam.However,itwasnotthecasethatthewholeteam

5

hasworkedtogetheronaspecificproblemwithinonespecificframeworkfor

innovation,simplyduetothefactthattheengineering,salesandmarketing,product

anddesignteamsatRoboWunderkindarenaturallyoftenquiteseparatedbecause

oftheessenceoftheirtasks(although,ofcourse,theystillworktogetherasonebig

team).Thatsaid,thecompanywantedtofindanewinnovativewaytowork

effectivelyandefficientlyaltogetheronspecificproblems,andtheGVDesignSprint

becamesuchsolutionforRoboWunderkindduetothereasonsexplainedinthenext

subchapter.

1.2Researchproblemandresearchquestions

ThisstudyaimstoresearchtheGVDesignSprintframeworkinthecontextof

developingasoftwareproductinahardwarestartup.Thebackgroundofthe

researchproblemliesinthefollowing:RoboWunderkindteammembershadanidea

todevelopanewsoftwareproduct,whichwouldbeindependentofthecompany’s

mainhardwareproduct.TheideatoutilizetheDesignSprintframeworkfor

developingtheproductideahasbeenproposed,asthefoundersofthecompany

haveheardofthecasestudieswhereitwasusedforsimilarpurposesofproduct

development,andthuswereenthusiastictotryitoutatRoboWunderkind.

Therefore,thefollowingresearchproblemhasbeenformulatedbytheauthor:

“HowcouldtheGoogleVenturesDesignSprintmethodologybeusedfordevelopinga

softwareproductinahardwarestartup?”

Thefollowingresearchquestionshavethenbeenderivedoutofthewholeresearch

problem:

1.Whatkindofsoftwareproduct,whichwouldbeindependentofthecompany’s

mainhardwareproduct,couldbecreatedwiththehelpofDesignSprintframework?

2.Whataretheproduct-relatedchallengesthatcouldariseaftertheproductlaunch?

6

3.HowwelldoestheDesignSprintmethodapplytothedevelopmentofasoftware

productinahardwarecompany?

Inordertoanswerthesequestions,therealDesignSprintprocesshasbeen

implementedinthecompany,inwhichtheauthorofthisthesishasalsoparticipated

alongsidetheotherteammembers.Actionresearchhasbeenchosenastheresearch

methodforthisstudy,asdescribedandjustifiedinthenextchapter.

2Researchdesign

2.1Researchapproachselection

AccordingtoCreswell(2014),researchapproachesarethegeneralseriesofsteps

andwaysofundertakingaresearchprojectinordertonarrowtheresearcher’sbroad

assumptionsdowntoconcretemethodsofcollecting,analyzingandinterpretingthe

data.Thedecisionofwhichresearchapproachtoundertakeismainlybasedonthe

researcher’sassumptions,researchdesign,themethodsofcollecting,analyzingand

interpretingthedata,whichapplytothisspecificresearchandonthenatureofthe

researchproblemitself.(ibid,3)

Therearetwobasicapproachestoconductingaresearch:quantitativeapproachand

qualitativeapproach.Quantitativeresearchappliestoaphenomenonthatneedsto

beresearchedintermsofitsquantity,thus,yieldingaconcreteamountasthere-

searchresult.Conversely,qualitativeresearchaimstoanswerresearchquestions

regardingaqualitativephenomenonthroughassessmentandanalysisofunderlying

motives,attitudes,opinions,andbehavior.Theresultsofthequalitativeresearch

alwaysappearinthenon-quantitativeform,orinaformthatcannotbeanalyzed

quantitatively(Kothari2004,3-5).

Asansweringtheresearchquestionsofthisstudydoesnotyieldanynumericalre-

sults,butinsteadrequiresverbalinteractioninagroupofpeople,thequantitative

approachwouldnothavebeensuitableforthisthesis,thusqualitativeresearchap-

proachwaschosen.Inaddition,thisapproachwasdeeplyrootedintheresearch

7

method,whichtheauthorplannedtoselect,sothedecisiononselectionofthere-

searchapproachforthisstudycameratherquickly.

2.2Researchmethodselection-Actionresearch

Sinceansweringtheresearchquestionsofthisthesisimplieddeveloping,prototyping

andtestinganactualsoftwaretoolinateam,theactionresearchmethodhasbeen

chosenasaprimarymethodtocompletetheresearch.

AccordingtoStringer(2014),actionresearchisasystematicandholisticapproachto

aresearch,whichallowsitsparticipantstocollaborativelyfindsolutionstotheir

particularproblems.Actionresearchinvolvesandengagestherapiddynamicsofany

socialsetting,asopposedtoothertypesofresearch,wheregeneralcausalities,

correlations,andexplanationsregardingasmallnumberofthingsthatare

researched,aresought.Anintegralpartofactionresearchiscontinuouscyclesof

investigationthatshowthesolutionstopresentedissuesandsuggestthepossible

meansforparticipantstoimprovetheirworkandtomakesustainabledevelopments

intheiractionsandpractices.Thenatureofactionresearchreliesonthestatement

thatgeneralizedsolutionsofplansinanysocialsettingcanbeirrelevantand

inapplicabletothatspecificsettingortogroupsinit,therefore,theyshouldbe

modifiedandadaptedtotheenvironmenttheyareusedin.Inanutshell,themain

purposeofactionresearchistoinvolveallpeoplewhoareinfluencedbythe

investigatedissue,or,conversely,influenceitthemselves,intheprocessof

systematicinvestigationandexperimentationinordertoachieveacertaingoaland

reflectonit.(ibid.,1-6.)

McNiffandWhitehead(2002)characterizeactionresearchasaspecialwayto

investigateone’slearningbylookingatone’spracticeinordertounderstandifit’s

donecorrectly,reflectonit,andmakechangesandimprovementsifneeded.This

kindofresearchcanbeconductedinavarietyofenvironments,suchassocial

sciences,businessmanagement,education,andmanyother.Regardlessofacontext,

thelearningsinactionresearchalwayscomefromactionandreflectionby

8

participants.(ibid.,15-16.)

Zuber-Skeritt(2001)arguesthattheactionresearchprocesscanbebrokendownto

fourphases:(1)strategicplanning,(2)acting(implementingtheplan),(3)observing

andevaluating,(4)criticallyreflectingontheresults.Altogether,thesephases

representacycle,which,inanactionresearch,continuouslyrepeatsitself(giventhat

thereflectionwasutilizedandtheactionplanhasbeenrevised),untilthesolutionto

aproblemisfoundand/ortheobjectiveisreached.(ibid.,19-20.)McNiffand

Whitehead(2002,16),provideasimilarexplanationofthesephases,breakingthem

downtogatheringdata,reflectingonanaction,generatingandvalidatingevidence

fromthecollecteddata,andmakingconclusionsoutofit.Belowisthevisual

representationofactionresearchphasesasperZuber-Skeritt(2001,20),which

suggestsperceivingitasacontinuousspiralofplanning,whereeachcycleleadstoa

betterunderstandingofanissueandbringsparticipantsclosertoasolution.

Figure1.Thespiralofactionresearchcycles(Zuber-Skeritt2001,20)

Whyactionresearch?

Thedecisiontochooseactionresearchmethodforthisstudywasmadeduetothe

severalreasons.Firstandforemost,thetopicofthethesisitselfwastakenintothe

9

account.Atthebeginning,duringthepreparationsforthisstudyatthestageof

decidingthetopic,itwasacknowledgedthatresearchingtheGVDesignSprint

frameworkinareal-lifesettingsimplycallsforactionresearch,duetothefactthat

thisframeworkitselfrepresentsaphilosophysimilartotheoneofactionresearch.

DesignSprintmethodisbasedoncollaboration,communicationandknowledge

sharingamongtheSprintparticipants,itscornerstoneis“learningbydoing”princi-

ple,whichisthesameapproachthatactionresearchrepresents.Inaddition,Design

Sprintframeworkiscyclicaltoo,whichdeemedtomakeresearchingitviaactionre-

searchphasesandcyclesreasonable.Finally,accordingtoMcNiffandWhitehead

(2002,85),actionresearchisalwayspracticalandrequiresadeepfocusofpartici-

pantsononeparticularissueinordertoprogressinunderstandingitbetter,whichis

whyitsuitedforthisstudywhereagroupofpeoplewaschallengedtodevelopa

concreteproductinareal-lifepracticalsetting.

Researchprocessimplementation

Theresearchprocesshasfollowedthepre-definedstep-by-stepframeworkofthe

DesignSprintmethod(discussedinmoredetailinChapter3).Inaddition,tomeet

thedemandsofactionresearchmethod,cyclesofactionandreflectionhave

beenincorporatedintotheDesignSprintprocess.Astheresult,theresearchhadfive

cyclesthatlastedonedayeachandhadoneactionandonereflectionprocessper

cycle.The5-dayresearchprocessthattookplaceisillustratedbelow.

Figure2.Theimplementedresearchprocessofthestudy.

10

Afterthedatahasbeencollectedandanalyzed,theconclusionsofthisstudyhave

beenmadeandpresentedtotheassignorcompany.

2.3Datacollectionandanalysis

Inordertoaddresstheresearchproblemandanswertheresearchquestionsofthe

thesis,thisstudyhasfollowedthecyclicalnatureoftheactionresearchmethod,il-

lustratedpreviously.Thedataforthisresearchhasbeencollectedthroughobserva-

tions,astheauthorhasbeendirectlyinvolvedintheactionresearchprocessthathas

beenexecutedviatheDesignSprintframework.AccordingtoKothari(2004),inthe

observationdatacollectionmethod,theresearcherextractstheinformationbyob-

servingtheenvironmentandnotaskingtherespondentsdirectly.Whenthismethod

isused,theresearchershouldaddressthequestionslike“WhatshouldIobserve?”,

“Howshouldtheobservationsbedocumented?”,“Howtoensurethevalidityofthe

results?”.Overall,observationcanbeusedasamethodwhenithasadefinedre-

searchpurpose,whenitisplannedanddocumentedinasystematicway,and

checkedforitsreliabilityandvalidity.(ibid.,96.)AsstatedbyYin,doingaresearchby

observingisauniquewayofdatacollection,sincethecollecteddatagoesthrough

theownperceptionsandfeelingsoftheresearcher,andthusitisnotinanywayal-

teredorbiasedbywhatresearchparticipantsarereporting.Suchresearchcanbe

bothcompletelypassiveandparticipatory,butinbothcases,theprimarydataisvery

valuable,asitisnotfilteredbytheothers.Inaddition,fortheresearcher,itisvery

importanttodecidecorrectly,when,whereandwhattoobserve.Inqualitativere-

search,researchersusuallyoperateinachangingenvironment,anditisthusim-

portanttoestablishtheclearvisionofhowtoconductanobservation.Whendecid-

ingonwhattoobserve,manythingscanpotentiallybeasubjectforobservation,

namelycharacteristicsofindividuals,interactionsbetweenindividuals,surrounding

environmentsandactionsthatarehappeningaround,bothhumanandtechnical

(non-human).(ibid.,143-145.)

Althoughtheauthorofthisstudyhasparticipatedintheprocessofexecutionofthe

DesignSprint,theresultsofthisthesiscamefromtheauthor’sobservationsofthe

teambehavior,theopinionsthattheteammembershaveexpressed,andfromthe

wholeprocessofexecutingtheDesignSprintframeworkinpractice.Thecollected

11

datahasbeenanalysedthroughthereflectionprocessesthattookplaceattheend

ofeachofthefivecyclesduringtheresearchprocess,andtheanswerstothethree

researchquestionshavebeenfoundatthevariouscyclesofthisresearch.

2.4Planforresearchethicsandquality

Researchethics

AccordingtoAguinisandHenle(2004,35),priortostartingaresearchproject,one

shouldassesshiscapabilitiesandproficiencytoexecutearesearch,hisawareness

abouttheethicalguidelinesthatexist,thecorrectnessandappropriatenessofthe

createdresearcheddesign,andiftheresearchisacceptabletobringtothelifefrom

theethicalperspective.Ethicsinresearchexistforthesakeofmakingsurethatthe

researchbringsmorebenefitsthanharmtotheresearchparticipantsandthesocie-

ty.Thisisdone,namely,byensuringtheinformedconsentofallinvolvedpartiesre-

gardingthenatureandthepurposeoftheresearch,byminimizinganypotential

harmorriskforparticipants,treatingallresearchparticipantswithrespecttotheir

personasandtheirprivacy,diminishingthechanceofthewasteoftimeforpartici-

pants,etc.(Eriksson,&Kovalainen2016,63;Aguinis&Henle2004,36.)

Inaddition,researchersareresponsibleforensuringtheoriginalityoftheirworkand

avoidingplagiarismissuesatallcosts(Eriksson,&Kovalainen2016).Plagiarismmight

happenevenunconsciouslybyforgettingtocitesourcesorbydoingitinanotcor-

rectmanner,thusbreakingtheethicalprinciplesandpotentiallyinfringingthecopy-

rights.Therefore,researchersshouldalwaysgivecredittootherauthorstheyreferto

intheirworks,andbecarefulincitingtheusedsourcescorrectly.(ibid.,75-76.)

Theauthorofthisstudytakestheethicalprinciplesseriouslyandthusisawareofher

moralresponsibilitytowardsallpartiesinvolvedinthisresearch.Allresearchpartici-

pantsaretreatedwithrespectandareprovidedwithfullinformationaboutthecon-

tentsofthisthesisanditspurpose.Theparticipantshavegiventheirpermissionsto

recordtheiranswersandtosubsequentlyusetheminthisstudy;however,asper

participants’request,theirnamesarenotmentionedandnotdisclosedtoany3d

parties.Theparticipantshavealsogiventheirconsenttousethematerialsthathave

beenproducedduringtheresearchprocess,inthisthesis.Noparticipantswere

12

harmedinanywayduringthisstudy,andtheresearchwillbenefittheirorganization

andtothefurtherexplorationoftheresearchedissue.Finally,allideasandconcepts

thathavenotbeendevelopedbytheauthorofthisthesis,areproperlycited,andthe

originalauthorsarereferredto.

ReliabilityandValidity

Theauthorhasreliedontheexistingacademicliteratureonvarioustopicswhen

workingonthisstudy.Theexamplesoftheliteratureincludedcoursebooks,articles

fromvariousjournalsandotherresearchworks,foundinthelibrariesandonthe

GoogleScholarplatform,whichisasourceofinformationusedbymanyacademics,

thus,supposedly,areliableone.Thisstudycanalsobeusedinthefuturebyother

researcherswhostudytheDesignSprintframeworkoranysimilartopic.Thedata

collectedinthisstudyoriginatefromusingtheDesignSprintframeworkinpractice,

andthuscanpresumablybeconsideredreliable,asthisresearchispracticalandob-

servestheissueinthereal-lifesetting.Moreover,theauthorofthisstudyhas

plannedtheresearchprocessinawaythatthefindingdirectlyanswerthestated

researchquestionsandgiveaprofoundbackgroundtoalloftheanswers,thusthe

validityoftheresearchisplannedindetailandensured.Thereflectiononthe

plannedreliabilityandvalidityofthisstudycanbefoundinChapter6.

3Theoryandknowledgebase

3.1Softwareengineering

Softwareengineering,asdefinedbyPressman(2005),isaprocess,accompaniedbya

selectionoftoolsandproceduresthatareusedtobuildcomputersoftware.Theob-

jectiveofsoftwareengineeringistocreatecustomer-orientedsoftwaresystemsthat

areoperatingwithefficiency,aretenableandsustainable.(ibid.,2-20.)Furthermore,

suchsystemsshouldbedesignedsothattheycanbesuccessfullyimplementedinthe

setprojecttimeframesandbudgets(Braude&Bernstein2016,1).Everysoftware

engineeringprojectbegins,tosomeextent,fromabusinessneed:itcouldbeaneed

toimproveandwidenthefunctionsoftheexistingsoftware,updateitaccordingto

13

thechangingneedsoftheenvironment,ortheneedtocreateacompletelynew

softwareproductorsystemcompletelyfromthescratch.Developingasoftware

productisaprocessofrepeatedlearning,whichyieldssomethingthatcanbenamed

as“softwarecapital”-anarrayofcollected,distributedandorganizedknowledge

andlearningsduringtheimplementationofthewholesoftwaredevelopment

process.Inaddition,softwareengineeringshouldn’tbeconfusedwithsoftware

developmentprocess.Whilebothhavetodowithsoftwaredevelopment,asoftware

developmentprocesscanbegeneralizedasageneralmethodologyandphilosophy

todevelopment,whilethedevelopment(engineering)itself,inaddition,referstothe

technicalmethodsbeingdeployed(Pressman2005,15-20).

Softwareengineeringisacomplexandachallengingprocess,whichrequires

cohesionbetweenanumberofpeopleformedintointerconnectedteams,whose

goalsshouldbealignedaroundaspecificproductwithapre-definedframeworkto

buildthisproduct.Allthissystemshouldbethenorganizedintooneprojectwitha

step-by-stepdefinedprocessofitsexecution.Altogether,theactivitiesneededtobe

performedduringsoftwaredevelopmentarefrequentlyreferredasto“4P’sof

softwareengineering”,whichare:people,product,project,process.“People”refers

toallprojectstakeholders,inotherwords-participantsofaproject,andthosewho

influenceit.“Product”issomethingthatisbeingdeveloped,itssubsequentend

resultandthedocumentationregardingit.“Project”meansalltheactivities

implementedinordertoachievetheresultandgettotheendproduct.Finally,

“Process”ischaracterizedasasharedsetofprocedureswithinwhichthe

stakeholdersexecutetheproject.Ifalloftheseelementsarebalanced,properly

takencareofandaddressed,asoftwareprojectisdeemedtobesuccessful,

therefore,stakeholdersneedtomakesurethat4P’sdonotpotentiallyconflictwith

eachother.(Braude&Bernstein2016,5-6)

Sincethisthesisdescribesthedevelopmentofasoftwareproductinacompany

throughtheDesignSprintmethodology(hence,thespecificprocess),theProcess

elementofthe4P’sofsoftwareengineeringisbrokendowninmoredetailbelow.

Thisisdoneinordertobuildabigpicturearoundthesoftwaredevelopmentbasics,

14

subsequentlyaddresstheDesignSprintframeworkandaddmoreclaritytothemain

issueofthisresearch.

3.2Softwareprocess

AsdefinedbyBraudeandBernstein(2016),asoftwareprocessisaframeworkfor

implementingtheactivitiesneededforaprojectinasystematicandorganizedway.

Followingasoftwareprocesshelpstoreachacohesioninateamandguideit

throughthetasks;itshowshowdifferentphasesofasoftwareprojectare

interconnectedandhelpstodefineandreachtheproject’soutput.(ibid.,9.)

Pressman(2005),summarizesthedefinitionofsoftwareprocessasa“seriesof

predictablesteps-aroadmapthathelpsyoutocreateatimely,high-qualityresult”.

Hefurtherclaimsthattheindividualsthatfollowsoftwareprocessesarenormally

softwareengineersandtheirmanagers,aswellasthosewhohaverequested

softwareoutoftheircertainbusinessneeds.(ibid.,20.)Inaddition,accordingto

Sánchez-GordónandO’Connor(2016,2),Zahran(1998)statesthatasoftware

processisaseriesofpracticesandmethodsthatareutilizedinordertodevelop,

sustainandpreservesoftwareandalldocumentationrelatedtoit.

Whiletheaforementioneddefinitionsvaryinwordingandthere’snouniversalway

torefertosoftwareprocessyet,still,asimilarpatterncanbeseenamongthem.

Therefore,thefollowingconclusioncanbemadeoutofit:anysoftwareprocessisa

systematicanddetailedwaythathelpsaproject’sstakeholderstodefinethegoalsof

aproject,astep-by-stepwaytoachievethem,andsubsequentlytomanageand

sustaintheendresult.Nevertheless,accordingtoSánchez-GordónandO’Connor

(2016,3),Pressman(2009)believesthatsoftwareprocessstilldoesn’tprovidea

definiterightorwrongwayofapproachingsoftwaredevelopment,butrather

presentsaflexibleandadaptableframeworkthatletsteamschooseandactuponthe

appropriatecourseofactionandtasks.Sommerville(2011,28)alsosuggeststhatan

idealsoftwareprocessdoesn’texistasitvastlydependsonpeoplewhoaremaking

decisionsandjudgmentsandthusadaptstothecapabilitiesandresourcesof

stakeholders,andthespecificsoftheprojects.

15

3.3Softwaredevelopmentmethodologies

AsstatedbySommerville(2011),softwareprocessescanfallintothecategoryof

eitherplan-drivenoragileprocesses.Plan-drivenprocessescanbedefinedasthose

processes,wheretheactionsareplannedbeforehandandthemeasurementof

progressisbasedaccordingtothisinitialplan.Agileprocesses,ontheotherhand,

suggestthatplanningisadaptive,andthuscanbedoneonthegoastheproject

evolvesandtheneedsofthecustomersarechanging.(ibid.,29.)Eachofthesetwo

paradigmsrepresentsmanydifferentsoftwaredevelopmentmethodologies,andthe

mostsignificantonesarefurtherdiscussedinthissubchapter.

Plan-drivenmethodologies

Boehm’s1988study(citedinGill2014,1),suggeststhattheplan-driven

methodologieshavebeenintroducedinthepastinordertomanagelargeand

importantprojectsusingfixedandrepeatableprocesses.AccordingtoPetersenand

Wohlin(2010,657),Hirsch(2005),definesthefollowingcharacteristicsoftheplan-

drivenapproach:thefunctionalityofthesoftwareshouldbedefinedbeforethestart

ofaproject,adetailedstep-by-stepplanofaprojectisrequired,allrequirementsare

verydetailedandifsomethingneedstobechanged,itisimplementedafterthe

outputisproduced.Moreover,thearchitectureanddesignelementsmustbe

specifiedbeforetheactualdevelopmentstarts,codinghappensonlyduringone

specificstage,testinghappensattheendoftheproject,andqualitycontrolprocess

isformal.Plan-drivenmethodologiesareconsideredtraditional,andtheyhavebeen

furtherdefinedas“heavyweight”duetoaveryelaboratesetofrequirements,exact

documentation,planningandinspection(Awad2005,1).Therearemanyplan-driven

methodologiesthatarepracticed,andthisstudywilllookatthetwoofthem:the

WaterfallmodelandtheSpiralmodel.

TheWaterfallmodel

MunassarandGovardhan(2010)claimthatthewaterfallmodelisconsidered

classicalandoneoftheoldestamongtheothermodelsofsoftwareengineering.The

mostcommoninstanceswhereit’susedaregovernmentalandbigcompanies’

16

projects.(ibid.,95.)Thebasicprincipleofusingwaterfallmodelimpliesthatonecan

startanewstageofaprojectonlyaftercompletingthepreviousone,thusthe

phasesareindependentandshouldbeperformedinasequence(Modi,Singh,&

Chauhan2017,117-118).AccordingtoKaurandSengupta(2011,1),thewaterfall

modelhasbeenfrequentlyusedinthepastduetotheveryformalinspection

requirementsthatitimposed.Thismodelputsemphasisontheearly-stageplanning

ofaprojectinordertominimizepotentialmistakes,aswellasonthedetailed

documentationandplanning,whichmakesitagoodfitforthoseprojects,wherethe

qualityconcernisofaverybigimportance(Munassar&Govardhan2010,95).

Ruparelia(2010)believesthatwaterfallmodelperformsthebestwhencreatingbig

softwareprojectsthatserveasback-endfunctionaltosmallersoftwareprojects.For

instance,anexampleofsuchsoftwarecouldbesecureoperatingsystems.(ibid.,8-9.)

AsnotedbyMunassarandGovardhan(2010,95),atypicalwaterfalllifecycleconsists

ofasequenceofsteps,whichbeginsfromspecificationandestablishmentofsystem

andsoftwarerequirements,proceedingtomodelinganddesign,thentoactual

programming,toverificationandtesting,andfinallytothesupportandmaintenance

activities.Thefigurebelowillustratesthissequentialmodel.

Figure3.TheWaterfallmodelofsoftwaredevelopment(SpriteCloudn.d.)

Thedisadvantageofthewaterfallmodelisthelackoffeedbackinbetweenthe

stages,whichoftenleadstoproblemsandissueswiththesoftwareonlybeing

17

discoveredaftertheimplementationofthewholeproject(Sommerville1996).In

addition,itisalsodifficulttomakeanychanges,whichcanberequestedbythe

customer/enduser,afterthefinalmaintenancestage.Thisresultsinthefinal

outcomeoftennotmeetingthecustomers’needs,whichiswhythewaterfallmodel

startedtobewidelycriticized,whichledtothefurtherdevelopmentofother

softwaredevelopmentmodels.(ibid.,269)

Spiralmodel

ThespiralmodelwasfirstlydevelopedbyBarryBoehmasaresultofvariouscasesof

adjustmentstotheclassicwaterfallmodelinbigsoftwareprojects(Awad2005,6).

AccordingtoPressman(2005,54),thismodelcombinesprototypingofthedesired

endproductwiththeverysystematicanddetailedapproachesofthewaterfall

model.Boehm(1988,61)himselfdefinesthemajorfeatureofthismodelasthe

adoptionoftherisk-drivenapproachtosoftwaredevelopment,asopposedto

traditionaldocument-drivenorcode-drivenprocesses.Fairbanks(2010)describes

therisk-drivenapproachastheonewheretheeffortsthatthestakeholdersputinto

theprojectareequivalenttotherisksthattheprojectfaces.Toputitsimply,this

approachadvocatesforwell-thought-outallocationofresources,anditallowsthe

project’sstakeholderstoidentifyandadequatelyaddresstheproject’srisksina

timelymanner.(ibid.,36.)

Thebasicideaofthespiralmodelimpliesthatsoftwareisdevelopedincyclesthat

evolve:duringtheearlycycles,aprototypeofthefinaloutcomeisdeveloped;atthe

laterstages,developersbuildupontheprototypeandproducemoresophisticated

andcompleteversionsofit(Pressman2005,54).Inhislaterpublication,Boehm

(2000),definesthespiralmodelasa“risk-drivenprocessmodelgenerator”,which

hastwomainfeatures:cyclicrecurrenceinordertograduallyreachthefinal

outcomeofasoftwareproject,andanumberofso-called“anchorpointmilestones”

thatensurethemutualunderstandingandcommitmentofthestakeholders.Inthis

definitionofthespiralmodel,risksareeventsthatcantriggerthefailureofaproject,

andanchorpointmilestonesrefertothemeansofprogresstrackingandcomparison

betweendifferentcyclesinaspiralmodel.(ibid.,3-4.)

18

Belowisthevisualrepresentationofthespiralmodel,whichillustratesitscyclical

nature.

Figure4.Spiralmodelofsoftwaredevelopment(Boehm1988,64)

AsillustratedinFigure3,thespiralmodelhasfourphases,whichmoveacrossfour

quadrantsinarepeatablecycle.AccordingtoRuparelia(2010),thephasesare:

1.Settingtheobjectivesofaproject.

2.Considerationofthealternativeobjectives,analysisofpossiblerisks.

3.Verification,development,andtesting.

4.Planningofthenextcycle.(ibid.,10-11.)

Asthephasesprogressandimprove,aprototypeofanendresultiscreatedalong

theway,inaccordancewiththerequirementsandtestingprocedures(Ruparelia

2010,10).Inaddition,thesephasesandcyclesofthespiralmodelareadaptableand

applicabletoanystageofalifecycleofasoftwaredevelopmentprojectuntilitgoes

outoftheuseorsimplygetsoutdated,unliketheothermodelswhichlifecyclesend

whentheworkontheprojectiscomplete(Pressman2005,55).

19

Oneofthemainbenefitsofspiralmodelisitsemphasisontherisksandcostsofthe

projectspecificallyfromthebeginningofit(Ruparelia2010,11).Thisriskcontrolis

thecornerstoneofthismodel,andthefurtheradvantageisitsrequirementofrisk

evaluationandreductionduringallstagesofaproject(Pressman2005,55-56).

However,accordingto,Bernal&Karam(2016,64),thedrawbackofthespiralmodel

liesintheassumptionthatsoftwaredevelopersareabletocorrectlyidentifyand

eliminaterisks,whichmightnothappeninallcases.Inaddition,thismodelrequiresa

veryflexibleprojectmanagementandstronglyadaptabledocumentationprocesses

betweenthestakeholdersastheproductprototypeevolvesinthespiral(Ruparelia

2010,11).Finally,thespiralmodelcanbesimplyverycostlyduetothefactthatthe

resourcesneededforitsimplementationincreasecyclebycycle,andtheconstant

riskanalysisisrequiredallthetime(Modi,Singh&Chauhan2017,118-119).

Agilemethodologies

AccordingtoBraudeandBernstein(2016),agilemethodologieshavebeendeveloped

inthe1990sasanalternativetotheclassicplan-drivenmethodologiesthatwere

seenastooplan-andrequirements-concentrated.Oneofthebiggestissuesofsuch

methodologiesisanunclearsetofrequirementsfortheendproductatthevery

beginningoftheproject,whichcausesmanyprojectsthatfollowsuchmethodologies

facemajorobstaclesduringthedevelopment.Agilemethodologiesaddresssuch

issuebyprovidingadaptable,efficientandresponsiveframeworks.Thecornerstone

ofallagilemethodsliesintheAgileManifesto-asummaryofthekeyprinciplesof

agilemethodologiesthathaveevolvedovertime,whichwasdevelopedin2001by

thesoftwareindustryexperts.AgileManifestocanbebrokendownintofourpoints:

1.Interactionbetweenindividualsisputoverprocessesandtools.

2.Well-developedandworkingsoftwareoverheavydocumentation.

3.Collaborationwithcustomersovernegotiatingcontractsandrequirements.

4.Addressingchangesoverfollowingparticularplans.(ibid.,63-64.)

Abrahamsson,Salo,Ronkainen,andWarsta(2017)suggestthatadevelopment

processisconsideredagilewhenit’sincremental,cooperative,straightforwardand

20

adaptive.Incrementalimpliesrapidandsmallsoftwarerelease,cooperativemeans

closecohesionandcommunicationbetweentheproject’sstakeholders,including

customers.Additionally,straightforwardmeansthatitiseasytolearnanddocument

thewholeprocess;finally,adaptivereferstotheabilityofmakingchangestothe

projectatanystage.Theauthorsfurtherspecifythatthemainfeaturesofagile

methodologiesaresimplicityandtheirfastspeed,whichallowsthedevelopersto

prioritizethemostimportantfunctionsandissuesfirst,developthem,testand

collectfeedbackinordertofurtheraddressit.(ibid.,17.)Overall,accordingto

BraudeandBernstein(2016),agilemethodssuggestcreatingasetofviableguiding

principlesforaproject’sstakeholdersratherthanspecificrulesthatmustbe

followed.Theseguidingprinciplesaredevelopedinorderforthestakeholdersto

decideontheappropriatepracticesandsolutionsastheprojectevolves.Inaddition,

agilemethodsvaluecreativethinkingwhilesolvingproblems,asopposedtothe

plan-drivenmethodologieswhereadaptingtotheprescribedrulesisexpected-such

practicesareseenineffectiveanddangerousintheagilemethods.(ibid.,65.)

Similartothebigvarietyoftheplan-drivenmethodologies,manyagile

methodologieshavealsobeendevelopedovertime.Thisthesiswilllookatthetwo

ofthem,whicharecommonlyused:ExtremeProgramming(XP)andScrum.

ExtremeProgrammingmethodology(XP)

AccordingtoLindstromandJeffries(2004),themethodofExtremeProgrammingis

basedonsimplicity,opencommunication,andfeedbackbetweentheproject’s

stakeholders.XPmethodologyisverycustomer-centered,andtheother

stakeholders,suchasbusiness,developmentandtestingteamsallworktogetherand

handleallaspectsandissuesoftheproject.InExtremeProgramming,teamsdevelop

softwareinsmallbatchesinashorttimeandinaconsistentmanner,inorderto

tracktheprogress,collectthefeedbackanddecideonthefurtheractionsandto

continueimprovingthesoftwaredesign.(ibid.,44-45.)Beck(1999),underlinesthe

followingfeaturesofXP:

21

1.Planning-programmersestimatethescopeofworkforaprojectandcustomers

decideonthescopeandthetimingofthesmallreleasesthatprogrammersproduce.

2.Smallreleases-asoftwareprojectisdevelopedinaseriesofshortreleases,which

areregularlyupdatedandrenewed.

3.Metaphor-customersanddevelopersdefinetheprojectbycertainmetaphors

thattheysharewitheachotherinordertohaveacommonvisionofhowthesystem

shouldwork.

4.Simpledesign-thesoftwaresolutionisdesignedassimplyaspossiblewithoutany

unnecessarycomplexities.

5.Tests-programmersconstantlytestthefunctionality.

6.Refactoring-thedevelopedsystemisadaptedonthewaybytransformingand

evolvingthedesignwithoutchangingthefunctionalityofthesoftware.

7.Pairprogramming-thecodingprocessisdonebytwopeopleononecomputer.

8.Continuousintegration-whenanewpieceofcodeisproduced,itisintegrated

intotheexistingsystemimmediately.

9.Collectiveownership-anyprogrammerfromtheteamisabletoimproveanypart

oftheprogramanytimeiftheyseeaneedforit.

10.On-sitecustomer:acustomerworkstogetherwiththedeveloperteamandis

physicallypresentwiththem.

11.40-hourweeks:itisforbiddentoworkovertimetwoweeksinarow,otherwise

thisisseenasaproblemthatneedstobesolved.

12.Openworkspace:teamworksinalargeopenspace.

13.Rules-althoughtherulesfortheprojectdoexist,theyareflexibleandcanbe

alwaysadaptedifallstakeholdersagreeonthem.(ibid.,71.)

ThelifecycleofaprojectthatfollowstheXPmethodologyconsistsof6phases:

Exploration,Planning,Iterationstorelease,Production,MaintenanceandDeath

(Awad2005,9).Belowisthevisualrepresentationofthislifecycle.

22

Figure5.Extremeprogramming(XP)methodologyofsoftwaredevelopment(Abra-

hamsson,Salo,Ronkainen,&Warsta2002,21)

Explorationphaserequirescustomerstocreatestorycardsthatcommunicatetheir

visionoftheendproductanditsdesiredfunctions(Awad2005,9).Intheplanning

phase,theapproximatetimeframeandplanfortheproductreleasesareset

(LindstromandJeffries2004).TheIterationstoReleasephaseproceedswiththe

developingsoftwareinrepetitivetwo-weekcycleswiththegoaltoproducea

workingsoftwareattheendofeachiteration.Thecustomeralsocontributesby

communicatingthedesiredfeaturestobedevelopedinthecourseofthenexttwo

weeks.(ibid.,47.)ThisphasefurtherevolvesintotheProductionphase,whereextra

testingandchangesaredonebeforethefinaloutcomeisreleasedtothecustomer

(Awad2005).IntheMaintenancephase,alldevelopmentideasthathavenotbeen

implementedpreviously,areintegratedintothesystemfortheupdatedreleases.

ThefinalDeathphaseoccurswhenthecustomerdoesn’thaveanymorerequeststo

beimplementedandthusnofurtherchangestothearchitectureofthewholesystem

aremade.(ibid.,9.)

Abrahamsson,Salo,Ronkainen,andWarsta(2017,26)suggestthattheExtreme

Programmingmethoddeliversthebestresultswhenusedinsmallandmedium-sized

teams.However,accordingtoLindstromandJeffries(2004),XPisoftencriticized

23

becauseitisseenastoosimpletodevelopbeyondthestatedcriteriathatsome

projectsrequire.Thus,astheauthorsfurtherclaim,inordertoevaluatethe

appropriatenessofusingXPinaproject,onemusttakeintotheconsiderationthe

following:firstly,whethertheteamisabletocommunicateconstantlyandbe

cohesiveandwhethertheteamiscomfortablewithcreatingsimplesolutions.

Moreover,oneneedstoevaluatewhetherthestableandconstructivefeedback

systemissetupandwhethertheteammembersarereadytoshowinitiativeandare

notafraidoffailure.Ifthesequestionsarepositivelyansweredtoagreatdegree,

thentheprocessofadoptionXPpracticeshappensmucheasier.(ibid.,43-50.)

Scrummethodology

Scrumisanotherwidelyusedagilemethodologythatrequireshighlevelsofflexibility

andadaptability.AccordingtoAbrahamsson,Salo,Ronkainen,andWarsta(2017),

thebasicprincipleofScrumliesinthebeliefthatdevelopmentofanysoftwareisa

complexprocesswithmanydetailstotakeintotheaccount,suchasresources,time

frame,customerrequirements,etc.,andthesedetailscannaturallychangeduring

thedevelopmentprocess.Thisiswhydevelopmentiscomplexandunpredictable,

whichcallsforahighlevelofteams’adaptabilityinordertoaddressthechangesthat

arehappeningintheproject.(ibid.,27-28.)

Schwaber(1995),suggeststhatScrumconsistsofthreegroupsofphases:Pregame,

Game,andPostgame.ThePregamephaseconsistsoftheinitialplanningofthe

developmentprocess,whichincludestheoverviewofthesoftwarerelease,costand

timelineestimations.Additionally,thisphasealsoincludesthedesignand

architectureofthesoftwareproduct.IntheGamephase,theactualdevelopmentis

happeninginaseriesofshort“Sprints”-setsofdevelopmentactivitiesthatare

implementedinalimitedtimeframe(usually1-4weeks)inarapidmanner.The

Gamephasenormallyconsistsofseveralsprintsinordertointensifythe

developmentandconstantlyimproveandadjustthesystem.(ibid.,125-126.)Oneof

thecrucialpartsoftheGamephaseisdailyteammeetings,inwhichthefollowing

questionsareaddressedtoeachteammember:1)Whathaveyoudoneyesterday?

2)Whatwillyoudotoday?3)Whichchallengesmightpreventyoufromdoingthis?

24

(Ionel2008).Byansweringthesequestions,teammembersareabletoseeeach

other’sprogressastheprojectevolves,theypresumablybecomemoreeagerto

involveandcontributetotheprojectandtheystaymoremotivated.(ibid.,438.)

Finally,thePostgamephaseincludesthefinalpreparationsbeforethereleaseofthe

software,whichincludesfinaldocumentation,testingandthereleaseitself

(Schwaber1995,125-126).BelowisthesimplevisualrepresentationofScrum

process,whichillustratesthethreephasesandhowtheyareconnectedtoeach

other.

Figure6.Scrummethodologyofsoftwaredevelopment(Schwaber1995,126)

Scrummethodologyismostefficientwhenusedinsmallteamsthatconsistupto10

engineers(Abrahamsson,Salo,Ronkainen&Warsta2017,36).Thebiggest

advantageofScrumisitsflexibilityandadaptabilitytochangingenvironmentsduring

aprojectthatenabledeveloperstolearnonthego,collaboratebetweeneachother

andcreatethemostappropriatesolutionsforaproject(Schwaber1995,129-130).

However,accordingtoIonel(2008),apotentialdrawbackinScrumapproach,

ironically,liesinthiscollaborationandconstantfeedbackloop:inorderto

successfullyimplementScruminaproject,itisrecommendedthatthemainclient

constantlyparticipatesinthedevelopmentactivitiesby,forexample,testingand

providingfeedback.Thatsaid,theclient’savailabilityisnotalwayspossible,

especiallywhentheclientisexternal.Therefore,itishighlypreferabletouseScrum

inprojectswhereclientsarealwaysavailableandopenforcollaboration(orcome

25

fromthesameorganizationandareinternal),sincethisdirectlyinfluencesthe

project’soutcome.(ibid.,439.)

3.4DesignThinking

SincetheDesignSprintmethod,whichistheprimarytopicofthisthesis,usesdesign

thinkingasapartofitsgeneralphilosophy(tobediscussedinmoredetailinthenext

chapter),theconceptofdesignthinkingneedstobebrokendowninordertogivea

clearerpictureofwhatDesignSprintframeworkisbasedon.

AccordingtoRazzoukandShute(2012,330),designthinkingisusuallyseenasan

analyticalandcreativeprocessthatletsindividualswhoareundertakingittocreate,

experimentandtestideas,collectfeedbackabouttheirprojectsandcreations,and

makechangestothembasedonit.Thisprocesscanbeseenasaspecialwayof

thinkingandapproachingagroundunderstandingofanynewandemerging

concepts,issues,events,etc.,thatleadstoinnovationandalterationinthewaywe

live,managebusinesses,people,etc(Tschimmel2012).Eventhoughinitially,the

conceptofdesignthinkingwasbasedonthewaydesignersandcreativepeople

approachworkandproblem-solvingactivities,nowadays,thisconceptisappliedto

anyofsuchprocesses,regardlessofateamorofanorganization.Today’sideaof

designthinkingbecameaneffectivesolutionforanykindofinnovationprocessby

mergingcreativethinkingwiththeusualstrategicbusinessmindset,andthusitis

veryactivelyexploredandusedinvariousareasofdifferentbusinessfunctions,for

instance,inmanagementandmarketing.(ibid.,1-2.)

AccordingtoTschimmel(2012),thecornerstoneofdesignthinkinginsolving

problems,seekingsolutionsorcreatingnewinnovationsisthedesignthinker’sability

tocombineandconsiderthreefollowingthingssimultaneously:needsofpeople,

availableresources,andopportunitiesandobstaclesoftheparticularthingthe

designthinkerisworkingon.Ifoneutilizesdesignthinkingapproach,heshouldalso

bereadytocombineanalyticalandemphaticthinking,belogicalandemotional,

followmethodsandrules,butbeflexibleandspontaneousatthesametime.

Anothertypicalfeatureofdesignthinkingprocessisvisualizingtheideasintheforms

26

ofsketches,drawings,notes,andprototypes-thishelpstobringclaritytothewhole

issuebeingworkedon,andhelpsdesignthinkerstofindoutfurtherthingsthatneed

tobeworkedonwithinthisissue.Furthermore,anessentialtraitofdesignthinkingis

itshuman-centeredapproach,whichmeansconstantcollaborationand

communicationbetweenpeopleinateam,andactinginaparticipatoryway.

Moreover,designthinkersaresupposedtonotonlybeworkingamongthemselves

butalsotoinvolvecustomers,endusersandotherstakeholdersoftheirprojectsin

thedesignthinkingprocess.Suchcooperationimprovestheendresultofthewhole

work,increasestheeffectivenessofreachingtheoutcomeandimprovesthe

satisfactionofthefutureusers.(ibid.,3-4.)

Allinall,designthinkingisaveryspecificapproachtosolvingcomplexproblems

and/orimplementingcomplexideas,whichrequiresmultidisciplinarygroupsof

peopledeployinguser-centeredandparticipatoryapproach(Thoring&Müller2011).

Designthinkingfounditsusefulnessnotonlyindesignfieldsbutalsoinbusinessand

engineeringareasinordertocultivateinnovation.Nowadays,itisbecomingmore

andmoreusedandexploredinmanyotherareasforsuchpurposes.(ibid.,1.)

3.5GoogleVenturesDesignSprintasanewmethodofDesignThinking

TheveryfirstroughimplementationofDesignSprintframeworkwasinitiallymadein

2009byJakeKnapp,whoatthattimewasanemployeeatGoogle(Knapp,Zeratsky,

andKowitz2016).TheideaofdesignsprintsemergedoutKnapp’sgoaltoimprove

teamprocessesatGoogleandtomaketheoutcomesofusualteambrainstorms

better.Severalyearslater,KnappjoinedGoogleVentures(laterreferredtoasGV)-a

venturecapitalcreatedbyGooglethatinvestsinstartups.GoogleVenturesgot

interestedintheideaofrunningdesignsprintswiththeirportfoliostartups,asthese

sprintscouldhelpyoungcompaniestotesttheirideasbeforelaunchingtheir

products.JakeKnappwasjoinedbyBradenKowitz,JohnZeratsky,andMichael

Margolis,andtogethertheystartedimplementingdesignsprintswithGVportfolio

startups,experimentingwiththeprocess,adjustingandimprovingtheframework.

(ibid.,1-5.)

27

AccordingtoKnapp,Zeratsky,andKowitz(2016),DesignSprintisafive-dayprocess

thathelpscompaniestoanswercrucialbusinessquestionsandproblemsbycreating

prototypesandtestingthemwithpotentialcustomers.Initsessence,thisprocess

combinestheideasofbusinessstrategy,innovation,design,psychologyandmany

more,thatarecombinedaltogetherinareadyframework,whichcanbeusedbyany

teamregardlessofabackground.Sincetheintroductionofdesignsprints,theyhave

beenrunnotonlybystartupsbutalsobyinvestmentbankers,engineeringteams,

andevenschoolstudents,whichsuggeststhatthisframeworkisapplicabletovarious

typesofteamswithdifferentbackgroundsandproblems.(ibid.,6-16.)

Therearethreethingsthatneedtobetakencareofbeforethebeginningofasprint

(Knapp,ZeratskyandKowitz2016).Firstly,aspecificchallengemustbe

acknowledgedandunderstoodbytheteam.AtGV,startupsareencouragedtouse

designsprintsforsolvingmostcriticalproblemsinthecompany,becausetheideaof

solvingsuchextremelyimportantissuesmakesteammembersbemuchmore

motivatedandeagertosolvethemthanitwouldhavebeenincaseofsolvingregular

day-to-dayquestions.Secondly,ateamforrunningasprintshouldbeformed.Itis

recommendedthattheteamsizeshouldbenotmorethan7peopleduetothefact

thatwithlargernumbersofparticipantsitisdifficulttokeepeveryoneefficientand

focusedonwork.Whatismore,teamsshouldbecross-functionalandmixed,and

thereshouldbeanexpertonspecializedtopicspresentduringsprints.This

requirementshouldbefollowedbecausehavingpeoplefromdifferentbackgrounds

fromthesamecompany,workingtogetherinasprint,candelivervaluableinsights

andhelplookattheissuefromdifferentperspectives.A“Decider”shouldbe

appointed-thispersonmakesthefinaldecisionsduringasprint,andthisisusually

thecompany’sCEO/founder,oranyothercompany’simportantdecision-maker.

Additionally,aFacilitatormustbechosen,whowillguidethewholeteamthrough

thesprint,managetime,discussions,andsummarizetheresults.Finally,timeand

spaceforasprintshouldbearranged.Ateamshouldshutdownalloperationsfor

oneworkingweekandbepresentinthesameroomMondaytoFridayfrom10a.m.

to5p.m.(from9a.m.onFriday).TestingdesignsprintsatGVprovedthesprint

durationoffivedaystobemostefficientamongallotheroptions,suchastendays,

onemonth,etc.,becausefivedaysgiveasenseofurgency,butatthesametimethey

28

giveenoughtimeandresourcestogetthroughasprintandsolvethechallenge.

Moreover,nodevicesareallowedtobeusedduringthesprint(unlessneededfora

specificsprint’spurpose),andthemainprerequisiteisthatthewholeteammustbe

100%concentratedonthechallenge.(ibid.,21-42.)

Thefive-daydesignsprintprocess,developedbyGoogleVentures,isthefollowing:

1. Monday-thelong-termgoalregardingaspecificissueischosen,andamap

ofthewholechallengeaboutitiscreatedintheteamsothateveryonehasa

sharedvisionoftheproblemKnapp,Zeratsky&Kowitz(2016).Then,the

company’sexpertsonspecifictopicssharetheirknowledgeandopinions,and

atargetofthesprintischosen:whatexactlyneedstobesolvedinthesefive

days,andwhatarethechallengesinvolved.Thewholeprocessisdocumented

onthewhiteboardandonthestickynotes.(ibid.,51-88.)

2. Tuesday-onthisday,solutionstotheproblemarecreatedKnapp,Zeratsky&

Kowitz(2016).Firstly,allteammembersconductaresearchonexistingideas

andcasestudies.Next,everyonecomesupwiththeirownideasregardinga

potentialsolutiontotheissueandanonymouslysketchesthemoninalimited

timeframe.Allsketchedarecollectedandleftuntoucheduntilthenextday.

(ibid.,93-118.)

3. Wednesday-teammembersgivefeedbackandcritiqueoneachofthe

sketchedsolutionsKnapp,Zeratsky&Kowitz(2016).Eventually,thesolutions

arevotedfor,andthesolutiontoworkwithfurtherisdecidedbytheteam’s

“Decider”.Theideafromthewinningsketchistakenasabaseforthe

prototype,anditisalsoenhancedbyideasfromothersketches.Basedonall

theseideas,astoryboardfortheprototypeiscreated.(ibid.,125-158.)

4. Thursday-onthisday,arealisticprototypeiscreatedusingtheWednesday’s

storyboardKnapp,Zeratsky&Kowitz(2016).Itcanbecreatedonscreen,on

paper,inaformofscriptwithactors,inaformofaphysicalspace,a3D

printedobject,etc.(ibid.,163-190.)

5. Friday-thelastdayofthesprintisreservedfortestingthecreatedprototype

byinterviewingtargetcustomersandobservingtheirreactionstothe

prototypeKnapp,Zeratsky&Kowitz(2016).Thisallowstheteamtolookat

29

theirideasthroughthecustomers’eyesandtoshowthemtheproblemsthat

can’tbeseenorpredictedinternallyinateam.(ibid.,193-211.)

Figure7.GoogleVenturesDesignSprint5-dayprocess(TetuanValley2017)

AccordingtoMuchaandNebe(2017),onedistinguishingfeatureofGVdesignsprint

isthatitdeliversveryquickfindingsandresults.Inaddition,sprintparticipantsfeela

senseofaccomplishmentduetothetangibleprototypethattheymanagetocreate

andtestinfivedays.(ibid.,3.)Moreover,onefurtherbenefitofthedesignsprint

frameworkisthatitallowstorapidlycreateandtestideaswithouttakinglong

periodsoftimetobuildandlaunchthem,sothatpotentialmonthsofworkshorten

downtofivedaysonly(http://www.gv.com/,2016).Itcanbethussummarizedthat

designsprintshelpfindawaynottoonlysolveimportantproblems,buttodoit

muchfaster,efficientandonabiggerscale(Knapp,Zeratsky&Kowitz,2016).With

thehelpofsprints,feasibilityofnewideascanbeassessed,existingproductscanbe

improvedandbusinessstrategiescanbecreated.(ibid.,6-16)

3.6Synthesisoftheconceptualframework

Inthetheoreticalpartofthisstudy,theconceptsrelatedtosoftwaredevelopment

havebeenintroducedalongsidethebasicsofdesignthinkingandthedetailedde-

30

scriptionoftheDesignSprintframeworkasthegroundconceptsofthiswork.Since

oneofthequestionsofthisstudyaimedatfindingoutwhatkindofasoftwareprod-

uctcouldbecreatedthroughtheDesignSprint,itwasseenasnecessarybytheau-

thortogiveanoverviewofhowsoftwareproductsareusuallydeveloped,testedand

broughttolife.Moreover,whilesoftwaredevelopmentmethodologiesanddesign

thinkingarenotdirectlyconnectedtotheDesignSprintmethoditself,andduringthe

sprint,theactualprogrammingoranyothertechnicalthingshappenquiterarely,still

someimportantsimilaritiesbetweenthethreeconceptscanbeseen,whicharedis-

cussedbelow.

1.SequentialityofthetraditionalsoftwaremodelsandtheDesignSprint

Asdiscussedpreviously,thetraditionalsoftwaredevelopmentframeworkstendto

beveryprocess-orientedandthereforeemphasizeaverydetailedandthoroughap-

proachtotheworkthatneedstobedone.ThiscanbeseenfromtheWaterfallmod-

elandtheSpiralmodelthathavebeenpresented:thefirstonehasasequenceof

steps,whereonecanmovebetweenthestepsonlyhavingcompletedtheprevious

steps;thelatterisbasedonfourphasesthatrepeatthemselvesinacyclicalnature

untilthedesiredoutcomeisreached.Similarlytothestructureofthetraditional

softwaremodels,theDesignSprintframeworkalsofollowstheconcreteseriesof

stepsthatstrictlygooneafteranother.Inthisframework,itisimpossibleandsense-

lesstostart,forexample,fromtheStep2,whichissolutionsketching,withouthav-

ingidentifiedtheproblemtobesolvedattheStep1.Itisalsonotpossibletoskipa

stepandtomoveforwardwithouttheoutcomesthatneededtobeproducedduring

it.Therefore,thenatureoftheDesignSprintmethodologyispartiallysimilartothe

oneoftraditionalsoftwaremodels,sinceitemphasizesastep-by-stepgradualpro-

cess,whichneedstobestrictlyfollowed.

2.RapidnessofAgilemethodsandtheDesignSprint

Asmentionedearlier,oneofthecorefeaturesoftheagilemethodologiesisthatthe

productdevelopmenthappensveryrapidly,cooperativelyanditiseasytodocument.

Inoneofthedescribedmethods,Scrum,theideaofsprintsisevenpresentedasthe

coreone:inthismethod,itiscrucialtoberapidinthedevelopmentactivities,be

efficient,andtoproducegoodoutcomesasquicklyaspossible.Thiscorrespondsto

31

theDesignSprintframework,wherethemainideaistoproduceaviableprototypein

alimitedamountoftime(fivedays),andmanyoftheactionsduringeachofthefive

daysarealsoputundercertaintimelimits.Inaddition,thisframeworkisalsocollab-

orative,similarlytotheideaoftheDesignSprint,whereworkishappeninginthe

team.Finally,agilemethodologiesplacenotmuchemphasistodocumentation,and

thereisnoneedinheavydocumentationintheDesignSprintframeworkeither,

sinceallideasarecollectedonawhiteboard,stickynotesandA4piecesofpaper

only.Therefore,interestinglyenough,asimilaritycanbeagainobserved,thistime

betweentheagilemethodsandtheDesignSprintframework(eventhoughtheAgile

methodologiesarecompletelydifferentfromthetraditionalones,whichaswellhave

similaritieswiththeDesignSprint).

3.CreativeproblemsolvingindesignthinkingandtheDesignSprint

Inthesubchapter3.4ofthisstudyithasbeendiscussedthatdesignthinkingisacre-

ativeandcollaborativeapproachtoinnovationandproblemsolving.GVDesign

Sprint,initsessence,hasthesameroots:italsototallyencouragescreativethinking

intheprocessofsolvingproblemsanddevelopingideasandproducts,anditempha-

sizedcollaborativeefforts.ThecreativepartoftheDesignSprintcanbeseen,for

instance,inthesketchingandprototypingprocesses,whereparticipantsneedto

createvisualandtangiblesolutions.Similarly,thesamemethodscanbedetectedin

theconceptofdesignthinking.Finally,bothinthedesignthinkingandtheDesign

Sprintframeworks,abigimportanceisalsoplacedonstrategicthinkingandplanning,

as,usually,businessmodelsarediscussedandstrategicproductdecisionsaremade

whenusingtheseframeworks.

Toconclude,eventhoughsoftwaredevelopmentmethodologies,designthinking,

andGVDesignSprintareessentiallydifferentconcepts,they,apparently,sharea

numberofsimilarcharacteristics.WhiletheDesignSprintmethodinthemostcases

doesn’tincludealotofcodingprocesses,itsnaturecanstillbecomparedtothetra-

ditionalandagilemethodologiesoftheactualsoftwaredevelopment.Atthesame

time,itisalsocomparabletotheideaofdesignthinking,whichfallsinacompletely

differentcategoryfromsoftwaredevelopment.ItcanbethussaidthattheDesign

Sprintframeworkhascombined“thebestfromthetwoworlds”,meaningthatithas

32

thestructure,logic,andrapidnessofsoftwaredevelopmentmethods,andthecrea-

tivityandstrategicapproachofdesignthinking.

4Results

Theresultsofthisstudyareconfidentialuntil12.11.2027.Theconfidentialityofthis

studyisagreedbetweenthethesisauthor,JAMKUniversityofAppliedSciences,and

RoboTechnologiesGmbH.TheresultsoftheresearchcanbefoundinAppendix1.

5Conclusions

Theconclusionsofthisstudyareconfidentialuntil12.11.2027.Theconfidentialityof

thisstudyisagreedbetweenthethesisauthor,JAMKUniversityofAppliedSciences,

andRoboTechnologiesGmbH.TheconclusionsoftheresearchcanbefoundinAp-

pendix2.

6Discussion

Thediscussionofthisstudyisconfidentialuntil12.11.2027.Theconfidentialityofthis

studyisagreedbetweenthethesisauthor,JAMKUniversityofAppliedSciences,and

RoboTechnologiesGmbH.ThediscussionoftheresearchcanbefoundinAppendix

3.

33

References

Abrahamsson,P.,Salo,O.,Ronkainen,J.,&Warsta,J.2002.Agilesoftwaredevelop-mentmethods:ReviewandAnalysis.TechnicalResearchCentreofFinland,VTTPubli-cations.

Aguinis,H.,Henle,C.A.2004.EthicsinResearch.InRogelberg,S.G.(Eds.)HandbookofResearchMethodsinIndustrialandOrganizationalPsychology.Oxford,BlackwellPublishing,34-57.

Awad,M.A.2005.Report.AComparisonbetweenAgileandTraditionalSoftwareDe-velopmentMethodologies.TheUniversityofWesternAustralia,SchoolofComputerScienceandsoftwareEngineering.

Beck,K.1999.EmbracingChangewithExtremeProgramming.IEEEComputer,32,70-77.

Boehm,B.2000.Specialreport.SpiralDevelopment:Experience,Principles,andRe-finements.CarnegieMellonUniversitySoftwareEngineeringInstitute,Pittsburgh,PA.

Boehm,B.W.1988.ASpiralModelofSoftwareDevelopmentandEnhancement.IEEEComputer,21,61-72.

Braude,E.J.,Bernstein,M.E.2016.SoftwareEngineering:ModernApproaches.2nded.WavelandPress,Inc.

Carmines,E.G.,Zeller,R.A.1979.ReliabilityandValidityAssessment.SAGEPublica-tions,Inc.

Creswell,J.W.2014.ResearchDesign:Qualitative,Quantitative,andMixedMethodsApproaches.SAGEPublications,Inc.

Eriksson,P.,Kovalainen,A.2016.QualitativeMethodsinBusinessResearch:APracti-calGuidetoSocialResearch.SAGEPublications,Inc.

Fairbanks,G.2010.JustEnoughSoftwareArchitecture:ARisk-DrivenApproach.Mar-shall&Brainerd.

Gill,A.Q.2014.HybridAdaptiveSoftwareDevelopmentCapability:AnEmpiricalStudy.JournalofSoftware,9,2614-2621.

Golafshani,N.2003.UnderstandingReliabilityandValidityinQualitativeResearch.TheQualitativeReport,8,597-606.

Ionel,N.2008.CriticalanalysysoftheScrumprojectmanagementmethodology.An-nalsoftheUniversityofOradea,EconomicScienceSeries,17,435–441.

Kaur,R.,Sengupta,J.2011.SoftwareProcessModelsandAnalysisonFailureofSoft-wareDevelopmentProjects.InternationalJournalofScientific&EngineeringRe-search,2,1-4.

Kimberlin,C.L.,Winterstein,A.G.2008.Validityandreliabilityofmeasurementin-strumentsusedinresearch.AmJHealthSystPharm,65,2276.

34

Knapp,J.,Zeratsky,J.,&Kowitz,B.2016.Sprint:HowtoSolveBigProblemsandTestNewIdeasinJustFiveDays.NewYork:Simon&SchusterPaperbacks.

Kothari,C.R.2004.ResearchMethodology:MethodsandTechniques.2nded.,Rev.ed.NewAgeInternational(P)Ltd.,Publishers.Stringer,E.T.2014.ActionResearch.4thed.SAGEPublications,Inc.McNiff,J.,Whitehead,J.ActionResearch:PrinciplesandPractice.2nded.London:RoutledgeFalmer.

Lindstrom,L.,Jeffries,R.2004.ExtremeProgrammingandAgileSoftwareDevelop-mentMethodologies.InformationSystemsManagement,24,41–52.

LoBiondo-Wood,G.,Haber,J.2014NursingResearch:MethodsandCriticalAppraisalforEvidence-BasedPractice.8thed.Mosby,Missouri.

Modi,H.S.,Singh,N.K.,Chauhan,H,P.2017.ComprehensiveAnalysisofSoftwareDevelopmentLifeCycleModels.InternationalResearchJournalofEngineeringandTechnology,4,117-122.

Moroni,I.,Arruda,A.,Araujo,K.2015.Thedesignandtechnologicalinnovation:howtounderstandthegrowthofstartupscompaniesincompetitivebusinessenviron-ment.ProcediaManufacturing,3,2199-2204.

Mucha,H.,Nebe,K.2017.Human-centeredtoolkitdesign.InHCITools:StrategiesandBestPracticesforDesigning,EvaluatingandSharingTechnicalHCIToolkits.WorkshopatCHI2017,Denver,USA.

Munassar,N.B.A.,Govardhan,A.2010.AComparisonBetweenFiveModelsOfSoft-wareEngineering.InternationalJournalofComputerScienceIssues,7,94-101.

Petersen,K.,Wohlin,C.2010.Theeffectofmovingfromaplan-driventoanincre-mentalsoftwaredevelopmentapproachwithagilepractices.Anindustrialcasestudy.EmpiricalSoftwareEngineering,15,654–693.

Pressman,R.S.2005.SoftwareEngineering:APractitioner'sApproach.6thed.McGraw-Hill.

Razzouk,R.,Shute,V.2012.WhatIsDesignThinkingandWhyIsItImportant?ReviewofEducationalResearch,82,330–348.

Ruparelia,N.B.2010.SoftwareDevelopmentLifecycleModels.ACMSIGSOFTSoft-wareEngineeringNotes,35,8-13.

Sánchez-GordónM.,O’ConnorR.V.2016.Understandingthegapbetweensoftwareprocesspracticesandactualpracticeinverysmallcompanies.SoftwareQualityJour-nal,24,549-570.

Schwaber,K.1995.ScrumDevelopmentProcess.OOPSLA’95WorkshopProceedings,117-134.

Sommerville,I.1996.SoftwareProcessModels.ACMComputingSurveys,28,269-271.

35

Sommerville,I.2011.SoftwareEngineering.9thed.PearsonEducation,Inc.

SpriteCloud,n.d.WaterfallModelofSoftwareDevelopment.PageonSpriteCloudwebsite.Accessedon4thofJuly2017.Retrievedfromhttps://www.spritecloud.com/2011/06/software-lifecycle-consultancy/waterfall/

TetuanValley.2017.WhentodoaDesignSprint?PageonMediumwebsite.Ac-cessedon4thofOctober2017.Retrievedfromhttps://medium.com/tetuan-valley/when-to-do-a-design-sprint-88e1e3355f05

TheDesignSprint.N.d.PageonGoogleVentureswebsite.Accessedon22ndofJuly2017.Retrievedfromhttp://www.gv.com/sprint/

Thoring,K.,Müller,R.M.2011.UnderstandingDesignThinking:AProcessModelbasedonMethodEngineering.InInternationalConferenceonEngineeringandProd-uctDesignEducation,CityUniversity,London,UK.

Tschimmel,K.ConferencePaper.DesignThinkingasaneffectiveToolkitforInnova-tion.InISPIMConferenceProceedings.Manchester:TheInternationalSocietyforProfessionalInnovationManagement(ISPIM),1-20.

Tsui,F.,Karam,O.,Bernal,B.2016.EssentialsofSoftwareEngineering.4thed.Jones&BartlettLearning.

Yin,R.K.2011.QualitativeResearchfromStarttoFinish.NewYork:TheGuilfordPress.

Zuber-Skerritt,O.2001.ActionLearningandActionResearch:Paradigm,PraxisandPrograms.InSankara,S.,Dick,B.andPassfield,R.(Eds),EffectiveChangeManage-mentthroughActionResearchandActionLearning:Concepts,Perspectives,ProcessesandApplications.SouthernCrossUniversityPress,Lismore,Australia,1-20.

36

Appendices

Appendix1. Results(19pages)

Confidentialuntil12.11.2027.

Appendix2. Conclusion(4pages)

Confidentialuntil12.11.2027.

Appendix3. Discussion(4pages)

Confidentialuntil12.11.2027.

Appendix4. ThedevelopedprototypeofasoftwareproductduringtheDesignSprintatRoboWunderkind(8pages)

Confidentialuntil12.11.2027.