The document discusses agile transformation at Oracle Corporation. It describes challenges with their original waterfall development process and how adopting scrum improved results. Key changes included implementing a 13-week release cycle with dedicated sprints for development, bug fixing, and stabilization. Metrics like defects, patches, and customer satisfaction significantly improved after the transition. The presentation concludes with "tips" for successful agile adoption, such as empowering teams, documenting decisions, and anticipating resistance to change.

1. Agile Transformation in Real World
1
How to Change Minds, Deliver Amazing
Results and Enjoy The Journey!
Obaidur (OB) Rashid
Senior Director, Product Development
Oracle Corporation
Twitter: @orashid

2. About Me Twitter: @orashid
§ 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 …
2
Oracle
OnVantage
StarCite
Taleo

3. 3
Disclaimer # 1
Opinions expressed in this talk
are my own and do not reflect
the view of my employer

4. 4
Road Ahead
§ Context
– Scope and Scale
– Impetus for Change
§ Highlights of the changes
§ Results / Outcome
§ “Tips”
§ Q&A

5. 5
Context

6. 6
Taleo Business Edition (TBE)

7. 7
Distributed Team

8. 8
8 - 10 Weeks
Original SDLC
Pre Release
Stabilization
Code Release
Complete
Code
Freeze
Next Release Development Starts Here
Post Release
Support
2 Weeks 1 Week
5 Weeks
2 Weeks
... Development
…
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

9. 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. 10
Changes

11. 11
Embrace Scrum

12. Release n-1 Release n+1
12
13 Week Release Cycle
Week 1 Week 13
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
RSS
Team 1
Team 2
Team 3
Single Focus SDLC
1 Week 2 Weeks

13. 13
Results

14. 14
# of Patches Post Release
Before After
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16

15. 15
# of Defects Patched
Before After
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16

16. 16
P1 Defects (Quarterly)
Before After

17. 17
500
450
400
350
300
250
200
150
100
50
0
R1 R2 R3 R4
Total
Release Induced
SR Trends Post Release
Before After

18. 18
Customer Satisfaction
Q3 12 Q4 12 Q1 13 Q2 13 Q3 13 Q4 13 Q1 14 Q2 14

19. 19
Happiness Restored!
“Agile at our company has promoted
collaboration, accountability and
accurate visibility into our project’s
progress.”
“We have all embraced a
process that allows us to
easily adapt to our
customers’ evolving needs,
yet achieve higher quality
and mitigate risk.”
“I do not feel like I am
running endlessly anymore”

20. 20 20
Disclaimer # 2 - Consequences

21. 21
Tips

22. Make a compelling case to
business for the change, first
time around
22
*** Tip # 1 ***

23. 23
Business Drivers for Us
§ Heterogeneous team
§ Growing product complexity
§ Lower risk tolerance
§ Increased sensitivity to quality issues
§ Team morale

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

25. 25
*** Tip # 3 ***
Make Transition Everyone’s
Problem

26. 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
27
*** Tip # 4 ***

28. 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. 29
Transition Backlog
Agile team
Accepting
Stories
A list of typical
tasks
All Meetings
Default task
created for story
Documentation
Plan
Planned
Vacations &
Unplanned
Absences
Issue Workflows
Internal Bugs
Enhancement
Requests
Engineering
Initiatives
Emergency
Patches
Production Bugs
Scope Change
Within Story
Lifecycle
Retrospective
Retrospectives
Shared/External
Resources
Dependencies
Team Formation Text Review for
Sprint Type,
Length, Start &
End Days
Sprint review
recordings
Sprint Meetings
Sprint
Descriptions
Specs to User
Story
Translations
WIP Limit
Guideline
Release / Sprint
Events
Release
Meetings

30. 30 30
Example Transition Story

31. Document the rationale behind
the decisions/choices made
31
*** Tip # 5 ***

32. 32 32
WIKI Space for Transition

33. When To Start Sprints?
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
33
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

34. 34 34
How Do Meetings Evolve?

35. 35 35
Philosophy on Internal Defects

36. Plan ahead for distractions,
recurring events and special
activities
36
*** Tip # 6 ***

37. 37 37
Emergency Patches

38. 38 38
Paid Time Off

39. 39 39
Shared / External Dependencies

40. 40 40
Engineering Initiatives / Technical Debt

41. Bend The Rule Judiciously, One
Size Does Not Fit All
41
*** Tip # 7 ***

42. 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. 43
*** Tip # 8 ***
Stress on team empowerment
every step of the way and
mean it

44. 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 45
Give Them The Tools of The Trade

46. 46 46
Give Them Autonomy

47. Anticipate Staggered / Delayed
Resistance
47
*** Tip # 9 ***

48. 48
Enthusiasm – Fear - Resistance

49. 49
Change Curve

50. 50
*** Tip # 10 ***
Set expectations carefully
and strike a balance
between optimism and fear

51. 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. 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. 53
That’s It!

54. 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