Scaling Agile(Good!)
Transcript of Scaling Agile(Good!)
-
8/8/2019 Scaling Agile(Good!)
1/70
Scaling Software Agility:Best Practices for Large
Enterprises
Dean Leffingwell
Agile 2009
Chicago, IL
August 26, 2009
1
-
8/8/2019 Scaling Agile(Good!)
2/70
About Dean Leffingwell
2
Executive MentorBMC Agile Transformation
Agile Enterprise CoachNokia S60, Symantec, Safeco
Insurance, Symbian
Software.
Cofounder/AdvisorPing Identity, Roving Planet,
Rally Software
Founder/CEORequisite, Inc.
Makers of RequisitePro
Senior VPRational Software
Responsible for Rational Unified
Process (RUP) & Support of
UML
Founder and CEOProQuo, Inc., Internet identity
-
8/8/2019 Scaling Agile(Good!)
3/70
More from Dean Leffingwell
Scaling Software Agility: Best Practices for Large
Enterprises, Addison-Wesley 2007Blog and Resources
www.scalingsoftwareagility.wordpress.com
Website
www.leffingwell.org
Reach me at [email protected]
3
http://www.scalingsoftwareagility.wordpress.com/http://www.leffingwell.org/mailto:[email protected]:[email protected]://www.leffingwell.org/http://www.scalingsoftwareagility.wordpress.com/ -
8/8/2019 Scaling Agile(Good!)
4/704
If you accept the premise that market needs change fasterthan the software industrys traditional ability to developsoluions, youre left with the question what can we do about
it? For me, the answer is Agile.
Israel Gat, Vice President,
Infrastructure Management, BMC Software, Inc.
-
8/8/2019 Scaling Agile(Good!)
5/70
BMC Results
QSM Associates press release remarkable levels of time-to-market and quality
produce large scale enterprise software in 4-5 months,
compared to typical one year exceptional time-to-market without sacrificing quality
especially noteworthy - BMC 'Secret Sauce enablesprocess to succeed in spite of geographically dispersedteams
Other companies experience higher defects and longerschedules with split teams, BMC does not. I've never seenthis before. The low bug rates also result in very low defect
rates post-production
clearly ahead of more than 95 percent of all the softwareprojects captured in the SLIM metrics database, they're
among the best I've seenSource: QSM Associates Press Release, Sep 10, 2007
5
-
8/8/2019 Scaling Agile(Good!)
6/70
Approaching Challenge at Scale
6
We place the highest value on actual implementation and taking action.There are many things one doesnt understand; therefore, we ask them,why dont you just go ahead and take action?
You realize how little you know, and you face your own failures and redo
it again, and at the second trial you realize another mistake . . . So youcan redo it once again.
So by constant improvement one can rise to the higher level of practiceand knowledge.
This guidance reminds us that there is no problem too large to be solvedif we are only willing to take the first step.
FuijoSho, President, Toyota
-
8/8/2019 Scaling Agile(Good!)
7/70
What Is Software Agility?
7
-
8/8/2019 Scaling Agile(Good!)
8/70
Team Agility
A disciplined set of
enhanced software engineering practices
empirical software project management practices
modified social behaviors
That empowers teams to: more rapidly deliver quality software
explicitly driven by intimate and immediate customer feedback
8
-
8/8/2019 Scaling Agile(Good!)
9/70
1.
The Define/Build/Test Team
2.
Mastering the Iteration
3. Two-levels of Planning and Tracking4.
Smaller, More Frequent Releases
5.
Concurrent Testing
6.
Continuous Integration
7.
Regular Reflection and Adaptation
1.
The Define/Build/Test Team
2.
Mastering the Iteration
3. Two-levels of Planning and Tracking4.
Smaller, More Frequent Releases
5.
Concurrent Testing
6.
Continuous Integration
7.
Regular Reflection and Adaptation
Achieving Team Agility
9
-
8/8/2019 Scaling Agile(Good!)
10/70
Enterprise Agility
That harness large numbers of agile teams to build
and release quality enterprise-class software more
rapidly than ever before
Explicitly driven by intimate and immediate customerfeedback
That harness large numbers of agile teams to build
and release quality enterprise-class software more
rapidly than ever before
Explicitly driven by intimate and immediate customer
feedback
A set of organizational best practices
core values and beliefs
A set of organizational best practices
core values and beliefs
10
-
8/8/2019 Scaling Agile(Good!)
11/70
Achieving Enterprise Agility
11
1.
Intentional Architecture
2.
Lean Requirements at Scale
3. Systems of Systems and the Agile Release Train4.
Managing Highly Distributed Development
5.
Impact on Customers and Operations
6.
Changing the Organization
7.
Measuring Business Performance
1.
Intentional Architecture
2.
Lean Requirements at Scale
3. Systems of Systems and the Agile Release Train4.
Managing Highly Distributed Development
5.
Impact on Customers and Operations
6.
Changing the Organization
7.
Measuring Business Performance
-
8/8/2019 Scaling Agile(Good!)
12/70
Agile Turns Tradition Upside-Down
Predictive Process
(Waterfall)
Adaptive Process
(Agile)
The plan createscost/schedule estimates
The vision createsfeature estimates
12
-
8/8/2019 Scaling Agile(Good!)
13/70
Helps Avoid the Death March
Time
Pressure
Deadline
13
Peak performanceachieved andmaintained indefinitely
at a sustainable pace
-
8/8/2019 Scaling Agile(Good!)
14/70
Reduces Risk
Time
Deadline
Risk
14
-
8/8/2019 Scaling Agile(Good!)
15/70
Starts Delivering Immediately
15
Time
ValueDe
livery
Deadline
-
8/8/2019 Scaling Agile(Good!)
16/70
Makes Money Faster
16
Time
ValueDe
livery
Deadline
-
8/8/2019 Scaling Agile(Good!)
17/70
Delivers Better Fit for Purpose
Time
waterfall plan, result
agile
(adaptive) plan, result
Measure of
waterfall customer
dissatisfaction
17
-
8/8/2019 Scaling Agile(Good!)
18/70
Agile Delivers Higher
18
-
8/8/2019 Scaling Agile(Good!)
19/70
Our implementation of agile practices . . . helps us find bugsearlier, helps us achieve higher quality, and helps us work wellwith SW QA
Jon Spence, Medtronic
Our implementation of agile practices . . . helps us find bugsearlier, helps us achieve higher quality, and helps us work wellwith SW QA
Jon Spence, Medtronic
I measure quality by the life of a defect, time measured frominjection to finding and fixing. Agile gives us solid results with
most defects living no longer than one to two iterations. Agiledelivers higher quality than anything Ive found with the waterfallmodel
Bill Wood, VP, Ping Identity Corp.
I measure quality by the life of a defect, time measured frominjection to finding and fixing. Agile gives us solid results with
most defects living no longer than one to two iterations. Agiledelivers higher quality than anything Ive found with the waterfallmodel
Bill Wood, VP, Ping Identity Corp.
19
-
8/8/2019 Scaling Agile(Good!)
20/70
Last year, we had 22 releases across 3 major product lines, andnot a one of them was late. We support hundreds of Fortune1000 enterprises with a single person dedicated to support --the software is that solid
Andre Durand, CEO, Ping Identity Corp.
Last year, we had 22 releases across 3 major product lines, andnot a one of them was late. We support hundreds of Fortune1000 enterprises with a single person dedicated to support --the software is that solid
Andre Durand, CEO, Ping Identity Corp.
We increased individual developer and team productivity by an
estimated 20 percent to 50 percentBMC Software
We increased individual developer and team productivity by an
estimated 20 percent to 50 percentBMC Software
20
-
8/8/2019 Scaling Agile(Good!)
21/70
Development teams are more engaged, empowered and highlysupportive of the new development process
BMC Software
Development teams are more engaged, empowered and highlysupportive of the new development process
BMC Software
Our implementation of agile practices . . . (1) makes the workmore enjoyable, (2) helps us work together, and (3) isempowering
Jon Spence, Medtronic
Our implementation of agile practices . . . (1) makes the workmore enjoyable, (2) helps us work together, and (3) isempowering
Jon Spence, Medtronic
21
-
8/8/2019 Scaling Agile(Good!)
22/70
Seven Agile TeamPractices That Scale
The Define/Build/Test Team
Mastering the Iteration
Two-level Planning and Tracking
Smaller, More frequent releases
Concurrent Testing
Continuous Integration
Regular Reflection and Adaptation
22
1 D fi /B ild/T t T
-
8/8/2019 Scaling Agile(Good!)
23/70
1. Define/Build/Test Team
Before Agile: Typical Functional Silos
Management Challenge:
Connect the Silos
23
D/B/T Team Agile Fractal
-
8/8/2019 Scaling Agile(Good!)
24/70
A self-organizing team that can Define, Buildand Testa thing of interest
Optimized for communication about the thing
Repeated at larger scales to produce largersystems
Teams can be based on
Components
Subsystems
Features
Interfaces
Products
D/B/T Team Agile Fractal
Team1
Team100
24
D/B/T Teams Have the Necessary Skills
-
8/8/2019 Scaling Agile(Good!)
25/70
D/B/T Teams Have the Necessary Skills
Developer Developer Developer Tester
TesterDeveloperProduct Owner
Architect
Tech lead Scrum / Agile Master
QA/Release
Mgt
25
2 Mastering the Iteration
-
8/8/2019 Scaling Agile(Good!)
26/70
The iteration is the heartbeat of agility. Master that,
and most other things agile tend to naturally fallinto place.
2. Mastering the Iteration
26
Iteration Pattern
-
8/8/2019 Scaling Agile(Good!)
27/70
Iteration Pattern
Story AStory B
Story C
Story D
Story E
Story FStory
Story AStory B
Story C
Story D
Story E
Story FStory
DefineDefine
P
lan
Plan
FixedR
esources
Fixed Time (Iteration)
27
3 Two Level Planning and Tracking
-
8/8/2019 Scaling Agile(Good!)
28/70
3. Two-Level Planning and Tracking
Iteration CycleIteration Cycle
Release CycleRelease Cycle
Drives
Feedback- Adjust
Plan Releases at the
SystemLevel
Three to six monthshorizon
Prioritized feature
sets define content
Plan iterations at the
component/feature level 2-4 iteration visibility
Currency: user stories
ReleaseVision
Release Planning
Release Scope
and Boundaries
28
IterationPlanning
Develop &TestReview
&Adapt
Release Pattern
-
8/8/2019 Scaling Agile(Good!)
29/70
Release Pattern
PrioritizedRelease (feature)
Backlog
Stories
Release timebox
29
4 Smaller More Frequent Releases
-
8/8/2019 Scaling Agile(Good!)
30/70
4. Smaller, More Frequent Releases
Shorter release dates
60-120 days
Releases defined by
Date, theme, planned
feature set, quality
Scope is the variable
Release date and
quality are fixed
CycleCycleCycle CycleCycleCycle CycleCycleCycle
30
CycleCycleCycle CycleCycleCycle CycleCycleCycle CycleCycleCycle CycleCycleCycle CycleCycleCycle
Fix the Dates - Float the Features
-
8/8/2019 Scaling Agile(Good!)
31/70
Fix the Dates Float the Features
Teams learn that dates MATTER
Product and business owners learn that priorities
MATTER
Agile teams MEET their commitments
Releasable
Increment
10/1/2009 11/1/2009 12/1/2009 1/1/2009 2/1/2009 3/1/2009
31
Releasable
Increment
5 Concurrent Testing
-
8/8/2019 Scaling Agile(Good!)
32/70
5. Concurrent Testing
All code is tested code. Teams get no credit for
delivering functionality that is coded, but not tested. Tests are written before, or concurrently with, the
code itself.
Testing is a team effort. Testers and developers allwrite tests.
Test automation is the rule, not the exception.
Philosophy of Agile Testing
32
Concurrent
-
8/8/2019 Scaling Agile(Good!)
33/70
Concurrent
Unit Testing Developer written
Acceptance Testing
Customer, product owner, tester written
Component Testing
Integrated BVT (build verification tests) at component/modulelevel
System, Performance and Reliability Testing
Systems tester and developer Written QA Involvement
33
Agile Testing Quadrants
-
8/8/2019 Scaling Agile(Good!)
34/70
Agile Testing Quadrants
34
Business-Facing
Su
pportDevelopment
Critiqu
eProduct
Technology-Facing
ManualAutomated &Manual
Automated Tools
Q1
Q2 Q3
Q4
Adapted from Brian Marick, Crispen and Gregory
On Test Automation
-
8/8/2019 Scaling Agile(Good!)
35/70
On Test Automation
You have no choice
Manual tests bottleneck velocity You cant ship what you cant test
35
6. Continuous Integration
-
8/8/2019 Scaling Agile(Good!)
36/70
g
Continuous integration is neither new nor invented by agile
It has been applied as a best practice for at least a decade
However, continuous integration is mandatory with agile
the teams ability to build continuously is
a critical bottleneck to delivered
velocity
the teams ability to build continuously is
a critical bottleneck to delivered
velocity
36
-
8/8/2019 Scaling Agile(Good!)
37/70
Continuous Integration Success
-
8/8/2019 Scaling Agile(Good!)
38/70
g
Team can build at least once a day
Effort is inversely proportional to time between builds!
A broken build stops
production and is addressed
immediately
Successful builds
Checks in all the latest source code
Recompile every file from scratch
Successfully execute all unit tests
Link and deploy for execution
Successfully execute automated Build Verification Test
38
Source: Martin Fowler
7. Regular Reflection and Adaptation
-
8/8/2019 Scaling Agile(Good!)
39/70
g p
Periodically, the entire team including owners/end users
reflects on the results of the process
learn from that examination
adapt the process -
and organization -
to produce better results
The team decides what is working well, what isnt, and
what one thing to do differentlynext time
At regular intervals, the team reflects on how to become moreeffective, then tunes and adjusts its behavior accordingly.
Agile Manifesto, Principle 12
The shorter the iterations and releases
the
faster the learning The shorter the iterations and releases
the
faster the learning
39
A hi i E i
-
8/8/2019 Scaling Agile(Good!)
40/70
Achieving Enterprise
Agility
40
1. Intentional Architecture
-
8/8/2019 Scaling Agile(Good!)
41/70
Continuous refactoring of large-scale, system-levelarchitectures is problematic:
Substantive rework for large numbers of teams
Some of whom would otherwise NOT have to refactor their component or
module
Potential Impact on deployed systems/ users
Best possible BVT (Build Verification Tests) are imperfect
Common architectural constructs ease usability, extensibility,
performance and maintenance
For systems of scale, some intentional architecture
is necessary
For systems of scale, some intentional architecture
is necessary41
Principles of Agile Architecture
-
8/8/2019 Scaling Agile(Good!)
42/70
Principle #1 The teams that code the system design the
system.Principle #2 Build the simplest architecture that can
possibly work.Principle #3 When in doubt, code it out.
Principle #4 They build it, they test it.
Principle #5 The bigger the system, the longer therunway.
Principle #6 System architecture is a role collaboration.
Principle #7 There is no monopoly on innovation42
-
8/8/2019 Scaling Agile(Good!)
43/70
2. Lean Requirements at Scale
-
8/8/2019 Scaling Agile(Good!)
44/70
Requirements still matter in agile. Atscale, lean and more extensible
requirements practices can be applied.
44
Lean Requirements at Scale
-
8/8/2019 Scaling Agile(Good!)
45/70
A scalable requirements practice with three elements
Vision+Vision+ RoadmapRoadmap Just-in-TimeElaboration
Just-in-TimeElaboration
45
Vision - Managements responsibility
-
8/8/2019 Scaling Agile(Good!)
46/70
Where are we headed as a
business?
What problem does this product
solve?
What features and benefits does itprovide?
For whom does it provide it?
What performance does it deliver?
46
Common and Non-functionalR i t
-
8/8/2019 Scaling Agile(Good!)
47/70
Requirements
Some requirements must be
known by all teams Common components, common
behaviors
Internationalization, accessibility Performance, reliability and security
requirements
Industry/Regulatory/Customer standards/specifications
Corporate standards: copyright, logo, graphics, legal
Documented and available to all affected teams.Documented and available to all affected teams.47
Roadmap System TeamsR ibilit
-
8/8/2019 Scaling Agile(Good!)
48/70
Responsibility
May 15, 08 May 22, 08 July 08
Features
Road Rage Ported
(part I)
Brickyard port started
(stretch goal to complete)Distributed platform demo
ALL GUIs for both games
demonstrable
New features (see
prioritized list)
Demo of Beemer game
Features
Road Rage Ported
(part I)
Brickyard port started
(stretch goal to complete)Distributed platform demo
ALL GUIs for both games
demonstrable
New features (see
prioritized list)
Demo of Beemer game
48
Features
Road Rage Completed
(single user)
Brickyard Ported (single
user)Road Rage multiuser
demonstrable
First multiuser game
feature for Road Rage
New features (see
prioritized list)Beemer game in Alpha
Features
Road Rage Completed
(single user)
Brickyard Ported (single
user)Road Rage multiuser
demonstrable
First multiuser game
feature for Road Rage
New features (see
prioritized list)Beemer game in Alpha
Features
Multiuser Road Rage first
release
Brickyard Ported
multiuser demoNew features for both
games (see prioritized list)
Beemer game to E3
Tradeshow?
Features
Multiuser Road Rage first
release
Brickyard Ported
multiuser demoNew features for both
games (see prioritized list)
Beemer game to E3
Tradeshow?
Just-In-Time Elaboration Agile Teams Responsibility
-
8/8/2019 Scaling Agile(Good!)
49/70
Story 1
Omnis decus
Plurubusunum
Story 1
Omnis decus
Plurubusunum
Story 2Story 2
Agile investment in documenting
requirements is minimal prior to
implementation
Features are high level, abstract
Communicate only concept
Little work in process
At iteration boundaries, elaborationis required
Refine the teams understanding
Support design, implementation andtesting
Define acceptance criteria
User Stories are the currency
Agile Teams Responsibility
49
3. Systems of Systems and the AgileRelease Train
-
8/8/2019 Scaling Agile(Good!)
50/70
Release Train
Scaling agile requires managing interdependencies
amongst teams of developers
Only the teams themselves can plan and manage this
complexity
Only the teams can commit to the schedule Systematic enterprise delivery requires an agile release
train delivery model
Rolling-wave Enterprise Release Planning drives release
train vision and execution
50
Component Agile is not System Agile
-
8/8/2019 Scaling Agile(Good!)
51/70
51
Time when you
discover you arenot Planned system
release date
....time spent thinking you are on track.IntegrateIntegrateand slip!and slip!SystemSystem
External Release
External Release
External Release
Internal Release
Internal Release
IterateIterate IterateIterate IterateIterate
IterateIterate IterateIterate IterateIterate IterateIterate
AA
BB
CC
Agile teams
Internal Release
IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate
The slowest team drags thetrain
Release docsRelease docs
Port and certsPort and certs
Port and certsPort and certs
Release docsRelease docs
Release docsRelease docs
Rules of the Agile Release Train
-
8/8/2019 Scaling Agile(Good!)
52/70
Periodic release dates for the solution are fixed
Intermediate, global integration milestones areestablished and enforced
Constraining these means that component/feature
functionality must flex Shared infrastructure must track ahead
Teams evolve to a flexible model:
Design spectrum for newfunctionality
Backup plan to ship
less capable version
if necessary
Lease
Imaginable
Minimum
CredibleModerate Best
52
Agile release train design continuum
Synchronized Agile Release Train
-
8/8/2019 Scaling Agile(Good!)
53/70
53
Release IncrementRelease Increment
(Potentially shippable(Potentially shippableincrement)increment)
Sys 1Sys 1 Sys 2Sys 2 Sys 3Sys 3 Sys 4Sys 4 Sys 5Sys 5 Sys 6Sys 6 Sys 7Sys 7 Sys 8Sys 8
IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate
IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate
IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate IterateIterate
TeamTeam
AA
Team BTeam B
TeamTeam
CC
SystemSystem
IterationsIterations
Release docsRelease docs
Ports certsPorts certs
ReleaseDocs
ReleaseDocs
ReleaseDocs
ReleaseDocs
Ports certsPorts certs
ContinuousIntegration
ContinuousIntegration
ContinuousIntegration
Component/Component/
Feature/Feature/
SubsystemSubsystem
IterationsIterations
For discussion, see www.scalingsoftwareagility.wordpress.com
http://www.scalingsoftwareagility.wordpress.com/http://www.scalingsoftwareagility.wordpress.com/ -
8/8/2019 Scaling Agile(Good!)
54/70
H
HH
H
2009 Leffingwell, LLC.
Rolling Wave Release Planning Drivesthe Train
-
8/8/2019 Scaling Agile(Good!)
55/70
BusinessContext
BusinessContext
Product VisionProduct Vision
TeamBreakouts
TeamBreakouts
Draft Release
Plan Review
Draft Release
Plan Review
ProblemSolving / Scope
Management
ProblemSolving / Scope
Management
9-10
10-11
11-12
12-1
1-2
2-3
3-4
4-6
Eng mgrs
State of the business
Objectives for upcoming periods
Objectives for release
Prioritized feature set
Each team presents plans to group
Issues/impediments noted
Issues/impediments assigned
Release commitment vote?
Teams plan stories for iterations
Work out dependencies
Architects and PMs, POs circulate
|1|1
|1|1
|2|2
|2|2
|3|3
|3|3
|4|4
|4|4
architects
Product managers/Product Owners
PMs
Executives
the Train
55
-
8/8/2019 Scaling Agile(Good!)
56/70
Release Commitment
-
8/8/2019 Scaling Agile(Good!)
57/70
57
4. Managing Highly DistributedDevelopment
-
8/8/2019 Scaling Agile(Good!)
58/70
Development
Co-locate team often at least at Release Planning
Establish core hours, with overlap required
Apply high cohesion and low coupling to sites (organize
and reorganize around features/components)
Dont let anyone go dark - apply daily Integration Scrums
Establish a single global instance of project assets
Invest in tools that support distributed, but shared view ofstatus
58
5. Changing the Organization
-
8/8/2019 Scaling Agile(Good!)
59/70
Transition as a Project
All in or Incremental Rollout
Eliminating Impediments
Moving to Agile Portfolio Management
59
Transition as a Project
-
8/8/2019 Scaling Agile(Good!)
60/70
Establish an Agile Enterprise Transition Team
Drives the enterprise vision and facilitates
implementation Cross-functional involvement
Cross-level involvement
Executive leadership
Create a transition backlog
Run project in iterations
Commit to weekly iteration goals
Meet at least weekly
Report to other executive stakeholders
Experience agile project management
60
Executive sponsors
Cross functional
All-In or Incremental?
-
8/8/2019 Scaling Agile(Good!)
61/70
All-in
Incremental
61
Eliminating Impediments
-
8/8/2019 Scaling Agile(Good!)
62/70
Existing rules demand adherence to document-driven, waterfall
processes and artifacts
Software test/ system test not integrated, responsive
Inadequate build and support infrastructure
Organization rewards individual over team behavior
Teams not co-located to maximum extent feasible
Teams not truly empowered
Other functions - sales, marketing, customer not supportive ofincreased delivery pace
Legacy thinking - Management expectations for fixed-price,
fixed-time, fixed-function delivery
62
Moving to Agile Portfolio Management
Changing Legacy Mindsets
-
8/8/2019 Scaling Agile(Good!)
63/70
63
g g g y
Investment
Funding Investment
Funding
Change
Management Change
Management
Governance
and Oversight Governance
and Oversight
From:
To:
DTE Energy Case Study, Agile 2009
6. Impact on Customers and Operations
-
8/8/2019 Scaling Agile(Good!)
64/70
More frequent releases challenge:
Customers
Suppliers
Marketing and Sales
Support
Documentation, certification, localization
64
-
8/8/2019 Scaling Agile(Good!)
65/70
7. Measuring Business Performance
-
8/8/2019 Scaling Agile(Good!)
66/70
66
The primary metric for agile is whether or not
working software actually exists, and isdemonstrably suitable for its intended purpose.
This is determined empirically, by demonstration,at the end of every single iteration.
All other measures are secondary.. (but not useless)
All other measures are secondary.. (but not useless)
Process Self-Assessment Metrics
-
8/8/2019 Scaling Agile(Good!)
67/70
67
Team Agility Assessment Radar Chart
-
8/8/2019 Scaling Agile(Good!)
68/70
Product Ownership
DevelopmentPractices/Infrastructure
Release Planning and Tracking
Testing Practices Iteration Planning and Tracking
Team
150%
125%
100%
75%
50%
25%
0%
68
Watch for these Anti-patterns
-
8/8/2019 Scaling Agile(Good!)
69/70
Insufficient refactoring of testing organizations and
inadequate test automation
Lack of team proficiency in agile technical practices
iterations and sprints treated as demo milestones, rather than
potentially shippable increments
Insufficient depth/competency in the critical product
owner role
Inadequate coordination of vision and delivery strategies
due to lack of coordinated, multi-level release planning
69
-
8/8/2019 Scaling Agile(Good!)
70/70