I spoke at a meetup hosted at Yahoo about Agile transformation and how to get it right. http://www.meetup.com/SV-ATL/events/166560992/

1. 1
10 Essential Tips for Conquering
Agile Transition
Obaidur (OB) Rashid
Senior Director, Product Development
Oracle Corporation

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

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

4. 4
Context

5. 5
Distributed Team

6. 6
ReleaseCode 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

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

8. 8
Changes

9. 9
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
PRS
Team 1
Team 2
Team 3
PDS - 1
Team 1
Team 2
Team 3
Release n+1Release n-1
RSS
Team 1
Team 2
Team 3
Single Focus SDLC

10. 10
Results

11. 11
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”

12. 12
Tips

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

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

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

16. 16
Make Transition Everyone’s Problem
Tip # 3

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

18. 18
Use an Agile approach to become an
Agile team
Tip # 4

19. 19
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
8. Rinse and repeat (3-7)

20. 20
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, St
art & End Days
Team Formation
Text Review for
Translations
WIP Limit
Guideline
Release / Sprint
Events
Release
Meetings

21. 2121
Example Transition Story

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

23. 2323
WIKI Space for Transition

24. 24
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?

25. 2525
Philosophy on Internal Defects

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

27. 27
Account For …
 Emergency patches
 Paid time off
 Shared / external resources
 Engineering initiatives

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

29. 29
Pragmatic Choices
 Managers as Scrum Master
 1 Shared QA per Sprint
 Weekly Demos instead of Sprint demo.
 Bug fixes sprinkled in feature sprints

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

31. 31
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!

32. 3232
Give Them The Tools of The Trade

33. 3333
Give Them Autonomy

34. 34
Anticipate Staggered / Delayed
Resistance
Tip # 9

35. 35
Enthusiasm – Fear - Resistance

36. 36
Change Curve

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

38. 38
Key Takeaways
- Create a single focus SDLC
- Make transition everyone’s problem
- Take an agile approach to the change
- Empower the team
- Measure progress & resultsfocus SDLC

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

40. 40
That’s It!