sap lean pull for agile teams

8/12/2019 Sap Lean Pull for Agile Teams

1/16Copyright 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 enticingproposition. In fact, 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 confronting the confusion andchurn 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 prioritizingactions and practices within Agile Teams and Programs. In this paper, you will learn:

The specic practices that adhere to the Pull discipline

Methods to keep you on the right path

Roadblocks to success Expected results of successful adoption of Agile for the Program

Tooling to support the successful adoption

Is your organization ready for this Agile means to an end or is Agile adoption inadvertentlycreating a classic x that fails? Can Agile truly work at the Program level?

This white paper is based on actual experiences of professionals who helped steer manyof the largest Agile implementations done over the last five years. Dedicate yourself tocreating great Teams and superior Programs with the guidance provided here aroundthe 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/16


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-qualitysoftware in a short and regular rhythm. Maturity is measured in terms of 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 of 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 of 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 of practices for value delivery and quickly create similarsuccess in a larger context. Team success plays the inadvertent role of 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 difficult when attempting to scale team successes to theprogram level. Have pilot teams absorbed enough discipline to act as a model for otherteams 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 Leanmanufacturing into five key principles:

Specify value

Identify the value stream

Flow

Pull

Perfection

The first two Lean principles match two fundamental principles of Agile: value definitionand value delivery. For the rst principle, Agile methods such as Scrum call for theimplementation of a prioritized product backlog to emphasize value definition. 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 of 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 oftheir inspections.

But there is more to learn from Lean Thinking. What do the Flow, Pull and Perfectionprinciples lend to Agile software development? And, how can they steer successfulenterprise Agile adoption?

1Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Womack, James P. and Daniel T. Jones. Free

Press, 2003.


3/16


Like many other industries, the software industry is continually seeking ways to delivervalue faster and more reliably. Agile software development steps up to this challenge in abig way by calling on teams to take on dramatic development process changes. For smallcollaborative teams, the changes work well in decreasing the time required to producehigh-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 bothscaling and maturity of Agile look like? How can we formulate both while avoidingthe risk of failure in either? This is the point where we take Agile and overlay the threeremaining Lean principles and find our guidance for scaling to Agile programs:

Flow provides guidance on how to grade and steer an Agile teams maturity

Pull provides structure for programs (teams of teams) to continue maturity whilescaling

Perfection (which we refer to here as Innovate) provides the set of practices fororganizational scaling and maturation of Agile

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

So, what do we really mean by Flow, Pull and Innovate with regard to what we refer to asEnterprise Agile Adoption?

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

1. Establish Agile practices with a single team that emphasizes the Flow principle.

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

practices in Flow and Pull.4. Scale to multi-organizational adoption by maintaining the Flow and Pull principles

in selecting and perfecting practices.

5. Apply the Innovate (Perfection) principle in order to scale your adoption of Agile tothe enterprise level.

Our overall framework takes on this stair-step look:

Figure 1: The 5-Step Enterprise Agile Adoption Approach


4/16


Think of Flow as a rhythm or drum beat that guides development teams to deliver high-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 overallproject. In a highly disciplined practice of Pull at the program level, two levers are atwork. First, the teams of teams can always pull ready and valued feature denitionsfrom the involved business units. Second, the business can always pull ready and valuedfeatures for delivery from the program. There is no pushing of requirements or pushing oflow-quality features. To scale across programs effectively, an organization must find a wayto replicate Pull across the entire context of software/IT of multiple dependent programs.

Finally, Innovate guides entire organizations in how to bring the maturity of Flowand Pull beyond the development organization. Innovate invites high quality, highproductivity and high visibility across the whole of the organization, all its divisions andlevels.

While this white paper focuses on Pull as guidance for Agile teams and programs, its guidancesits in the larger context of a 5-step Enterprise Agile Adoption; that is, Team Pull adoptionassumes a successful adoption of Team Flow. And, the Multi-Team Program Pull is actuallyrecommended as a step before scaling to the Multi-Program Organization in an Enterprise Agile

Adoption.

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

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


5/16


Given our 5-step approach, before teams or programs can move to a Pull mode ofoperating, they must rst exhibit the characteristics of Agile teams in Flow:

Are empowered and collaborative in decision making

Begin to dene a denition of done for how they make commitments to valuedelivery

Use a time-boxed rhythm of high-quality product delivery

Dene, build and test every committed feature within the time box

Engage in inspection and adaption practices that amplify their learning about teamagreements, process and their definition of done

To then enable adoption of the Pull principle for programs, let us first establish a basicview of Pull; that is, what does a team in Pull look like? From this base, we can thenevaluate 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 ahighly disciplined adoption of Pull, pilot teams use two levers. First, the teams can alwayspull prioritized, ready, valued feature definitions from the backlog maintained by thebusiness. Secondly, the business in turn can always pull ready, valued, done featuresfor final user and system testing with potential customers. Gone are the days of pushingrequirements onto teams or waiting for drop points to do final acceptance tests on keyfeatures or system performance.

Figure 3 is one teams denition of done that shows its discipline to maintain a Flow ofvalue 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/16


With this definition of 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 definition so that readiness continuallyattacks any impediments to the businesss ability to pull ready valued items.

The Pull discipline also has a bit more to it with regard to business discipline. Itconstrains over-elaboration of 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. Pulldoesnt allow surprises about business requests. It simply eliminates the waste of waitingfor the prioritization and definition of the items. Pull also ensures that the business isonly elaborating the highest-value items. Teams do not wait for all items to be completelydetailed in order to pull work forward.

Critical to setting up Pull is an effective release planning mechanism. This mechanismbegins with a product roadmap to guide the prioritization of features across themedreleases. 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. Thebusiness benets from a longer term view into the delivery teams best work at estimating

a sequence of stories. Delivery teams, in turn, can anticipate upcoming stories to pull offthe 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 followingcharacteristics:

The team has no surprises and no waiting in pulling sufciently detailed valuedenition of items from the businesss backlog.

The business is always working one or two time boxes ahead in its own Flow sothat items are always in a ready state to be pulled from the prioritized backlog.

The business always has the option to pull done RTF (Running Tested Feature)value items at the end of each time box.

The team has a multi-release roadmap and commitment to the scope of the currentrelease.

The team holds a policy of collaborative emergent design based on simplicity andthe feedback from the done items.

The deliverable is stable, has zero defect backlog and therefore invites morepossibility of shift in the eventual set of valuable features for release.

B. Potential Roadblocks

There are potential roadblocks to adopting the Pull discipline including:

Lack of collaboration from the business: Agile asks product owners, such as productmanagers, business analysts or architects, to be much more engaged than intraditional waterfall approaches. A teams ability to mature can be stopped in itstracks due to distracted or inaccessible product owners. Teams may also unearthunclear acceptance procedures that were hiding in the Quality Assurance (QA)phase at the end of their projects.


7/16


Organizational change ceiling: Because of this new, highly visible demand onthe business organization, Pull maturity may encounter bumps and bruises. Pullalso requires that testing be fully integrated into the team, as this is no longer anoptional part of the definition of done. Pull discipline requires the organizationto consider an organizational change backlog, critical once we move to the next

level of scaling and maturity.

Weak feedback loops on value: Without product ownership engaged, a disciplinedteam will still push up against a roadblock of delayed feedback loops on valuedelivery. Are priorities right? Are the delivered features meeting customerexpectations? Does the cost of delivery (team and organizational resources) 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 inProcess (WIP) at any given time is decreased. In addition, the team releases fully-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 ahigher view: The team sees the whole and has a clear path to delivering a high-valueproduct. A release view of the product elevates the visibility of each iterations impacton the product for the team, the customer representative and all stakeholders. With thishigher view, and the ability to pull only ready backlog items, the Agile team pushes backon backlog items that arent ready. They are able to recognize that these items that arenot 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, releasequality is fixed. Teams now work with a zero defect mentality across time boxes and theentire system, not just within a time box for new functionality.

2Photo by Jean Tabaka used with permission from Rally Software, Boulder, CO


8/16


C. Tooling the Agile Team for Pull

When implementing Pull, tool requirements for visibility and signaling increase. Teamsin Pull track tasks, acceptance criteria, automated-testing requirements and defects. Teamssignal in real time how to work more effectively and measure done. For visibility into

release success, teams must also have access to cycle-time metrics. For example, Howlong did it take me to fix that defect?

Finally, the Pull discipline requires a highly visible, real-time automated and prioritizedbacklog. At any time, the business must be open to discussions about whats comingnext in the backlog, and be ready for the delivery team to plan and estimate. In thisautomated, prioritized backlog, business owners must be able to show emergingelaboration of information about the items. Backlog items open themselves up for 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 of 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 fix their functional- and regression-testing batches byimplementing automated functional testing and system-build capabilities. See Figure 6below.

Figure 6: Continuous Quality in Pull

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

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

Not overstufng their time boxes, resulting in cost savings from smoother Flow

Providing the business market with deployment decisions based on truly donevalue items

Fixing their quality thresholds (as a result of lessening the accumulation oftechnical debt)

Increasing value gained from direct feedback from a fully engaged productmanagement/ownership organization

Making deployment/release decisions based on completed items, and taking in awider view of the product, beyond one time box at a time

However, Pull discipline at the pilot team level has its limitations. Quality andthroughput benefits are still limited to the scope of any single one of the pilot teams.Now is the time to scale these practices, tools and processes beyond a single team, up to acollection of teams that can deliver large-scale and complex systems.


10/160


III. Scaling the Pull Discipline to Programs

Scaling the success of independent pilot teams to multiple, interdependent teams requiresthe same disciplines guided by the Flow and Pull principles. But now the stakes arehigher. 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 teamsthat must rely on each other either for resources, feature completion or release readiness.Adopting Agile with Pull discipline within a program is a true test of an organizationsintent to scale.

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

Bring in members from the pilot teams that matured through Flow and Pull.

Bring in outside Agile coaches familiar with the disciplines required to succeed atthe program level.

Combine the two approaches and establish a train the trainer practice of growing

the programs own staff of seasoned, disciplined Agile coaches.

Any Program Pull approach for 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, total participation can bring up other concerns. For example, afunctional manager who owns all the QA resources might worry about how this newway of doing business is going to impact their overall QA organizations processes andtools. 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 of success.

Remember, Agile requires that teams grow by splitting into teams of teams within theprogram versus one big team. The ensuing hand-wringing regarding splitting teamsrequires a well-articulated organizational rollout plan for the program. The rolloutdemands true, engaged executive sponsorship. For distributed program teams, thechallenges only increase. And yet, the Pull discipline requires program managers andthe organization to engage the entire program membership in the success of the productrelease.

In addition to executive support, the program has to know how its going to scale up tothe next level. If there is no detailed plan for moving forward, or if the program doesntaddress all the valid concerns about organizational change, youre likely to hit a glassceiling at a single program level.

A. Characteristics of a Program in Pull

So, given these requirements and concerns for moving a program to a discipline of Pull,what are the ultimate characteristics of such a program?

A cross-functional program steering team that clears obstacles and tends to thevision

Company infrastructure that supports cross-program, cross-team integrated builds

Adaptive Agile work standards that are fully embraced across all teams andcontinually inspected and adapted


11/161


Large-scale release planning meetings that establish a synchronized schedule anddependency mitigation strategies

Cross-team resources balanced on a synchronized release schedule

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 intoseemingly insurmountable roadblocks:

Functional efdoms or silos: The QA functional manager mentioned earlier or anoperations team is not prepared to work at the pace demanded of an Agile programin Pull.

Lack of infrastructure investment to coordinate distributed teams. The organizationmay be unwilling to acknowledge that the Pull discipline requires investing ininfrastructure/tooling for increased signaling, visibility, tracking and quality.

Other parts of the organization dont know how to handle the programs pace:Marketing says, We cant release that fast because our customers cant handle it.The support and operations organizations may also be reluctant to take on thefaster schedules and more feedback, despite the obvious benefits for product valuedelivery.

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

The teams get to market faster with a higher-value, higher-quality solution

The teams embrace increased feature and resource complexity

There is a unied program vision

The quality of the entire solution increases dramatically


12/162


C. A Successful Pull Example

In 2004, BMC Software, headquartered in Houston, Texas, decided it needed to moveto an aggressive release schedule for one of its product lines. Their objective was to getto 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 productdeployment. For this effort, they formed a program of teams of 93 members (developers,testers, tech writers, and architects) and adopted the Pull approach of Agile productdelivery. The program held regular cross-team coordinated release planning meetings andadopted a Program steering committee to maintain the vision, remove impediments andcontinually invest in the tooling and infrastructure.

What was the result of this Pull discipline? BMC delivered a product with 600,000 lines ofcode four-and-a-half times faster than the industry average. Their overall program teamwas twice the size of the 45-person average, but delivered 11 percent fewer defects thanaverage. When compared to comparable 93-person teams, they had 70 percent fewerdefects. 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

increments and faster time-to-market than competitors products. Rally coaching on thePull discipline supported by Rally tooling contributed signicantly to BMCs success. Thiscase study is part of the larger QSMA Agile Impact Study available at www.rallydev.com/agileimpactreport.

D. Synchronized Calendars and Disciplined Program Pull

To reach BMCs level of success, a great deal of coordination must be built into aprograms cadence. Program teams synchronize their release calendars through a full-team release planning meeting. All team members participate in the discussions, theplanning and the release commitment. Everyone plans the entire product release together(see Figure 8). Every aspect of the program is lined up and synchronized, includingmeasurement spots and iteration planning.

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


13/163


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 releasetrain synchronizes schedule, dependencies, and rhythm across teams.

2. Steering committee rhythm clears the prioritized organizational impediments. Dailyand weekly rhythms match the teams rhythms.

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

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

E. Tooling for Program Pull

Supporting program Pull requires tooling that elevates the signaling and trackingbeyond 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 todelegate dependent work and do rollups across all the programs teams. In addition toshared status across teams, a program in Pull needs visibility into system quality acrosscomponents, 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 movingtoward a truly expert level. If it doesnt aggressively embrace the Pull discipline and tryto scale, it will fail. The teams will remain a group of amateurs and potentially embracethe mentality of complacency, Now that I can do this, I will just keep doing it the sameway. Its very important now to invest in and raise the visibility of the incremental wins,and celebrate success. Also, consider re-investing the programs ROI benets to add moreinfrastructure for testing or integrating the complete software lifecycle for better feedbackmanagement.


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

IV. Conclusion

Agile is an approach that was originally formulated for single co-located teams. To growour industries and build software to solve the worlds toughest challenges, we need toscale 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 full benefits of 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.

If Team Pull and Program Pull are implemented correctly, Agile and Rally can dramaticallyshorten your development cycles, increase quality and productivity, speed value delivery,and put your entire organization on the path to being truly innovative. Rallys leadershipcan help your organization break free of older, plan-based methodologies and siloed toolswhile avoiding the pitfalls of a non-disciplined Agile adoption plan. Teams in Pull canlead to programs in Pull and ultimately organizations that Innovate.


15/16


16/16


About the Authors

Jean Tabaka is an Agile Fellow with Rally Software Development in Boulder, Colorado.With over 25 years of experience in the software development industry, she hasnavigated numerous plan-driven methodologies in a variety of contexts (government,

IT, consulting) and in a variety of roles (programmer, architect, project manager,methodologist). Her move to Agile software development approaches came in the late 90sas a result of studying DSDM in the UK. Since that time, she has become an Agile devotee,consulting with teams of all sizes worldwide wishing to derive more value faster throughthe adoption of Agile principles and practices.

She specializes in scaling Agile practices, applying Lean principles and practices, andbuilding continuous planning and testing into organizations. She also creates a strongcollaborative approach in how organizations adopt Agile. Ms. Tabaka is a CertifiedScrumMaster and Practitioner, a Certied ScrumMaster Trainer, and a CertiedProfessional Facilitator. She holds a Masters in Computer Science from Johns HopkinsUniversity and is the author of Collaboration Explained: Facilitation Skills for SoftwareProject Leaders published in the Addison-Wesley Agile Software Development Series. You

can reach her at [email protected].

Ryan Martens is the founder & Chief Technology Ofcer of Rally Software and an expertin assisting organizations in transitioning from traditional development processes tomore Agile techniques.

Before founding Rally Software Development his fourth software start-up Mr.Martens directed the corporate adoption of Internet technologies within QwestCommunications, and then moved on to co-found Avitek, a Boulder-based customsoftware development firm where he served as Vice President of Marketing & BusinessDevelopment. Mr. Martens successful efforts at Avitek culminated in an acquisition byBEA Systems in 1999. At BEA, Mr. Martens served as Director of Product Management for

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

sap lean pull for agile teams

Documents