A Story of DevOps >>Episode 9. Kryptonite (DevOps Anti-Patterns)

#Gin. This is my weakness. This is my Kryptonite. Gin is the inspiration for this article.

From either knowing me or from reading my articles, you will know that I am a positive, outgoing and passionate individual. I have an inbuilt anti-depression system (according to my Insights analysis). I once had the nickname ‘Tigger’.

Gin. Gin. Gin – the only thing on planet Earth that overrides my anti-depression system. I went to a leaving do yesterday and one of my colleagues was desperately trying to get me to try her fancy Gin. No chance! not one sip. I shall not risk the consequences of Gin infiltrating my system. I don’t do being depressed very well.

Kryptonite

Kryptonite affects Superman’s powers. We have previously discussed how when Superman came to Earth, with our environment and our Sun, he developed super-human powers. Kryptonite is the one substance that interferes with Superman’s powers – even to the point of his death.

Kryptonite is a transuranic element whose inherent radioactivity inhibits the absorption of high-energy solar radiation which Kryptonians use to power their feats of superhuman ability.

DevOps Kryptonite

I recently read somewhere that good leaders have a ‘start doing’ list and a ‘stop doing’ list. This concept is in Good to Great (Collins) but I have read this in other places as well. The ‘Stop Doing’ list normally comprises of the things that don’t add value or probably more importantly ‘interfere’ with the work that adds value. I have heard these refereed to as anti-patterns.

In a similar way, DevOps has anti-patterns – things that destroy the power of DevOps in your organisation. I think 12 of these anti-patterns are neatly summarised in a blog from 2013 by the DevOpsGuys – The Anti-Patterns are

  1. DevOps is a Process >> It’s not, it’s a philosophy, a way of thinking.
  2. Agile equals DevOps >> It’s not, it’s an agile enabler that allows a more continuous flow of work
  3. Rebrand your Ops/Dev/Any Team DevOps >> Rebranding a team or naming engineers with DevOps does not mean you are DevOps.
  4. Start a separate DevOps group >> Created another silo, have we?
  5. The Hostile Takeover >> Dev does not take over Ops. There is an equal share of responsibility between Dev and Ops
  6. DevOps is a BuzzWord >> Actually, some people use this as a swear word… “Can you do this in a DevOps way?” – i.e. can you do this quickly and break the rules whilst you are at it. DevOps is a state of mind and its underpinned by engineering excellence.
  7. Sell DevOps as a Silver Bullet >> Sell DevOps – Some people thinking putting these two words in the same sentence is like putting ‘Cheese’ and ‘Cake’ into the same word. It’s not. DevOps is one of the hardest things you will ever attempt and its something an organisation needs to do for itself with the right mentoring and education.
  8. DevOps means Developers Managing Production >> No, DevOps does not take the responsibility of managing production from people who’s primary responsibility is the stability of the production system.
  9. DevOps is Development-driven release management >> Anything that suggests the DevOps replaces IT Operations is nonsense. Sure, accelerate and automate but DevOps is not a process or automation capability and its not the replacement of IT Operations.
  10. We can’t do DevOps – We’re Unique >> Yep, you are. This is the main reason why DevOps works as its not a one size fits all cook-in-5-mins recipe. Apply the philosophies and principles and you have your own DevOps flavour. One of my favourite phrases is “Use the culture to change the culture
  11. We can’t do DevOps – We’ve got the wrong people >> Radical Candor and Powerful; Building a culture of Freedom and Responsibility say that you don’t have bad people – you have bad processes. Put the right people in the right role and then off you go… (Good to Great)
  12. Collaboration when sh*t hits the fan >> Nope. This should not only happen at 2am on a Monday morning after a weekend of disaster – this happens all the time – everyday, as part of the same team!

DBmaestro re-enforces some of the above with:

  1. Imitating Technology but Not Culture >> You can export open source tech but you cannot export culture or mindset – you will need to build your own.
  2. Building Additional Silos >> A DevOps department is aimless by design, since the ideals and practices cannot work across departments.
  3. Tackling the Lowest Hanging Fruit Only >> DevOps greatness means incorporating all practices, not just cherry picking the lowest hanging fruit.
  4. Maintaining Team Structure >> DevOps requires smaller, more autonomous, cross functional teams. You will need to redesign the org like ING or Spotify.
  5. Not Accepting the New Reality >> Modern companies are becoming IT companies – whether they like it or not. Deal with this. There is also a very different nature between Manual Work and Knowledge Work – create the right environment.
  6. Missing KPIs >> Building DevOps success is about improving two KPIs; Lead Time and Quality.

I love this video by Spotify, there are two parts and in them they talk about what works and what does not.

The Sun

Superman gets his power from the Sun, in the absence of Kryptonite. DevOps needs to get it’s power from the right environment, in the absence of DevOps Anti-Patterns.

In our organisation, we;

  • re-architicted teams around Products who do Dev and Ops, with increased priority on service over new features,
  • defined and lived our target culture with emphasis on an environment that stimulates knowledge worker productivity,
  • applied and re-enforced ‘feedback-enhancing’ practices, re-educated our workforce and engaged our customer on our new ‘ways of working’.

Our challenge now is that, in many cases, we can define, build, test, release and deploy features faster than our business can consume. Bottlenecks in agreeing and funding the pipeline, user acceptance testing and business change are the next areas of focus – bringing our business colleagues closer to the action is the next challenge. This will be followed by focussing on automation for the test and release pipeline.

I hope that this helps identify the things that will kill your DevOps initiatives and gives your the pointers to develop an environment for ‘DevOps greatness’

More in this series #AStoryof DevOps:

  • A Story of DevOps
  • Episode 1 >> Origins (Traversing the Change Curve)
  • Episode 2 >> One Ring (Alignment and Empowerment)
  • Episode 3 >> Freedom (Leadership)
  • Episode 4 >> Assemble (Productive and Teams)
  • Episode 5 >> Shield (Tools of the Trade)
  • Episode 6 >> Kryptonian (Value, Flow, Quality in a Complex World)
  • Episode 7 >> Jedi (Mastery)
  • Episode 8 >> Balrog (Confront the Brutal Facts)
  • Episode 9 >> Kryptonite (Anti-Patterns of DevOps)
  • Episode 10 >> The Suit (Digital Transformation)
  • Episode 11 >> Flux Capacitor (Automation and Orchestration)

#AStoryofDevOps #DevOps #Kryptonite

Raj Fowler

I am a natural, enthusiastic and authentic leader who understands the impact of IT as a differentiator for business performance and how organisational culture directly influences IT and business performance. With a strong appreciation of the changing technology environment, I have spearheaded a transformation of organisational ‘ways of working’ through adoption of the philosophies and principles that underpin DevOps, Agile and Lean. As a result, I have a track record of delivering operational excellence whilst improving IT agility, security and responsiveness enabled through close business relationships, technology-led thinking and inspirational leadership. 3 years ago we delivered about 50 to 100 changes per annum across about 80 business systems, all of which we managed using our standard plan, build and operate practices. Change was difficult and the transition from project to service was painful. I lived the opening chapters of the Phoenix Project on a regular basis. I now manage over 100 business systems and we categorised 7 of these as Products which include ServiceNow, Salesforce, Cognos, SuccessFactors, SharePoint. SAP and Bespoke Applications where we have established Product Teams. These are teams that build and support Product using DevOps philosophies. As a result, we delivered over 2500 changes last year whilst at the same time improving the service by 30%, improving customer satisfaction and employee morale. Using the "you build it, you support it" (Amazon) mentality, change is no longer a big event but a normal everyday occurrence and the usual spikes of incidents are no longer there, in fact with each change we deploy, the incident volumes reduce! Teams are not only delivering new features but are cleaning up their code and removing technical debt with every release. As a result, we have made a significant impact to the efficiency of our internal functions which in turn helps the competitiveness and profitability of the enterprise.

Have Your Say: