Comparing Ways to Scale Agile at LAST Conference 2014
•
44 likes•6,672 views
Session "Comparing Ways to Scale Agile" at the LAST Conference 2014 in Melbourne, Australia. These days organisations are looking for support to scale their Agile environment. There’s a difference between having one Agile team on its own, or to have several Agile teams providing value to the customer and interacting with each other. This session will give an overview and comparison of all the different Agile scaling approaches out there, e.g.: * Scaled Agile Framework (SAFe) * Evidence-Based Management (EBMgt) * Disciplined Agile Delivery (DAD) * Enterprise Transition Framework (ETF) * Large-Scale Scrum (LeSS) * ScALeD Agile Lean Development * Scaling Agile @ Spotify (SA@S) * Product Development Flow by Reinertsen (PDFbyR)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (16)
More from Bernd Schiffer
More from Bernd Schiffer (20)
Recently uploaded
Recently uploaded (16)
Comparing Ways to Scale Agile at LAST Conference 2014
- 1. Comparing Ways to Scale Agile BerndSchiffer LASTConferenceMelbourne11/07/2014
- 2. “ Acorepremiseofagileisthatthe peopledoingtheworkarethe peoplewhocanbestfigureout howtodoit.Thejobof managementistodoanythingto helpthemdoso,notsuffocate themwithSAFe. Ken Schwaber "unSAFe at any speed" by Ken Schwaber (06.08.2013, http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed )
- 3. “ Thisapproachfitsrightinwith therequirementsinCMMIML3for processtailoring.Itcouldbe straightoutofa1990stextbook onprocessengineering. David Anderson "Kanban - the anti-SAFe for almost a decade already" by David Anderson (31.07.2013, http://www.djaa.com/kanban-anti-safe-almost-decade-already )
- 4. “I’vejustwatchedapresentation that’smademesoangryit’s promptedmetowritemyfirst blogpostinages!…I’mnotafanof the“ScaledAgileFramework”to saytheleast.…Yukyukyuk! Neil Killick "The Horror OfThe Scaled Agile Framework" by Neil Killick (21.03.2012, http://neilkillick.com/2012/03/21/the-horror-of-the-scaled-agile-framework )
- 5. “ SomeonejustshottheAgilebrand inthebackofthehead… Chris Matts "Two Legs Good." by Chris Matts (30.08.2013, http://theitriskmanager.wordpress.com/2013/08/30/two-legs-good )
- 6. “ PutbrutallySAFeseemedtobePRINCEII camouflagedinAgilelanguage.…SAFeisnot onlyabetrayalofthepromiseofferedby AGILEbutisamassiveretrogradestep givingthemanagerialclassanexcuseto avoidanysignificantchange. Dave Snowden "SAFe: the infantilism of management" by Dave Snowden (25.03.2014, http://cognitive-edge.com/blog/entry/6238/safe-the-infantilism-of-management )
- 7. “ L.A.F.A.B.L.E-LargeAgile FrameworkAppropriateforBig, LumberingEnterprises Mike Cohn "L.A.F.A.B.L.E - Large Agile Framework Appropriate for Big, Lumbering Enterprises" by Mike Cohn (04.2013, http://lafable.com )
- 8. “ …containsalotof“processvoodoo”that willnotberequiredinmostcases.… confusinglycomplicatedframework…. SAFeheightenstheriskofjustapplying “lipsticktothepig”andnotdealingwiththe fundamentalchangesthatarerequiredin everyorganisation Peter Hundermark "Scaling Scrum to the Organisation" by Peter Hundermark (14.01.2014, http://www.scrumsense.com/blog/scaling-scrum-organisation )
- 10. OverviewThesearethescalingapproachesIexploredandcomparedsofar. SAFeinteractiveknowledgebasefor implementingagilepracticesatenterprise scale Agilelandscapeforenterpriseswith portfolioKanban,Scrumteams,and ExtremeProgrammingtechniques DeanLeffingwell +more AgileSoftwareRequirements byDeanLeffingwell ScaledAgileFramework it’s a idea peoplebehind this main book/article hierarchywiththreelevels:epicsonportfoliolevel,featuresonprogramlevel,stories onteamlevel minimumunitofpeopleistheAgileReleaseTrain(50-125persons) wantstohaveanswersupfrontforeverything(leadership,architecture,portfolio, teams,culture,etc.) allofthem,e.g.,businessowners,release trainengineer,productmanagers,system architects,UXprofessionals,development management,andmanymore roles key aspects http://scaledagileframework.com home SAFe ScaledAgileFramework some diagrams SAFeScaledAgileFramework DADagoverned,hybridapproachthat providesasolidfoundationfromwhichto scaleagilesolutiondeliverywithin enterprise-classorganisations Buildingonmainstreammethods istheDADprocessdecisionframework, providinganend-to-endapproachforagile softwaredelivery.ScottAmblerandMarkLines +more DisciplinedAgileDelivery byMarkLinesandScottAmbler DisciplinedAgileDelivery it’s a idea peoplebehind this main book/article people-first,learningoriented,hybrid,fulldeliverylifecycle,processgoaldriven, solutionfocused,risk-valuelifecycle,enterpriseaware definedlife-cycle(inception,construction,transition) mashesScrum,XP,Kanban,LeanStartup,Outside-insoftwaredevelopment,AgileData, AgileModeling(AM),UnifiedProcess primary(stakeholder,productowner, teammember,teamlead,architecture owner) andsecondary(specialist,domain expert,technicalexpert,independent tester,integrator) roles key aspects http://disciplinedagileconsortium.org home DAD DisciplinedAgileDelivery some diagrams DAD DisciplinedAgileDelivery DAD Exploratory Lifecycle Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org Observe & Measure Deploy Measure Productize Build a Little Envision Keep going Hypothesis Pivot Proven Idea Disproven Idea This lifecycle is followed by agile or lean teams that find themselves in startup or research situations, typically when their stakeholders do not understand what their potential user base wants. Development proceeds via a series of quick learning experiments designed to home in on what stakeholders actually want. This lifecycle is often a replacement for the Inception phase of other DAD life cycles About this lifecycle: Options Copyright 2014 Disciplined Agile Consortium DAD Continuous Delivery Lifecycle This lifecycle is best utilized by Product Teams. The Inception Phase occured in the distant past, and is, in fact, an historical artifact unless the product vision changes. The Transition Phase has become an activity rather than an explicit phase through automation and discipline. Supports DevOps by streamlining continuous delivery of con- sumable solutions to stakeholders. About this lifecycle: Work items are pulled when capacity is available to address them Replenishment modeling session Copyright 2014 Disciplined Agile Consortium Operate and support solution in production Enhancement Requests and Defect Reports Daily work Retrospective Demo Release solution Coordination Meeting Construction T Continuous stream of development Sufficient functionality New Work Feedback Learnings Strategy Production ready Delighted stakeholders Expedite Fixed Delivery Date Intangible New Features Business Value Options Expedite Fixed Delivery Date Intangible Work items are pulled when capacity is available to address them Replenishment modeling session Operate and support solution in production Enhancement Requests and Defect Reports New Features Initial Requirements Initial Architectural Vision Initial modeling, planning, and organization Daily work Retrospective Demo Release solution into production Coordination Meeting Construction Transition Continuous stream of development Stakeholder vision Sufficient functionality New Features Feedback Learnings Strategy Inception Production ready Delighted stakeholders Proven architecture Identify, prioritize, and select projects Envision the future This lifecycle is best utilized by mature teams who need to release regularly, leading towards a continuous delivery strategy using a Lean approach. Development activities (e.g. demos, retrospectives, requirements elicitation, ...) occur as needed in a continuous manner throughout construction. Work is prioritized and pulled into the team on a just-in-time basis. Work in progress is minimized. About this lifecycle: Business Value Identify, prioritize, and select projects Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Advanced/Lean Lifecycle This Scrum-based lifecycle is typically used by project teams new to agile software development. The team produces a consumable solution at the end of each construction iteration (typically 1-3 weeks in length). Work items are typically prioritized based on a combination of business value and technical risk. About this lifecycle: Highest-Priority Inception Construction Transition Operate and support solution in productionInitial Vision and Funding Iteration Daily Work Consumable Solution Daily Coordination Meeting Iteration review & retrospective: Demo to stakeholders, determine strategy for next iteration, and learn from your experiences Funding & Feedback Tasks Initial Requirements and Release Plan Initial modeling, planning, and organization Initial Architectural Vision Consumable Solution Release solution into production One or more short iterations Many short iterations producing a potentially consumable solution each iteration One or more short iterations Stakeholder vision Proven architecture Sufficient functionality Production ready Project viability (several) Delighted stakeholders Envision the future Business Roadmap, Technology Roadmap Enhancement Requests and Defect Reports Backlog Work Items Iteration planning session to select work items and identify work tasks for current iteration Iteration Work Items Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Basic/Scrum-Based Lifecycle EBMgtEBMgt…isanapproachtomanaging softwareorganisationsforthevaluethey delivertotheorganizationasawhole. WhatScrumisforsoftware development,EBMgtisforwhole organisations;usingScrumtochangeon organisationallevel.KenSchwaber&GuntherVerheyen +more "TheAgilityGuidetoEvidence-Based Change"byKenSchwaber (2014,http://www.ebmgt.org/portals/agilitypath/The%20Agility %20Guide%20v1.5.pdfversion1.5http://www.ebmgt.org/Agility-Guide) The Agility Guide to Evidence-Based Change Using Scrum to Transform Your Enterprise Version 1.5 Developed and sustained by Ken Schwaber & Scrum.org Evidence-BasedManagement™ it’s a idea peoplebehind this main book/article measure,diagnose,andimproveareitemsinaniterativecycle(inspectandadapt) differentdomainsaddressedbyapproach:enterprise,process,productivity,quality, value measurewithmetricstimetomarket,value,andabilitytoinnovate thesemetricsaresocalled"directevidenceofvalue",hencethenameEBMgt,in contrasttocircumstantialevidencelike"AredoingalltheScrummeetings?” metricresultsarecombinedinAgileIndex(singlenumber) diagnosisisindividualforeachorganisation SM,PO,ChangeTeam(SingleEnterpriseand severalDomainAgilityTeams) roles key aspects EBMgt Evidence-BasedManagement™ http://ebmgt.org home some diagrams EBMgt Evidence-BasedManagement™ ETFTheEnterpriseTransitionFramework …leadsandsupportsanorganization throughtheprocessofbecomingmore Agile. Assessment,strategy,pilotphase,rollout aspartofaninspectandadaptlifecycle AndreaTomasiniandMartinKearns +more AgileTransition-Whatyouneedto knowbeforestarting byAndreaTomasiniandMartinKearns EnterpriseTransitionFramework™ it’s a idea peoplebehind this main book/article pilotprojects traininternalcoaches Agilestrategymap independentoforganisation'ssize analysisofvision&strategy,organisation&structure,people&skills,products& technology leadershipteam roles key aspects http://www.agile42.com/en/agile-transition/etf home ETF EnterpriseTransitionFramework™ some diagrams ETFEnterpriseTransitionFramework™ LeSS Large-scaleScrumisregularScrum appliedtolarge-scaledevelopment. regularScrumappliedtolarge-scale developmentCraigLarmanandBassVodde ScalingLeanAndAgile byCraigLarmanandBasVodde Large-ScaleScrum it’s a idea peoplebehind this main book/article twoframeworks:lessorequal10teams,andmorethan10teams pureScrum-everythingelsehastobeevolvedindividuallyperorganisation Scrumrolesplus AreaPO(onlyin>10) roles key aspects http://www.craiglarman.com/wiki/index.php?title=Large-Scale_Scrum home LeSS Large-ScaleScrum some diagrams LeSSLarge-ScaleScrum Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds Henrik Kniberg & Anders Ivarsson Oct 2012 Dealing with multiple teams in a product development organization is always a challenge! One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite having scaled to over 30 teams across 3 cities. Spotify is a fascinating company that is transforming the music industry. The company has only existed 6 years and already has over 15 million active users and over 4 million paying. The product itself can be likened to “a magical music player in which you can instantly find and play every song in the world”. Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said “Nice - I've been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see.” So how is this managed? We have both presented at conferences and been caught in engaging discussions around how we work at Spotify and how the company handles agile with hundreds of developers. Many people are fascinated by this, so we decided to write an article about it. Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed. 1/14 Oneofthemostimpressiveexamples[fordealingwithmultiple teamsinaproductdevelopmentorganization]…isSpotify autonomy,mastery,purpose resultinhigh-performanceteams allofSpotify'semployees(spreadingtheword: HenrikKniberg,AndersIvarsson,andJoakimSundén) ScalingAgile@SpotifybyHenrikKnibergand AndersIvarsson(10.2012,https://dl.dropboxusercontent.com/u/ 1018963/Articles/SpotifyScaling.pdf) ScalingAgile@Spotify it’s a idea peoplebehind this main book/article SA@S I made this acronym up! Scrum,Kanban,XP,hybridsatteamlevel(teamsarefreetochose) autonomoussquads specialinterestgroupscalledchapterstoaddressmastery severalsquadsformtribes(20-100ppl) measurablequarterlygoalsforsquads dedicatedPOpersquad;Agilecoachingasneeded; stablefeatureteams;chapterlead;tribelead roles key aspects … home ScalingAgile@Spotify SA@S I made this acronym up! some diagrams ScalingAgile@Spotify SA@S I made this acronym up! “Big Projects” 57 https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf asetofguidingprinciples autonomy,mastery,purpose resultinhigh-performanceteams PeterBeck,MarkusGärtner,Christoph Mathis,StefanRoock,AndreasSchliep … ScALeDAgileLeanDevelopment it’s a idea peoplebehind this main book/article ScALeD Woohoo, it’s a recursive acronym! principlesinthecategoriesexcitedcustomers,happyandproductiveemployees,global optimisation,supportiveleadership,continuousimprovement readslikeamanifestforAgilescaling … roles key aspects http://scaledprinciples.org home ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym! some diagrams ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym! sorry, no diagrams so far anewparadigm …thedominantparadigmformanagingproduct development…isaswrongaswewereinmanufacturing, beforetheJapaneseunlockedthesecretoflean manufacturing.Ibelievethatanewparadigmisemerging, onethatchallengesthecurrentorthodoxyofproduct development. DonReinertsen ProductDevelopmentFlow byDonReinertsen ProductDevelopmentFlowbyReinertsen it’s a idea peoplebehind this main book/article PDFbyR I made this acronym up! majorthemesareeconomics,queues,variability,batchsize,WIPconstraints,cadence &synchronisation&flowcontrol,fastfeedback,decentralisedcontrol severalprinciplesforeachofthemajorthemes … roles key aspects http://reinertsenassociates.com home ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up! some diagrams sorry, no diagrams so far ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up! SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR
- 16. some diagrams DAD DisciplinedAgileDelivery DAD Exploratory Lifecycle Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org Observe & Measure Deploy Measure Productize Build a Little Envision Keep going Hypothesis Pivot Proven Idea Disproven Idea This lifecycle is followed by agile or lean teams that find themselves in startup or research situations, typically when their stakeholders do not understand what their potential user base wants. Development proceeds via a series of quick learning experiments designed to home in on what stakeholders actually want. This lifecycle is often a replacement for the Inception phase of other DAD life cycles About this lifecycle: Options Copyright 2014 Disciplined Agile Consortium DAD Continuous Delivery Lifecycle This lifecycle is best utilized by Product Teams. The Inception Phase occured in the distant past, and is, in fact, an historical artifact unless the product vision changes. The Transition Phase has become an activity rather than an explicit phase through automation and discipline. Supports DevOps by streamlining continuous delivery of con- sumable solutions to stakeholders. About this lifecycle: Work items are pulled when capacity is available to address them Replenishment modeling session Copyright 2014 Disciplined Agile Consortium Operate and support solution in production Enhancement Requests and Defect Reports Daily work Retrospective Demo Release solution Coordination Meeting Construction T Continuous stream of development Sufficient functionality New Work Feedback Learnings Strategy Production ready Delighted stakeholders Expedite Fixed Delivery Date Intangible New Features Business Value Options Expedite Fixed Delivery Date Intangible Work items are pulled when capacity is available to address them Replenishment modeling session Operate and support solution in production Enhancement Requests and Defect Reports New Features Initial Requirements Initial Architectural Vision Initial modeling, planning, and organization Daily work Retrospective Demo Release solution into production Coordination Meeting Construction Transition Continuous stream of development Stakeholder vision Sufficient functionality New Features Feedback Learnings Strategy Inception Production ready Delighted stakeholders Proven architecture Identify, prioritize, and select projects Envision the future This lifecycle is best utilized by mature teams who need to release regularly, leading towards a continuous delivery strategy using a Lean approach. Development activities (e.g. demos, retrospectives, requirements elicitation, ...) occur as needed in a continuous manner throughout construction. Work is prioritized and pulled into the team on a just-in-time basis. Work in progress is minimized. About this lifecycle: Business Value Identify, prioritize, and select projects Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Advanced/Lean Lifecycle This Scrum-based lifecycle is typically used by project teams new to agile software development. The team produces a consumable solution at the end of each construction iteration (typically 1-3 weeks in length). Work items are typically prioritized based on a combination of business value and technical risk. About this lifecycle: Highest-Priority Inception Construction Transition Operate and support solution in productionInitial Vision and Funding Iteration Daily Work Consumable Solution Daily Coordination Meeting Iteration review & retrospective: Demo to stakeholders, determine strategy for next iteration, and learn from your experiences Funding & Feedback Tasks Initial Requirements and Release Plan Initial modeling, planning, and organization Initial Architectural Vision Consumable Solution Release solution into production One or more short iterations Many short iterations producing a potentially consumable solution each iteration One or more short iterations Stakeholder vision Proven architecture Sufficient functionality Production ready Project viability (several) Delighted stakeholders Envision the future Business Roadmap, Technology Roadmap Enhancement Requests and Defect Reports Backlog Work Items Iteration planning session to select work items and identify work tasks for current iteration Iteration Work Items Identify, prioritize, and select projects Identify, prioritize, and select projects Copyright 2014 Disciplined Agile Consortium DisciplinedAgileConsortium.org DAD Basic/Scrum-Based Lifecycle
- 17. EBMgtEBMgt…isanapproachtomanaging softwareorganisationsforthevaluethey delivertotheorganisationasawhole. WhatScrumisforsoftware development,EBMgtisforwhole organisations;usingScrumtochangeon organisationallevel.KenSchwaber&GuntherVerheyen +more "TheAgilityGuidetoEvidence-Based Change"byKenSchwaber (2014,http://www.ebmgt.org/portals/agilitypath/The%20Agility %20Guide%20v1.5.pdfversion1.5http://www.ebmgt.org/Agility-Guide) The Agility Guide to Evidence-Based Change Using Scrum to Transform Your Enterprise Version 1.5 Developed and sustained by Ken Schwaber & Scrum.org Evidence-BasedManagement™ it’s a idea peoplebehind this main book/article
- 26. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds Henrik Kniberg & Anders Ivarsson Oct 2012 Dealing with multiple teams in a product development organization is always a challenge! One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite having scaled to over 30 teams across 3 cities. Spotify is a fascinating company that is transforming the music industry. The company has only existed 6 years and already has over 15 million active users and over 4 million paying. The product itself can be likened to “a magical music player in which you can instantly find and play every song in the world”. Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said “Nice - I've been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see.” So how is this managed? We have both presented at conferences and been caught in engaging discussions around how we work at Spotify and how the company handles agile with hundreds of developers. Many people are fascinated by this, so we decided to write an article about it. Disclaimer: We didn’t invent this model. Spotify is (like any good agile company) evolving fast. This article is only a snapshot of our current way of working - a journey in progress, not a journey completed. By the time you read this, things have already changed. 1/14 Oneofthemostimpressiveexamples[fordealingwithmultiple teamsinaproductdevelopmentorganisation]…isSpotify autonomy,mastery,purpose resultinhigh-performanceteams allofSpotify'semployees(spreadingtheword: HenrikKniberg,AndersIvarsson,andJoakimSundén) ScalingAgile@SpotifybyHenrikKnibergand AndersIvarsson(10.2012,https://dl.dropboxusercontent.com/u/ 1018963/Articles/SpotifyScaling.pdf) ScalingAgile@Spotify it’s a idea peoplebehind this main book/article SA@S I made this acronym up!
- 28. some diagrams ScalingAgile@Spotify SA@S I made this acronym up! “Big Projects” 57 https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf
- 29. asetofguidingprinciples autonomy,mastery,purpose resultinhigh-performanceteams PeterBeck,MarkusGärtner,Christoph Mathis,StefanRoock,AndreasSchliep … ScALeDAgileLeanDevelopment it’s a idea peoplebehind this main book/article ScALeD Woohoo, it’s a recursive acronym!
- 31. some diagrams ScALeDAgileLeanDevelopment ScALeD Woohoo, it’s a recursive acronym! sorry, no diagrams so far
- 32. anewparadigm …thedominantparadigmformanagingproduct development…isaswrongaswewereinmanufacturing, beforetheJapaneseunlockedthesecretoflean manufacturing.Ibelievethatanewparadigmisemerging, onethatchallengesthecurrentorthodoxyofproduct development. DonReinertsen ProductDevelopmentFlow byDonReinertsen ProductDevelopmentFlowbyReinertsen it’s a idea peoplebehind this main book/article PDFbyR I made this acronym up!
- 34. some diagrams sorry, no diagrams so far ProductDevelopmentFlowbyReinertsen PDFbyR I made this acronym up!
- 35. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 1010 9 8 55 00 Comparison: Blueprint vs. Principles Whereisthescalingapproach’sfocus onascalefrom0(verymuchblueprintandspecs)to10(allaboutprinciples)?
- 36. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 8 7 9 8 5 3 00 Comparison: Commercialisation Howmassivelyhasthisscalingapproachbeencommercialised,i.e.exploitedinawaydesignedtomakeaprofit, onascalefrom0(looksverymuchlikeit)to10(notatall)?
- 37. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 10101010 55 00 Comparison: Scaling Howdoesthisscalingapproachactuallyhandlescaling,i.e.alineartransformationthatenlargesobjects,onascale from0(doesnotscale,i.e.worksonlywithsuperbigorgs)to10(doesscale,i.e.workswithverysmallorgs)? What I mean is: does it work with 2 teams?
- 38. 0 2 4 6 8 10 SAFe DAD EBMgt ETF LeSS SA@S ScALeD PDFbyR 10101010 1 3 1 3 Comparison: Recommendation HowlikelyisitthatI(BerndSchiffer)wouldrecommendthisscalingapproachtoacustomerofmine,onascale from0(veryunlikely)to10(verylikely)?