Skip to main content

Lean Culture Change

We all know culture is a huge part of DevOps.  What we don't know is how to change it.  The easy answer is change culture just like you would "eat an elephant",  one bite at a time.  What this does not tell you is where it start.  Do you start with the thigh, leg, tail or even the head?  This is where you should look at culture change just like any other lean process improvement.  Here are some examples:


  • Focus on the value to the customer
    • This will help you sale why DevOps is important to the company.  There are plenty of information and statistics of how DevOps is changing the industry.  Do your research and be prepared when a decision is made that is anti-DevOps.  Try to right the ship and stir it a little closer to DevOps.  Keep iterating through these opportunities over time.
  • Respect and Engage People
    • Culture change and job change is scary.  You will meet people who hate you.  You have to be a leader that can empathize and learn to respectfully debate new changes.  Why should a traditional engineering team want to give up responsibility to developers or a DevOps team?  They don't trust you.  They may not even like you.  Find ways to sale the customer and employee value over time.  Pick small steps like managing the dev environment, writing Chef scripts or moving all their scripts into source control.  You have to see their side of the change and show them how it helps them. 
  • Improving the value stream
    • Don't try to change everything.  Start with what the company culture will let you change.  Then, wait until you need to pull the Andon cord for other changes.  If no one can see anything wrong, they will not be motivated to change it.  A recent example is letting support teams make bug fixes.  I know, I know capital versus expense, blah, blah...  I had a short debate with the a leader who was planning to outsource bug fixes for his support team.  He was dead set on it and I could see that early.  No matter what, this will go bad.  Either support will overwrite some code, not do it right, break something else, poorly test it or not follow good development practices.  A key tenet of DevOps is have the most knowledgeable people do the work.  Enterprises seems to miss this badly.  When things go wrong, bring to light how it can be done easier or better by letting those skilled and trained in the craft do features as well as bug fixes.  Remember the first two items, but keep building your case over time and opening everyone's eyes to how the change benefits the customer. 
These are just a few examples of thinking about culture changes just like lean process improvement can help you in your journey.  Start with the easy stuff that provides value and then, focus only on things that provide value when they happen.  It will take years to change a traditional IT enterprise to DevOps.  Don't try to change what is perceived to be working until you have metrics or visible waste to remove. A huge side benefit of this is your job satisfaction.  If you take a pragmatic approach, you will not feel so depressed or beat down by not making change fast enough.

Comments

Post a Comment

Popular posts from this blog

2020 State of DevSecOps by Accurics

 This is an excellent report for all IT Pros and Engineers.   Highlights: Storage is most impacted solution Open security groups or network configuration Secrets are not so secret Unused resources are not secure. Take a look at these.  Look again.  These are not highly skilled problems.  They just need guidelines and proactive management.  The article uses policy as code as a solution for many of the problems.  I will drill into each of these more in the future.  I wanted to get the awareness out first and then, come back to solutions.  
Post a Comment
Read more

Manage IT by Johanna Rothman

I just completed this book. I think it is a really good book which covers a whole lot of software development. This book could possibly be the best book for first time project managers. I believe many of the PMs understand PMM but do not understand software development. This book gives a view of each project role. The only one that it does not cover is Business Analyst or requirements documentation. It does cover QC, development and of course PMs. It gives a PM a view into development processes like TDD, CI and estimation. Many PMs that are new to SD can read this book and get a great start to manager an SD project. If you are a PM or know some, read this book. http://www.jrothman.com/
3 comments
Read more

Matrix Organizations are bad for Software Dev

Development teams need to be teams first and company people second. What happens when your team wants to start using user stories and index cards, but your analyst team manager thinks Use Cases are the best way to document requirements? How about when your QA process is not mature and you keep releasing with defects but the QA manager does not do anything about it? How about your project manager never buys into the team and only cares about being on time and on budget because their review is based on it. Maybe the tech lead wants requirements that never change and never lets the client change their mind. The technical manager taught your tech lead and agrees with everything the tech lead says. Agile or what I like to call "Successful Teams" are teams. They do what it takes to do what the customer wants, deliver features. I am not saying only agile teams are successful but successful teams are agile. If your organization is matrix, get your leadership buy in to override...
3 comments
Read more