Antifragility, DevOps and BiSL Next. Leading and lagging indicators. Leading and lagging in IT. Enterprise DevOps Dialogue, 28 maart 2017

Size: px
Start display at page:

Download "Antifragility, DevOps and BiSL Next. Leading and lagging indicators. Leading and lagging in IT. Enterprise DevOps Dialogue, 28 maart 2017"

Transcription

1 Antifragility, DevOps and BiSL Next Jan de Vries working groups agile scaling, agile leadership & por4olio management Enterprise DevOps working group Enterprise DevOps Dialogue, 28 maart 2017 Organisatie in beweging brengen Seeing things early & Connecting the dots In kaart brengen van Blue Oceans Product snel en zonder waste naar de markt Automatisering in korte cycli opleveren Leading and lagging indicators Leading and lagging in IT Leading indicator: hard to measure easy to influence Lagging indicator: easy to measure hard to influence

2 Nassim Nicholas Taleb Gain Gain Variable Variable Pain Pain

3 Asymmetry is key Gain Pain Variable 1 Nonlinearity Definition: anything that has more upside than downside from random events / shocks is antifragile; the reverse is fragile. to judge the (anti)-fragility of a system is to ask whether it is accelerating towards harm or benefit Gain Gain Variable Variable Pain Pain

4 Gain Gain Variable Variable Pain Pain Concave Convex Gain Pain Concave Convex Variable Gain Pain CONTINUOUS DELIVERY IS ANTIFRAGILE Number of deployments per month

5 Smile or frown Gain SOFTWARE PROJECTS ARE FRAGILE Number of tasks coordinated in a project Pain The 'opposites' of fragile Robust Resilient Antifragile Gain Time Pain Source: Sogeti

6 Fragile Fragile Fragile Robust

7 Robust in IT Resilient Resilient Antifragile

8 Antifragile in IT Latency monkey Janitor monkey Conformity monkey Chaos gorilla Gain Time How to become less fragile, even antifragile? Pain Source: Sogeti

9 Disorders in IT Definition: Stable systems, because they don t change, eventually experience shocks large enough to cause catastrophic failure. Antifragile systems break a little all the time but evolve as a result, becoming less prone to catastrophic failure. The change -> software must be adapted to the business needs changing existing functionality implementing new requirements support new business opportunities Fragile in IT Robust in IT not easy to change, to extend, to deploy not able to handle unexpected user inputs or external system failures carrying technical debt Unix

10 Resilient in IT Antifragility in IT retry mechanisms self healing, auto repair auto scaling microservices continuous deployments chaos engineering open source It is not just a software system but a social-technical system Source: Bilgin Ibryam Why is agile fragile? How iterative is your software process? 2 week iterations c 3 week iterations

11 How often do you release to your customer? The result and the consequences Monthly c Quarterly Tester: discovers defects that a developer introduced 3 months ago Developer: what did I build 3 months ago? Designer: what did I design 6 months ago User: what did I ask for long time ago? Time Why not release more often? Manual activities: Integration Acceptance tests deployments conversions If it hurts... Do it more often Vicious So we keep the frequency low: Saves time for Dev and Ops Increases stability circle 600 Why not automate? No business case Because we don t do it often enough Definition: Asymmetry is key 2 Optionality an option is a contract which gives the buyer the right, but not the obligation, to buy or sell an underlying asset or instrument at a specified strike price on a specified date, depending on the form of the option. a financial options is expensive non-financial options are usually free or cheap, but... we don't recognise them.

12 Antifragile tinkering The Unicorn Club Don t lecture birds how to fly Change in value Time Tinkering in IT Fragile tinkering Change in value Time The third way, continual experimentation and learning

13 Via Negativa Fragile Definition the best way for a person or organization to become antifragile is to first decrease their downside: things, people, actions, habits, or systems that make you vulnerable to volatility and risk. negative knowledge (what is wrong, what does not work) is more robust to error than positive knowledge (what is right, what works). Change in value Time Via Negativa in IT Technical debt? Get rid of: hand-offs between teams (Spotify) politics, fear and ego (Spotify) technical debt = what you feel the next time you want to make a change (Gene Kim) inequalities between MTTR and MTBF Source: Brian Teunissen, Inspearit

14 4 backlogs make 1 4 backlogs make 1 Product backlog Defect backlog Tasks Technical Improvement Debt debt nt Backlog backlog backlog Bite the bullet Technical debt has many forms

15 Inequalities between MTTR and MTBF What is more important? MTTR or MTBF? Failure is not acceptable. But it will happen! MTTR is more important than MTBF (John Allspaw) Time spent on facilitating an efficient and effective response to failure >= time spent at preventing that failure. Focus on MTBF: only for space hardware and embedded medical devices Focus on MTTR: everything else 57 Asymmetry is key Transferring fragility Definition: if one party has the downside and another party has the upside, there is an agency problem / principal-agent problem: fragility is being transferred from one party to another The reverse: skin in the game -> a person has something to lose in a given situation 3 Skin in the game missing (silo's) SILO'S ARE FRAGILIZERS

16 Skin in the game missing (projects) PRINCE 2 defines a project as A temporary organisation that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources. The project model leads to chasing date over benefit chasing time over benefit chasing cost over benefit chasing features over benefit Source: Allan Kelly Skin in the game missing (projects) PROJECTS ARE FRAGILIZERS The most destructive idea known to software development: temporary organisations Disbanding teams destroys - Knowledge - Capability - Performance Source: Allan Kelly Project based organisation Product based organisation

17 DevOps teams in stead of projects Direct relationship between customer and DevOps team Tech is not the problem, people are just execute the product backlog In stead of staffing projects Bring the work to the scrum team No resource shuffling Reliable velocity Clear Cost of Ownership per business line 66 Provisioning in the last decade Continuous Delivery As Code 3 weeks 3 minutes 3 seconds 68

18 Fully automated to production 9 square model Business Information Technology Strategic Tactic Operational 69 9 square model 9 square model revisited Business Information Technology Business Information Technology Strategic Strategic Pull Don't lecture birds how to fly Tactic Operational Tactic Operational rigorous automation of operational processes Push DevOps

19 Conway's Law Definition: organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organization High heel organization High heel organization Business Information Technology Business Information Technology Strategic Pull Don't lecture birds how to fly Strategic Don't lecture birds how to fly Tactic Operational rigorous automation of operational processes Push DevOps Tactic Operational rigorous automation of operational processes DevOps

20 The Cuckoo Effect Any foreign innovation in a corporation will stimulate the corporate immune system to create antibodies that destroy it. Peter Drucker Behavior over process BiSL Next and DevOps Formula 1 in IT -> DevOps In the business information management domain BiSL exists uniquely to help you with governing and controlling the information services from a business perspective. Source: Car and Driver, K.C. Colwell / Bryan Christie Design 80

21 Anatomy of an F1 Pit Stop: 0:03 Is the Magic Number Car and Driver, K.C. Colwell / Bryan Christie Design DASA 83 84

22 Focus of BiSL the Governance and Strategic oversight that the enterprise needs to ensure that existing IT dependent business services are improved rapidly and effectively and that new services are brought to market more efficiently. the Operational information processes that most enterprises need to streamline 85 Target audience BIM business IT service suppliers Key issues for effective BIM Portfolio and programme management in line with your enterprise strategy Designing information services that meet business needs Organizing your digital information needs Selecting appropriate technology If you can t do it yourself finding people you can trust

23 BIM DevOps

24 93