2020 2-11 myths of dev ops-final
•Download as PPTX, PDF•
0 likes•14 views
The document discusses myths and misconceptions about DevOps. It lists common myths such as the ideas that DevOps requires IT reorganization, cannot work with outsourcing or existing tools, and that there is a single right way to implement it. The document also discusses how to dispel these myths by acquiring new skills, starting small, and addressing legacy mindsets. It notes the importance of having a shared vision and that changing minds relies more on beliefs and values than logic alone.
Recommended
Recommended
More Related Content
Similar to 2020 2-11 myths of dev ops-final
Similar to 2020 2-11 myths of dev ops-final (20)
Recently uploaded
Recently uploaded (20)
2020 2-11 myths of dev ops-final
- 2. The Myths
- 3. Family Fortunes and Crowd Source!
- 4. Results 1. DevOps means IT has to re-organise 2. DevOps and outsourcing wont work 3. There is a single right way to do DevOps 4. Is just about (open source) tools …wont work with existing tools 5. Lean and DevOps are not related 6. DevOps and Agile are different things 7. Can’t work with ITIL/ITSM.
- 5. DevOps means IT re-org
- 6. DevOps and Outsourcing wont work Syngenta (DOES London 2019)
- 7. Is just about (open source) tools (wont work with existing tools
- 8. There is one right way to do DevOps
- 9. Lean and DevOps are not related
- 10. DevOps and Agile are different things
- 11. Can’t work with ITIL
- 12. How to dispel myths
- 15. Start small
- 18. Legacy Mindset
- 19. Do we share a vision?
- 20. Michelle Smyth
- 21. When change comes…. • Naysayers • Change Junkies • Ostriches
- 22. Burning platform • 27 weeks for Hello World at Barclays • True cost of IT Snowflakes at Santander • Standard Bank – 6 month deploys • 300k Revolut accounts in Ireland
- 23. Changing minds • The best engineers are lazy – can we find a way to do this quicker/less effort • BUT arguments are won and lost on inherited belief’s and values – Logic is a poor relative
- 24. • Origins of Waterfall – DOD – IT reports to CFO • Change requests are the problem – The business is always changing its mind • The project process was a success
Editor's Notes
- Company introduction Fenchurch Private training – hearts and minds – we also offer certifications – diff audience. High and low go here.
- The title is the myths of DevOps but in in a minute … I hope your all paying attention we will list them Whats more interesting is to look at the reasons these myths exist and how they impact organisations that are trying to move towards what good looks like in an agile sense. Then we look at how to dispel myths…and finally if I have time I will offer some useful hacks to get things started… …
- DevOps means IT has to re-organise DevOps and outsourcing wont work There is a single right way to do DevOps Is just about (open source) tools (wont work with existing tools) Lean and DevOps are not related DevOps and Agile are different things Can’t work with ITIL/ITSM. Are sincerely believed Persist and spread Go hand in glove with change aversion Spawn sub myths. Have grains of truth Are vendor influenced Unicorn – cloud
- Show of hands for 1 …
- Delivery and SRE Teams – you have people managing your career and people managing your tasks – if there is an existing org structure there is no need to change how teams are composed Working more closely with the business – can the biz assign people the delivery teams/as needed? Could we organize by LOB or value stream? Does the delivery team understand the value of the software they are building for the customer? UAC Flatter – hierarchies don’t always help – as signals from top to bottom and bottom to top get distorted – voice of customer gets lost. Our experience with clients indicates that there is no right or wrong number of levels but a servant leader and empowered teams is way more important. That means leaders who deliver value should be rewarded rather than leaders who are managing x hundreds of staff. The leader managing x hundreds will see that number as a power base but the org culture should orient towards delivery of value and bonus based on this.
- Syngenta (DOES London 2019) is a good case study to disprove this myth. They have multiple out source dev partners and ops partners and they operate very nicely with their metrical dashboards and integrated services deliveries. Would it be better if they had insourced? – A better question is if the delivery of IT services is in synch with the business demand– so its good enough? Part of the challenge with outsource is contracts for manual release or test or deploy - why would outsource vendor want to change the contract? In fact contracts have end dates – and generally a vendor will want to ensure that their skills are relevant etc. If ops is outsourced you can optimise for the LHS – build pipelines and deploy to cloud pending completion of the outsourced ops – a number of our clients are going this way If dev is outsourced – you can optimise for the RHS
- Bottom up – means stealth mode skunk works – means free tools – god bless Jenkins,Vagrant, Redmine et al BUT when you want to scale you need to – go looking for big boy tooling and that generally means funding etc. and C suite approval in larger organisations. The sense of empowerment teams get from building their own automations is terrific – but it needs also to be tempered by having a reasonably standard set of tools – with room to maneuver as per BBVA or Adobe Kickbox models Tooling strategy on existing tools should be that all tools should be Integra table through API’s AND if existing tools don’t do that they are propping up a silo ..– otherwise don’t and integrate them so that the tool chain upholds the 3 DevOps principles – take a system view… improve the left to right flow removing constraints … feedback loops and continuously improve. All tools should be download try buy – no need for lengthy beauty parades…
- This really comes from the top down command and control school of business and IT management Reality is C&C needs to go in any agile journey and be replaced by agile values … Plus… Everyone’s start point on the journey is different and so is everyone’s end point The principles are the same – processes are similar but their implementation is unique Culture and context play a large part in each unique implementation Leadership style Recruitment vs grow in house strategy Vendor relationships IT’s start point with the business Businesses perception of IT Cd or cd Tools - mix n match or 1 vendor,,,
- Lean says remove waste from processes– and DevOps says remove manual tasks from processes. Quite often these are one and the same thing One of our services is Value Stream Mapping – where you measure the flows of information through processes and look for waste and wait times. Waste can be a manual task or work for which no value can be attributable (ie we always did it like this) meetings about meetings etc tickets creating other tickets Emails sitting in peoples box unattended creates wait time – if you eliminate these wait times – the features go into prod and earn money sooner … Down the road you can pull these value streams into living dashboards from a range of tools vendors including XebiaLabs who are one of our partners Kaizen is another lean tool PDCA which underpins a fail fast mind set
- This thinking originated with people thinking that agile means scrum when in fact agile is a set of values that can underpin dev ops marketing sales finance etc. Open Respectful Focus Committed and Courageous To do DevOps – open up to your colleagues in other specialist areas … Respectful means active listening to these colleagues … focussed means no alligator batting or recognising it for what it is and finding ways to reduce this time … Committed … so your colleagues know you are serious but you need to ensure you have a common why – get my weekends back is a fav of mine … Courageous – but not foolhardy … take risk and fail but have a plan b or a way out
- I think we can get ourselves in knots trying to retrofit older processes and accreditations with newer processes but as with any religious beliefs –don’t get too religious … take the best of what works well for you and see what you can – onboard and use from new religions eg SRE Its back to there is only one way or accreditation etc – there are guiding principles – the rate at which you deliver value that fits with your business/customer cadence and then you continuously improve on that.
- Lunch and learn Book clubs Meetups Team training and exercises Workshops
- Experiential learning – act yourself into new ways of thinking … Evidence based decisioning Value Stream Mapping Don’t Waterfall Plan Get started
- If your team are running at 110% OR Your team is running between fires Attrition will increase Burn out Rework Lack of growth opp’s
- Bring the business with you They don’t like alligators either Build a coalition of the willing Discovery pilot Prove some small automation … release? Automation MUST reduce real man hours Apply newly created capacity to next automation Repeat Communicate x 3 Apply spare capacity to more DevOps innovations Value stream map to identify and prioritise blockers and measure customer value Evolve done
- questions
- Waterfall origins Even when a project does not deliver – IT professionals tend to view the project process as a success which drives business sponsors nuts Cant tell you how often we meet with companies where the business is telling us that they don’t get what they want when they want it of sufficient quality IT says the business keeps changing its mind and they are CR’d to death….change requests are the order of the day with associated meetings etc But lets not throw out the baby with the bathwater here …waterfall still adds value--- customer facing b2c/b2b – agile way to go Back office COTS deploys by SI’s – waterfall but with DevOps automations post the delivery drop
- But what waterfall really did was create the Risk averse No risk better than measured risk ... This is simply untrue and you only have to check the top 50 listed companies on any international stock exchange for the last 20 or 30 years to find major brands being disrupted …but if a business gets to a place where there is simply no risk taking there is probably no innovation and in turn the business will die Change leads to instability CAB Silos’ of SME’s handing off to another and assuming done means their silo has exited the piece of work…. Experience is valuable – agile only is also a concern…my daughter … The good news is that there is tons and tons of logic and you can read all about it in the DevOps Report – 5.5k companies contribute to a very detailed survey and on the front of our new site you can read 2 data points. Google acquired. The bad news is everyone has acquired wisdom from people who managed us in the past and these core beliefs are hard to let go off
- Alfred Idle- original crowd sourcer 1884
- In other good news … the experience people have built up in managing risk is a real advantage when it comes to planning devops and agile journeys For example release processes are generally excellent – they just happen to be manual.. Identifying risk in pilots and scale ups is a skill ‘agile only’ folks don’t have Plenty of other organisations have made the journey from waterfall to agile. Project to product … and there are tons of best practices – publicly available But to overcome these – it’s a case of seeing is believing And there has to be a burning platform or if not a real sense of purpose….