leaning it: applying the principle of “pull” to scale...

Copyright ©2008 Rally Software Development Corp. All rights reserved. www.rallydev.com

By Jean Tabaka and Ryan Martens

Abstract:

Reaping the benefits of Agile software development beyond the team level is an enticing proposition. In fact, in today’s competitive climate and brutal economy, perhaps it is even more than that — it is a necessity. Based on documented successes, organizations are recognizing the business imperative to “go big” with Agile and as a result, they are confronting the confusion and churn of when and how to scale their Agile adoption.

This white paper introduces the Lean principle of Pull and applies it as a theme for prioritizing actions and practices within Agile Teams and Programs. In this paper, you will learn:

• ThespecificpracticesthatadheretothePulldiscipline• Methodstokeepyouontherightpath• Roadblockstosuccess• ExpectedresultsofsuccessfuladoptionofAgilefortheProgram• Toolingtosupportthesuccessfuladoption

Is your organization ready for this Agile “means to an end” or is Agile adoption inadvertently creatingaclassic“fixthatfails?”CanAgiletrulyworkattheProgramlevel?

This white paper is based on actual experiences of professionals who helped steer many of the largest Agile implementations done over the last five years. Dedicate yourself to creating great Teams and superior Programs with the guidance provided here around the Lean discipline of Pull. Your reward will be the poise to gracefully continue to scale, mature, and win with Agile.

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

2


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

Agile software development has classically emphasized project management and engineering practices for small, co-located teams. These teams deliver high-quality software in a short and regular rhythm. Maturity is measured in terms of team and product disciplines. How do we continually improve our team and engineering practices, product quality and code robustness? We do this by inspecting and adapting our practices in the context of team agreements and commitments. We rely on team-oriented metrics to guide how these agreements bring greater team commitment and increased value delivery.

The Agile team creates its own culture of reliability with engineering practices, social pacts, communication mechanisms and contracts with the business. In turn, business owners, such as product management, product marketing and program management, take this team-based set of practices for value delivery and quickly create similar success in a larger context. Team success plays the inadvertent role of an organizational trampoline: success in a small context attempting to “spring” into success across the organization. This presents a problem because team-based practices do not translate immediately or obviously to greater scales.

The challenge becomes more difficult when attempting to scale team successes to the program level. Have pilot teams absorbed enough discipline to act as a model for other teams of teams? What should be the basis for how a program inspects and adapts pre-defined 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 of Lean manufacturing into five key principles:

• Specifyvalue

• Identifythevaluestream

• Flow

• Pull

• Perfection

The first two Lean principles match two fundamental principles of Agile: value definition andvaluedelivery.Forthefirstprinciple,AgilemethodssuchasScrumcallfortheimplementation of a prioritized product backlog to emphasize value definition. With the second principle, Agile teams continually inspect and adapt their value delivery by examining 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 of our value delivery? Through demos and reviews, Agile teams regularly peer across their value stream to evaluate tweaks that may improve their value delivery. Reading more about what Womack and Jones say about these two principles can help teams boost the power of their inspections.

ButthereismoretolearnfromLeanThinking.WhatdotheFlow,PullandPerfectionprinciples lend to Agile software development? And, how can they steer successful enterprise Agile adoption?

1LeanThinking:BanishWasteandCreateWealthinYourCorporation,Womack,JamesP.andDanielT.Jones.FreePress, 2003.

3


Like many other industries, the software industry is continually seeking ways to deliver value faster and more reliably. Agile software development steps up to this challenge in a bigwaybycallingonteamstotakeondramaticdevelopmentprocesschanges.Forsmallcollaborative teams, the changes work well in decreasing the time required to produce high-quality features with reduced expenses. But, can the Agile equation be translated to more than one team, to teams of teams or to an entire organization? What can both scaling and maturity of Agile look like? How can we formulate both while avoiding the risk of failure in either? This is the point where we take Agile and overlay the three remaining Lean principles and find our guidance for scaling to Agile programs:

• FlowprovidesguidanceonhowtogradeandsteeranAgileteam’smaturity

• Pullprovidesstructureforprograms(teamsofteams)tocontinuematuritywhilescaling

• Perfection(whichwerefertohereasInnovate)providesthesetofpracticesfororganizational scaling and maturation of Agile

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

So,whatdowereallymeanbyFlow,PullandInnovatewithregardtowhatwerefertoasEnterprise Agile Adoption?

Our five-step approach, structured around three Lean principles, establishes the order and ranking of 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 of teams by maintaining your adoption of Agile practicesinFlowandPull.

4. Scaletomulti-organizationaladoptionbymaintainingtheFlowandPullprinciplesin selecting and perfecting practices.

5. ApplytheInnovate(Perfection)principleinordertoscaleyouradoptionofAgiletothe enterprise level.

Our overall framework takes on this stair-step look:

Figure 1: The 5-Step Enterprise Agile Adoption Approach

4


ThinkofFlowasarhythmordrumbeatthatguidesdevelopmentteamstodeliverhigh-quality products consistently. There is no churn, no turbulence — none of the waste-packed, non-sustainable practices of linear software development, only a continuous, smooth flow of value from the team.

Pull empowers a team or program to define release requirements, resulting in good, functioning software increments that are not dependent on completing the overall project. In a highly disciplined practice of Pull at the program level, two levers are at work.First,theteamsofteamscanalwayspullreadyandvaluedfeaturedefinitionsfromtheinvolvedbusinessunits.Second,thebusinesscanalwayspullreadyandvaluedfeatures for delivery from the program. There is no pushing of requirements or pushing of low-quality features. To scale across programs effectively, an organization must find a way to replicate Pull across the entire context of software/IT of multiple dependent programs.

Finally,InnovateguidesentireorganizationsinhowtobringthematurityofFlowand Pull beyond the development organization. Innovate invites high quality, high productivity and high visibility across the whole of the organization, all its divisions and levels.

While this white paper focuses on Pull as guidance for Agile teams and programs, its guidance sitsinthelargercontextofa5-stepEnterpriseAgileAdoption;thatis,TeamPulladoptionassumesasuccessfuladoptionofTeamFlow.And,theMulti-TeamProgramPullisactuallyrecommendedasastepbeforescalingtotheMulti-ProgramOrganizationinanEnterpriseAgileAdoption.

As you follow these 5 steps, you can envision scalability of practices from Team to Program to Organization as follows:

Figure 2: Practice Overview for Team to Program to Organization for Enterprise Agile Adoption

5


Given our 5-step approach, before teams or programs can move to a Pull mode of operating,theymustfirstexhibitthecharacteristicsofAgileteamsinFlow:

• Areempoweredandcollaborativeindecisionmaking

• Begintodefineadefinitionof“done”forhowtheymakecommitmentstovaluedelivery

• Useatime-boxedrhythmofhigh-qualityproductdelivery

• Define,buildandtesteverycommittedfeaturewithinthetimebox

• Engageininspectionandadaptionpracticesthatamplifytheirlearningaboutteamagreements, process and their definition of “done”

To then enable adoption of the Pull principle for programs, let us first establish a basic viewofPull;thatis,whatdoesateaminPulllooklike?Fromthisbase,wecanthenevaluate how teams of teams, that is programs, act when in Pull.

II. What “Pull” Looks Like for One Team

The discipline of Pull empowers teams to define release features, resulting in good, functioning software increments that are not dependent on other project teams. In a highlydisciplinedadoptionofPull,pilotteamsusetwolevers.First,theteamscanalwayspull prioritized, ready, valued feature definitions from the backlog maintained by the business.Secondly,thebusinessinturncanalwayspullready,valued,“done”featuresfor final user and system testing with potential customers. Gone are the days of pushing requirements onto teams or waiting for drop points to do final acceptance tests on key features or system performance.

Figure3isoneteam’sdefinitionof“done”thatshowsitsdisciplinetomaintainaFlowofvalue delivery and a true readiness of Pull for the product team.

Figure 3: A Sample Definition of “Done” for an Item (Story) Ready to Pull

6


With this definition of “done,” any item that passes these criteria is considered completed by the delivery team. In turn, it is considered ready to be pulled by the business. As the team matures, it continually inspects this definition so that readiness continually “attacks”anyimpedimentstothebusiness’sabilitytopullreadyvalueditems.

The Pull discipline also has a bit more to it with regard to business discipline. It constrains over-elaboration of requirements either too soon or too late. Pull sets up the business to say, “Here is what needs to be accomplished in the next two weeks.” Pull doesn’tallowsurprisesaboutbusinessrequests.Itsimplyeliminatesthewasteofwaitingfor the prioritization and definition of the items. Pull also ensures that the business is only elaborating the highest-value items. Teams do not wait for all items to be completely detailed in order to pull work forward.

Critical to setting up Pull is an effective release planning mechanism. This mechanism begins with a product roadmap to guide the prioritization of features across themed releases. This, in turn, defines a release time box that is broken into groups of iterations. The discipline of release planning helps both the business and development teams. The businessbenefitsfromalongertermviewintothedeliveryteam’sbestworkatestimatinga sequence of stories. Delivery teams, in turn, can anticipate upcoming stories to pull off the release backlog in a way that reduces risk and speeds feedback on high-value stories.

A. Characteristics of a Team in Pull

Given what we have just described, Agile teams in a state of Pull exhibit the following characteristics:

• Theteamhasnosurprisesandnowaitinginpullingsufficientlydetailedvaluedefinitionofitemsfromthebusiness’sbacklog.

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

• Thebusinessalwayshastheoptiontopull“done”RTF(RunningTestedFeature)value items at the end of each time box.

• Theteamhasamulti-releaseroadmapandcommitmenttothescopeofthecurrentrelease.

• Theteamholdsapolicyofcollaborativeemergentdesignbasedonsimplicityandthe feedback from the “done” items.

• Thedeliverableisstable,haszerodefectbacklogandthereforeinvitesmorepossibility of shift in the eventual set of valuable features for 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 in traditionalwaterfallapproaches.Ateam’sabilitytomaturecanbestoppedinitstracks due to distracted or inaccessible product owners. Teams may also unearth unclearacceptanceproceduresthatwerehidingintheQualityAssurance(QA)phase at the end of their projects.

7


• Organizationalchangeceiling:Becauseofthisnew,highlyvisibledemandonthe business organization, Pull maturity may encounter bumps and bruises. Pull also requires that testing be fully integrated into the team, as this is no longer an optional part of the definition of “done.” Pull discipline requires the organization to consider an organizational change backlog, critical once we move to the next level of scaling and maturity.

•Weakfeedbackloopsonvalue:Withoutproductownershipengaged,adisciplinedteam will still push up against a roadblock of delayed feedback loops on value delivery. Are priorities right? Are the delivered features meeting customer expectations?Doesthecostofdelivery(teamandorganizationalresources)providesufficient ROI to continue the effort?

Once team Pull is established, there are many benefits. The highest-priority features, and the ones most likely to be used, are completed first. The percentage of Work in Process(WIP)atanygiventimeisdecreased.Inaddition,theteamreleasesfully-testedincrements more often and, as a result, customer feedback is frequent and improved.

What do we see when a team is in Pull? Teams begin to think about the product from a higher view: The team “sees the whole” and has a clear path to delivering a high-value product.Areleaseviewoftheproductelevatesthevisibilityofeachiteration’simpacton the product for the team, the customer representative and all stakeholders. With this higher view, and the ability to pull only ready backlog items, the Agile team pushes back onbacklogitemsthataren’tready.Theyareabletorecognizethattheseitemsthatarenot ready will adversely impact their commitment to release goals.

Figure 4: A Team Planning a Release Across Time Boxes2

When Pull discipline is fully embraced and visibility is raised to the release level, release quality is fixed. Teams now work with a zero defect mentality across time boxes and the entire system, not just within a time box for new functionality.

2PhotobyJeanTabakausedwithpermissionfromRallySoftware,Boulder,CO

8


C. Tooling the Agile Team for Pull

When implementing Pull, tool requirements for visibility and signaling increase. Teams in Pull track tasks, acceptance criteria, automated-testing requirements and defects. Teams “signal”inrealtimehowtoworkmoreeffectivelyandmeasure“done.”Forvisibilityintoreleasesuccess,teamsmustalsohaveaccesstocycle-timemetrics.Forexample,“Howlong did it take me to fix that defect?”

Finally,thePulldisciplinerequiresahighlyvisible,real-timeautomatedandprioritizedbacklog.Atanytime,thebusinessmustbeopentodiscussionsaboutwhat’scomingnext in the backlog, and be ready for the delivery team to plan and estimate. In this automated, prioritized backlog, business owners must be able to show emerging elaboration of information about the items. Backlog items open themselves up for 24 by 7 scrutiny.

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 of a Team in Pull

9


In addition to a real-time project management system that allows them to see the complete status, teams need to fix their functional- and regression-testing batches by implementingautomatedfunctionaltestingandsystem-buildcapabilities.SeeFigure6below.

Figure 6: Continuous Quality in Pull

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

What are the benefits of teams in Pull? Teams become much more adept at:

• Notoverstuffingtheirtimeboxes,resultingincostsavingsfromsmootherFlow

• Providingthebusinessmarketwithdeploymentdecisionsbasedontruly“done”value items

• Fixingtheirqualitythresholds(asaresultoflesseningtheaccumulationoftechnicaldebt)

• Increasingvaluegainedfromdirectfeedbackfromafullyengagedproductmanagement/ownership organization

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

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

10


III. Scaling the Pull Discipline to Programs

Scalingthesuccessofindependentpilotteamstomultiple,interdependentteamsrequiresthesamedisciplinesguidedbytheFlowandPullprinciples.Butnowthestakesarehigher. These disciplines have to be embraced and synchronized across teams of teams, or what we refer to as programs. Program Pull disciplines and practices support teams that must rely on each other either for resources, feature completion or release readiness. AdoptingAgilewithPulldisciplinewithinaprogramisatruetestofanorganization’sintent to scale.

To scale Agile adoption to Pull for the program, an organization must first consider the best way to “seed” the Agile scaling effort:

• BringinmembersfromthepilotteamsthatmaturedthroughFlowandPull.

• BringinoutsideAgilecoachesfamiliarwiththedisciplinesrequiredtosucceedatthe program level.

• Combinethetwoapproachesandestablisha“trainthetrainer”practiceofgrowingtheprogram’sownstaffofseasoned,disciplinedAgilecoaches.

Any Program Pull approach for scaling and maturing Agile has to involve all employees in the program community. Just as in the pilot teams, all program community members are empowered to bring insights, and, with all members engaged, learning is greatly amplified.However,totalparticipationcanbringupotherconcerns.Forexample,afunctional manager who owns all the QA resources might worry about how this new wayofdoingbusinessisgoingtoimpacttheiroverallQAorganization’sprocessesandtools. This is where organizational commitment to Pull is essential. An oversight team, the program steering committee, must engage to knock down organizational barriers and incent a “whole program” view of success.

Remember, Agile requires that teams grow by splitting into teams of teams within the program versus one big team. The ensuing hand-wringing regarding splitting teams requires a well-articulated organizational rollout plan for the program. The rollout demandstrue,engagedexecutivesponsorship.Fordistributedprogramteams,thechallenges only increase. And yet, the Pull discipline requires program managers and the organization to engage the entire program membership in the success of the product release.

Inadditiontoexecutivesupport,theprogramhastoknowhowit’sgoingtoscaleuptothenextlevel.Ifthereisnodetailedplanformovingforward,oriftheprogramdoesn’taddressallthevalidconcernsaboutorganizationalchange,you’relikelytohitaglassceiling at a single program level.

A. Characteristics of a Program in Pull

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

• Across-functionalprogramsteeringteamthatclearsobstaclesandtendstothevision

• Companyinfrastructurethatsupportscross-program,cross-teamintegratedbuilds

• AdaptiveAgileworkstandardsthatarefullyembracedacrossallteamsandcontinually inspected and adapted

11


• Large-scalereleaseplanningmeetingsthatestablishasynchronizedscheduleanddependency mitigation strategies

• Cross-teamresourcesbalancedonasynchronizedreleaseschedule

Figure 7: The Agile Program in Pull Has Intense Practices

B. Roadblocks in Moving an Organization to Program-level Pull

With so much to absorb for success in program-level Pull, an organization can run into seemingly insurmountable roadblocks:

• Functionalfiefdomsorsilos:TheQAfunctionalmanagermentionedearlieroranoperations team is not prepared to work at the pace demanded of an Agile program in Pull.

• Lackofinfrastructureinvestmenttocoordinatedistributedteams.Theorganizationmay be unwilling to acknowledge that the Pull discipline requires investing in infrastructure/tooling for increased signaling, visibility, tracking and quality.

• Otherpartsoftheorganizationdon’tknowhowtohandletheprogram’space:Marketingsays,“Wecan’treleasethatfastbecauseourcustomerscan’thandleit.”The support and operations organizations may also be reluctant to take on the faster schedules and more feedback, despite the obvious benefits for product value delivery.

And yet, programs willing to invest in the time, training and discipline to move to Pull can reap serious business benefits:

• Theteamsgettomarketfasterwithahigher-value,higher-qualitysolution

• Theteamsembraceincreasedfeatureandresourcecomplexity

• Thereisaunifiedprogramvision

• Thequalityoftheentiresolutionincreasesdramatically

12


C. A Successful Pull Example

In2004,BMCSoftware,headquarteredinHouston,Texas,decideditneededtomoveto an aggressive release schedule for one of its product lines. Their objective was to get to market 50% faster than previous releases. In doing so, BMC wanted to be able to protect quality standards and not allow defects to accumulate for the sake of product deployment.Forthiseffort,theyformedaprogramofteamsof93members(developers,testers,techwriters,andarchitects)andadoptedthePullapproachofAgileproductdelivery. The program held regular cross-team coordinated release planning meetings and adopted a Program steering committee to maintain the vision, remove impediments and continually invest in the tooling and infrastructure.

WhatwastheresultofthisPulldiscipline?BMCdeliveredaproductwith600,000linesofcode four-and-a-half times faster than the industry average. Their overall program team was twice the size of the 45-person average, but delivered 11 percent fewer defects than average.Whencomparedtocomparable93-personteams,theyhad70percentfewerdefects. As a result, BMC surpassed its competition and is enjoying incredible success. This is the big benefit of program Pull: finished products, not just single-team software incrementsandfastertime-to-marketthancompetitors’products.RallycoachingonthePulldisciplinesupportedbyRallytoolingcontributedsignificantlytoBMC’ssuccess.ThiscasestudyispartofthelargerQSMAAgileImpactStudyavailableatwww.rallydev.com/agileimpactreport.

D. Synchronized Calendars and Disciplined Program Pull

ToreachBMC’slevelofsuccess,agreatdealofcoordinationmustbebuiltintoaprogram’scadence.Programteamssynchronizetheirreleasecalendarsthroughafull-team release planning meeting. All team members participate in the discussions, the planning and the release commitment. Everyone plans the entire product release together (seeFigure8).Everyaspectoftheprogramislinedupandsynchronized,includingmeasurement spots and iteration planning.

The program steering committee, up one level from the teams, is also on the same schedule. All the meetings and product demos are disciplined. Demos need to be conducted every iteration so that Team A knows that Team B is going to deliver what is needed. If not, feedback must be given immediately so that features, resources and schedules can be adjusted as soon as possible.

13


Figure 8: A Program Release Train Across Teams in Pull

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

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

2. Steeringcommitteerhythmclearstheprioritizedorganizationalimpediments.Dailyandweeklyrhythmsmatchtheteams’rhythms.

3. A set of norms emerges to enable scaling and program agreements. These are derived from collaboration and full-participation.

4. Quality is visible daily across teams. A unified build is used to signal “stop-the-line” to 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 to delegatedependentworkanddorollupsacrossalltheprogram’steams.Inadditiontoshared status across teams, a program in Pull needs visibility into system quality across components, multiple levels of planning and just-in-time requirements management.

In this way, the program is passing what could be called an amateur level and moving towardatrulyexpertlevel.Ifitdoesn’taggressivelyembracethePulldisciplineandtryto scale, it will fail. The teams will remain a group of amateurs and potentially embrace thementalityofcomplacency,“NowthatIcandothis,Iwilljustkeepdoingitthesameway.”It’sveryimportantnowtoinvestinandraisethevisibilityoftheincrementalwins,andcelebratesuccess.Also,considerre-investingtheprogram’sROIbenefitstoaddmoreinfrastructure for testing or integrating the complete software lifecycle for better feedback management.

14


Agile LifecycleManagement

& OperationsCustomer Management

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 Software Lifecycle

IV. Conclusion

Agile is an approach that was originally formulated for single co-located teams. To grow ourindustriesandbuildsoftwaretosolvetheworld’stoughestchallenges,weneedtoscale and mature. Paying attention to these guidelines around Team Pull and Program Pull can put you on the road to becoming an Agile expert beyond the team. Our approach requires leadership, discipline, dedication, and a partner like Rally who works closely with your company to make sure you reap the full benefits of the Pull solution. Rally is not simply 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 Agile expert.

If Team Pull and Program Pull are implemented correctly, Agile and Rally can dramatically shorten your development cycles, increase quality and productivity, speed value delivery, andputyourentireorganizationonthepathtobeingtrulyinnovative.Rally’sleadershipcan help your organization break free of older, plan-based methodologies and siloed tools while avoiding the pitfalls of a non-disciplined Agile adoption plan. Teams in Pull can lead to programs in Pull and ultimately organizations that Innovate.

15


To move through these steps successfully, consider a timeline of organizational actions and Rally training and coaching as follows:

Dedicate yourself to creating great Teams and superior Programs with the guidance provided here around the Lean discipline of Pull. Your reward will be the poise to gracefully continue to scale, mature, and win with Agile.

16


About the Authors

JeanTabakaisanAgileFellowwithRallySoftwareDevelopmentinBoulder,Colorado.With over 25 years of experience in the software development industry, she has navigatednumerousplan-drivenmethodologiesinavarietyofcontexts(government,IT,consulting)andinavarietyofroles(programmer,architect,projectmanager,methodologist).HermovetoAgilesoftwaredevelopmentapproachescameinthelate90sasaresultofstudyingDSDMintheUK.Sincethattime,shehasbecomeanAgiledevotee,consulting with teams of all sizes worldwide wishing to derive more value faster through the adoption of Agile principles and practices.

ShespecializesinscalingAgilepractices,applyingLeanprinciplesandpractices,andbuildingcontinuousplanningandtestingintoorganizations.Shealsocreatesastrongcollaborative approach in how organizations adopt Agile. Ms. Tabaka is a Certified ScrumMasterandPractitioner,aCertifiedScrumMasterTrainer,andaCertifiedProfessionalFacilitator.SheholdsaMastersinComputerSciencefromJohnsHopkinsUniversityandistheauthorof“CollaborationExplained:FacilitationSkillsforSoftwareProjectLeaders”publishedintheAddison-WesleyAgileSoftwareDevelopmentSeries.Youcan reach her at [email protected].

RyanMartensisthefounder&ChiefTechnologyOfficerofRallySoftwareandanexpertin assisting organizations in transitioning from traditional development processes to more Agile techniques.

BeforefoundingRallySoftwareDevelopment—hisfourthsoftwarestart-up—Mr.Martens directed the corporate adoption of Internet technologies within Qwest Communications, and then moved on to co-found Avitek, a Boulder-based custom software development firm where he served as Vice President of Marketing & Business Development.Mr.Martens’successfuleffortsatAvitekculminatedinanacquisitionbyBEASystemsin1999.AtBEA,Mr.MartensservedasDirectorofProductManagementforthe eCommerce applications division and he was instrumental in growing that division to more than $50 million in revenue within its first twelve months.

leaning it: applying the principle of “pull” to scale...

Documents