Leading DevOps

If you are in the Enterprise, you likely know about ITIL.  If you talk to your leadership or operations about DevOps concepts, they will eventually say that ITIL or Service Management will not let us do DevOps.   How do you over come this thinking?  You don't.  ???? I recently heard the best justification for ITIL.  John Willis made a statement on a podcast that ITIL was put in place to control operations that are human or manual based and by definition out of control.  (paraphrased)  This was a great statement that really hit home with some of the operations team I have seen.  When people are doing all the work, you need to put in practices that moderate all impacting activities. Now, if you understand DevOps and how most ITIL shops work, you should see the path to start working toward DevOps practices in an ITIL Enterprise.   If you don't see it yet, then close this blog now and come back in a few hours after you think through it. ...

We have been working on a solution to gain better control of our operations work and projects.  With Windows 2003 expiring in July, we have been out of control or not focused.  We have adopted KanBan.  Why, because it just felt right.  No real reason or specific goal but just thought a system that appeared to keep people focused and had an easy way to track the work. I found the pod cast below really helped to solidify my thoughts on KanBan and why it is a great tool for operations work.  Instead of my repeating why it is needed, just listen to the Pod Cast and by the way, their other Pod Cast are really good too. http://www.cloudtp.com/2015/01/13/kanban-scrub-devops/ Another great tool we are using is KanBanTool.com.  Do you have to use it, no?  You can use sticky notes and index cards.  Some of the people on my team are managing their time with sticky notes with a BackLog, WIP and done KanBan approach. KanBan for development might be ano...

I was talking to some people from old dev teams.  We did unit testing and CI way back in 2005.  We did deployment packages and did iterative development.  We did DevOps right? Comparing what we did back then to some of the solutions these same guys deliver today, Hell Yea we did DevOps.  So how do you do fundamental DevOps back then and not do it today?  It is because things like ITIL, SILOs and separations of concerns made you lose your mind.  All these same guys have gone from architects to managers and they have to worry about audits and best practices. We really lost track of what made our teams great back then.  One bad incident leads to a PMR saying dev can't touch prod.  Then, management started creating silos which made everyone lose sight of the goals that DevOps emphasizes.  Customer Happiness. Let's really get back to the original question, did we do DevOps.  Not really.  We had large deployments.  ...

Many people have their opinions on DevOps?  It is doing Continuous Itegration or Continuous Delivery or using Chef, Team City or even the cloud.  While these all maybe tools for improving DevOps, I don't see this as DevOps. I see DevOps as the realization that software development does not start at writing code or end with code check in, DevOps is continuously improving everything from customer request to customer saying "Thank You" for a new working feature.  

I have been away for a while for a few reasons.  One reason, I forgot I even had this blog. :)  I was shocked to see I actually got some comments on some early post.  Thanks, to those who did comment. Another reason is that I went from software development into operations again.  I could say that I was too busy fighting fires to keep up this blog and practice.  If I am honest and I look back that would not be true.  I could have taken this blog to another level while I was in ops, if I could have seen the bigger picture. As I got more and more frustrated with the operations team lack of improvement and more frustrated with how development treated operations, I realized this process was just broken.  I really had no solutions.   I would tell operations to just take their beating and we can figure it out later.  Ops kept pushing back on Dev.  Dev stayed longer and longer on projects.  Dev struggled with the turn around on ops depl...