Presentation at Agile Tour Montreal 2018 by Maurizio Mancini of Exempio and Paul T. Ryan CTO of OpenX. Many organizations think they are Agile when they are not. Here is how to recognize when you need an Agile reboot and how to reboot your organization to become a true Agile organization.

1. Getting Agile right - rebooting an
Agile organization in 100 days
MAURIZIO MANCINI | CONSULTANT | EXEMPIO.COM | @QAANDPROCESSGUY
PAUL T. RYAN | CTO | OPENX.COM | @PTRYAN123

2. Reboot?

3. Sign 2
Teams still early in the Agile
journey - number of flavours of
Agile is equal to the number of
teams you have
3 Most Common Signs you need a Reboot
Sign 3
You have Featuritis or
Small-ball
Sign 1
You have 3 to 4 times more
“projects” than your teams
can deliver

4. Bonus 1
You’ve rolled out Agile at least
3 times already
Bonus 2
People tell you ‘Agile Doesn’t work’
Bonus Signs

5. Everyone Was Busy

6. PLAYING AGILE BEING AGILE
TO DO
IN
PROGRESS
DONE

7. Kick Starting your Reboot
The Five Steps

8. What is OpenX?

9. # 1 Buy-In from the Top!

11. # 2 Clear Business Goals

12. Business Goals

13. Business Goals

14. Business Goals

15. Business Goals

16. # 3 Clear Ownership

17. Role Confusion
“Why did the engineers build it if it wasn’t going to
work?” “I thought the CTO sets development priorities”
Process Confusion
“Hey -- I just said it would be a good idea to add the
feature — I didn’t tell them to do it!”
Accountability Resistance
“We don’t need any planning — it just slows things down”

18. # 4

19. # 5 Get Moving

20. 100 Days and Counting
Our Roadmap

21. Strategic
Assessment
Sept 2017
Oct 2017
Team
Assessments
Dec 2017
Agile Refresher,
Tool Realignment
Team
Assessments and
Agile Refreshers
Nov 2017
100 Business Days and Counting… Our RoadMap
Organization-wide
meetings on priorities,
accountability & drive
Nov 2017
Nov 2017
Tech Roadmap
for TechDebt

22. Go!
January 2018

23. Strategic Assessments

24. Meet with CTO
Gather his perspective
Meet with
Key Team
Members
Gather teams
perspective of
companies
Strategic Direction
Vision
1 year and 3 year
Tech Debt
Analysis
Quality of current
code
Strategic Assessment

25. Strategic
Assessment
KEY FINDINGS AND RECOMMENDATIONS

26. Everything is
a
Top Priority
Teams
Playing Agile
instead of
Being Agile
Portfolio and
Program
planning
inadequate
Strategic Assessment Key Findings
Tech Debt
Analysis
Level was
Reasonable
TO DO IN
PROGRESS
DONE

27. ARB and PC
Architecture Review Board and
Product Council
Weighted Shortest Job First
WSJF for Project Ranking
Portfolio Kanban for
Upper Management
WSJF
RECOMMENDATIONS

28. Projects use
Scrum or
Kanban
Dynamic Teams
Scrum
Kanban
RECOMMENDATIONS

29. Strategic and Team Vision

30. Team Assessments

31. Interviewed more than 50
people across various roles
Through the use of 1-1 or small group interviews
Directors
Managers
Team Leads
Team Members

32. Conducted a survey-Five Point scale
31 questions
on
6 dimensions
and a
comments
section

33. Agile Basics (6)
Values and Principles, Scrum or Kanban roles,
Stable Teams, Epics and Stories
Product Ownership (5)
Available, Vision, Product Backlog Prioritization,
Refinement and Readiness, Acceptance Criteria
Team Roles and Agile Skills (5)
Clear roles, Sprint Planning and Goals, Definition of
Done, Predictable Velocity, Building in Quality

34. Team and Processes (5)
Scrum Master assigned, user stories ready, self-
organized team, collaborative planning, retrospective
and followup
Release Management and Delivery (5)
Release Planning, product backlog prioritization, business
feature estimation and slicing, cross team dependancies,
Sprint Reviews
Quality (5)
Quality goals: corporate, software product, software
component. Sprint quality goal improvements, quality
measurements being made

35. Attended a number
of team meetings
Where I needed a little more insight into
how the team or product worked

36. Team
Assessment
Results
POSITIVE PATTERNS AND ANTI-PATTERNS

37. Keep it Up!
• Team Work
• Self Organized Teams
• Two Week Release Train
• Technical Level of QA Team Members
• Continuous Integration was available
• Some Dev helping with Automation
• Tools were up to date
• Separate team doing End to End testing
• Some requirements were on the Wiki
Opportunities to take it to
the Next Level

38. Opportunities Discovered
• Who owns Quality?
• Who owns Test Automation?
• Accounting for Test Automation
• Maintenance
• UI Automation Path
• Release Process and Cadence
• Release Tool and CI process adoption
• Process and Tools Team
• Tool Tune-Up
• Service Desk - Replace
• Portfolio Management - Replace
Opportunities Discovered
• Maturing Agile
• Role Clarification
• Project Prioritization
• Organization of Work
• Backlog Cleanup
• What’s an EPIC?
• One Story at a Time
• Release Planning
• Estimation
• Tech Debt Tracking
• Updating Requirements
• Dev/QA Ratio
• Hiring and On-boarding
• Test Environments
Many of these
Opportunities are
Common Anti-Patterns
found in many
organizations

39. People Process Tools
Key Recommendations

40. Role Clarification
and
Maturing Agile

41. Scrum Master?
PM
Line Manager?
Role Confusion
PM
PM
PO
Project Manager Program Manager
Product Manager Product Owner

42. No Full Time Scrum
Masters
Product Owner role was
not clearly defined
People Playing Multiple Roles

43. Agile Refreshers
• Scrum/Kanban Short Refresher - ½ day
• Scrum/Kanban Full Refresher - 1 day
• Scrum Master Training - ½ day
• Product Owner Training - ½ day
• Being an Agile Manager - ½ day

44. We focused on:
• Getting back to the basics
• Fixing the misconceptions
• Ensuring everyone had the same foundation
• The roles
Agile Refreshers

45. Who own’s Quality?

48. 1. QA Director-Advocate of
Who owns Quality
2. Promote the
implementation of a
DevOps culture
3. Holding a QA education event
Top 3 Recommendations

49. Aligning the Process

50. Recommendation
• Minimum - Close all issues older than 1 year.
• Issues older than 6 months.
Backlog Cleanup
Most common Anti-Pattern
“We have this large number of issues
in the backlog because ‘one day’ we
may come back and do the work…”
• Projects with hundreds of issues
older than 2 years.

51. • Sounds basic, but not really
• Scaling Agile confusion in definition
• EPIC was being used to manage
Projects
What’s an EPIC?
Recommendation
Bring it back to the
basic definition

52. One Story at a Time
• Stories were too large - Some were EPICs
• Stories were just work tasks
• Teams needed to focus
• Stop Starting, Start Finishing!

53. Process and Tools Team

54. The Importance of the Process and Tools Team
• Mechanics of the triad
• Not just tool configuration
• Team owns the triad!
• Agile Coaches and Scrum Masters
• Community of Practice (CoP)

55. Aligning the Tools

56. Aligning the Tools-OpenX Context
• 22 Teams-Mostly Software Teams, some Operational Teams
• Projects -Mostly Software, a few Operational
• PMO -Required Portfolio Management

57. TOOL CONFIGURATION SPECTRUM
Use the tool out of the box
-
No Configuration
OpenX
Why did you buy a
packaged software?
OOB Extreme

58. Common Anti-Patterns
• Tools are being used improperly
• Tools are not optimally configured
Tools are impacting the effectiveness
of the teams and the process

59. Teams told that tools couldn’t do
something when they could
Never shown the potential of the
tools
Previous tool experience - impacting
higher level reporting
Impact of tool mis-use and configuration on the Teams

60. Implemented
Process to use the
wiki collaboration
with the task
management tool.
Replaced
Homegrown service
desk with a modern
service desk
Intervention
We optimized the
task management
tool through a deep
intervention.
Aligning Tools for the Reboot

61. Portfolio Management
• Projects Products
• Replaced the more complex tool
• Start Simple - Get the basics working
• Portfolio’s are complex - Some data manipulation

62. Results — 10 Months

63. The Good
The Bad
The Ugly

64. The Good
• 28 Projects completed
• Clear project prioritization
• Scrum & Kanban both used
• Project teams have all skills
required to launch
• All teams have scrum masters,
product owners and are self-
empowered

65. The Bad
Project Portfolio
• Monotonically increasing backlog w/o
grooming
• Phases of a project without any value
attainment
• Inadequate estimates of value & no value
accountability
Staffing
• Too many multiple-project assignments (key
resources) w/context switching problems

66. The Ugly
Go To Market (GTM)
• Not used to project completion
Prioritization
• Objectives -> Initiatives -> Project prioritization
Staffing
• Managers moving around resources

67. Quality
• Solid progress on culture change - quality owned
by everyone
• Dev/QA wall slowly coming down
• DevOps culture slowly starting to emerge

68. The Tools
• Optimized for OpenX reality
• 1-1, Task Management - Wiki Space association
• Moved to a simpler Portfolio Management tool
• Migrated from home grown service desk to modern Service Desk

69. Key Takeaways
and
What we would do differently

70. Transformation is Hard!

71. It Starts from the Top
Exec Portfolio Kanban

72. Start with the Basics

73. How we would start the journey today…
• Metrics First
• Staffing Consistency
• Real Value Estimation
• Limit & Groom Backlog
• Go To Market (GTM)
• DevOps Culture

74. The Power of the Cloud

76. MAURIZIO MANCINI | CONSULTANT | EXEMPIO.COM | @QAANDPROCESSGUY
PAUL T. RYAN | CTO | OPENX.COM | @PTRYAN123
Thank you!
Merci!