Methods used in scaling Scrum: An experience report
1 like746 views
While the business context of a project decidedly influences the success of any software development project, project execution matters as well. Scrum, like most agile software development methods, is originally intended for the use of a small team. Larger companies in the software development field have a need to scale these methods to larger environments, often a global operation. This presentation describes a two-year project involving over a hundred people across the globe directly. The perspective is that of practical methods that helped F-Secure to keep the project moving against many difficulties and uncertainties. Organizational observations are also included. These areas will be touched: - Organizing the project staff into teams and projectmanagement - Large joint planning sessions - Backlog management and tooling - Communication about backlog - Project governance bodies - Project steering and communication - Pushing responsibility down - Integration - Test automation status radiators - Testing - Bug handling process - Beta releases - Development environments - Dealing with disruptions, setbacks, direction changes and surprises This session will be most valuable to those who are working with real software development projects and want experienced advice on methods that have been successfully applied in global commercial context. The audience is expected to be familiar with Scrum and those who know Scrum well will benefit the most. As the topic is very wide not much time will be used on each area. The focus will be determined by the interest of the audience. Interactive discussion will be encouraged during the session.
Methods used in scaling Scrum: An experience report
- 1. F-Secure Corporation, Towo Toivola, director of R&D Global Methods This presentation is dedicated to the survivors of the IS11 project.
- 25. So, what to concentrate on? Clear, frequent, systematic, high-quality human-to-human communication about Backlog Actions Situation Quality Expectations Improvements Make sure you place reality and estimates way above needs and wishes of the organization. Maintain quality in your software and your operations, it is cheaper and faster than not doing it.
Editor's Notes
- #2: This is an experiencereport of a, in my world, prettywellexecutedlarge-scaleScrumin verydemandingcircumstances.To some of you, the practicesdescribedheremaysoundbasicoroldfashioned. Pleaserememberthatfor otherstheymaybe science fiction.Also, bear in mindthattheory is theory, and this is practice.Try and find the partsthataremostinteresting to you.
- #3: About950 peopleworld-wide, about350 in R&D. HQ inHelsinki, 5-6 DCs.Internetsecurity software, backup, sync, othersMillions and millions of end-users
- #4: I willattempt to speak in straightforwardplainlanguage.I willdosomegeneralization andstereotyping to make the messagecrisper. I am alsoattempting to keepyouawake. Somemaygetupset. Thismaybegood as well.Whenever I use a termthatyoudontunderstandorotherwisesaysomethingthatsoundsstrange, pleaseask for clarification.I believethatwewillgainmost out of a interactive session, sofeelencouraged to raiseyourhand and interrupt. I willreserve the right to police the situationhowever.
- #5: There is muchmorecontentherethanwehavetimeto cover.IwillexpectthatyouarefamiliarwithScrum. Ifnot, ask the person next to you.Wheneversomethingcomesupthatignitesyourinterest, pleasetell me to digdeeperinto that.Youare in charge of howthistime is spent, soyouneed to governhowmuchtimeweuse on differenttopics. Itsalsowise to leavesometime and questions in reserve for the end.By the way. Prettymuchall the picturesarekosher, sofeelfree to askaboutthem as well.Most of the slidescanactuallytake the entirepresentationtime.
- #6: The projectthat I am about to describewasnot a great business success. This is due to the projectpreconditions and environment.Thispresentationfocuses on the projectexecutionthattried to copewith the situation.Itneeds to beunderstoodthatno executioncanmakeup for an impossiblecontext.
- #7: Now, lets look at how the projectwas..
- #8: The mission was to make a completely new software system, includingclientproducts, backends, business models, architecture, youname it.New technologies: QT, .MSI, backendstuff, Alluser/partnerfunctionalityneeded to beon-parwith the oldone.Manydetails and somesignificantlargerelementswereunclearwhenstartingwork and evenduring the firsthalf a year of the project.Weemployednew planningmethodsas wefelt the existingoneswerenotup to the task (I agree).Weemployedournew R&D process.Wehad a largeamountof new functionalityspecified, and I mean a lot, and allwasmust-have.Wehadabout 7 months for the projectthatactuallytook a couple of yearswithhighlymodifiedscope.
- #9: The new methodsincluded a new companyagileprocessthatwasbasically a slightlymodifiedscaledscrumwithsomeadditionalroles, engineering practicesstandard, and abstactionlevels for differentsizes of backlogitems.
- #10: Allpossiblepotential for problems:DifferentlanguagesDifferentculturesSubcontractor(s)Differentmaturity as organizationDifferentquality of engineeringRadicallydifferenttime-zonesThesehadneverworkedreallytogetherbefore.Integration of a recentaquisitionwasstillunderway.Morethan100 ppl, between8-13 scrumteamsat alltimes.
- #11: Clear:Teamsare in teamrooms, no distributedteamsSubcontractorswereeitheremployed as wholeteamsordistributed to sit in existingteamrooms to join existingteams.Teamsneed to beresponsibleof allconsequences of whattheyproduce Line management separatedfromprojectsteeringseparatedfromrequirementsmanagamentThe organizationwasfocused on projectexecution, to hellwithline management.
- #12: Wetook into use a new backlog management tool(versionone) whichwelaterchanged to another (jira + greenhopper).Thiswasgood, as moread-hocmethodsprobablywouldnothaveworkedwiththatmass.Wealsogotgoodvisibility into progress (real) and howmuchrequirementschanged and howmanywereadded.The poorquality of requirementswasalsovisible to thosewhocouldsee it.Project reportingwasbased on backlog.The toolingwouldhaveenabled a constructivedialogaboutwhat is mostimportant, whythingsaredone, and how to maketrade-offs.
- #13: In order to describesuch a largeamount of work for differentaudiencesweemployed 4 levels of backlogitemsizes:Task (hours)Story (days, fits in sprint)Feature (weeks, fits in release)Epic (visionarycontainer, doesntfitanywhere)Later on weadded business goal or roadmapitem that is biggerthan a feature butmorerelevant for biz and customersthanepic.Main communicationmethodaboutexpectations, requirements, and allsuchwasface-to-facecommunication, especially in R&D. Thiswasdone to increaseunderstanding and enabledialogue.
- #14: Similarly to a sprintplanningwereallteammemberscooperate to figure out the upcomingsprint, the projectteamsgathered to Business Iterationplanningevery 2-3 months to prepare for the next Business Iteration. Thispractisewasstartedwith the help of Dean Leffingwell. In this 2-3 dayworkingoff-sitemegameetingpeoplewerealigned, dependenciesfigured out, and initialplans made.DeathbypowerpointPlanningstartsHelpdesksbydifferentsupportfunctionsManagement availableIssuemitigationscrum-of-scrumsevery 2 hoursArchitecturemeeting at intervalsMidpointprogressreviewFinalplanreview
- #15: Thereweremanydifferentcombinations of projectsteering/managemententitiesduring the lifespan of the project.As a trendtherewasmuchmore management and control in the beginning and less in the end.
- #16: Inpractice the mostimpactfulprojectsteering and communicationhappened in daily scrum-of-scrumsthathappenedface-to-face as much as possible.To aidtheseweemployedStatus radiatorsTeleconferencingequipmentRules and guidelines on how to run the meetingsRolingEtherpad for multi-usermeetingminutesIn the meetingweGained a view to currentsituationfrommanyanglesSolvedsimpleproblemsquicklyorAgreed to a spinofforAgreedwhowillcontactwhoAsked for and offered helpBroughtupproblems and potentialsolutionsAgreed on actions
- #17: The directionhasbeen to moveresponsibility and authoritydown to the hands-onpeople. Thisshowswellwith the betareleasingdecisionsthatused to be made by PSG butwerelatergiven to SoS.In thispicturetherearevirtually no managers.Youcanalsosee the improvedtelecomequipment.
- #18: Multi-levelintegrationfrom single developer to team to project.Commonlyagreed and iterativelyimproved.Jenkins. One trunk. Lastknowngood. Release fromtrunk.
- #19: Performed in the teamsbyquality engineering specialistsCoordinatedmostlyby the teamsExploratorytestingestablishesqualityestimateTestautomationmonitorsbasicqualityNo systemtestingteam, no externaltestingteam.
- #20: Mandatorypart of large-scaleagileeffort, enablingcontinuousintegration, monitoringquality, iterativeimprovements and so on.Needs to beperformed in multipleabstractionlevels and for differentmaturitybranches of the product. Crucial for maintaining a near-shippablequality.Tooling is notrequired as youdevelop software for a livinganyway. Social mass is moreimportantthantechnicalmass.
- #21: The developmentenvironmentswerenotadvancedenough for the needs of thisproject, so the projectstafftookcharge and built a new generation of developmentenvironmentsthatwerequicklyadopted for globalcompanyuse. Ifyourtoolsareinsufficient, makebetterones.Fromindividualmachines to farm of vmware to dynamicallyprovisionedvirtualmachines in KVM.
- #22: Bugdecisionswerehandledbyhands-onstaff (according to a companyguideline), everyday. Decisionsweredemanded, ignoringbugswasnot an option.Bug countswerestillrising, so a policy of stop-the-linewasinvented (namedafter the famous Toyota practice).Priorities:FixnowfixnextsprintMove to backlogtrash
- #23: Initiallyweaimed to publishbetareleaseseverymonth, butitproved to betoodifficultsowestarteddoingitaftereverytwoweeksprint.Betareleaseswere a majorcontributor to stablequality, integration and internalcommunication. TP is believing.
- #24: Thisprojectsuffered an incredibleamount of disruptions, includingnumerouscompletedirectionchanges, scopechanges, schedulechanges, architecturechanges, staffingchanges, reorganizations, and evenlayoffs. Nevertheless the projectwasable to continuallymakeprogress and keep publishing working software. No meanfeat.
- #25: Nowtime for the reservequestions.
- #26: Someadvice,ifweget to this.