This presentation was done at Journee Agile in Liege. It explains how technical capabilities are an important part of any transformation. Without tech capabilities you will have a hard time to release, and a hard time to inspect and adapt.

1. Technical Capabilities
as enabler
for Agile and DevOps
wemanity
@nelisboucke
@matteo_pierro

2. The hard truths about transformations!
85% of transformations fail
source: https://www.thedrum.com/news/2018/12/04/digital-transformation-takes-around-four-years-and-85-them-fail-says-ibm
IBM study
IDG research
source: https://www.insightcdct.com/Transform

3. Why?
Goal of the transformation is not well understood

4. Agile Transformation
Push a new Process
(Framework)
DevOps
Transformation
Push new Tools
Goal != transform for transformation
4 to 5 years of

5. Agile Transformation
Organisation
Performance
DevOps
Transformation
Goal = better business outcome
• Profitability
• Productivity
• Expand market share
?

6. Agile Transformation
Organisation
Performance
DevOps
Transformation
Achieve better business outcome
Inspect & Adapt

7. Wait…..We already do it, right?
• No real potentially shippable product!
• Full of bugs
• Long testing activities
• Release orchestration
• Adding feature goes slower and slower
You need the (tech) capabilities to do so!

8. Facts please!

9. What did they discover?
• 4 software delivery metrics are correlated with organisational
performance
• Companies scoring well on the metrics share 24 capabilities
Business
Outcome
Metrics
Capabilities Metrics

10. Software Delivery Metrics
Business
Outcome
Metrics

11. Typical used metrics

12. Flaws of the typical used metrics
• Most focus on local productivity.
• Are they linked with the organisation performance?
• Focus on output rather then outcome
• Focus on local measures rather than organisation objectives

13. Better Metrics
•Lead Time
•Deployment Frequency
•Mean Time To Recover (MTTR)
•Change Failure Rate

14. Lead Time

15. Lead Time
CVS
Push

16. Lead Time
Build
CVS
Push

17. Lead Time
Build Deploy
CVS
Push

18. Lead Time
Lead Time
Build Deploy
CVS
Push

19. Deploy frequency
Deploy
Timeline of 4 days

20. Deploy frequency
Deploy
3 deploys/day

21. Deploy frequency
Deploy
3 deploys/day

22. Deploy frequency
Deploy
more than 2 deploys/day

23. Deploy frequency
Deploy
2 deploys/day

24. Change Failure Rate

25. Change Failure Rate
CVS
Push

26. Change Failure Rate
Build
CVS
Push

27. Change Failure Rate
Build
CVS
Push
Deploy

28. Change Failure Rate
Build
CVS
Push
Deploy
WTF?!?!

29. Mean Time To Recover (MTTR)
Build
CVS
Push
Defect!
Deploy
WTF?!?!

30. Mean Time To Recover (MTTR)
Build
CVS
Fix
Defect!
Deploy
WTF?!?!

31. Mean Time To Recover (MTTR)
Build
CVS
Fix
Defect!
Deploy
WTF?!?!

32. Mean Time To Recover (MTTR)
Build
CVS
Fix
Defect!
Deploy
WTF?!?!

33. Mean Time To Recover (MTTR)
Build
CVS
Fix
Defect!
Deploy
It’s Amazing

34. Benchmark
High Performers Medium Performers Low Performers
Lead Time Less than one hour
Between one week and
one month
Several months
Deployment Frequency
On Demand
(Multiple deploys per
day)
Between once per week
and once per month
Between once per
month and once per
quarter
MTTR Less than one hour
Less than one
day
Between one day and
one week
Change Failure Rate 0 - 15% 0 - 15% 31 - 45%
“High performers are twice as likely to exceed organisational performance
goals as low performers”

35. How capabilities impact Metrics?
Capabilities Metrics

36. 24 Capabilities
Capabilities
Transformational
Leadership
Lean Product
Development
Lean
Management
Technical
Capabilities
Business
Outcome
Metrics

37. Technical capabilities
• Test Automation
• Test Data Management
Testing
• Versioning
• Trunk-Based Development
• Continuous Integration
CI
• Shift Left On Security
• Deployment Automation
Deployment
• Monitoring
• Proactive notifications
Feedback
• Empowered Teams
• Loosely Coupled
Architecture
Architectural

38. Testing Capabilities
• Reliable and Fast test suite
• tests pass —> we can release
• failures —> pinpoint to real problems
• Acceptance tests by Developers
• No separated QA or outsourcing
• Test Data for Automated Tests
Deploy Frequency
Lead Time

39. • Loosely coupled architecture
• teams can test and deploy
independently
• enables scaling
• Architect for Empowered Teams
• Teams choose their own dev tools!
Architectural Capabilities
Deploy Frequency
MTTR

40. CI Capabilities
• Version Control everything!
• e.g. system configuration, application
configuration, scripts for build and configuration
• Trunk based development
• never have “code freeze” or stabilisation periods.
• Continuous integration
• Change triggers a build process and tests
• On failure, teams do fix immediately.
Deploy Frequency
Lead Time

41. Deployment Capabilities
• Shifting left on security
• security not as a downstream phase
• in process with software delivery
• no separated security teams
• Deployment automation
• deployments are fully automated
• no manual intervention
• Make release a non event
Deploy Frequency
MTTR

42. Feedback Capabilities
• Proactive Notification
• Monitor system health, using threshold
and rate-of-change warnings, to enable
teams to preemptively detect and
mitigate problems.
• Monitoring:
• telemetry across application and
infrastructure to inform business
decisions.
MTTR
Lead Time

43. 24 Capabilities
Capabilities
Transformational
Leadership
Lean Product
Development
Lean
Management
Technical
Capabilities
Business
Outcome
Metrics

44. Our path towards
Technical Capabilities

45. First improve yourself …
Depth-firstTeam
Embedded (Stake)
Volunteering
Empathy
Focus on their problems
Important problem

46. First improve yourself …
Architectural MonitoringDeploymentTesting CI
Team
Metrics?

47. … and others will follow
Team
Management
QASecurity team
Release mngt
Infrastructure
Metrics!

48. Conclusion
•Have a clear goal that improves the business outcome
•Key for a transformation = build technical capabilities!
•not Process and Tools
•Focussing on improving the software delivery metrics

49. Who are we?
Nelis Boucké Matteo Pierro
@nelisboucke
@matteo_pierro

50. Additional Material