leaning-it---applying-the-principle-of-pull-to-scale-agile-teams

8/7/2019 Leaning-IT---Applying-the-Principle-of-Pull-to-Scale-Agile-Teams

1/16Copyright 2008 Rally Software Development Corp. All rights reserved. www.rallydev.com

By Jean Tabaka and Ryan Martens

Abstract:Reaping the benefts o Agile sotware development beyond the team level is an enticingproposition. In act, in todays competitive climate and brutal economy, perhaps it is even morethan that it is a necessity. Based on documented successes, organizations are recognizing thebusiness imperative to go big with Agile and as a result, they are conronting the conusion andchurn o when and how to scale their Agile adoption.

This white paper introduces the Lean principle o Pull and applies it as a theme or prioritizingactions and practices within Agile Teams and Programs. In this paper, you will learn:

ThespecicpracticesthatadheretothePulldiscipline

Methodstokeepyouontherightpath

Roadblockstosuccess ExpectedresultsofsuccessfuladoptionofAgilefortheProgram

Toolingtosupportthesuccessfuladoption

Is your organization ready or this Agile means to an end or is Agile adoption inadvertentlycreatingaclassicxthatfails?CanAgiletrulyworkattheProgramlevel?

This white paper is based on actual experiences o proessionals who helped steer manyo the largest Agile implementations done over the last ve years. Dedicate yoursel tocreating great Teams and superior Programs with the guidance provided here aroundthe Lean discipline o Pull. Your reward will be the poise to graceully continue to scale,mature, and win with Agile.

Leaning IT: Applying the Principle of Pull to Scale Agile Teams


2/16


I. Setting the Context: Lean Principles and the 5-Step Enterprise

Agile Adoption

Agile sotware development has classically emphasized project management and

engineering practices or small, co-located teams. These teams deliver high-qualitysotware in a short and regular rhythm. Maturity is measured in terms o team andproduct disciplines. How do we continually improve our team and engineering practices,product quality and code robustness? We do this by inspecting and adapting our practicesin the context o team agreements and commitments. We rely on team-oriented metricsto guide how these agreements bring greater team commitment and increased valuedelivery.

The Agile team creates its own culture o reliability with engineering practices, socialpacts, communication mechanisms and contracts with the business. In turn, businessowners, such as product management, product marketing and program management,take this team-based set o practices or value delivery and quickly create similarsuccess in a larger context. Team success plays the inadvertent role o an organizationaltrampoline: success in a small context attempting to spring into success across the

organization. This presents a problem because team-based practices do not translateimmediately or obviously to greater scales.

The challenge becomes more dicult when attempting to scale team successes to theprogram level. Have pilot teams absorbed enough discipline to act as a model or otherteams o teams? What should be the basis or how a program inspects and adapts pre-dened patterns? Are these patterns the right path to scaling?

A. Using Lean Principles to Guide Agile Growth for the Organization

In their book on Lean Thinking1, James Womack and Daniel Jones distill the work o Leanmanuacturing into ve key principles:

Specifyvalue

Identifythevaluestream

Flow

Pull

Perfection

The rst two Lean principles match two undamental principles o Agile: value denitionandvaluedelivery.Fortherstprinciple,AgilemethodssuchasScrumcallfortheimplementation o a prioritized product backlog to emphasize value denition. Withthe second principle, Agile teams continually inspect and adapt their value delivery byexamining their metrics and practices over time. What does it cost us to deliver value?What is sitting in our value stream that is getting in the way o our value delivery?Through demos and reviews, Agile teams regularly peer across their value stream toevaluate tweaks that may improve their value delivery. Reading more about whatWomack and Jones say about these two principles can help teams boost the power otheir inspections.

ButthereismoretolearnfromLeanThinking.WhatdotheFlow,PullandPerfectionprinciples lend to Agile sotware development? And, how can they steer successulenterprise Agile adoption?

1LeanThinking:BanishWasteandCreateWealthinYourCorporation,Womack,JamesP.andDanielT.Jones.Free

Press, 2003.


3/16


Like many other industries, the sotware industry is continually seeking ways to delivervalue aster and more reliably. Agile sotware development steps up to this challenge in abigwaybycallingonteamstotakeondramaticdevelopmentprocesschanges.Forsmallcollaborative teams, the changes work well in decreasing the time required to producehigh-quality eatures with reduced expenses. But, can the Agile equation be translated

to more than one team, to teams o teams or to an entire organization? What can bothscaling and maturity o Agile look like? How can we ormulate both while avoidingthe risk o ailure in either? This is the point where we take Agile and overlay the threeremaining Lean principles and nd our guidance or scaling to Agile programs:

FlowprovidesguidanceonhowtogradeandsteeranAgileteamsmaturity

Pullprovidesstructureforprograms(teamsofteams)tocontinuematuritywhilescaling

Perfection(whichwerefertohereasInnovate)providesthesetofpracticesfororganizational scaling and maturation o Agile

B. Lean and the 5-step Enterprise Agile Adoption Approach

So,whatdowereallymeanbyFlow,PullandInnovatewithregardtowhatwerefertoasEnterprise Agile Adoption?

Our ve-step approach, structured around three Lean principles, establishes the order andranking o enterprise Agile adoption:

1. EstablishAgilepracticeswithasingleteamthatemphasizestheFlowprinciple.

2. Mature more pilot teams to Agile practices using the Pull principle.

3. Once in Pull mode, scale to teams o teams by maintaining your adoption o Agile

practicesinFlowandPull.4. Scaletomulti-organizationaladoptionbymaintainingtheFlowandPullprinciples

in selecting and perecting practices.

5. ApplytheInnovate(Perfection)principleinordertoscaleyouradoptionofAgiletothe enterprise level.

Our overall ramework takes on this stair-step look:

Figure 1: The 5-Step Enterprise Agile Adoption Approach


4/16


5/16


Given our 5-step approach, beore teams or programs can move to a Pull mode ooperating,theymustrstexhibitthecharacteristicsofAgileteamsinFlow:

Areempoweredandcollaborativeindecisionmaking

Begintodeneadenitionofdoneforhowtheymakecommitmentstovaluedelivery

Useatime-boxedrhythmofhigh-qualityproductdelivery

Dene,buildandtesteverycommittedfeaturewithinthetimebox

Engageininspectionandadaptionpracticesthatamplifytheirlearningaboutteamagreements, process and their denition o done

To then enable adoption o the Pull principle or programs, let us rst establish a basicviewofPull;thatis,whatdoesateaminPulllooklike?Fromthisbase,wecanthenevaluate how teams o teams, that is programs, act when in Pull.

II. What Pull Looks Like for One Team

The discipline o Pull empowers teams to dene release eatures, resulting in good,unctioning sotware increments that are not dependent on other project teams. In ahighlydisciplinedadoptionofPull,pilotteamsusetwolevers.First,theteamscanalwayspull prioritized, ready, valued eature denitions rom the backlog maintained by thebusiness.Secondly,thebusinessinturncanalwayspullready,valued,donefeaturesor nal user and system testing with potential customers. Gone are the days o pushingrequirements onto teams or waiting or drop points to do nal acceptance tests on keyeatures or system perormance.

Figure3isoneteamsdenitionofdonethatshowsitsdisciplinetomaintainaFlowofvalue delivery and a true readiness o Pull or the product team.

Figure 3: A Sample Defnition o Done or an Item (Story) Ready to Pull


6/16


With this denition o done, any item that passes these criteria is considered completedby the delivery team. In turn, it is considered ready to be pulled by the business. Asthe team matures, it continually inspects this denition so that readiness continuallyattacksanyimpedimentstothebusinesssabilitytopullreadyvalueditems.

The Pull discipline also has a bit more to it with regard to business discipline. Itconstrains over-elaboration o requirements either too soon or too late. Pull sets up thebusiness to say, Here is what needs to be accomplished in the next two weeks. Pulldoesntallowsurprisesaboutbusinessrequests.Itsimplyeliminatesthewasteofwaitingor the prioritization and denition o the items. Pull also ensures that the business isonly elaborating the highest-value items. Teams do not wait or all items to be completelydetailed in order to pull work orward.

Critical to setting up Pull is an eective release planning mechanism. This mechanismbegins with a product roadmap to guide the prioritization o eatures across themedreleases. This, in turn, denes a release time box that is broken into groups o iterations.The discipline o release planning helps both the business and development teams. Thebusinessbenetsfromalongertermviewintothedeliveryteamsbestworkatestimating

a sequence o stories. Delivery teams, in turn, can anticipate upcoming stories to pull othe release backlog in a way that reduces risk and speeds eedback on high-value stories.

A. Characteristics of a Team in Pull

Given what we have just described, Agile teams in a state o Pull exhibit the ollowingcharacteristics:

Theteamhasnosurprisesandnowaitinginpullingsufcientlydetailedvaluedenitionofitemsfromthebusinesssbacklog.

ThebusinessisalwaysworkingoneortwotimeboxesaheadinitsownFlowsothat items are always in a ready state to be pulled rom the prioritized backlog.

ThebusinessalwayshastheoptiontopulldoneRTF(RunningTestedFeature)value items at the end o each time box.

Theteamhasamulti-releaseroadmapandcommitmenttothescopeofthecurrentrelease.

Theteamholdsapolicyofcollaborativeemergentdesignbasedonsimplicityandthe eedback rom the done items.

Thedeliverableisstable,haszerodefectbacklogandthereforeinvitesmorepossibility o shit in the eventual set o valuable eatures or release.

B. Potential Roadblocks

There are potential roadblocks to adopting the Pull discipline including:

Lackofcollaborationfromthebusiness:Agileasksproductowners,suchasproductmanagers, business analysts or architects, to be much more engaged than intraditionalwaterfallapproaches.Ateamsabilitytomaturecanbestoppedinitstracks due to distracted or inaccessible product owners. Teams may also unearthunclearacceptanceproceduresthatwerehidingintheQualityAssurance(QA)phase at the end o their projects.


7/16


Organizationalchangeceiling:Becauseofthisnew,highlyvisibledemandonthe business organization, Pull maturity may encounter bumps and bruises. Pullalso requires that testing be ully integrated into the team, as this is no longer anoptional part o the denition o done. Pull discipline requires the organizationto consider an organizational change backlog, critical once we move to the next

level o scaling and maturity.

Weakfeedbackloopsonvalue:Withoutproductownershipengaged,adisciplinedteam will still push up against a roadblock o delayed eedback loops on valuedelivery. Are priorities right? Are the delivered eatures meeting customerexpectations?Doesthecostofdelivery(teamandorganizationalresources)providesucient ROI to continue the eort?

Once team Pull is established, there are many benets. The highest-priority eatures,and the ones most likely to be used, are completed rst. The percentage o Work inProcess(WIP)atanygiventimeisdecreased.Inaddition,theteamreleasesfully-testedincrements more oten and, as a result, customer eedback is requent and improved.

What do we see when a team is in Pull? Teams begin to think about the product rom ahigher view: The team sees the whole and has a clear path to delivering a high-valueproduct.Areleaseviewoftheproductelevatesthevisibilityofeachiterationsimpacton the product or the team, the customer representative and all stakeholders. With thishigher view, and the ability to pull only ready backlog items, the Agile team pushes backonbacklogitemsthatarentready.Theyareabletorecognizethattheseitemsthatarenot ready will adversely impact their commitment to release goals.

Figure 4: A Team Planning a Release Across Time Boxes2

When Pull discipline is ully embraced and visibility is raised to the release level, releasequality is xed. Teams now work with a zero deect mentality across time boxes and theentire system, not just within a time box or new unctionality.

2PhotobyJeanTabakausedwithpermissionfromRallySoftware,Boulder,CO


8/16


C. Tooling the Agile Team for Pull

When implementing Pull, tool requirements or visibility and signaling increase. Teamsin Pull track tasks, acceptance criteria, automated-testing requirements and deects. Teamssignalinrealtimehowtoworkmoreeffectivelyandmeasuredone.Forvisibilityinto

releasesuccess,teamsmustalsohaveaccesstocycle-timemetrics.Forexample,Howlong did it take me to x that deect?

Finally,thePulldisciplinerequiresahighlyvisible,real-timeautomatedandprioritizedbacklog.Atanytime,thebusinessmustbeopentodiscussionsaboutwhatscomingnext in the backlog, and be ready or the delivery team to plan and estimate. In thisautomated, prioritized backlog, business owners must be able to show emergingelaboration o inormation about the items. Backlog items open themselves up or 24 by 7scrutiny.

Shared release readiness reporting Visible system-level quality Reinforcing story by story work and pulling tasks Complete cycle time metrics

Just-in-Time Requirements Management and Doneness Traceability provide:

Figure 5: Project Visibility o a Team in Pull


9/16


In addition to a real-time project management system that allows them to see thecomplete status, teams need to x their unctional- and regression-testing batches byimplementingautomatedfunctionaltestingandsystem-buildcapabilities.SeeFigure6below.

Figure 6: Continuous Quality in Pull

Testers and product owners can now pull builds as required to provide rapid quality andunctional eedback to the Agile team.

What are the benets o teams in Pull? Teams become much more adept at:

Notoverstufngtheirtimeboxes,resultingincostsavingsfromsmootherFlow

Providingthebusinessmarketwithdeploymentdecisionsbasedontrulydonevalue items

Fixingtheirqualitythresholds(asaresultoflesseningtheaccumulationoftechnicaldebt)

Increasingvaluegainedfromdirectfeedbackfromafullyengagedproductmanagement/ownership organization

Makingdeployment/releasedecisionsbasedoncompleteditems,andtakinginawider view o the product, beyond one time box at a time

However, Pull discipline at the pilot team level has its limitations. Quality andthroughput benets are still limited to the scope o any single one o the pilot teams.Nowisthetimetoscalethesepractices,toolsandprocessesbeyondasingleteam,uptoacollection o teams that can deliver large-scale and complex systems.


10/160


III. Scaling the Pull Discipline to Programs

Scalingthesuccessofindependentpilotteamstomultiple,interdependentteamsrequiresthesamedisciplinesguidedbytheFlowandPullprinciples.Butnowthestakesarehigher. These disciplines have to be embraced and synchronized across teams o teams,

or what we reer to as programs. Program Pull disciplines and practices support teamsthat must rely on each other either or resources, eature completion or release readiness.AdoptingAgilewithPulldisciplinewithinaprogramisatruetestofanorganizationsintent to scale.

To scale Agile adoption to Pull or the program, an organization must rst consider thebest way to seed the Agile scaling eort:

BringinmembersfromthepilotteamsthatmaturedthroughFlowandPull.

BringinoutsideAgilecoachesfamiliarwiththedisciplinesrequiredtosucceedatthe program level.

Combinethetwoapproachesandestablishatrainthetrainerpracticeofgrowing

theprogramsownstaffofseasoned,disciplinedAgilecoaches.

Any Program Pull approach or scaling and maturing Agile has to involve all employeesin the program community. Just as in the pilot teams, all program community membersare empowered to bring insights, and, with all members engaged, learning is greatlyamplied.However,totalparticipationcanbringupotherconcerns.Forexample,aunctional manager who owns all the QA resources might worry about how this newwayofdoingbusinessisgoingtoimpacttheiroverallQAorganizationsprocessesandtools. This is where organizational commitment to Pull is essential. An oversight team,the program steering committee, must engage to knock down organizational barriers andincent a whole program view o success.

Remember, Agile requires that teams grow by splitting into teams o teams within theprogram versus one big team. The ensuing hand-wringing regarding splitting teamsrequires a well-articulated organizational rollout plan or the program. The rolloutdemandstrue,engagedexecutivesponsorship.Fordistributedprogramteams,thechallenges only increase. And yet, the Pull discipline requires program managers andthe organization to engage the entire program membership in the success o the productrelease.

Inadditiontoexecutivesupport,theprogramhastoknowhowitsgoingtoscaleuptothenextlevel.Ifthereisnodetailedplanformovingforward,oriftheprogramdoesntaddressallthevalidconcernsaboutorganizationalchange,yourelikelytohitaglassceiling at a single program level.

A. Characteristics of a Program in Pull

So,giventheserequirementsandconcernsformovingaprogramtoadisciplineofPull,what are the ultimate characteristics o such a program?

Across-functionalprogramsteeringteamthatclearsobstaclesandtendstothevision

Companyinfrastructurethatsupportscross-program,cross-teamintegratedbuilds

AdaptiveAgileworkstandardsthatarefullyembracedacrossallteamsandcontinually inspected and adapted


11/16


12/16


13/163


Figure 8: A Program Release Train Across Teams in Pull

The program steering group is managing a set o teams in Pull when:

1. Large-scale release planning allows every team member to see the whole. The releasetrain synchronizes schedule, dependencies, and rhythm across teams.

2. Steeringcommitteerhythmclearstheprioritizedorganizationalimpediments.Dailyandweeklyrhythmsmatchtheteamsrhythms.

3. A set o norms emerges to enable scaling and program agreements. These are derivedrom collaboration and ull-participation.

4. Quality is visible daily across teams. A unied build is used to signal stop-the-lineto all developers.

E. Tooling for Program Pull

SupportingprogramPullrequirestoolingthatelevatesthesignalingandtrackingbeyond just an Agile team level. Each team structure and its status must have a view and

impact into the overall program structure and status. The Program needs to be able todelegatedependentworkanddorollupsacrossalltheprogramsteams.Inadditiontoshared status across teams, a program in Pull needs visibility into system quality acrosscomponents, multiple levels o planning and just-in-time requirements management.

In this way, the program is passing what could be called an amateur level and movingtowardatrulyexpertlevel.IfitdoesntaggressivelyembracethePulldisciplineandtryto scale, it will ail. The teams will remain a group o amateurs and potentially embracethementalityofcomplacency,NowthatIcandothis,Iwilljustkeepdoingitthesameway.Itsveryimportantnowtoinvestinandraisethevisibilityoftheincrementalwins,andcelebratesuccess.Also,considerre-investingtheprogramsROIbenetstoaddmoreinrastructure or testing or integrating the complete sotware liecycle or better eedbackmanagement.


14/164


Agile LifecycleManagement

Management

Product&Portfolio

Requests

ROI & Adoption

Harden &Release

Deploy &Support

BusinessCase

CollaborativeDevelopmentTask, Code, Build, SCM

Defects

Define &Develop

Test &Accept

Prioritize &Schedule

Figure 9: Entire Sotware Liecycle

IV. Conclusion

Agile is an approach that was originally ormulated or single co-located teams. To growourindustriesandbuildsoftwaretosolvetheworldstoughestchallenges,weneedtoscale and mature. Paying attention to these guidelines around Team Pull and ProgramPull can put you on the road to becoming an Agile expert beyond the team. Our approachrequires leadership, discipline, dedication, and a partner like Rally who works closely withyour company to make sure you reap the ull benets o the Pull solution. Rally is notsimply selling an Agile tool, but success through expertise, business value, partnership, a

total integration strategy and a complete solution backed by a company that is an Agileexpert.

I Team Pull and Program Pull are implemented correctly, Agile and Rally can dramaticallyshorten your development cycles, increase quality and productivity, speed value delivery,andputyourentireorganizationonthepathtobeingtrulyinnovative.Rallysleadershipcan help your organization break ree o older, plan-based methodologies and siloed toolswhile avoiding the pitalls o a non-disciplined Agile adoption plan. Teams in Pull canlead to programs in Pull and ultimately organizations that Innovate.


15/165


To move through these steps successully, consider a timeline o organizational actionsand Rally training and coaching as ollows:

Dedicate yoursel to creating great Teams and superior Programs with the guidanceprovided here around the Lean discipline o Pull. Your reward will be the poise tograceully continue to scale, mature, and win with Agile.


16/16


About the Authors

JeanTabakaisanAgileFellowwithRallySoftwareDevelopmentinBoulder,Colorado.With over 25 years o experience in the sotware development industry, she hasnavigatednumerousplan-drivenmethodologiesinavarietyofcontexts(government,

IT,consulting)andinavarietyofroles(programmer,architect,projectmanager,methodologist).HermovetoAgilesoftwaredevelopmentapproachescameinthelate90sasaresultofstudyingDSDMintheUK.Sincethattime,shehasbecomeanAgiledevotee,consulting with teams o all sizes worldwide wishing to derive more value aster throughthe adoption o Agile principles and practices.

ShespecializesinscalingAgilepractices,applyingLeanprinciplesandpractices,andbuildingcontinuousplanningandtestingintoorganizations.Shealsocreatesastrongcollaborative approach in how organizations adopt Agile. Ms. Tabaka is a CertiedScrumMasterandPractitioner,aCertiedScrumMasterTrainer,andaCertiedProfessionalFacilitator.SheholdsaMastersinComputerSciencefromJohnsHopkinsUniversityandistheauthorofCollaborationExplained:FacilitationSkillsforSoftwareProjectLeaderspublishedintheAddison-WesleyAgileSoftwareDevelopmentSeries.You

can reach her at [email protected].

RyanMartensisthefounder&ChiefTechnologyOfcerofRallySoftwareandanexpertin assisting organizations in transitioning rom traditional development processes tomore Agile techniques.

BeforefoundingRallySoftwareDevelopmenthisfourthsoftwarestart-upMr.Martens directed the corporate adoption o Internet technologies within QwestCommunications, and then moved on to co-ound Avitek, a Boulder-based customsotware development rm where he served as Vice President o Marketing & BusinessDevelopment.Mr.MartenssuccessfuleffortsatAvitekculminatedinanacquisitionbyBEASystemsin1999.AtBEA,Mr.MartensservedasDirectorofProductManagementfor

the eCommerce applications division and he was instrumental in growing that divisionto more than $50 million in revenue within its rst twelve months.

leaning-it---applying-the-principle-of-pull-to-scale-agile-teams

Documents