Agility at Scale

IBM ag|||ty@sca|e
:
Become as Ag||e as
You Can Be
By Scott W. Ambler
Chief Methodologist for Agile and Lean, IBM Rational
Next page
IBM agility@scale
: Become as Agile as You Can Be

IBM ag|||ty@sca|e
"
:
Become as Ag||e as You Can Be
Next page
3 Foreword
4 lntroduction
5 The Agile Scaling Model
8 Core Agile Development
10 Disciplined Agile Delivery
14 Agility at Scale
15 Agile Online Bartering
19 Become as Agile as You Can Be
20 Parting Thoughts and References
21 About the Author 21 About the
Author
Contents
IBM agility@scale

3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
3
Foreword
Scott Amblers work on Agile process maturity provides the structure that is needed by many companies
seeking to make the transition to Agility while still meeting their overall organizational needs and requirements.
In some cases, this means establishing IT governance and compliance while others simply need just enough
process to get the job done. Scotts work teaches us that the Agile Manifesto emphasis of Individuals and
Interactions over processes and tools, does not rule out mature repeatable process frameworks where they
make sense. More importantly, as an Agile thought leader, Scott Ambler gives us the necessary structure to
understand Agile process maturity and thereby successfully implement Agile processes that can support part
of or, in some cases, the entire systems development lifecycle. Scott raises the bar by helping us implement
disciplined agile processes which address one or more scaling factors such as team size or distributed teams
that are critical for scaling Agility.
Agile works and the results of many Agile initiatives have been stunning in their success in terms of both quality
and productivity. With Scott Amblers help we can enhance our Agile processes to the point where we can
literally be as Agile as we can be while meeting larger organizational needs for process repeatability and Lean
Agile frameworks. I encourage you to read this work carefully as it takes us on a journey to successfully
implementing Agile processes in ways that yield dramatic results and increased success in systems
development.
Prev|ous page Next page
Bob A|e||o
Ed|tor |n Oh|ef
OM Orossroads
Author of 'Oonfgurat|on Management Best Pract|ces:
Pract|ca| Methods that Work |n the Rea| Wor|d "
IBM agility@scale

4
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
|nc|ud|ng but not ||m|ted to e-commerce
compan|es, fnanc|a| compan|es,
manufacturers, reta||ers and government
agenc|es
Ag||e software deve|opment techn|ques
have taken the |ndustry by storm, w|th 76
percent of organ|zat|ons report|ng that they
had one or more ag||e projects under way
[1|
. Ag||e |s becom|ng w|despread because |t
works - organ|zat|ons are fnd|ng that ag||e
project teams, when compared to trad|t|ona|
project teams, enjoy h|gher success rates,
de||ver h|gher qua||ty, have greater |eve|s of
stakeho|der sat|sfact|on, prov|de better
return on |nvestment (ROl} and de||ver
systems to market sooner
[2, 3|
.
Ag||e software deve|opment |s an
evo|ut|onary, h|gh|y co||aborat|ve, qua||ty-
focused approach to software deve|opment
where potent|a||y sh|ppab|e work|ng
software |s produced on a regu|ar bas|s.
Ag||e software deve|opment processes
|nc|ude Scrum, Extreme Programm|ng (P},
D|sc|p||ned Ag||e De||very (DAD} and Ag||e
Mode||ng (AM}, to name a few. A|though
ag||e approaches are often equated to the
deve|opment of Web-based app||cat|ons, |n
rea||ty they`re a|so be|ng app||ed to mob||e
app||cat|ons, fat-c||ent app||cat|ons,
bus|ness |nte|||gence (Bl} systems and even
ma|nframe app||cat|ons. They`re be|ng
app||ed by a range of organ|zat|ons,
IBM agility@scale

5
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Th|s eBook beg|ns w|th an overv|ew of the
Ag||e Sca||ng Mode| (ASM}, a framework we
use to prov|de context to the p|ethora of
ag||e methodo|og|es ava||ab|e today. lt then
descr|bes each of the three categor|es |n
deta|| - core ag||e, d|sc|p||ned ag||e de||very,
and ag|||ty at sca|e - show|ng how they
bu||d on one another. Then |t works through
an examp|e of the deve|opment of an on||ne
barter|ng system and fn|shes w|th some
adv|ce for successfu| ag||e adopt|on.
The Agile Scaling Model (ASM)
The Ag||e Sca||ng Mode| (ASM}
[4|
|s a
contextua| framework for effect|ve adopt|on
and ta||or|ng of ag||e pract|ces to meet the
un|que cha||enges faced by a system
de||very team of any s|ze. F|gure 1 overv|ews
the ASM, dep|ct|ng how the ASM
d|st|ngu|shes between three sca||ng
categor|es:
1. Core agile development. Oore ag||e
methods, such as Scrum and Ag||e
Mode||ng, are se|f govern|ng, have a va|ue-
dr|ven system deve|opment ||fecyc|e (SD|O},
and address a port|on of the deve|opment
||fecyc|e. These methods, and the|r
pract|ces, such as da||y stand up meet|ngs
and requ|rements env|s|on|ng, are opt|m|zed
for sma||, co-|ocated teams deve|op|ng fa|r|y
stra|ghtforward systems.
2. Disciplined agile delivery. D|sc|p||ned
ag||e de||very processes - wh|ch |nc|ude The
Open n|fed Process (OpenP} and the
D|sc|p||ned Ag||e De||very (DAD} method
|tse|f - go further by cover|ng the fu||
software deve|opment ||fecyc|e from project
|ncept|on to trans|t|on|ng the system |nto
your product|on env|ronment (or |nto the
marketp|ace as the case may be}.
D|sc|p||ned ag||e de||very processes are se|f
Learn More
Be As Agile As You Can Be (webcast)
IBM agility@scale

6
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
organ|z|ng w|th|n an appropr|ate governance
framework and take both a r|sk and va|ue
dr|ven approach to the ||fecyc|e. ||ke the
core ag||e deve|opment category, th|s
category |s a|so focused on sma||, co-
|ocated teams de||ver|ng fa|r|y
stra|ghtforward so|ut|ons. To address the fu||
de||very ||fecyc|e you need to comb|ne
pract|ces from severa| core methods, or
adopt a method wh|ch has a|ready done so.
3. Agility at Scale. Th|s category focuses
on d|sc|p||ned ag||e de||very where one or
more sca||ng factors are app||cab|e. The
e|ght sca||ng factors are team s|ze,
geograph|ca| d|str|but|on, regu|atory
comp||ance, organ|zat|ona| comp|ex|ty,
techn|ca| comp|ex|ty, organ|zat|ona|
d|str|but|on, doma|n comp|ex|ty, and
enterpr|se d|sc|p||ne. A|| of these sca||ng
factors are ranges, and not a|| of them w|||
||ke|y be app||cab|e to any g|ven project, so
you need to be fex|b|e when sca||ng ag||e
approaches to meet the needs of your
un|que s|tuat|on. To address these sca||ng
factors you w||| need to ta||or your
d|sc|p||ned ag||e de||very pract|ces and |n
some s|tuat|ons adopt a handfu| of new
pract|ces to address the add|t|ona| r|sks that
you face at sca|e.
IBM agility@scale

7
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Figure 1: Agile Scaling Model (ASM)
IBM agility@scale

8
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Core Agile Development
Oore ag||e methods address a port|on of the
software deve|opment ||fe cyc|e. They
conform to the va|ues and pr|nc|p|es of the
Ag||e Man|festo
[5, 6|
wr|tten |n 2001 by a
group of 17 software deve|opment experts,
and are typ|ca||y descr|bed as a cohes|ve
co||ect|on of pract|ces. Examp|es of core
ag||e processes |nc|ude:
Scrum. The focus of Scrum |s project
|eadersh|p and requ|rements management.
Scrum defnes a h|gh-|eve| ||fe cyc|e for
construct|on |terat|ons (what Scrum ca||s
'spr|nts"}, see F|gure 2, and severa|
pract|ces such as a da||y stand-up 'Scrum"
meet|ng, product owner, product back|og,
|terat|on/spr|nt p|ann|ng and potent|a||y
sh|ppab|e software.
Extreme Programming (XP). P |s a
co||ect|on of pract|ces for software
construct|on, |nc|ude refactor|ng, test-frst
des|gn, pa|r programm|ng, on-s|te-
customer, cont|nuous |ntegrat|on, who|e
team and co||ect|ve ownersh|p. Note that
P |s c|ose to be|ng a fu||-fedged,
d|sc|p||ned ag||e de||very method but |s
m|ss|ng exp||c|t project |n|t|at|on and re|ease
pract|ces.
Agile Modeling (AM). AM |s a co||ect|on of
pract|ces for ||ght-we|ght mode||ng and
documentat|on, |nc|ud|ng requ|rements
env|s|on|ng, executab|e spec|fcat|ons,
act|ve stakeho|der part|c|pat|on, pr|or|t|zed
requ|rements, and prove |t w|th code.
Agile Data (AD). AD |s a co||ect|on of
pract|ces for database deve|opment,
|nc|ud|ng ag||e data mode||ng, database
test|ng, database refactor|ng, and
cont|nuous database |ntegrat|on.
Learn More
Scaling Scrum: Lessons from the
Trenches (webcast)
IBM agility@scale

9
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Sprint
Backlog
Sprint
Tasks
Working
System
Funding and
Feedback
30-day
Sprint
Daily
Work
Daily Scrum
Meeting:
Share Status and
identify potential
issues
Sprint review: Demo system
to stakeholders and gain funding
for next Sprint Retrospective:
Learn from your experiences
Planning session to select
requirements for current
Sprint and to identify work tasks
Figure 2. Scrum construction life cycle
IBM agility@scale

10
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
adopt|ng just the r|ght amount of ceremony
for the s|tuat|on they face.
Examp|es of |eve| 2 ag||e processes
|nc|ude:
Open Unied Process (OpenUP).
OpenP
[5|
, the defn|t|on of wh|ch |s
ava||ab|e v|a open source, comb|nes and
extends pract|ces from Scrum, P, AM and
Rat|ona| n|fed Process (RP} for co-
|ocated ag||e teams that are bu||d|ng
bus|ness app||cat|ons. OpenP pract|ces
|nc|ude who|e team, da||y stand-up meet|ng,
pr|or|t|zed work |tems, r|sk-dr|ven ||fe cyc|e,
TDD, act|ve stakeho|der part|c|pat|on and
cont|nuous |ntegrat|on.
Dynamic System Development Method
(DSDM). DSDM |s an ag||e de||very process
or|g|na||y based on Rap|d App||cat|on
Deve|opment (RAD}, wh|ch |s often used to
Disciplined Agile Delivery
D|sc|p||ned ag||e de||very processes extend
core ag||e deve|opment methods to address
the fu|| system de||very ||fe cyc|e (SD|O}. As
the cr|ter|a suggest (see s|debar: Are You
Rea||y Ag||e?}, they a|so tend to 'd|a| up"
certa|n aspects of ag||e deve|opment, such
as test|ng, measurement and process
|mprovement. D|sc|p||ned ag||e de||very |s an
evo|ut|onary (|terat|ve and |ncrementa|}
approach that regu|ar|y produces h|gh-
qua||ty so|ut|ons |n a cost-effect|ve and
t|me|y manner v|a a r|sk- and va|ue-dr|ven
||fe cyc|e. lt |s performed |n a h|gh|y
co||aborat|ve and se|f-organ|z|ng manner,
w|th act|ve stakeho|der part|c|pat|on to
ensure that the team understands and
addresses the chang|ng needs of |ts
stakeho|ders. D|sc|p||ned ag||e de||very
teams prov|de repeatab|e resu|ts by
Learn More
Take the Agile Fitness Survey
IBM agility@scale

11
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
deve|op user-|nterface |ntens|ve
app||cat|ons. DSDM pract|ces |nc|ude
prototyp|ng, test throughout the ||fe cyc|e,
revers|b|e changes and feas|b|||ty study.
Disciplined Agile Delivery (DAD). DAD
[6|
|s a hybr|d method wh|ch comb|nes
strateg|es and pract|ces from severa|
software methods, |nc|ud|ng Scrum, P,
AM, Ag||e Data, and the Open n|fed
Process (OpenP}. My apo|og|es for any
confus|on around us|ng the same name for
both the ASM category and the method..
F|gure 3 dep|cts the ||fe cyc|e of the
D|sc|p||ned Ag||e De||very (DAD} method.
Th|s ||fe cyc|e expands upon the Scrum
construct|on ||fe cyc|e |n severa| |mportant
ways. F|rst, |t |nc|udes an exp||c|t project
|ncept|on phase where you do some |n|t|a|
mode||ng, start putt|ng together your team,
and ga|n |n|t|a| project fund|ng. Second, |t
extends the product back|og concept to
|nc|ude not on|y funct|ona| requ|rements but
a|so defects and other work |tems such as
prov|d|ng feedback on work from other
teams, tak|ng tra|n|ng courses, and so on.
Th|rd, |t |nc|udes exp||c|t trans|t|on/re|ease
and product|on phases.
IBM agility@scale

12
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Figure 3. Disciplined Agile Delivery (DAD) system-development life cycle
IBM agility@scale

13
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents Are You Really Agile?
A common problem in many organizations is that
undisciplined ad hoc" teams will claim to be agile,
often simply because they're not writing any
documentation and have read an article or two about
how cool agile is. Unfortunately, those ad hoc teams
often run into trouble and give actual agile teams a
bad name. l suggest the following criteria to
determine whether a team is agile:
1. Value. Agile teams provide value to their
stakeholders on a regular basis.
2. Validation. Agile teams do, at a minimum,
continuous developer regression testing. Disciplined
agile teams take a Test-Driven Development (TDDj
approach.
3. Active stakeholder participation. Agile teams
work closely with their stakeholders, ideally on a daily
basis.
4. Self organization. Agile teams are self-organizing,
and disciplined agile teams work within an
appropriate governance framework.
5. Improvement. Agile teams regularly reect on, and
disciplined teams also measure, how they work
together, and then act to improve on their ndings in a
timely manner.
Several of the terms in the above criteria are
underlined to indicate where your strategy needs to
be exible. For example, some agile teams will
produce working software every two weeks, whereas
others may be in a more complex situation and may
do so only every two months. Different situations
require different strategies, implying that one process
size does not t all. Sadly, the 2010 How Agile Are
You? Survey
[7|
found that only 53% of agile" teams
met all ve of these criteria, with self organization as
the most challenging criterion to fulll.
IBM agility@scale

14
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Agility at Scale
ln the ear|y days of ag||e, the app||cat|ons
where ag||e deve|opment was app||ed were
sma||er |n scope and re|at|ve|y
stra|ghtforward. Today, organ|zat|ons app|y
ag||e strateg|es to a broader set of projects.
Th|s |s what lBM ag|||ty@sca|e |s a|| about
-exp||c|t|y address|ng the comp|ex|t|es that
d|sc|p||ned ag||e de||very teams face |n the
rea| wor|d. F|gure 4 g|ves an overv|ew of the
e|ght sca||ng factors of ag||e deve|opment.
Each factor has a range of comp|ex|t|es,
and each team w||| have a d|fferent
comb|nat|on and therefore w||| need a
process, team structure and too||ng
env|ronment ta||ored to meet |ts un|que
s|tuat|on. Oase ag||e processes on the ASM
work best when bas|ca||y a|| factors are at
the |eft-hand s|de (the |ow-comp|ex|ty s|de},
a|though they can potent|a||y be ta||ored to
address greater comp|ex|ty w|th strateg|es
from h|gher-|eve| processes. D|sc|p||ned
ag||e de||very processes typ|ca||y assume
that one or more of the factors are s||ght|y
to the r|ght, a|though you are cons|dered to
be 'at sca|e` when one or more factors are
s|gn|fcant|y to the r|ght (the h|gh-comp|ex|ty
s|de}.
When |t comes to too||ng, many ag||e teams
w||| fnd that they can make do w|th open
source too|s when most sca||ng factors are
to the |eft. But, when they fnd themse|ves |n
ag|||ty at sca|e s|tuat|ons they soon d|scover
that they need to adopt more soph|st|cated
too|s. To succeed at sca||ng ag||e, you w|||
need too|s that |ntegrate eas||y, are
suffc|ent|y |nstrumented to prov|de the
metr|cs requ|red for effect|ve governance,
support d|str|buted deve|opment, enhance
co||aborat|on between d|sparate team
Learn More
Adapt Agile Methods for Complex
Environments (whitepaper)
IBM agility@scale

15
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Team Size
Geographical Distribution
Regulatory Compliance
Domain Complexity
Organizational Distribution
Technical Complexity
Enterprise Discipline
Organizational Complexity
Under 10
Developers
Co-located
Low Risk
Straightforward
Globally
Distributed
Thousands of
Developers
Low Risk
Intricate/
Emerging
Collaborative
Homogenous
Flexible
Project
Focus
Enterprise
Focus
Rigid
Heterogeneous/
Legacy
Contractual
Simple Complex
Figure 4. Potential scaling factors for software development
IBM agility@scale

16
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
members, and automate as much of the
work as poss|b|e to comp|y w|th regu|at|ons.
Jazz-comp||ant too|s, see www.jazz.net, are
very good opt|ons for ag||e teams work|ng
at sca|e.
Agile Online Bartering
The best way to understand ag||e software
deve|opment at sca|e |s by examp|e. SWA
lnternat|ona|, a fct|t|ous company, wanted
to extend |ts ex|st|ng e-commerce offer|ngs
by add|ng barter|ng funct|ona||ty. W|th the
current econom|c t|mes as they are, the
company found that fewer peop|e were
on||ne purchas|ng products from them.
Off|ne, SWA had not|ced that some of |ts
customers were try|ng to barter, offer|ng
the|r serv|ces to he|p pay down the|r ex|st|ng
debt to SWA. The company fe|t the t|me
was r|pe for on||ne barter|ng.
SWA put together a team that wou|d
eventua||y grow to 25 peop|e, composed of
two subteams, one |n Toronto and the other
|n San Franc|sco, p|us severa| peop|e
work|ng from the|r home offces |n other
c|t|es. The company chose to fo||ow the
D|sc|p||ned Ag||e De||very (DAD} method w|th
two-week |terat|ons. The frst |terat|on was
spent do|ng |n|t|a|-requ|rements env|s|on|ng,
w|th four sen|or bus|ness staff, four sen|or
deve|opers on the project, two operat|ons
staff members and the ch|ef techno|ogy
offcer (OTO}.
The goa|s were not on|y to understand the
scope of the new system but a|so to come
to stakeho|der concurrence regard|ng what
that scope was, thereby reduc|ng bus|ness
r|sk. ln para||e|, the OTO and sen|or
deve|opers d|d h|gh-|eve| arch|tecture
env|s|on|ng to |dent|fy the subsystems and
the|r |nterfaces, cr|t|ca| |nformat|on requ|red
to sp||t the work appropr|ate|y between the
IBM agility@scale

17
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
work was performed |n Toronto, the
headquarters for SWA lnternat|ona|, w|th
three members of the San Franc|sco team
|nvo|ved. The team bu||t a s|mp|e Web page
that a||owed an end user to se|ect an |tem
from a ||st and then make a barter|ng offer
for |t. The offer was then pers|sted by the
system, and an e-ma|| not|ce was sent to
the owner of the |tem for wh|ch the offer
had been made. The team ran |oad tests
show|ng that the system worked w|th 500
concurrent users for a per|od of 10 hours
- a cr|t|ca| performance requ|rement for the
system. At the end of the |terat|on, they
demonstrated the system to the or|g|na|
stakeho|ders who had been |nvo|ved |n
sett|ng the requ|rements env|s|on|ng for the
prev|ous |terat|on, prov|ng that the
arch|tecture for the system worked. At the
end of the frst month, they had reduced
both the|r bus|ness and techn|ca| r|sks
substant|a||y.
two subteams - d|str|buted ag||e teams
prefer to organ|ze themse|ves around the
arch|tecture |nstead of around a job funct|on
(e.g., hav|ng the deve|opers |n one |ocat|on,
the testers |n another, the mode|ers |n
another and so on}. One member of the
bus|ness staff was an expert |n regu|atory
|ssues, an |mportant |ssue because SWA
was enter|ng a new ||ne of bus|ness and
pub||c|y traded |n the .S. (hence,
Sarbanes-Ox|ey comp||ance was an |ssue}.
Two of the bus|nesspeop|e became product
owners, one for each subteam, for the rest
of the project. The product owner |s the
person who pr|or|t|zes the requ|rements and
prov|des deta||ed |nformat|on about the
bus|ness to deve|opers.
The second |terat|on focused on deve|op|ng
an end-to-end work|ng ske|eton of the
system to prove that the arch|tecture
actua||y works. To s|mp||fy th|s effort, the
IBM agility@scale

18
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
For the next four construct|on |terat|ons, the
work was sp||t between the Toronto and
San Franc|sco teams, w|th the Toronto team
focus|ng on the fnanc|a| process|ng (SWA
takes a fee for each swap}, tax ca|cu|at|on
and rem|ttance, and management report|ng,
wh||e the San Franc|sco team focused on
the trad|ng funct|ona||ty. Both teams needed
to coord|nate the|r work on a da||y bas|s,
w|th the arch|tecture owner on each team
serv|ng as the pr|mary contact po|nt for
techn|ca| |ssues (often putt|ng together the
r|ght techn|ca| peop|e on each team to
reso|ve an |ssue}, and the product owners
coord|nat|ng the requ|rements. A person
||v|ng |n Mau| was the '|ndependent test
team," |ntegrat|ng the ent|re system every
day and perform|ng exp|oratory test|ng on |t
to |ook for bugs the deve|opers had
m|ssed
[8|
. Even though the deve|opment
team was do|ng comprehens|ve regress|on
test|ng of |ts own, many prob|ems st||| got
past them, so the defects the |ndependent
tester found were reported back to the
deve|opment teams v|a the|r Jazz-based
too|s. The frst vers|on of the system was
de||vered |nto product|on after three months,
and subsequent re|eases every s|x weeks
(three |terat|ons} after that.
Become as Agile as You Can Be
Many organ|zat|ons have been successfu| at
adopt|ng ag||e software deve|opment
approaches |n part because the greatest
focus unt|| now has been on p||ot projects
or on a handfu| of projects w|th|n an
organ|zat|on. However, successfu| process
|mprovement across an ent|re organ|zat|on
can prove d|ffcu|t to |mp|ement |n pract|ce,
often s|mp|y because by cast|ng a w|der net
you run |nto a w|der range of cha||enges.
l`ve found that the fo||ow|ng strateg|es can
he|p |ncrease your chances of success at
|mprov|ng your software process.
IBM agility@scale

19
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
4. Explicitly manage your process-
improvement efforts. A common ag||e
strategy |s for a team to refect regu|ar|y
on |ts approach so as to |dent|fy potent|a|
|mprovements, and then to act on those
|mprovements. Teams that exp||c|t|y track
the|r progress at adopt|ng |mprovements
are more successfu| than those that
don`t
[9|
.
5. Invest in your staff. You need to tra|n,
educate and mentor your staff |n ag||e
ph||osoph|es, processes, pract|ces and
too||ng. Focus on the peop|e |nvo|ved w|th
the p||ots at frst and tra|n them on a just-|n-
t|me (JlT} bas|s. Don`t forget sen|or
management, project management and
anyone |nterfac|ng w|th the p||ot team -
because these |nd|v|dua|s need to change
the way that they work, too.
1. Recognize that the true goal is to
improve. The rea||ty |s that nobody |s go|ng
to g|ve you a ||tt|e go|d star for be|ng ag||e.
They m|ght, however, reward you for
becom|ng more effect|ve at system de||very.
Ag||e techn|ques can often he|p w|th th|s,
but we need to remember that there are st|||
some pretty good |deas out there |n the
trad|t|ona| commun|ty, too.
2. Have a plan. For your process-
|mprovement efforts to be successfu|, you
shou|d frst determ|ne what your goa|s are,
what your current s|tuat|on |s and what
cha||enges you face.
3. Gain some experience. Adopt ag||e
approaches on one or more med|um-r|sk
p||ot project(s} to ga|n organ|zat|ona|
exper|ence as we|| as bu||d expert|se among
your staff. lt`s |mportant to expect to run
|nto a few prob|ems because p||ot projects
never go perfect|y.
Learn More
Organize Global Agile Teams
(Agile 101 class)
IBM agility@scale

20
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
References and Suggested Resources
1. Dr. Dobb's Journal's July 2009 State of the lT Union
Survey.
2. Dr. Dobb's Journal's 2008 Project Success Survey.
3. Dr. Dobb's Journal's 2010 Project Success Survey.
4. Ambler, S.W. (2009j. The Agile Scaling Model (ASMj:
Adapting Agile Methods for Complex Environments.
5. Kroll, P. and Maclsaac, B. (2006j. Agility and Discipline
Made Easy: Practices from OpenUP and RUP. Boston:
Addison-Wesley.
6. Ambler, S.W. (2009j. Disciplined Agile Delivery (DADj.
7. Ambler, S.W. (2010j. 2010 How Agile Are You? Survey
Results.
8. Ambler, S.W. (2003j. Agile Testing and Quality
Strategies: Discipline Over Rhetoric.
9. Kroll, P. and Krebs, W. (2008j. lntroducing lBM
Rational Self Check for Software Teams.
10. lBM Agile Development - Rational Home Page.
Parting Thoughts
Many organ|zat|ons have succeeded at
app|y|ng ag||e at sca|e, and you can, too. lf
you keep your w|ts about you and stay
away from some of the rhetor|c surround|ng
core ag||e methods you shou|d be okay.
M|n|ma||y, you want a d|sc|p||ned ag||e
system de||very approach that addresses
the fu|| ||fe cyc|e, not just parts of |t.
Remember that you w||| often fnd yourse|f |n
a sca||ng s|tuat|on and that d|fferent teams
w||| exper|ence d|ffer|ng sca||ng factors --
that`s okay because |t |s fa|r|y
stra|ghtforward to sca|e ag||e strateg|es w|th
effect|ve pract|ces and too||ng. W|th a
rea||st|c approach to process |mprovement
and w|th a b|t of he|p from the outs|de, you
can |ncrease your return on |nvestment
(ROl}, qua||ty, stakeho|der sat|sfact|on and
t|me to va|ue through ag|||ty at sca|e.
IBM agility@scale

21
3 Foreword
4 lntroduction
14 Agility at Scale
21 About the Author
Contents
Prev|ous page
About the Author
Scott W. Amb|er |s Oh|ef Methodo|og|st for
Ag||e and |ean w|th lBM Rat|ona|, and he
works w|th lBM customers around the
wor|d to |mprove the|r software processes.
He |s the founder of the Ag||e Mode||ng
(AM}, Ag||e Data (AD}, D|sc|p||ned Ag||e
De||very (DAD}, and Enterpr|se n|fed
Process (EP} methodo|og|es.
Amb|er |s the (co-}author of 19 books,
|nc|ud|ng Refactor|ng Databases, Ag||e
Mode||ng, Ag||e Database Techn|ques, The
Object Pr|mer 3rd Ed|t|on, and The
Enterpr|se n|fed Process. He |s a sen|or
contr|but|ng ed|tor w|th Dr. Dobb`s Journa|.
H|s persona| home page |s
ibm.com/software/rat|ona|/|eadersh|p/
|eaders/scott , and h|s Ag|||ty@Sca|e b|og
|s ibm.com/deve|operworks/b|ogs/page/
amb|er
Learn More
IBM Agile Development
Next page
Scott W. Ambler
Oh|ef Methodo|og|st for Ag||e and |ean,
lBM Rat|ona|
Copyright IBM Corporation 2010
IBM Global Services
Route 100
Somers, NY 10589
U.S.A.
Produced in the United States of America
November 2010
All Rights Reserved
IBM, the IBM logo, ibm.com, IBM agilty@scale and Rational
are trademarks or registered trademarks of International
Business Machines Corporation in the United States, other
countries, or both.
If these and other IBM trademarked terms are marked on
their rst occurrence in this information with a trademark
symbol ( or ), these symbols indicate U.S. registered or
common law trademarks owned by IBM at the time this
information was published. Such trademarks may also be
registered or common law trademarks in other countries.
A current list of IBM trademarks is available on the Web at
Copyright and trademark information at: |bm.com/legal/
copytrade.shtml
Other product, company or service names may be trademarks
or service marks of others.
References in this publication to IBM products or services
do not imply that IBM intends to make them available in all
countries in which IBM operates.
Prev|ous page

Agility at Scale

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agility at Scale

Uploaded by

Copyright:

Available Formats

IBM ag|||ty@sca|e

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

: Become as Agile as You Can Be

You might also like