Download to read offline
Uploaded byDevOpsDays DFW
Dana Finster - DevOps - Do the Math
The document discusses the concept of DevOps as a combination of people, processes, and products aimed at delivering continuous value to end users. It emphasizes a shift in mindset from siloed teams and output-focused approaches to collaborative and outcome-focused strategies with small increments. Various case studies illustrate these principles, along with the importance of architectural flexibility in the DevOps framework.
More Related Content
Similar to Dana Finster - DevOps - Do the Math
Dana Finster - DevOps - Do the Math
- 1. DevOps – Dothe Math Dana Finster
- 2. ©2019 FireEye©2019 FireEye2 Casestudies and examples are drawn from our experiences and activities working for a variety of customers, and do not represent our work for any one customer or set of customers. In many cases, facts have been changed to obscure the identity of our customers and individuals associated with our customers.
- 3. ©2019 FireEye©2019 FireEye —Donovan Brown Microsoft 3 “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.”
- 4. ©2019 FireEye©2019 FireEye MindsetShift VALUE to END USERS TEAMS Output focused Siloed Outcome focused Collaborative PLANNING Fixed scope Major releases Prioritized features Small increments ARCHITECTURE Tightly coupled Loosely coupled
- 5. ©2019 FireEye©2019 FireEye MindsetShift VALUE to END USERS TEAMS Output focused Siloed Outcome focused Collaborative PLANNING Fixed scope Major releases Prioritized features Small increments FOCUSED and INDEPENDENT ARCHITECTURE Tightly coupled Loosely coupled
- 6. ©2019 FireEye©2019 FireEye MindsetShift VALUE to END USERS TEAMS Output focused Siloed Outcome focused Collaborative CONTINUOUS PLANNING PLANNING Fixed scope Major releases Prioritized features Small increments FOCUSED and INDEPENDENT ARCHITECTURE Tightly coupled Loosely coupled
- 7. ©2019 FireEye©2019 FireEye VALUEto END USERS Mindset Shift TEAMS Output focused Siloed Outcome focused Collaborative CONTINUOUS PLANNING PLANNING Fixed scope Major releases Prioritized features Small increments FOCUSED and INDEPENDENT ARCHITECTURE Tightly coupled Loosely coupled
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15. ©2019 FireEye©2019 FireEye15 Openstory/feature:
- 16. ©2019 FireEye©2019 FireEye16 Openstory/feature:
- 17. ©2019 FireEye©2019 FireEye 17 Openstory/feature:
- 18. ©2019 FireEye©2019 FireEye 18 Openstory/feature:
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. ©2019 FireEye©2019 FireEye 25 Openstory/feature:
- 26. ©2019 FireEye©2019 FireEye Accelerate MakingWork Visible Engineering the Digital Transformation Domain Driven Design The Unicorn Project trunkbaseddevelopment.com agilealliance.org 26 Thank You! Dana Finster Staff Engineer, FireEye [email protected] @Dana_Finster
Editor's Notes
- #2 benefits of continuous “Ah-Ha” Helping teams with big mindset shift Big change – (ah-ha) Change mindset is hard - context no prescription for DevOps toolkit – ideas, perspectives, success/horror stories encourage experiments. My tool (mantra)
- #3 No actual FireEye customers are represented or otherwise implicated in this talk.
- #4 not the tools not dev and ops culture of the organization mindset of people value delivered to end users. In this talk…mindset of the people Change - build efficient teams - deliver value quickly .
- #5 3 key areas Project – individuals / set of requirements / silos Work intertwined – manual – deploy takes too much effort CD - collaborative product teams – lifecycle Lean process/automation – outcomes (value).
- #6 Architecture - incremental growth. Tightly coupled – integration, complex coordination, slow Not all microservices domain driven design / functional products / guide evolutionary change. Loosely coupled / independently deployable/ teams own Removes need to manage dependencies.
- #7 Need long planning sessions – features, complexity CD - short, frequent planning sessions; incorporate feedback “every release is missing the next feature” Stop planning for done -> focus on what value can we deliver today.
- #8 “We’re fine.” “branching strategy” “next release more important” “better deployment pipeline”. excuses --- change in mindset is necessary for continuous delivery success.
- #9 [Get Clipboard & Glasses]
- #10 Word problem - how the way teams work affects delivery success
- #11 Let’s do the math. single person 90 days divided by 6 Priority #1 delivered in 15 days 75 days earlier; 83% shorter cycle time Assumptions.. perfect world? Break it down – arguments… and see… .
- #12 Is this realistic? Argument - Customer request Not just dev & IT – important everyone understand value/speed of incremental change Apps, etc --- already trained to receive incremental value Continuously Deliver small = more similar sizes Not literally same effort – inherently closer w/ smallest possible batches.
- #13 If anything can go wrong, it will. At the worst possible time Causing the most damage Factors scored 1-9 change the odds - change one of the elements. urgent or complex - find a simple way small batches - reduce risk, large/complex more likely to go wrong
- #14 But experts T-shaped – learn – focus on highest priority Deployments small and focused, work together, feedback, focus on right value Priorities change, reorganize w/o stopping in the middle – work sitting on shelf like stale inventory Speed - 83% faster working together
- #15 simple math fact “new math”
- #16 Visual – work delivered faster working together… (run/describe animations) Left – team working together Right – individuals assigned work to complete on their own … go through work increments (sprints)
- #17 Small batches / large amount of work, long timeframe Team knowledgeable - troubleshooting easier – saves $$ / Troubleshooting harder, slower – costs $$ Team focused on next priority / no real prioritization Set priorities, smaller batches, collaborate, knowledge shared - best chance of success Some things still don’t go as planned.
- #18 - Sick / vacation / leave - Feature more complex Bugs/support Team - still best for success CI – daily to master, multiple tasks/day Doesn’t work well w/ individuals in own streams Siloed – gold plating, rabbit holes, fragile/interruptions Team – focused on same outcome - estimation errors, feedback, correct course multitasking/interruptions
- #19 Higher probability – get more done, priority first 5 of 6 features, 83% 3 of 6 features, 50% The 3 features that are complete may not be able to be delivered. Deploy at once, does not force features to be independent from code deployed at the same time.
- #20 External or siloed internally Coordination / change one place, changes something else Troy Magennis – 2015 Agile Alliance / Dominica DeGrandis Making Work Visible Logical rule Formula 1 in 8 shot, 12% chance Independent, loosely coupled teams and architecture are key to success
- #21 Working as team, small batch, minimizing complexity/dependencies Moving fast! Planning, retrospectives, team updates – more often More Meetings No real work Mindset that needs to change
- #22 Think boring… Yes! Boring when siloed manager/lead tracking multiple streams or work Meetings are chaotic
- #23 Team focus: same outcome, single deliverable (single piece flow) Planning, retros, daily updates valuable, integral Feedback / right value faster Understand requirements – reduce uncertainty and rework Effectively harnessing feedback Focused… less effort to deliver value
- #24 Use Simple math to change minds and influence DevOps culture. Build collaborative, t-shaped, focused on outcomes Build small, focused & independent / minimize dependencies – all costs / cost a lot Continuous planning - integral, learn, harness feedback Work in small batches, commit daily, and always be deployable… murphy
- #25 Show of hands…
- #26 Paying attention, should answered a) Work together on only the highest priority.
- #27 a few of the resources that I find to be helpful in doing a more in-depth exploration of some of these ideas.