jdd2014: agile transformation - how to change minds, deliver amazing results and enjoy the journey!...
DESCRIPTION
Transitioning an organization from Waterfall to Agile can be difficult much like any change management tends to be. For most people involved, it ends up being an ordeal. But, there is a better way. With the right strategy and tools, this can be a rather rewarding and unifying experience instead. In this talk, we will discuss one such transition and the elements that contributed to its success.TRANSCRIPT
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