2008 ASA Agile DB2 Final

8/12/2019 2008 ASA Agile DB2 Final

1/22


2/22

IBM Academy of Technology: Second Agile Methods and Practices Conference

McKimmon Center at NC State Univ

June 23-25, 2008

2 Agile@IBM

AgendaAgenda

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


3/22



June 23-25, 2008

3 Agile@IBM

for maximum flexibility andperformance in diverse workloadand operating system environments

IBM DB2IBM DB2for Linux, Unix, and Windowsfor Linux, Unix, and Windows

23 of the Top 25US Retailers

25 of the Top 25Worldwide Banks

9 of the Top 10Global Life / HealthInsurance Providers

FlexibleOLTP + Warehousing

Relational + XML

Multi-platform

PowerfulLeading performance

reliability andscalability

Low costSelf optimizing

Deep compression

Optimized for SAP

BusinessPerformanceAdvantage

CostEffectiveSolutions

Introductions


4/22



June 23-25, 2008

4 Agile@IBM


5/22



June 23-25, 2008

5 Agile@IBM

DB2 LUW ChallengeDB2 LUW ChallengeThe 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?!


6/22



June 23-25, 2008

6 Agile@IBM

What weWhat weve already been doing in past releasesve already been doing in past releasesWe 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


7/22



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?


8/22



June 23-25, 2008

8 Agile@IBM

Approach to Adopting AgileApproach 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


9/22



June 23-25, 2008

9 Agile@IBM

Why We Picked the Steady Adoption ApproachWhy We Picked the Steady Adoption ApproachWe 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 practicesWe needed flexibility to adapt and roll out team by team And to change over the release

Not locked in for 18 months

Adopting Agile


10/22



June 23-25, 2008

10 Agile@IBM

KickoffKickoff Sept 2007Sept 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 skillsneeded 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

SolutionTeam

Developers(16)

Performance

(2)

Specialists(2)

Architects(2)

Information

Developers(2)

SystemTester

(1)

Functional

Testers(8)

SolutionTeam


11/22



June 23-25, 2008

11 Agile@IBM

What Solution Teams DoWhat Solution Teams DoSolution 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


12/22


13/22



June 23-25, 2008

13 Agile@IBM

What Solutions DoWhat 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


14/22



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

Reflections

Scrum meetings

Iterative

Automated Unit Tests

User Stories and Use Cases

Vision

828Talk3.7765.47.0

Does all code written have coverage by automated unit tests? Are the tests ran frequently? Are theyassociated with the component so others know to run them?

Automated Unit Tests

171Talk1.8971.85.0

Does your solution backlog specify user stories and/or use cases?User Stories and Use Cases

311Talk1.9743.8Does your Solution Description and Architecture document state clear goals for your solution? Do you refer to itduring the release?

Vision

cbaTalk?StDevMean

Pr

evDB2 DescriptionPractice (memory jogger)

Measuring Agile

Range Partitioning

Reflection 1

0

2

4

6

8

10Use 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

10Use Cases


Working Software

Estimating


Prioritized Backlog


Whole Team



Sustainable Pace

Daily Scrum

Range Partitioning

Reflection 3

0

2

4

6

8

10Use Cases


Working Software

Estimating


Prioritized Backlog


Whole Team



Sustainable Pace

Daily Scrum

19 of 26 solutions in current release have adopted AgileUsing Team Pulse/DEF to measure our Agile adoptions

and drive continuous improvement


15/22



June 23-25, 2008

15 Agile@IBM

Are we better for it? YESAre 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 chartsBurn-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

%WorkComplete

%Work Left (Projected)

%Work Left (Actual)

Measuring Agile Success


16/22



June 23-25, 2008

16 Agile@IBM

Are we better for it? YES, contAre we better for it? YES, contdd

Measuring Agile Success

Defects are following Agile trends wave of arrivalsand 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 monthsearlier than previous releases


17/22



June 23-25, 2008

17 Agile@IBM

Proof of Early TestingProof of Early Testing

Delivered Weekly by Team Origin

1 1 1 1 2 4 4 1 1 1 4 1 47

2 1 1 25

17 6 5

9 9 13

17 17

8 7 8 8

17

8

19 1514

11 125

24 221 2

15

1 2

1 5 2 4

4

4

6 10

9

69

7

17

10

1 12 1

5 4

22 3 5

5

5

1

2

1

4

2

6

4

1 1

1

3

2

1

1

1 3 11

2

15

4 4 2

1

2

4

6

38

5

4

5

1 11

1 3

1

3

3

1

13

4

32

14 3

4

3 3

6

1

5

5

1

31

1

1 1

2

2

1

11 12 1116 14 16

27 27

14

20

15

23

28

19

3135

30

2326

11

47

37

0

10

20

30

40

50

60

70

80

90

11-Jan

25-Jan

8-Feb

21-Feb

7-Mar

21-Mar

4-Ap

r

18-Apr

2-May

16-May

30-May

13-Jun

27-Jun

11-Jul

UT

SVT

SERVICEREGRESSION

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

111

11

7 121219

23

111310 8 12

18

142218 20

1115 7

34

2443

2

1014

15

46

16 169 12

10

24

26 9 16 16

1214

13

29

18

12

1

1

22

3

1 2

6 3 2

27

64 3

43

3

5

3

1

1 1

1

13

22

1

3

1

1

1

6

21

3

5

3

1

2

6

2

2

1417

3 1

43

1

5

412

21

7

11

5

4

22

2

1

1

11

1

1

1

4

1

3

5

5

4

5

8

4

3

4 8

8 7

4 8

8

5

119

7

2

8

6

4

2

1

2

1

1

1

3 3

2631

20

30

4043

3934

3934

3130

5156

46

5352

4239

28

87

47

0

20

40

60

80

100

120

1

1-Jan

2

5-Ja

n

7-Feb

21-Feb

7-Mar

21-Ma

r

4-Ap

r

1

8-Ap

r

2-May

16-May

30-May

1

3-Jun

2

7-Jun

11-Jul

UT

SVT

SERVICE

REGRESSION

PERF

MISC TEST

MISC

FVT

DEVELOPMENT

BUILD

Code Only


18/22



June 23-25, 2008

18 Agile@IBMMeasuring Agile Success

0

20

40

60

80

100

120

140

160

180

52 49 46 43 40 37 34 31 28 25 22 19 16 13 10 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 OutflowTotal Cobra Outflow

InflowInflow vsvs Outflow: Comparing Current to Prior ReleasesOutflow: Comparing Current to Prior Releases


19/22



June 23-25, 2008

19 Agile@IBM

Anecdotal Evidence we are getting it #1Anecdotal 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}


20/22


21/22



June 23-25, 2008

21 Agile@IBM

Lessons LearnedLessons LearnedYou 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


22/22



June 23-25, 2008

22 Agile@IBM

WhatWhats Nexts NextContinued 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 successReflections

2008 ASA Agile DB2 Final

Documents