An Agile Implementation of SeRUM

Transcription

1 An Agile Implementtion of SeRUM Michele Gnnon John Hopkins University Applied Physics Lborry Johns Hopkins Rod Lurel, MD AbstrctIs Agile wy cut corners? To some, use of n Agile Softwre Development Methodology hs negtive connottion "Oh, you're just not producing ny documenttion". So cn tem with no experience in Agile successfully implement nd use SCRUM? This pper explores fundmentls of SCRUM s well s how this Agile development methodology hs been implemented on project t Johns Hopkins University Applied Physics Lborry. It will review devitions mde from trditionl SCRUM frmework, mngement of project using stndrd SCRUM rtifcts such s Product Bcklog, Sprint Plnning, Dily Serum meetings, Sprint Reviews, Sprint Retrospectives, metrics nd documenttion s well s integrting use of Knbn bord nd pir progrmming methods from Extreme Progrmming (XP). In ddition explining "wht's" nd "how's" of project implementtion, it will exmine mny chllenges nd successes encountered. 1. INTRODUCTION TABLE OF CONTENTS 2. THE SCRUM PROCESS 3. IMPLEMENTATION 4. CHALLENGES 5. RESULTS SUMMARY... REFERENCES BIOGRAPHY INTRODUCTION It is inevitble tht re will be chnge on ny softwre project, so why not pln for it? serum is n itertive softwre development methodology tht utilizes n "inspect nd dpt" frmework. re is stndrd set of roles nd rtifcts s well s n officil SeRUM Guide. But s we ll know, no two softwre development projects ever seem be sme. So why not be gile in implementtion of n gile softwre development methodology? With guidnce of project mnger dedicted success of project s well s use of n gile methodology nd tem hving never used SeRUM before, is it possible succeed? Yes! 2. THE SCRUM PROCESS serum is frmework for developing nd sustllllllg complex products nd consists of following rtifcts, roles, nd events. [1] SeRUM Tems deliver products itertively nd incrementlly, mximizing opportunities for feedbck. [1] SCRUM Artifcts Figure 1 SeRUM Process [2] Wri.i"G inow't'wtnt of.oftw... SeRUM hs two rtifcts: Product Bcklog nd Sprint Bcklog. Product Bcklog is prioritized list of requirements for system. list cn include functionl nd nonfunctionl cusmer requirements s wen s technicl requirements. Sprint Bcklog is set of items from Product Bcklog tht tem hs committed complete during single itertion or Sprint. serum Roles serum hs three roles: Product Owner, Tem Member, nd SeRUM Mster. Product Owner is single person who represents interest of stkeholders. It is sole responsibility of Product Owner prioritize Product Bcklog. tem members include cross functionl group of people responsible for delivering n end end product t end of ech itertion or Sprint. SeRUM Mster coches tem in following SeRUM process. SCR UM Events Sprint Plnning Meeting gol of sprint pll1l1ing is identify gol of Sprint, wht will be done in Sprint, nd how tht work will get done. [1] Product Bcklog is reviewed determine which items will be ddressed in this Sprint. gol of Sprint identifies why Sprint is being conducted. Spring Bcklog is n creted bsed on items pulled from Product Bcklog be completed in this Sprint. Sprint Bcklog $31.00 «J2013 IEEE

2 hs tsks broken down in units of one dy or less nd tem selforgnizes determine how se tsks will get done. [1] Dily ScrumA timeboxed Dily Scrum (or stnd up meeting) is conducted or held every dy in which ech member of tem nswers three questions: Wht did you ccomplish yesterdy? Wht will you commit complete dy? Do you hve ny impediments? Any identified impediments re resolved immeditely within tem or esclted by SCRUM mster for resolution s soon s possible. Sprint ReviewAt end of ech sprint re is Sprint Review meeting where tem hs chnce present stkeholders wht ws done in Sprint. During this meeting ttendees collborte on wht ws done nd wht do next. [1] Feedbck is collected nd product bcklog is updted include items be completed in future Sprints. Sprint Retrospective Sprint Retrospective is held fter Sprint Review nd prior next Sprint Plnning Session. This is opportunity for SCRUM Tem identify things tht went well nd not so well during Sprint. meeting results in one or more identified improvements tht cn n be incorported in future Sprints. This encourges nd ensures continuous improvement throughout process. 3. IMPLEMENTATION Following bove SCRUM rules tem set out develop complex softwre. Softwre Pwpose purpose of softwre this tem ws developing ws remotely monir nd control equipment tht builds connection from mnned worksttion stellite remote site which houses vrious components. re is COTS product which provides core functionlity. Tem Composition tem consisted of 1 Product Owner, 6 softwre developers, 5 network engineers, 4 testers, 2 IA representtives, I Project Mnger, nd 1 SCRUM Mster. Tem members rnged in lloction project of 50% 100%. Becuse re were tem members with less thn 100% lloction, Sprints were scheduled lst greter thn 30 dys. In ddition one tem member ws not colocted with rest of tem. DilyScrum Dily Serums were held every dy t 9m in tem lb. Initilly Dily Serums included just softwre engineers. se meetings typiclly resulted in illlnswered questions which would require follow up with or tems. It becme beneficil hve ech of or tems represented t Dily Serum. Becuse of lrger tem size, Dily Serums were timeboxed 30 minutes versus 15 minutes. Originlly tem mde one pss round tble nswer 3 questions in Dily Serum. re were typiclly dditionl, beneficil discussions held t Serum. This would result in longer meeting or tem members following discussion being rushed through ir 3 questions. After severl sprints tem relized it ws necessry hve two psses; one for 3 questions nd second for ny furr discussion or questions. This ctully resulted in meetings being shorter. Product Bcklog Product Bcklog ws written with Product Owner nd or stkeholders in form of user sries. A user sry is description of feture of softwre written from perspective of n end user. [3] formt for user sries is "As [nme of end user or role] I wnt [simple description offunctionlity] so tht I hve [business vlue]." user sries reflect requirements for softwre. Ech user sry is ssigned Sry Points by development tem. Sry Points re simply number used express complexity of user sry. Sry Points re used during Sprint Plnning ssist in determining number of user sries tht cn be completed in Sprint, s well s for cpturing metrics on SCRUM Tems velocity. Product Bcklog for this project strted with 53 user sries nd 2200 sry points. Sprint Plnning After completing Product Bcklog or immeditely following Sprint Retrospective for Sprint, plnning for next Sprint ws strted. Sprint Plnning typiclly lsted between six nd eight hours, broken up over two four meetings. Spring Plnning strted with set of user sries tht hd similr me nd tht when grouped ger could result in demo ble product. Ech selected user sry ws reviewed identify list of detiled tsks complete sry. Ech of tsks ws written on sticky note, which would ultimtely be dded Knbn bord s "To Do" tsk. After ll tsks for Sprint hd been defined second pss cross ll of tsks ws mde. During this pss hour estimtes nd priority were ssigned ech tsk. EstimtingEstimting lwys seems be difficult process with ny softwre development methodology. This strts with decomposition of tsks n pproprite 2

3 In Sprints 3 nd 4, decomposition of tsks becme esier for level. In first Sprint tsks were decomposed very low leve l. As multiple tsks could be completed within piece of code, mu ltipl e tsks were worked by single tem member in prllel. In Sprint 2 tsks were no t decomposed sme low level, which resulted in need decompose tem s y hd seen result of poor tsk decomposition. gol of decomposition nd estimtion ws keep ech tsk unde r 20 hours s tsk gret thn 20, hours shou ld be broken down furr. tsks even furr before y could be strted. SPRINT BURN DOWN CHART f ; ::c Dys in Sprint Figure 3 Sprint Burndown Chrt

4 of TsksTo ensure tht most criticl were ddre ss ed first, tem begn prioritize tsks s prt of sprint plnning. Tsks were given priority of one three. Priority 1 tsks were criticl success of Sprint. A priority 3 tsk could be deferred from Sprint should mount of work in Sprint exceed cpcity of tem. Prioritiztion tsks Assigning Tsks s tem methodology. tsks becme process of tsk more in using TD this J(q,1Lb...TOIJl Following Spring Plnning for Sprint I ll were ssigned tem memb er. In subsequent sprints just n initil set of tsks were Figure 4 s tsks were often first Sprint. ssigned ressigned multiple times throughout lwys continuous or improvements improvements being note d, m d e. during In Test, Sprint K nbn Bord where tsks were in Review, Redy for & Tested. Originlly re ws just one big In Progress se ctio n on Knbn bord. tem decided split this re up so ech tem member hd ir own se c tio n of bord. This wy everyone could esily see tsk lod on ech tem member. Sprint Review SCRUM Mster creted nd mintined Sprint B cklo g nd Sprint Bumdown Chrt. S print Bcklog, s illustrted in F igure 2, includes ll tsks be completed in S print s well s tl hour estimtes nd hours re mini ng on ech tsk. With this informtion one cn grph completed nd remining hours in Sprint in Bumdown Chrt, s illustrted in Figure 3. Sprint red line in chrt, incorported s "idel" Sprint Review meeting ws scheduled t be ginning of ech Sprint nd ws open ny stkeholder. A dry tem memb e r or of review demonstrtion ws run typiclly s c heduled bout week prior Sprint Review meeting. demonstrtion of Sprint ccomplishments ws by tem members, ech presenting fetures or functions y developed. Prticipnts were encourged sk questions nd mke comments t ny Bcklog nd Bumdown Chrt re reviewed nd updted conducted bum line. This llows tem esily guge wher y re behind or point during meeting. hed of schedule. Following Knbn demonstrtion completion of user Sprint were ssessed. If user sry remining or missing functionlity nd sries identified for ws not fully complete new user sry ws creted tem used Knbn chrt, illustrted in Figure 4, trck on ctegories were dded better trck Sprint Burndown Chrt every dy. tsks ir lifecycle, such s Awiting Code Plnning for Sprint 2 tem identified c ertin tsks tht would need hppen with every user sry, thus bse set of tsks for ech user sry ws c re ted. Exmples of se tsks inc lud e d "crete detiled use cse," "crete design documenttion," nd "crete test cse". process improvement, conveys Knbn Bord Exmple included To Do, In Progress, nd C ompl eted. Additionl dpt frmework, s well s Sprint Retrospective, re ddition originl ctegories of Process ImprovementsWith use of n inspect nd ws.hj KY IIOTf!l \I'.sCIU8E ssignment chnged experienced &ET M AUI A8M HANM' cpture progress of ech tsk throughout Sprint. This provided visul ny point in time representtion of Product Bcklog where tem ws t tem continully refined use of for ese of use nd effectiveness for ws updted. A tem member would cpture ll comments nd discussion p o ints so it could nd ws displyed prominently in lb. ultimtely be determined Knbn Bord if ddi ti onl tsks, de fects or user sries were required. tem. Sprint Retrospectives Sprint Retrospective ws one hour timeboxed meeting discuss how Sprint went, similr identifiction of lessons lerned. During Sprint Retrospective re is period of llotted for everyone write down time things tht y felt went well or not so well during Sprint. After time ws reched, re ws round robin discussion go through ech item tht ws meeting, fter every item 4 written down. ws discussed, At end of tem would

5 collectively identify process improvements of next Sprint. be implemented i mmeditely t strt Person A Person B Person C Person D Pers on E Person F Reminin Totl: S print Retrospectives were highly effective for this tem ws open, honest, nd professionl when identifying nd discussing pics tht cme up t meeting. Mny process improvements were implemented throughout project. Exmples of items cptured during Sprint Retrospective include: tem. tem ws flexible in ssignment of tsks nd "rolled with punches" 1344 Figure 5 tem collective estblished trust Tem Cpcity Metric d feeling of n success tl effort tem is cpble of in bsed on hisricl dt. Velocity cn be mesured VelocityVelocity is Poor communiction with network Esti mtes sprint nd test tems in user sries or sry points. (re sulted in process improvement) mesured fter re relible metric over Velocity cn only be is hisricl dt nd becomes more time. Need stremline code reviews, s y were cumbersome Some (resulted in process improvement) Definition of Done overlooked (resulted in process tsks re Sry Point$ Completed by Sprint being improvement). tir " l Metrics nd result of process is successful Sprint. two essentil metrics for this process were Cpcity nd Metrics re necessry ssist with Sprint Plnning ensure Velocity. CpcityCpcity is tl number of hours vilble for work between strt nd end of Sprint. eqution used crete person's cpcity for this implementtion Figure 6 ws: (Workdys in sprint Pllmed out of office) Alloction project *.75 This metric tkes in ccount tht Tem Velocity Metric Documenttion * so me tem members Most documenttion ws creted on JustinTime bsis nd re were few forml templtes. Checklists were creted nd used for ensuring completed tsks met tems Definition of Done. documenttion reposiry included re of office. In ddition, it ssumes tht ech tem member spend 75% of ir llocted time on project on tsks in Sprint Bcklog. This llows time for breks, trining n unplnned out of office, or corporte meeting nd events. not llocted 100% project nd scheduled time out folder structure under ech Sprint for documenttion be This included code review documenttion, Dily minutes, d emo scripts, design documents, use cses, nd checklists. A user guide, style guide, nd instlltion procedures were updted with ech Sprint. cptured. Serum, tl tem cpcity ws sum of ech individul tem member's cpcity. 4. CHALLENGES will occur on ny softwre development project. benefit of using n Agile Development Methodology is tht with continuous inspecting nd dpting process improvements cn be mde s needed nd re plnned for Chllenges, within ech Sprint. Tem Only one of six tem members ws llocted 100% project. or tem members were llocted 50%, 5

6 60%, or 70% project. Ech tem member mnged ir own time cross ir projects. At beginning of project it ws decided tht tem members' or project could not be stted s n impediment. As tem met every dy for Dily Scrum it ws cceptble sy tht y hd completed only few hours of work or tht y were unble work on project for tht dy. If re were criticl tsks be completed tht dy, tsks were ressigned. re were times when tem members stted tht y were working more hours on project thn y were llocted. This ws ddressed s prt of Sprint Plnning. entire tem prticipted in Sprint Plnning nd mde collective commitment meet Sprint gol by Sprint Review dte. Through this commitment nd with ssistnce of Dily Serum meetings tem members hd become good with ir own time mngement. Anor chllenge for tem ws chnges in tem composition from Sprint Sprint. This is not desirble, but project ssignments would chnge for vrying resons nd occurred frequently throughout first few Sprints. This mde identifying tem velocity metric difficult. This ws ddressed by ensuring tl hours for tsks ssigned Sprint were less thn tem cpcity nd by Sprint Bcklog tsk prioritiztion. Priority 3 tsks were identified s tsks tht could be deferred future Sprint if needed. A third chllenge for tem ws tht one tem member ws not colocted with rest of tem. He ws involved in every meeting nd mny discussions vi phone; however body lnguge nd emotion re not esily conveyed vi phone converstion. serum Mster would convey some of this informtion over phone in meetings nd through follow up converstions, but this is not chllenge esily overcome. A fourth tem chllenge ws ech tem member's menbility chnge. Some softwre developers re set in ir wys nd hve difficulty dpting multiple improvements being mde. Ech tem member must be honest with tem nd open frequent chnge. Also, s new tsks were creted tem members needed ccept tht lthough se tsks re being identified y my not fll within gol of current Sprint. se tsks would be filed under new or existing user sry nd be reviewed nd possibly implemented in future Sprint. Dily Scrum Softwre developers re not typiclly fns of meetings. This ws evident in some of erlier Dily Serum meetings, s tem ws lerning process. After completing Sprint nd strting second Sprint, purpose nd benefits of this meeting becme pprent tem. In ddition, through experience tem lerned how quickly ddress 3 questions, wht wrrnted dditionl discussion during SeRUM nd wht pics should be deferred smller discussion immeditely following serum or follow up meeting lter in dy. Sprints length of Sprints ws chllenge. With tem members being llocted less thn 100% project Sprints were typiclly longer thn 30 dys nd ir durtions vried from Sprint Sprint. It is difficult ensure tht Sprint is not o long or o short. Longer Sprints cn result in difficulty with motivtion nd stying focused; s well s lrger set of tsks, which could be potentilly overwhelming. Shorter Sprints resulted in more ttention being pid schedule nd tsks tht hd yet be strted. Tool Setup nd Configurtion Tsks in Product Bcklog nd ultimtely tlle Sprint Bcklog did not include ol set up nd configurtion or product instlltion. In initil Sprints this ws chllenge, becuse umted builds nd unit testing ws desirble. For second Sprint new user sry ws creted ddress Relese Engineering. This user sry ws broken down in tsks tht included product instlltions nd configurtion, s well s infrstructure tsks nd test hrness cretion. Portions of this user sry were executed over severl Sprints, so s not impct qulity or diminish number of end user requirements in given Sprint. "/n Sprint" Testing It ws chllenge conduct testing of Sprint within Sprint. A development environment ws mintined where softwre developers creted nd compiled code. A test environment ws mintined which hd content of lst Sprint. Testers could not relibly test in development environment due instbility nd continuous chnging of environment. Thus, testing ws lwys Sprint behind development. Procurement Delys As purpose of softwre being developed ws monir vrious pieces of equipment, delys in procurement nd receipt of equipment presented chllenge tem. Becuse of this some user sries were broken in wht tem clled "verticl slices". A verticl slice ws defmed s n implementtion of feture cross single piece of equipment or subset of tl pieces of equipment be monired. S.RESULTS ultimte success, of course, is finl working product tht meets end user requirements. Ech Sprint however ws success in tht it resulted in functionlity tht could be demonstrted stkeholders. 6

7 re were lso successes in imp lementtion of SCRUM. documenttion ws being updted, unit tests were being creted nd executed, nd code reviews were b eing conducted. checklist ws posted in lb nd tem would ensure tht ll items were incorported resulting in higher qulity code s well s supporting mterils. Working s Tem Dily meetings, collbortion, tem commitment, p ired or tem progrmming, honest discussion, nd vrious or tem buil ding ctivities resulted in tightly knit tem environment. Through this strong sense of tem nd shred commitment gile processes s eemed hppen umticlly. T sks could esily shift from one tem member nor, unit nd integrtion testing becme 6. SUMMARY possible introduce nd succeed using new Agile Softwre Development Methodol ogy? Of course it is. Will re be chllenges long wy? Of course re will. Will re be chnges nd improvements tht must be mde long wy? Yes. Is it better t o understnd thi s from project inception nd p ln for se things l ong wy? Is it esier, bugs were identified nd resolved by nyone nd everyone, potentil problems or pitflls resolved collectively, experience, Sprint were discussed nd reviews code P lnning nd were estimtion positive improved Ab solutely. proj ect nd collbortive tem nd test tem re j ust throughout durtion of work between development smll set of result of strong gile Three key requirements SCR UM tem. n Sprint Plnning Agile improved throughout durtio n of tem becme c omfortble with process nd ech or, s well s ir collective gol, Sprint Plnning discussions were more honest nd thorough. This resu lte d in better estimtes, properly de compo se d tsks, nd As A well defined bseline set SCRUM rules of or Supportive mngement nd stkeholders educted in gile methods relistic set of chievble user sries. Tem members tht Sprint Review re open minded nd menbl e chnge. only constnt in most softwre development is chnge. It is inevitble tht re will tem suc c e s s. Ech member of tem presented port ion of product y developed. This llowed for everyone on execution of Sprint Review meeting ws be chnge on ny softwre proj ect, so why not pln for it? re implement n Agile Development is no "right" wy Methodology. Py ttention wht wo rks nd wh t does not work nd mke dj ustments s nee d e d Inspect nd Adpt. Be Agile. tem prti cipte nd tke pride in ech incrementl de liv ery successful implementtion of frmework, such s Sprint P lnning proj ect. for Development Methodology include :. Sprint Retrospectives REFERENCES re is lwys room improve. Effective communiction is es sentil tem ' s s ucce ss. This, long with professionlism, self evlution, honesty, nd openness llowed tems S print Retrospective beneficil success of tem. retrospective ws be [ 1 ] officil Scrum highly gol of ech identify 3 process improvements. [2] This gol for tem. Process improvements were esily identi fi ed nd implemented. And if process ws n esy tem ws ble nd productivity. s needed. Due se retro spectives wikinledi. org/wikilf ile: S crum process. s yg [3 ] gilemodeling. comlrtifcts/usersry.htm improvement did not meet desired gol, it ws mended inlprove qulity, cpbility, BIOGRAPHY Improved Productivity Michele Gnnon received B.S. in Stte University, in She hs worked t Johns Hopkins Un iversity Applied Physics lb for two yers nd with Agile Softwre Development Methodologies for over n ine As ny identified i mpediment s re removed on dily bsis, tem is ble focus ir efforts on productive tsks resulti ng in incre sed productivity. Computer Science from Improved Qulity With do cumented Definition of Done on nd sprint level, re is lwys focus stte tht some thing ws Guide: www. s crum. orwscrumguides.spx "Done". on tsk, user sry, yers. wht it ment This ensured throughout process stndrds were being tht followed, 7 Towson