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

com
By Jean Tabaka and Ryan Martens
Abstract:
Reaping the benets of Agile software development beyond the team level is an enticing
proposition. In fact, in todays 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:
The specifc 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 inadvertently
creating a classic fx that fails? Can Agile truly work at the Program level?
This white paper is based on actual experiences of professionals who helped steer many
of the largest Agile implementations done over the last ve 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
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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 difcult 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-
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 Thinking
1
, James Womack and Daniel Jones distill the work of Lean
manufacturing into ve key principles:
Specify value
Identify the value stream
Flow
Pull
Perfection
The rst two Lean principles match two fundamental principles of Agile: value denition
and value delivery. For the frst principle, Agile methods such as Scrum call for the
implementation of a prioritized product backlog to emphasize value denition. 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.
But there is more to learn from Lean Thinking. What do the Flow, Pull and Perfection
principles lend to Agile software development? And, how can they steer successful
enterprise Agile adoption?
1
Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Womack, James P. and Daniel T. Jones. Free
Press, 2003.
3
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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
big way by calling on teams to take on dramatic development process changes. For small
collaborative 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 nd 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 while
scaling
Perfection (which we refer to here as Innovate) provides the set of practices for
organizational 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 as
Enterprise Agile Adoption?
Our ve-step approach, structured around three Lean principles, establishes the order and
ranking 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 to
the enterprise level.
Our overall framework takes on this stair-step look:

Figure 1: The 5-Step Enterprise Agile Adoption Approach

4
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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 ow of value from the team.
Pull empowers a team or program to dene 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, the teams of teams can always pull ready and valued feature defnitions
from the involved business units. Second, the business can always pull ready and valued
features 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 nd a way
to 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 Flow
and 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
sits in the larger context of a 5-step Enterprise Agile Adoption; that is, Team Pull adoption
assumes a successful adoption of Team Flow. And, the Multi-Team Program Pull is actually
recommended 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 to
Program to Organization as follows:
Figure 2: Practice Overview for Team to Program to Organization for Enterprise Agile Adoption
5
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
Given our 5-step approach, before teams or programs can move to a Pull mode of
operating, they must frst exhibit the characteristics of Agile teams in Flow:
Are empowered and collaborative in decision making
Begin to defne a defnition of done for how they make commitments to value
delivery
Use a time-boxed rhythm of high-quality product delivery
Defne, build and test every committed feature within the time box
Engage in inspection and adaption practices that amplify their learning about team
agreements, process and their denition of done
To then enable adoption of the Pull principle for programs, let us rst establish a basic
view of Pull; that is, what does a team in Pull look like? From this base, we can then
evaluate 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 dene release features, resulting in good,
functioning software increments that are not dependent on other project teams. In a
highly disciplined adoption of Pull, pilot teams use two levers. First, the teams can always
pull prioritized, ready, valued feature denitions from the backlog maintained by the
business. Secondly, the business in turn can always pull ready, valued, done features
for nal user and system testing with potential customers. Gone are the days of pushing
requirements onto teams or waiting for drop points to do nal acceptance tests on key
features or system performance.
Figure 3 is one teams defnition of done that shows its discipline to maintain a Flow of
value delivery and a true readiness of Pull for the product team.

Figure 3: A Sample Denition of Done for an Item (Story) Ready to Pull
6
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
With this denition 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 denition so that readiness continually
attacks 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. 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
doesnt allow surprises about business requests. It simply eliminates the waste of waiting
for the prioritization and denition 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, denes a release time box that is broken into groups of iterations.
The discipline of release planning helps both the business and development teams. The
business benefts 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 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:
The team has no surprises and no waiting in pulling suffciently detailed value
defnition of items from the businesss backlog.
The business is always working one or two time boxes ahead in its own Flow so
that 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 current
release.
The team holds a policy of collaborative emergent design based on simplicity and
the feedback from the done items.
The deliverable is stable, has zero defect backlog and therefore invites more
possibility 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 product
managers, business analysts or architects, to be much more engaged than in
traditional waterfall approaches. A teams ability to mature can be stopped in its
tracks due to distracted or inaccessible product owners. Teams may also unearth
unclear acceptance procedures that were hiding in the Quality Assurance (QA)
phase at the end of their projects.
7
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
Organizational change ceiling: Because of this new, highly visible demand on
the 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 denition 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.
Weak feedback loops on value: Without product ownership engaged, a disciplined
team will still push up against a roadblock of delayed feedback loops on value
delivery. Are priorities right? Are the delivered features meeting customer
expectations? Does the cost of delivery (team and organizational resources) provide
sufcient ROI to continue the effort?
Once team Pull is established, there are many benets. The highest-priority features,
and the ones most likely to be used, are completed rst. The percentage of Work in
Process (WIP) at any given time is decreased. In addition, the team releases fully-tested
increments 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. A release view of the product elevates the visibility of each iterations impact
on 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
on backlog items that arent ready. They are able to recognize that these items that are
not ready will adversely impact their commitment to release goals.
Figure 4: A Team Planning a Release Across Time Boxes
2

When Pull discipline is fully embraced and visibility is raised to the release level, release
quality is xed. Teams now work with a zero defect mentality across time boxes and the
entire system, not just within a time box for new functionality.
2
Photo by Jean Tabaka used with permission from Rally Software, Boulder, CO
8
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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 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, How
long did it take me to x that defect?
Finally, the Pull discipline requires a highly visible, real-time automated and prioritized
backlog. At any time, the business must be open to discussions about whats coming
next 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
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
In addition to a real-time project management system that allows them to see the
complete status, teams need to x their functional- and regression-testing batches by
implementing automated functional testing and system-build capabilities. See Figure 6
below.

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 benets of teams in Pull? Teams become much more adept at:
Not overstuffng their time boxes, resulting in cost savings from smoother Flow
Providing the business market with deployment decisions based on truly done
value items
Fixing their quality thresholds (as a result of lessening the accumulation of
technical debt)
Increasing value gained from direct feedback from a fully engaged product
management/ownership organization
Making deployment/release decisions based on completed items, and taking in a
wider 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 benets 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 a
collection of teams that can deliver large-scale and complex systems.
10
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
III. Scaling the Pull Discipline to Programs
Scaling the success of independent pilot teams to multiple, interdependent teams requires
the same disciplines guided by the Flow and Pull principles. But now the stakes are
higher. 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.
Adopting Agile with Pull discipline within a program is a true test of an organizations
intent to scale.
To scale Agile adoption to Pull for the program, an organization must rst consider the
best 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 at
the 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 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
amplifed. However, total participation can bring up other concerns. For example, a
functional manager who owns all the QA resources might worry about how this new
way of doing business is going to impact their overall QA organizations processes and
tools. 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
demands true, engaged executive sponsorship. For distributed program teams, the
challenges 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.
In addition to executive support, the program has to know how its going to scale up to
the next level. If there is no detailed plan for moving forward, or if the program doesnt
address all the valid concerns about organizational change, youre likely to hit a glass
ceiling 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 the
vision
Company infrastructure that supports cross-program, cross-team integrated builds
Adaptive Agile work standards that are fully embraced across all teams and
continually inspected and adapted
11
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
Large-scale release planning meetings that establish a synchronized schedule and
dependency 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 into
seemingly insurmountable roadblocks:
Functional fefdoms or silos: The QA functional manager mentioned earlier or an
operations team is not prepared to work at the pace demanded of an Agile program
in Pull.
Lack of infrastructure investment to coordinate distributed teams. The organization
may be unwilling to acknowledge that the Pull discipline requires investing in
infrastructure/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 the
faster schedules and more feedback, despite the obvious benets for product value
delivery.
And yet, programs willing to invest in the time, training and discipline to move to Pull
can reap serious business benets:
The teams get to market faster with a higher-value, higher-quality solution
The teams embrace increased feature and resource complexity
There is a unifed program vision
The quality of the entire solution increases dramatically
12
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
C. A Successful Pull Example
In 2004, BMC Software, headquartered in Houston, Texas, decided it needed to move
to 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. 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 product
delivery. 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.
What was the result of this Pull discipline? BMC delivered a product with 600,000 lines of
code 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. When compared to comparable 93-person teams, they had 70 percent fewer
defects. As a result, BMC surpassed its competition and is enjoying incredible success.
This is the big benet of program Pull: nished products, not just single-team software
increments and faster time-to-market than competitors products. Rally coaching on the
Pull discipline supported by Rally tooling contributed signifcantly to BMCs success. This
case 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 a
programs cadence. Program teams synchronize their release calendars through a full-
team release planning meeting. All team members participate in the discussions, the
planning and the release commitment. Everyone plans the entire product release together
(see Figure 8). Every aspect of the program is lined up and synchronized, including
measurement 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
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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. Steering committee rhythm clears the prioritized organizational impediments. Daily
and weekly rhythms match the teams 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 unied build is used to signal stop-the-line
to all developers.
E. Tooling for Program Pull
Supporting program Pull requires tooling that elevates the signaling and tracking
beyond 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
delegate dependent work and do rollups across all the programs teams. In addition to
shared 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
toward a truly expert level. If it doesnt aggressively embrace the Pull discipline and try
to scale, it will fail. The teams will remain a group of amateurs and potentially embrace
the mentality of complacency, Now that I can do this, I will just keep doing it the same
way. 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 benefts to add more
infrastructure for testing or integrating the complete software lifecycle for better feedback
management.
14
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
Agile Lifecycle
Management
& O
peratio
n
s
Custom
er M
a
n
a
g
e
m
e
n
t
M
a
n
agem
ent
P
r
o
d
u
ct &
Portfolio
Requests
ROI & Adoption
Harden &
Release
Deploy &
Support
Business
Case
Collaborative
Development
Task, 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
our industries and build software to solve the worlds toughest challenges, we need to
scale 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 benets 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,
and put your entire organization on the path to being truly innovative. Rallys leadership
can 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
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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
Leaning IT: Applying the Principle of Pull to Scale Agile Teams
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 has
navigated 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 90s
as 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 through
the adoption of Agile principles and practices.
She specializes in scaling Agile practices, applying Lean principles and practices, and
building continuous planning and testing into organizations. She also creates a strong
collaborative approach in how organizations adopt Agile. Ms. Tabaka is a Certied
ScrumMaster and Practitioner, a Certifed ScrumMaster Trainer, and a Certifed
Professional Facilitator. She holds a Masters in Computer Science from Johns Hopkins
University and is the author of Collaboration Explained: Facilitation Skills for Software
Project Leaders published in the Addison-Wesley Agile Software Development Series. You
can reach her at jean.tabaka@rallydev.com.
Ryan Martens is the founder & Chief Technology Offcer of Rally Software and an expert
in assisting organizations in transitioning from traditional development processes to
more Agile techniques.
Before founding Rally Software Development his fourth software start-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 rm where he served as Vice President of Marketing & Business
Development. Mr. Martens successful efforts at Avitek culminated in an acquisition by
BEA 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 division
to more than $50 million in revenue within its rst twelve months.