Transcription
Cognizant 20-20 InsightsDigital BusinessScaled and Distributed Scrum:Key Considerations for SuccessThese best practices in choosing a Scrum framework to handle large-scaleAgile projects with distributed teams help avoid chaotic project situations whileenabling today’s digital companies to outpace traditional enterprises.Executive SummaryScrum, a framework for effective project teamcollaboration on a complex topic, is the most popularproject approach in the Agile methodology. Thislightweight framework, which is easy to understand butdifficult to master, is used for work projects of all kinds,across business units with various sizes and organizationalstructures.This has given rise to new challenges. Given its lightweightframework, Scrum’s application in large project teams canlead to chaotic project situations. For this reason, manyframeworks for scaling Scrum have been created over thelast few years to accommodate a high number of projectparticipants.In addition, Scrum is no longer used only for co-locatedteams – teams are often spread across different offices,February 2019countries or global regions. While the use of Scrum forlarge teams requires that the framework is adapted andextended, the distribution of project teams also leads tonew challenges.In regard to this, many companies that recently startedworking Agile are still looking for approaches to adapttheir processes to those emerging challenges.This white paper offers high-profile insights drawn fromour client experiences where scaled and distributedScrum techniques have been used in variousconstellations, and provides guidance on what additionalactions can create even more value when Scrum isimplemented for large and/or distributed projects.
Cognizant 20-20 InsightsScaled Scrum: The frameworksWhen Scrum is used for projects with more thantwo project teams (so-called “scaled Scrum”), it’srecommended to use an additional frameworkto deal with the increased dependencies andcommunication effort and to ensure that the projectstill profits from the advantages of working Agile.Figure 1 provides an overview of three of the mostfrequently used Agile frameworks that deliverscaled Scrum.The scaling frameworksNexus/ScaledProfessionalScrumScaled AgileFramework(SAFe)Large * Framework author/sFigure 1All such frameworks are built on the principlesof Scrum, which pivots around self-organizingand cross-functional teams. As in traditionalScrum, teams in scaled Scrum also share oneproduct backlog and plan the workload for Sprintscollaboratively.1The differences are found in the structure of theframeworks, techniques used, popularity, flexibility,cost, support and proximity to the Scrum frameworkas a basis.Choosing the right frameworkWhen adapting a framework to scale a Scrumproject, the first question is which framework tochoose: A large variety of frameworks are availableonline and in the respective trade press and media.While some frameworks offer more detailedguidance, others allow greater freedom andmore flexible policy rules. However, this does notnecessarily mean that one is better than another.When choosing an appropriate solution, theteam members involved and the needs of theorganization are decisive. For example, a highlysophisticated and complex framework will not helpanyone if the team has zero Agile experience yetand the project is starting in a few days. These arethe important requirements and factors to considerwhen making a decision: The company’s, and especially the projectteam’s, experience and skills: Has the companyused any frameworks already? Is there anyexisting internal support or expertise for acertain framework?2 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 Insights Support and training availability: Is it possibleto access support (if needed) and/or trainingsfor project participants? What kind of material isavailable to onboard team members? Company culture: Does the framework’sphilosophy fit your company’s culture? Available software and budget for new tools:What is needed to establish the framework?Does the company have the tools to use it yet orcan it buy them? Regulations: Are there regulatoryrequirements to fulfill concerning processesor documentation? Which supervisoryauthorities apply?Furthermore, the implementation effort itself andthe resulting structural changes play a major roleand differ from framework to framework. Thebig challenge here is to find the most suitableframework for the organization – according to itsindividual requirements.The implementation effort and the level of guidanceprovided are the two main axes to differentiate thethree frameworks (see Figure 2).Nexus is a highly lightweight framework that onlyapplies a few additional rules to Scrum. However, itis conceivable that some teams, particularly thosewho are new to Agile project management, willneed more support than this framework provides.In this case, it makes sense to apply a more detailedframework, e.g. LeSS, with a medium level ofdetail, or SAFe, a more complex framework. Thedisadvantages of using a more highly detailedframework are that its implementation requiresgreater effort and it takes more time to internalize.A matrix of frameworksHIGHEffort for ImplementationSAFeLeSSNexusLOWLOWLevel of GuidanceFigure 23 / Scaled and Distributed Scrum: Key Considerations for SuccessHIGH
Cognizant 20-20 InsightsThe main advantages of Nexus are its low learning andimplementation barrier and that it does not create muchoverhead. On the other hand, this framework provides onlymoderate guidelines: teams need to align with additionalcustom rules and best practices to set up a well-functioningscaled Scrum environment.NexusNexus uses Scrum as its building block. Followingthe Nexus Guide, the framework binds and weavestogether the work of three to nine Scrum teamsworking on a single product backlog to build an2integrated increment to meet a project goal. Itscomponents are roles, events, artifacts and rules.Nexus is an unrestricted framework that merelyspecifies some important add-ons to Scrum suchas an additional integration team to coordinate,coach and supervise the Nexus implementation inorder to ensure the best possible outcomes.It is important to note that Nexus provides anexoskeleton for Scrum teams to work with, yetit is not a methodology that defines everythingindividuals need to know to scale Scrum. Themain advantages of Nexus are its low learning andimplementation barrier and that it does not createmuch overhead. On the other hand, this frameworkprovides only moderate guidelines: teams needto align with additional custom rules and bestpractices to set up a well-functioning scaledScrum environment.Navigating the NexusNexusScrumTeamsNexusNexus Sprint xus SprintPlanningNexus SprintBacklogIntegratedWorkNexusSprintReview3–9 Scrum TeamsFigure 34 / Scaled and Distributed Scrum: Key Considerations for SuccessIntegratedIncrement
Cognizant 20-20 InsightsOne example is the overview about the large varietyof requirements: The more teams work on oneproject, the more requirements are transformedinto a product increment every Sprint. The NexusGuide states that the teams have to ensure that thework which is done forms a potentially shippableincrement every Sprint (similar to basic Scrum).Also, the increased importance of dependenciesbetween stories in a scaled Scrum environment isexplained. However, the guide doesn’t contain anyinformation about how the needed overview can beachieved – the project teams have to either comeup with their own ideas or take special trainings onNexus. There are about 50 best practices that canbe learned from specialized Nexus trainers; thesepractices include instructions on how to properlydo a story mapping. Otherwise, the large size ofthe product backlog can lead to double-entryaccounting, various Excel lists and other unhelpfulattempts to sort the backlog once the requirementchaos has developed.Other aspects, such as organizational requirementsthat are dealt with in other frameworks (e.g., inLeSS), are not taken into account. Therefore, it is amajor advantage if team members, especially thosewho are part of the Nexus integration team, alreadyhave experience in the use of (scaled) Scrum.SAFeSAFe is a framework of detailed scope, in which3work is divided into value streams. Each valuestream consists of work steps that are repeatedlyapplied to deliver value to the company, and thesework steps are handled by a release train (five to 154teams, up to 150 people).SAFe works with program increments (PIs), whichconsist of intervals of about 10 weeks. These arecadence-based and include other events such asthe PI planning event where all teams meet for oneor two days to arrange upcoming activities.EpicOwnersDevOpsAgile Release TrainRoadmapDev TeamXPTeamVisionProductOwnerNFR’sNFR’sScrum MasterLean UXScrum Plan Execute Review RetroAgile TeamsKanbanBacklogSystem DemosEnablerFeatureIterationsPIStoryReleaseon DemandContinuousDeploymentEnablerPIEnablerDevelop on CadenceFigure 45 / Scaled and Distributed Scrum: Key Considerations for SuccessFeaturePIStoryPIPI PlanningPI ObjectivesContinuousIntegration Culture Automation Lean Flow Measurement RecoverySolutionPI PlanningNFR’sPI onBacklogSystem TeamCustomerContinuous Delivery PipelineProgram IncrementProgramValue alRunwayProgram Portfolio tMetricsCoPEpicNFR’sProgram laying it SAFeBuilt-InQuality
Cognizant 20-20 InsightsThe framework consists of three levels: the portfoliolevel, where strategic decisions are made; theprogram level, where PIs are developed with theAgile Release Train; and the team level, where workfor the single stories of the team’s Sprint backlog5is planned and performed (see Figure 4, previouspage). The combination of these three levels equalsone value stream. The SAFe framework itself can bescaled by adding additional value streams (largescale SAFe).Using the SAFe framework, the last Sprint of everyPI (the Innovation & Planning Sprint) is blocked tofinish work in progress, plan further incrementsand experiment with new ideas. Also, requirementsin all other Sprints take up 30–70% of the Sprintto ensure sufficient time for defect management,user support and upgrading the developmentenvironment.SAFe is not a purely Scrum-based framework,as it includes a Kanban process at the portfoliolevel. It takes a lot of initial effort to understandand implement its structure properly, as it is acomparatively detailed framework. One advantageof SAFe is that it can natively be extended to caterto projects with more than 150 developers as itincludes two scalable layers. In addition to scalingvalue streams on the program level, the team levelcan also be scaled by adding more teams to oneAgile Release Train.LeSSLeSS is based on minimalism: It requires only afew process changes and adjustments to the basicScrum framework to handle projects with multiple6Scrum teams. The core principle of this frameworkis the understanding that teams should act as longliving feature teams. With the decrease of initialeffort at the beginning of a new project, alreadyestablished teams pick up work faster. Ideally, theteams are maintained on a cross-project basis, andthey always have a single product owner and sharedproduct backlog.Where LeSS is tBacklogPotentially ShippableProduct IncrementProduct BacklogRefinementSprintReviewScrum Master &Feature rdinationOverallRetrospectiveDaily ScrumFigure 56 / Scaled and Distributed Scrum: Key Considerations for SuccessNextSprint
Cognizant 20-20 InsightsFor teams which aim to use a framework with acertain level of detail and want to get their projectsstarted with a minimum level of implementationeffort, LeSS represents a good compromise. Sincethe framework offers a certain set of rules andalso shows practical examples for customization, itoffers strong guidance, yet doesn’t add too muchstructure to Scrum. LeSS is optimized for threeto eight teams; for larger projects, the LeSS Huge7framework can be applied.LeSS’s balanced level of guidance and ease make ita great choice for a large variety of project setups.For example, the LeSS approach aims to steermultiple teams in large projects with less effortwhile keeping processes as small and simple as8possible. LeSS is based on Scrum with adaptionsfor scaled and distributed teams. At its most basiclevel, it can be understood as a specification of how9Scrum is meant to be applied. It applies the sameprinciples and rules for its three to eight teamsas Scrum with one team. With the involvementof more teams, a few amendments apply to easecommunication and increase the overall efficiency10of the project teams.At the core, LeSS is a set of principles drawn frompractical experience that provides the foundation of11the framework.LeSS includes several rules that build the keyelements of the framework to ease project setupand create a foundation. Furthermore, practical tipsare given to enable project teams to adopt rules andprinciples to their underlying project case.LeSS principlesQueuing TheoryLarge-ScaleScrum Is ScrumTransparencyEmpericalProcess ControlMore with LessWhole ProductFocusSystemsThinkingLeanThinkingContinuous ImprovementToward PerfectionCustomerCentricFigure 67 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 InsightsLeSS elementsThe roles described within LeSS are similar to thosefound in Scrum, where only microinvasive changesapply: There is one product owner, three to eightfeature teams and a Scrum master for every one to12three teams.With LeSS, artifacts stay consistent; the onlydifference is that every team maintains its ownSprint backlog. But note that since the outcome ofthe project is one product, all teams share a singleproduct backlog.In scaled Scrum projects, product owners are ata high risk to lose oversight and for the productbacklog to become overloaded when more thanthree teams work on the same product. Thefollowing events in the LeSS framework helpfacilitate coordination of teams and overcomeproject difficulties: Sprint planning part one includes the productowner, Scrum masters and some teamrepresentatives in order to coordinate theactivities of different teams. Members discussbacklog items and then plan how to split upitems for the upcoming Sprint. Sprint planning part two is held by each teamseparately, as in Scrum with one team. Within themeeting, team members discuss how to achievethe Sprint goal. A daily Scrum is held by each teamindependently. Overall product backlog refinement includes theproduct owner, subject matter experts, and eitherall members of the teams or representativesfrom each team. Participants analyze therequirements briefly. They estimate itemsand split those that are too big for estimation.Also, dependencies as well as strongly relateditems are identified. If a requirement will clearlybe done by one team, it is forwarded to therespective team’s product backlog refinement. Sprint review includes the product owner, allteam members and important stakeholders. Forbetter learning, a “science fair” approach may beconsidered. Overall retrospective includes the product owner,Scrum master and members from each team.It is used to identify and discuss challenges thataffect more than one team.LeSS HugeLeSS Huge can be adopted for more than eightteams working on the same product. LeSS Hugeis basically built of multiple LeSS frameworksstacked on top of each other, so there are multiplesimilarities LeSS and LeSS Huge share: One product owner who is responsible for theoverall prioritization of the product backlog itemsand who decides on the scope and schedule ofthe releases. One product backlog, which contains all therequirements for the product to be developed. One definition of done for all teams: Even thoughit is possible that some of them expand thedefinition of done in their teams, the basis andminimum requirement for an increment to beconsidered potentially shippable is this shareddefinition. One shippable increment that is potentiallyreleasable is the shared goal of all the teams. One Sprint for all teams, which starts and endsat the same time. This is viable for the creation ofone shippable product increment per Sprint.Differences apply regarding roles, artifacts andevents due to increased complexity and the numberof requirements and people. In addition to LeSS,LeSS Huge also comprises an area product owner,area backlog and Sprint execution per requirementarea.8 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 InsightsWith LeSS Huge, teams are divided around majorareas of customer focus, so-called requirementareas. This represents the principle of customer13centricity as introduced in LeSS. The completeproject team decides on requirement areas suchas management, performance, front end, etc. Assoon as the basic structure is defined, items fromthe product backlog are classified into appropriaterequirement areas. The product backlog is splitinto different area backlogs for each of thoserequirement areas.Advantages of LeSSIf the organization has experience in working withScrum, LeSS is readily adoptable as it is based onScrum with only small adaptations. Applying LeSSoffers further benefits to the entire organization andits projects:Furthermore, a new role – the area productowner – is introduced. Every area product owneris responsible for one area backlog and for theproduct features it contains. The area productowner prioritizes backlog items and approachesdevelopment from a customer perspective.Nevertheless, the overall responsibility for theproduct backlog stays with the main product owner. LeSS concentrates on descaling the organization,enhancing simplification and setting upextended-duration team structures that remain18intact beyond a single project period.Every area feature team works within onerequirement area and focuses on the itemswithin one area product backlog. From a team’sperspective, working in an area is similar to working14in a smaller LeSS framework.The area product owner acts as product ownerfor teams working on the area backlog under hisresponsibility. When applying LeSS Huge, it isrecommended to engage four to 10 teams per15requirement area. LeSS is centered on customers and the16product. While other scaling frameworksdivide teams according to single functions orarchitectural components, LeSS focuses on the17customers’ concerns. LeSS is a “no-brainer” framework for thoseorganizations that are experienced in workingwith Scrum. It can easily be adopted andcontains everything a project team will likely19need to function. The combination and coordination of multipleteams around one product is easier with LeSSthan with other frameworks or no framework at all. LeSS creates synergies between projects andpeople, and the entire organization is included in20the product value flow.9 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 InsightsScrum with distributed teamsAnother decisive factor for the success of a Scrumproject is the location of project participants.Working with decentralized teams is increasinglyimportant as external teams who do not use Scrumusually work only with half of the velocity of central21teams that use it. There are several ways to buildteams relating to their location:Nevertheless, we came across some new challengesand “how to” questions arising when teams arenot (fully) co-located while helping our clientsintroduce and adapt Agile concepts using scaledand distributed Scrum. Co-located: Teams are located at the samegeographic place.At the beginning of every project, especially inan Agile environment, the whole team needs todevelop a shared understanding of the overallproject vision and project objectives. A shortperiod of co-location is therefore recommendedto ensure the onboarding of all members. Thisensures that teams work effectively and quickly getup to speed, and it lessens communication barriersas all team members have a shared understandingof the project. It can also be used to onboardteam members with the LeSS framework and itsprinciples. Based on our varied project experiences,we recommend that the LeSS advice “first educateeveryone in depth” should be taken as seriouslyas possible – not only for the developers but alsofor the product owner, Scrum Master(s) and otherstakeholders as the correct adaptation is vital forLeSS. This period of co-location also facilitatesfurther knowledge transfer (e.g., on the domain)24and helps establish shared working standards. Nearshore: The teams are located near eachother – geographically as well as culturally. Thedistance is kept at a level where events from theScrum cycle can be held at the same day/timeand (except for the daily Scrum) in one place. Far shore: Teams are located abroad, travel timeis long and both cultural and time differencesapply. Mixed: A mix of the three aforementionedoptions (e.g., one team is co-located, five teamsare placed nearshore). Having different locationswithin development teams themselves is also apossibility but is not recommended.The three key advantages of near- or far shoring(both nuances of offshoring) are: lower labor cost,access to locally unavailable skills, and their flexibility22in project size without layoffs. Thus, scaling withremote capacity enables the local team to remain23stable as the project is scaled up or down.Shared vision10 / Scaled and Distributed Scrum: Key Considerations for Success10 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 InsightsWay of workCommunication problems often develop dueto differences in working style between onshoreand offshore teams. Agile project managementis sometimes understood and lived differentlywith regard to cultural differences. To counteractthis, project teams should introduce workingstandards to which each individual commits. Thosecan be taken from respective frameworks andcan additionally be defined by the teams. Also,management should support the team in findinga shared way of working, as this is seen as a major25team achievement in distributed Scrum. Thiscan happen through LeSS framework-specificmethodology like “go see” or “experiments overconformity” or via project-individual solutions. Inone of our scaled Scrum projects, for example, theclient stakeholders decided to really “go see” andspend some time at the developer’s sites abroad tohave a look at how they work there and to also get arealistic sense of the environment, challenges andpotential for optimization by supporting the teams.This diminishes the feeling of having a “black box”for the involved stakeholders.A lack of cross-team learning can be an issuewhen it comes to scaled and decentralized teams.LeSS addresses this potential issue by hostingrefinement and review meetings for co-locatedand nearshore teams in large rooms, as knownfrom science fairs. From our experience, even ifit’s not possible to host all those Scrum eventslive, this get-together of all participants shouldhappen every time the Sprint changes – and atleast once a month. The time spent together,including common meetings, ensures that all teammembers and stakeholders have the chance tobuild trustworthy relationships and communicatedirectly about project progress or the difficultiesthat may affect development. In-personinteraction can be crucial sometimes – and its lackcan slow down the entire development process.LeSS also provides a solution to handle dependencyissues and the coordination between teams:It structures work-around features (LeSS) orrequirement areas (LeSS Huge). Therefore, theoverlap of requirements and tasks is kept at aminimum level.Time zonesWhen setting up a distributed Scrum project,carefully consider the impact of multi-sitedevelopment. The challenges for communication,knowledge-sharing and building reliablerelationships are greater, plus distributed teams alsooften work in different time zones, where workingAgile project management is sometimes understood and liveddifferently with regard to cultural differences. To counteract this,projectteams shouldto whichMostinstrumentshaveintroducea 15 yearworkinglifecycle standardsbefore refresh,eveneachwhenindividualcommits.can be seare available.Addingsensorsto existingand can additionallybe thedefinedby theequipment,can extendlife spanof teams.existing instruments.›Firstname Lastname, Title, Company11 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 Insightshours overlap only briefly. This challenge affectsfar-shore teams (at least partly). All larger Scrummeetings are attended by the complete team orat least by representatives from every team, whichrequires a high level of flexibility and understandingof working hours from all team members. Meetingtimes can be kept short by preparing the sharedScrum events to the maximum degree. However,this cannot be applied to the daily Scrum meeting,as the time difference would cause unease amongteam members. A proxy product owner role helpsovercome these burdens by connecting andsharing information between two (or more) daily26Scrum meetings held in different time zones.ToolsLast but not least, applying distributed Scrumrequires additional tools for conferencing,document sharing, etc. This becomes even moreimportant than with co-located projects sinceteam members do not have the option to meet for27quick face-to-face conversations. Furthermore,alternative digital solutions are required to maintainthe common definition of done, discuss the list of28unsolved obstacles and overcome impediments.Various project management tools, like JIRA orConfluence, provide further functionalities.The LeSS framework attaches value to informalcommunication and networks. Team membersare encouraged to use the easiest way tocommunicate – e.g., via code (using comments, forexample), interdisciplinary meetings, mentoringfor special components, open spaces, etc. Inour experience, this leads to quick and easycommunication patterns but can also createadditional workload if there’s not one source foralready-made decisions. Therefore, we recommendthe use of a common communication platform tomeet challenges in team communication and tofacilitate the exchange of information among teams.By applying this, all team members have accessto the same information, can track changes andthus ensure a balanced distribution of information.Tools that can be used for this purpose reach fromgeneral project management tools (like Jira orConfluence, as mentioned above) to specific toolsfor distributed scrum.If scaled Scrum is applied, the project organization must finda framework that meets the individual project requirements. Fromour experience supporting clients through the entire Agile journey,LeSS offers a good compromise in terms of detail and flexibility forMost instruments have a 15 year lifecycle before refresh, even whenmost common project situations with a comparatively manageablenew, smarter devices are available. Adding sensors to existingimplementation effort.equipment, can extend the life span of existing instruments.›Firstname Lastname, Title, Company12 / Scaled and Distributed Scrum: Key Considerations for Success12 / Scaled and Distributed Scrum: Key Considerations for Success
Cognizant 20-20 InsightsLooking forwardBoth scaled and distributed Scrum can be used indifferent ways and come with specific challenges.If scaled Scrum is applied, the project organizationmust find a framework that meets the individualproject requirements. From our experiencesupporting clients through the entire Agilejourney, LeSS offers a good compromise in termsof detail and flexibility for most common projectsituations with a comparatively manageableimplementation effort.On one hand, the framework provides defined rules,which offer guidance to project participants (if welladapted and trained); on the other hand, it alsocontains abstract principles that give each projectthe freedom to choose an appropriate setup, tryingthings out using the LeSS experiments while alsoavoiding common pitfalls. When using LeSS withour clients, we are well aware that LeSS does notoffer everything needed for successful scaling, butit does form the basis for it – a starting point forinspection, adaption and improvement.opportunity to apply know-how that is not locallyavailable. It also increases flexibility in terms ofproject size. Yet, the offshore location causeschallenges when it comes to developing a sharedvision and working practices. Moreover, time zonedifferences add difficulties in scheduling meetingsand require additional tools for planning andholding joint meetings.LeSS supports distributed Scrum, as it workswith feature teams who work independently to acertain degree. This reduces dependencies andoverlaps within the teams. LeSS also promotes thestability of teams beyond a single project period.If these principles are lived by organizations, theeffort of setting up new projects is significantlyless and finding a common ground of workpractices is simplified – even if teams are spreadglobally. Against this background, applying theLeSS framework for decentralized Scrum projects(nearshore, far shore or mixed) should be seen as abest practice.Furthermore, the location of the teams plays animportant role. The use of offshore teams leadsto (partly) lower labor costs and provides the13 / Scaled and Distributed Scrum:
Scaled Scrum: The frameworks. When Scrum is used for projects with more than two project teams (so-called "scaled Scrum"), it's recommended to use an additional framework to deal with the increased dependencies and communication effort and to ensure that the project still profits from the advantages of working Agile.
