On the way to DevOps at Infinera A successful Feature Development Model Mladen Milev DevOps Lisbon - 30 March 2020

[email protected] @milev_mladen https://www.linkedin.com/in/mladenmilev/ About Me Mladen Milev • Software engineer with 17+ years experience • Lean Development and DevOps enthusiast • Author of a patent and patent pending applications 2 Hardware and Software Networking Solutions in 100+ countries across six continents

3 Road to Success!

The Product 4 Used by our sales and customer support (Internal Customers) Is used by selected end customers (External Customers) Enables new business and revenue

Hands-On (Q2-2015) The Team • Product Manager – 0.2 • System Engineer – 1 • Developers – 2 • Quality Assurance – 2 5 310k Lines of Code 840 Days of SonarQube Technical Debt 25 Days Ready for Market Visual C++/win32

The process 6 Implemented Agile process: • Iterative • Incremental • Evolutionary

A A A ABC ABC B B B C C C Release Execution (2015-2017) 7 Example release with 3 Features - A, B and C Specification Development Tests Integration Legend Regression

SonarQube 8 72% decrease in Technical Debt over a 2-year period 0 100 200 300 400 500 600 700 800 G H I J K L M N O P Technical Debt (days) Q3/2015 Q3/2017

Progress 9 0 50 000 100 000 150 000 200 000 250 000 300 000 350 000 400 000 450 000 G H I J K L M N O P Lines of code 0 5 000 10 000 15 000 20 000 25 000 G H I J K L M N O P SonarQube Code functions Q3/2015 Q3/2017 Q3/2015 Q3/2017

1 4 8 5 8 7 8 7 3 1 G H I J K L M N O P Number of Features in release Being Agile Agile practices but ... • The throughput was unstable • Some features were shifted to next • Quality issues, requiring maintenance release • Escalations from customer 10 Q3/2015 Q3/2017

Team Perspective 11 Retrospective meetings indicated • Requests are high-level, • Hidden details • Difficult to elaborate accurate estimations • Late change requests

Product Perspective 12 Product manager feedback: • Difficulty in planning releases • Shifting functionality to later release • Not fulfilling customer expectations

13

14 Deliver Functionality As Expected a.k.a. “Feature Development Model"

Feature Development (Ownership) Ownership • Feature Responsible • Each feature should be user testable • Initial workshop • Feature Delivery workshop 15

Feature Development (Process) Process • Each Feature ~ 1 week • Individual Work Package – 2/3 days • Limits are NOT strict but highly advisable 16

Feature Development (Engagement) Customer Engagement • Workshops while developing • Participating in the acceptance tests • Presentation of delivered functionality from Dev to Customer 17

FDD A A A A B B B C C C FDD B FDD C 18 3 Features 3 Features Traditional Approach New Approach Feature Development (Execution) ABC ABC Specification Development Tests Integration Legend Regression

Feature Development (Execution) FDD A Legend FDD B FDD C New Approach 3 Features Reordering the execution is possible with no or minor impacts 19 Specification Development Tests Integration Regression

Feature Development (Execution) Legend FDD D FDD E New Approach 5 Features Linear scaling possible 20 Specification Development Tests Integration Regression FDD A FDD B FDD C

How did it work? 21 25 2 0 5 10 15 20 25 30 2015 2019 Minimum time to market (days) 14 2 0 2 4 6 8 10 12 14 16 2015 2019 Shifted functionality to later release

1 4 8 5 8 7 8 7 3 1 2 4 7 10 14 15 G H I J K L M N O P Q R S T U V Number of Features in release 22 Results Once the process was established it was scalling-up Q3/2015 Q3/2017 Q2/2020

Conclusions Achieved: • Decreased minimum time to market • Increased functionality per release • Less deviation from planned reoadmap Results in: • Increased stakeholders' confidence in the roadmap • Increased satisfaction of customer • Happier team 23

Thank You Mladen Milev [email protected] https://www.linkedin.com/in/mladenmilev/