jdd2014: agile transformation - how to change minds, deliver amazing results and enjoy the journey!...

1

Agile Transformation in Real World

Obaidur (OB) Rashid Senior Director, Product Development

Oracle Corporation

How to Change Minds, Deliver Amazing Results and Enjoy The Journey!

Twitter: @orashid

2

§  Bachelor & Masters in CS

§  15 years in the software industry

§ Taught at College of San Mateo

§ Cloud / SaaS / Agile enthusiast

§ My career in a nut shell …

Oracle

OnVantage

StarCite

Taleo

About Me Twitter: @orashid

3

Disclaimer # 1

Opinions expressed in this talk are my own and do not reflect the view of my employer

4

§ Context

–  Scope and Scale

–  Impetus for Change

§  Highlights of the changes

§ Results / Outcome

§  “Tips”

§  Q&A

Road Ahead

5

Context

6

Taleo Business Edition (TBE)

7

Distributed Team

8

Release Code Complete

Code Freeze

Next Release Development Starts Here

Post Release Support

2 Weeks 1 Week

5 Weeks

2 Weeks

Challenges 1.  Multiple focus 2.  Every release starts from behind

3.  Dev. & QA are not aligned 4. QA is always behind and quality suffers

5.  No built in ramp up, ramp down cadence

Pre Release Stabilization

8 - 10 Weeks

... Development …

Original SDLC

9

Unhappy Team! I wish we had more

time to test! No matter how fast we run,

we are always behind!

There is got to be a better way!

I do not like switching context all the time!

10

Changes

11

Embrace Scrum

12

Week 1 Week 13

13 Week Release Cycle

Building Blocks PDS – Product Development Sprint BFS – Bug Fix Sprint (Customer Defects)

PRS – Product Release Sprint RSS – Release Stabilization Sprint

RSS

Team 1

Team 2

Team 3

1 Week

PDS - 1

Team 1

Team 2

Team 3

2 Weeks

PDS - 2

Team 1

Team 2

Team 3

PDS - 3

Team 1

Team 2

Team 3

PDS - 4

Team 1

Team 2

Team 3

BFS

Team 1

Team 2

Team 3

PRS

Team 1

Team 2

Team 3

2 Weeks 2 Weeks 2 Weeks 2 Weeks 2 Weeks

PDS - 1

Team 1

Team 2

Team 3

Release n+1 Release n-1

RSS

Team 1

Team 2

Team 3

Single Focus SDLC

1 Week 2 Weeks

13

Results

14

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16

# of Patches Post Release

Before After

15

# of Defects Patched

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16

Before After

16

P1 Defects (Quarterly)

Before After

17

0

50

100

150

200

250

300

350

400

450

500

R1 R2 R3 R4

Total

Release Induced

SR Trends Post Release

Before After

18

Q3 12 Q4 12 Q1 13 Q2 13 Q3 13 Q4 13 Q1 14 Q2 14

Customer Satisfaction

19

Happiness Restored!

“We have all embraced a process that allows us to

easily adapt to our customers’ evolving needs, yet achieve higher quality

and mitigate risk.”

“Agile at our company has promoted collaboration, accountability and

accurate visibility into our project’s progress.”

“I do not feel like I am running endlessly anymore”

20 20

Disclaimer # 2 - Consequences

21

Tips

22

Make a compelling case to business for the change, first time around

*** Tip # 1 ***

23

Business Drivers for Us

§  Heterogeneous team

§ Growing product complexity

§  Lower risk tolerance

§  Increased sensitivity to quality issues

§ Team morale

24

Invest in formal training for the entire team and insist on doing it together

*** Tip # 2 ***

25

Make Transition Everyone’s Problem

*** Tip # 3 ***

26

Why Form A Transition Team?

§ More than one brain in action

§  Avoids the perception of a top-down push

§ Greater ownership of the new process

§  An insider can do the selling when resistance arises

§  Increased appreciation for cross functional

considerations

27

Use an Agile approach to become an Agile team

*** Tip # 4 ***

28

Follow Scrum for Transition Itself

1.  Form the transition team 2.  Assign roles and responsibility 3.  Create backlog of stories

4. Configure the tools 5.  Prepare agile boards

6.  Do Sprint meetings including daily stand-ups 7.  Conduct sprint review and retrospect

29

Transition Backlog

Agile team

Accepting Stories

A list of typical tasks

All Meetings

Default task created for story

Documentation Plan

Emergency Patches

Engineering Initiatives

Enhancement Requests

Internal Bugs

Issue Workflows

Planned Vacations & Unplanned Absences

Production Bugs

Scope Change Within Story

Lifecycle

Retrospective

Retrospectives

Shared/External Resources

Dependencies Specs to User

Story

Sprint Descriptions

Sprint Meetings

Sprint review recordings

Sprint Type, Length, Start &

End Days

Team Formation Text Review for Translations

WIP Limit Guideline

Release / Sprint Events

Release Meetings

30 30

Example Transition Story

31

Document the rationale behind the decisions/choices made

*** Tip # 5 ***

32 32

WIKI Space for Transition

33

Friday – Thursday Sprint Planning – Friday or Thursday afternoon Sprint Review (demo) & Retrospective – Thursday morning

Pros Cons Demo & Release are currently on Thursdays, so no change needed

Sprint Planning is on WFH Friday – requires team to be present

Team can start tasks on Monday – start of the week

Thursday - Wednesday Sprint Planning – Thursday Sprint Review (demo) & Retrospective - Wednesday

Pros Cons Most people will be in office for major meetings

Demo needs to be changed to Wednesday

Release date will not coincide with sprint end

Sprint start is on same day as release

Monday - Friday Sprint Planning – Monday Sprint Review (demo) & Retrospective - Friday

Tuesday - Monday Sprint Planning – Tuesday Sprint Review (demo) & Retrospective - Monday

Pros Cons Most people will be in office for major meetings

Demo needs to be changed to Monday

Release date will not coincide with sprint end

Weekend break prior to sprint end is not ideal

Pros Cons Follows natural work week

Demo needs to be changed to Friday

Release date will not coincide with sprint end

Sprint Review & Retrospective on WFH Friday

When To Start Sprints?

34 34

How Do Meetings Evolve?

35 35

Philosophy on Internal Defects

36

Plan ahead for distractions, recurring events and special activities

*** Tip # 6 ***

37 37

Emergency Patches

38 38

Paid Time Off

39 39

Shared / External Dependencies

40 40

Engineering Initiatives / Technical Debt

41

Bend The Rule Judiciously, One Size Does Not Fit All

*** Tip # 7 ***

42

Pragmatic Choices

§ Managers as Scrum Master

§  1 Shared QA per Sprint

§ Weekly Demos instead of Sprint demo.

§  Bug fixes sprinkled in feature sprints

43

Stress on team empowerment every step of the way and mean it

*** Tip # 8 ***

44

Relinquish Control to The Team

§ Make them the stake holders for Transition Team

§ Give them the freedom to form their own team

§ Team names themselves

§ Team decides when they want to meet

§ Team decides their WIP limit

§ Team defines the meaning of story points

§ Team commits to stories

§ Team is given privacy during the retrospect

Yes, even when it makes everyone else uncomfortable!

45 45

Give Them The Tools of The Trade

46 46

Give Them Autonomy

47

Anticipate Staggered / Delayed Resistance

*** Tip # 9 ***

48

Enthusiasm – Fear - Resistance

49

Change Curve

50

Set expectations carefully and strike a balance between optimism and fear

*** Tip # 10 ***

51

Key Takeaways

- Create a single focus SDLC

- Make transition everyone’s problem

- Take an agile approach to the change

- Empower the team

- Measure progress

52

Additional Resources

§ The Agile Architecture Roadmap https://www.youtube.com/watch?v=kF09A-E6K0M

§ Rolling out Agile in a Large Enterprise http://evolvebeyond.com/resources/yahoorollout/YahooAgileRollout1.pdf

§  Agile on InfoQ http://www.infoq.com/agile/

§  Succeding with Agile http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364/ref=sr_1_2?s=books&ie=UTF8&qid=1397853335&sr=1-2&keywords=agile

53

That’s It!

54

Tips

1.  Make a compelling case to business for the change, first time around

2.  Invest in formal training for the entire team and insist on doing it together

3.  Make Transition Everyone’s Problem

4.  Use an Agile approach to become an Agile team

5.  Document the rationale behind the decisions/choices made

6.  Plan ahead for distractions, recurring events and special activities

7.  Bend the rule judiciously, one size does not fit all

8.  Stress on team empowerment every step of the way and mean it

9.  Anticipate Staggered / Delayed Resistance

10.  Set expectations carefully and strike a balance between optimism and fear