2008 ASA Agile DB2 Final

IBM Academy of Technology
Second Agile Methods and Practices Conference

McKimmon Center at NC State Univ
June 23-25, 2008
Agile@IBM
The Agile Transformation of the DB2 The Agile Transformation of the DB2
LUW Team LUW Team
Large Scale Agile Adoption Large Scale Agile Adoption
Robert Begg, robert@ca.ibm.com
Katherine Franklin, kfranklin@ca.ibm.com
IBM Academy of Technology: Second Agile Methods and Practices Conference
June 23-25, 2008
2 Agile@IBM
Agenda
Agenda
Background
Our Approach for Adopting Agile
Measuring Success of Agile Adoption (so far)
Measuring Success of Product Team using Agile
(so far)
Reflections and Whats next
June 23-25, 2008
3 Agile@IBM
for maximum flexibility and
performance in diverse workload
and operating system environments
IBM DB2
IBM DB2
for Linux, Unix, and Windows for Linux, Unix, and Windows
23 of the Top 25
US Retailers
25 of the Top 25
Worldwide Banks
9 of the Top 10
Global Life / Health
Insurance Providers
Flexible
OLTP + Warehousing
Relational + XML
Multi-platform
Powerful
Leading performance
reliability and
scalability
Low cost
Self optimizing
Deep compression
Optimized for SAP
Business
Performance
Advantage
Cost
Effective
Solutions
Introductions
June 23-25, 2008
4 Agile@IBM
June 23-25, 2008
5 Agile@IBM
DB2 LUW Challenge
DB2 LUW Challenge
The DB2 Linux, Unix Windows (LUW) team consists of 600 professionals
spread across multiple sites around the world
More traditional big plan development processes
Innovative in research and patents
Large legacy code base (primarily C with some C++)
Diverse customer requirements
Lack of automated Unit test infrastructure.
Homegrown build, test, reporting tools
Disbelief that large items can be broken down into iterations
Now how do we measure success adopting Agile into our team?
How will we know were getting Agile?
How will we know its working for us?
How can we convince the skeptics?
Introductions
What can you
measure?!
June 23-25, 2008
6 Agile@IBM
What we
What we
ve already been doing in past releases

ve already been doing in past releases
We need to continue and accelerate practices we already
started in previous releases
Investment Strategy based on market segments
SVT Core Stability & Integration Testing (continuous) even earlier
FVT Automation less effort to analyze results
Leverage Virtualization for SVT on demand anyone can run
Milestone project management shorter iterations
Branching/code management strategies increase code deliveries
Solution teams more innovative teamwork
FVT Test Case Writing Parties more innovative ways to deliver fast
Introductions
June 23-25, 2008
7 Agile@IBM
What do we need?
What do we need?
We need to deliver to the business:
More complete solutions to business problems
Better quality, lower total cost of ownership
More effective earlier Beta engagements
To do this, we need:
More content, with same time/resources and top quality
Stable codebase, early defect removal
More stable and satisfied teams
Consistently, with less risk and less waste
Introductions
Can Lean Principles and Agile Practices help? Can Lean Principles and Agile Practices help?
Can they scale? Can they scale?
June 23-25, 2008
8 Agile@IBM
Approach to Adopting Agile
Approach to Adopting Agile
Three main approaches to adopting Agile practices in a
large product development group
1. Run a pilot project
18 month release cycles 3yrs before wed see big pay off
2. All in, all at once, Top Down mandate
Too many changes not clear which would work best for DB2?
We needed time to learn
Needs and challenges of solutions vary greatly
Too much risk
3. A slow but steady transformation
Self directed change
Do, reflect, change
Lack of top-down direction can be confusing
Were doing the third
Adopting Agile
June 23-25, 2008
9 Agile@IBM
Why We Picked the Steady Adoption Approach
Why We Picked the Steady Adoption Approach
We needed to start with the current release plan
OID approach was sound, and the Goals clear
We needed to take both top down and grass roots approach
We have a large team to motivate & include
We did not have all the answers at the start
We needed to draw on the diverse experience of the global
teams
Share best practices
We needed flexibility to adapt and roll out team by team
And to change over the release
Not locked in for 18 months
Adopting Agile
June 23-25, 2008
10 Agile@IBM
Kickoff
Kickoff
Sept 2007
Sept 2007
Hired/Identified key leaders
Release Plan
Already set based on market segment
investment and Outside In Design
Solution Teams Defined
Staffed with whole team approach, all skills
needed to deliver high quality customer solution
Smallest team is 2 people, largest was 33
Each solution has an owner ( = project owner)
Each solution has a team lead (usually also the scrum-master)
Chief Architect along with small strategy team = overall product owner
Training & Education
Educate everyone
Core 2 day workshop for early adopters (35 people)
Internal 1 day workshops (~325 people)
Up-line learning sessions, follow up sessions, all hands, etc
Allowed the teams to self select Agile practices to focus on
Continuous follow up, learning and adjustment
Adopting Agile
Solution
Team
Developers
(16)
Performance
(2)
Specialists
(2)
Architects
(2)
Information
Developers
(2)
System
Tester
(1)
Functional
Testers
(8)
Solution
Team
June 23-25, 2008
11 Agile@IBM
What Solution Teams Do
What Solution Teams Do
Solution team leads worked with solution teams to
Self identify Agile practices to utilize
Engage entire team for setting/meeting iteration goals e.g. fully tested
Determine the amount of upfront design required
Set up iterations & backlogs
Initiate daily scrums, Chair reflection sessions
Weekly review of progress,
Posted to Team wiki
Collectively deliver share the work,
ideas, etc
Writers co-owning specs
Testers setting use cases
Team executing test cases
Demo what they deliver
Started small with team
Expanding to broader audience
Adopting Agile
June 23-25, 2008
12 Agile@IBM
Product Backlog List With Relative
Product Backlog List With Relative
Sizings
Sizings
C
o
m
p
l
e
t
e
Estimated
Points 1 (Nov) 2(Dec) 3(Jan) 4(Feb) 5(Mar) 6(Apr) 7(May)
1070 1017 922 800 740 682 618 537
1.1 In-memory Metrics 654 628 561 452 419 386 329 263
1.1.1 Infrastructure 112 108 86 42 41 33 24 24
Collection block infra 4 4 4 3 3 3 2 2
Rollup framework 33 33 19 2 2 0 0 0
Externals framework 21 17 9 3 2 2 2 2
Control knobs 8 8 8 8 8 8 2 2
Reset capability 4 4 4 4 4 0 0 0
Perf optimizations [?] 40 40 40 20 20 20 18 18
1.1.2 Time Spent 150 128 98 48 41 52 41 36
1.1.3 Conventional Metrics 105 105 90 85 75 68 59 44
1.1.4 Data Object Metrics 258 258 258 248 238 212 186 143
1.1.5 Package Cache List (to replace Dynamic SQL Snapshot) 29 29 29 29 24 21 19 16
1.2 In-Memory Activity History Buffer 20 20 20 20 13 8 8 8
Externals Spec 20 20 20 20 13 8 8 8
1.4 Enhanced "Runtime Explain" 40 40 40 40 40 40 40 40
Externals Spec 20 20 20 20 20 20 20 20
New "COLLECT ACTIVITY INFORMATION" option to reqeust capture of working copy of section at completion [?] 10 10 10 10 10 10 10 10
New explain stored procedure to produce output compatible with Visual Explain tools [?] 10 10 10 10 10 10 10 10
1.5 Fast-Writer Event Infrastructure 52 25 25 17 11 11 9 9
1.5.1 Queueing Infra 26 17 17 17 11 11 9 9
1.5.2 Writers y 5 0 0 0 0 0 0 0
1.5.3 Table Event Monitor Infrastructure y 21 8 8 0 0 0 0 0
1.6 Enhanced Event Monitors 153 153 130 125 116 109 109 95
1.6.1 Enhanced SQL / Activity Event Monitoring 72 72 49 44 39 32 32 29
1.6.2 Enhanced Transaction Event Monitoring 27 27 27 27 27 27 27 23
1.6.3 Enhanced WLM Statistics Event Monitoring 17 17 17 17 17 17 17 10
1.6.4 New SQL Cache Event Monitoring 37 37 37 37 33 33 33 33
1.7 Comprehensive Lock Monitoring 83 83 78 78 73 60 55 54
1.7.1 Locking Event Monitor 83 83 78 78 73 60 55 54
1.8 Enhanced Tooling Support 68 68 68 68 68 68 68 68
DRDA ACR7008 Specification 8 8 8 8 8 8 8 8
External Spec 20 20 20 20 20 20 20 20
DB2ID enablement 20 20 20 20 20 20 20 20
DB2ID Query support 20 20 20 20 20 20 20 20
Description
Solution Total
Monitor & PD Burndown Chart
0
200
400
600
800
1000
1200
0 1 2 3 4 5 6 7 8 9 10 11 12
Iterations
R
e
l
a
t
i
v
e

P
o
i
n
t
s
Predicted Points
Actual Points
June 23-25, 2008
13 Agile@IBM
What Solutions Do
What Solutions Do
Adopting Agile
Scheduled into iterations based on capacity using IBMs Rational Portfolio
Manager to share & track
Do higher risk earlier, do foundation/need to learn/need to know earlier
Gather feedback, Reflect and learn, Replan
Backlog are the things you might not get to run ats
June 23-25, 2008
14 Agile@IBM
Are We Agile? Getting there!
Are We Agile? Getting there!
0 2 4 6 8 10
Custom
Non Solo
Ref lections
Scrum meetings
Iterative
Automated Unit Tests
User Stories and Use Cases
Vision
8 2 8 Talk 3.776 5.4 7.
0
Does all code written have coverage by automated unit tests? Are the tests ran frequently? Are they
associated with the component so others know to run them?
Automated Unit Tests
1 7 1 Talk 1.897 1.8 5.
0
Does your solution backlog specify user stories and/or use cases? User Stories and Use Cases
3 1 1 Talk 1.974 3.8
Does your Solution Description and Architecture document state clear goals for your solution? Do you refer to it
during the release?
Vision
c b a Talk? StDev Mean
Pr
ev DB2 Description Practice (memory jogger)
Measuring Agile
Range Partitioning
Reflection 1
0
2
4
6
8
10
Use Cases
Time-Boxed Iterations
Working Software
Estimating
Product (Solution) Backlog
Prioritized Backlog
Stakeholder Feedback
Whole Team
Iteration Kickoff Meeting
Self Directing Teams
Sustainable Pace
Daily Scrum
Range Partitioning
Reflection 2
0
2
4
6
8
10
Use Cases
Working Software
Estimating
Prioritized Backlog
Whole Team
Sustainable Pace
Daily Scrum
Range Partitioning
Reflection 3
0
2
4
6
8
10
Use Cases
Working Software
Estimating
Prioritized Backlog
Whole Team
Sustainable Pace
Daily Scrum
19 of 26 solutions in current release have adopted Agile
Using Team Pulse/DEF to measure our Agile adoptions
and drive continuous improvement
June 23-25, 2008
15 Agile@IBM
Are we better for it? YES
Are we better for it? YES
More, reliable deliver of content?
Too early for KLOC, but surveys of staff report higher content using DEF to track for now
scoring 8/10
More effective earlier Beta engagements
Delivering to Beta engagements every 8 weeks
8 drops planned this release instead of 2
2 completed on time, on content, on quality, 3rd in progress
More stable and satisfied workforce
Significant majority of staff report strong preference to work Agile in next project
Consistently, with less risk and less waste
Using burn down charts
Burn-down Chart
-20.00%
0.00%
20.00%
40.00%
60.00%
80.00%
100.00%
120.00%
14-Nov-
2007
3-Jan-
2008
22-
Feb-
2008
12-Apr-
2008
1-Jun-
2008
21-Jul-
2008
9-Sep-
2008
29-Oct-
2008
18-
Dec-
2008
6-Feb-
2009
Date
%
W
o
r
k

C
o
m
p
l
e
t
e
%Work Left (Projected)
%Work Left (Actual)
Measuring Agile Success
June 23-25, 2008
16 Agile@IBM
Are we better for it? YES, cont
Are we better for it? YES, cont
d
d
Defects are following Agile trends wave of arrivals
and deliverables
Wave of arrivals and deliverables, oscillating
weekly
Lower inflow/outflow when compared with
previous 2 releases
Early system and integration testing
System & Performance testing started 6 months
earlier than previous releases
June 23-25, 2008
17 Agile@IBM
Proof of Early Testing
Proof of Early Testing
Delivered Weekly by Team Origin
1 1 1 1
2
4 4
1 1 1
4
1
4
7
2
1 1
2
5
1
7
6
5
9
9 13
17 17
8
7
8 8
17
8
19
15
14
11
12
5
24
22
1
2
1
5
1
2
1 5
2
4
4
4
6
10
9
6
9
7
17
10
1
1
2
1
5
4
2
2
3
5
5
5
1
2
1
4
2
6
4
1
1
1
3
2
1
1
1 3 1
1
2
1
5
4
4
2
1
2
4
6
3
8
5
4
5
1
1
1
1
3
1
3
3
1
1
3
4
3
2
1
4
3
4
3
3
6
1
5
5
1
3
1
1
1
1
2
2
1
11
12
11
16
14
16
27 27
14
20
15
23
28
19
31
35
30
23
26
11
47
37
0
10
20
30
40
50
60
70
80
90
1
1
-
J
a
n
2
5
-
J
a
n
8
-
F
e
b
2
1
-
F
e
b
7
-
M
a
r
2
1
-
M
a
r
4
-
A
p
r
1
8
-
A
p
r
2
-
M
a
y
1
6
-
M
a
y
3
0
-
M
a
y
1
3
-
J
u
n
2
7
-
J
u
n
1
1
-
J
u
l
UT
SVT
SERVICE
REGRESSION
PERF
MISC TEST
MISC
FVT
DEVELOPMENT
BUILD
Code Only
Originated Weekly By Team
1
6
1 1
3 4 3
1 1 1 2
7
1
3
6
2 1 1
3
8
1
11
11
7
12
12 19
23
11 13
10
8
12
18
14
22
18
20
11
15
7
34
24 4
3
2
10
14
15
46
16 16
9 12
10
24
26
9
16
16
12
14
13
29
18
1
2
1
1
2
2
3
1 2
6 3
2
2
7
6
4
3
4
3
3
5
3
1
1 1
1
1
3
2
2
1
3
1
1
1
6
2
1
3
5
3
1
2
6
2
2
14
17
3 1
4
3
1
5
4
12
21
7
11
5
4
2
2
2
1
1
1
1
1
1
1
4
1
3
5
5
4
5
8
4
3
4
8
8
7
4 8
8
5
11
9
7
2
8
6
4
2
1
2
1
1
1
3
3
26
31
20
30
40
43
39
34
39
34
31
30
51
56
46
53
52
42
39
28
87
47
0
20
40
60
80
100
120
1
1
-
J
a
n
2
5
-
J
a
n
7
-
F
e
b
2
1
-
F
e
b
7
-
M
a
r
2
1
-
M
a
r
4
-
A
p
r
1
8
-
A
p
r
2
-
M
a
y
1
6
-
M
a
y
3
0
-
M
a
y
1
3
-
J
u
n
2
7
-
J
u
n
1
1
-
J
u
l
UT
SVT
SERVICE
REGRESSION
PERF
MISC TEST
MISC
FVT
DEVELOPMENT
BUILD
Code Only
June 23-25, 2008
18 Agile@IBM
0
20
40
60
80
100
120
140
160
180
5
2
4
9
4
6
4
3
4
0
3
7
3
4
3
1
2
8
2
5
2
2
1
9
1
6
1
3
1
0 7 4 1
Total VIPER Inflow
Total VIPER 2 Inflow
Total Cobra Inflow
0
20
40
60
80
100
120
140
160
180
5
2
4
9
4
6
4
3
4
0
3
7
3
4
3
1
2
8
2
5
2
2
1
9
1
6
1
3
1
0 7 4 1
Total VIPER Outflow
Total VIPER 2 Outflow
Total Cobra Outflow
Inflow Inflow vs vs Outflow: Comparing Current to Prior Releases Outflow: Comparing Current to Prior Releases
June 23-25, 2008
19 Agile@IBM
Anecdotal Evidence we are getting it #1
Anecdotal Evidence we are getting it #1
(based on a real story (based on a real story ) )
[Busy Team:]
We have already defined a 3 month iteration, with a Beta drop defined as
a result.
Cant move to 1 month iterations now, too much change
Cant fit in 3 Betas, . (Go away and leave us alone!)
[Understanding Agile Coach]
A beta in 3 months, with external stakeholder feedback is great!
How about using six 2-week iterations to get there?
You can plan the next 2 weeks in more detail, with the 3 month goal in mind.
You can get feedback from internal stakeholders every two weeks
You can iteratively add to the content of the beta along the way with less risk.
[Busy Team]
Hey, so every six iterations I could deliver a major beta! Or milestone.
[Understanding Agile Coach (thinking to himself)]
{I will suggest doing Betas every 6 weeks next time }
June 23-25, 2008
20 Agile@IBM
Another Small Example #2
Another Small Example #2 (based on a real story (based on a real story ) )
[Busy developer]
This work requires some external specs to be written every iteration
I cant fit writing specs, coding and fixing defects into a 4 week iteration,
we need 6 week iterations.
[Busy writer]
How about I write most of the spec every iteration?
I will get the time back, since writing the external documentation will be
much easier
[Busy tester]
I can help also, since it will help me write the tests
But I may need help executing the tests
[Busy developer]
I can run the tests that are failing and fix the defects, it is worth a try
June 23-25, 2008
21 Agile@IBM
Lessons Learned
Lessons Learned
You can never have enough communication and discussion!
Actively encourage sharing between teams
Seek out and address concerns along the way
Repeat the key messages
Top down messages need to be timely!
In response to issues being raised (up) by the teams
Just enough to provide direction but leave options open
Education needs to be rapid across the teams!
Multiple sites and logistics can slow this down.
Reflections or Retrospectives are key!
Reinforces key messages
Drives continuous improvement
Reflections
June 23-25, 2008
22 Agile@IBM
What
What
s Next
s Next
Continued emphasis on time boxing
Clear meaning of done
Set clearer expectations for visible backlogs
Transparent to release team and others
Clear expected scope and progress (good for the team, and reassures "others )
User stories & Estimating
User stories to drive team focus and track progress
Validate solutions effectiveness
Running reflections
Responding to what we learn
Both team based improvements, and organization level improvements
Also tooling and other Software best practices
Video cameras for more collaboration
Apply Code Inspections in an Agile way
Pilot Rational Team Concert
Continue looking for ways to measure business success
Reflections

2008 ASA Agile DB2 Final

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2008 ASA Agile DB2 Final

Загружено:

Авторское право:

Доступные форматы

IBM Academy of Technology

Second Agile Methods and Practices Conference

ve already been doing in past releases

Вам также может понравиться