Leading DevOps

I hear many people asking which is better Chef or Puppet.  Which is for developers and which is for Admins?  Then, you throw in Ansible and Salt and you get even more drama and stress.  Some companies have pockets of Chef and then, another of Puppet.  Then, someone brings in another tool and everyone is debating and struggling.   Here is my opinion and many of you are not going to like it because it will cause one vendor or team to be critical of my recommendation. I recommend going with which ever your Ops teams like or uses.  This is the team that needs the most help in this area.  Tools like Puppet and Chef provide the most value when everyone is on the same page and want to use them.  If your Dev teams are shoving Chef down the Ops guys throats, they will never buy in.  If the Ops guys start using any tool, Devs should be able to pick them up easily.   If you have multiple ops teams, and they are using multiple tools, that m...

Say this 100 times every day.

I have been racking my brain on how to scale DevOps across a company or enterprise.  If you have any thoughts please let me know. Some options Force everyone to read Phoenix Project Target DoJo model Internal DevOps days Embed DevOps coaches in every team Create documentation and point everyone to it Have your CTO make them do learn it Do team by team DevOps maturity assessments Use security or compliance requirements to force teams to automate delivery Make one team really awesome and let others come asking for the awesomeness.

After God and family, I am very thankful for DevOps.  It is opening the eyes of many companies across the world.   People are seeing really how awful IT has been the last ten or so years.   We need to keep leading the way to a better life for IT professionals.

DevOps is about continuous improvement.  Sometimes changes are easy and everyone loves them.  You implement them quickly and everyone is happy.  Sometimes people hate the change and it dies.  Most of the time it is a combination of fans, skeptics and who cares. How should you present changes you are passionate about?  Here are some steps to successfully proposing changes. 1. Start with the goals your are trying to achieve.  Unless your goals are way off base, people usually can't argue with goals that make the future better. 2. Present solutions to the goals as a "recommendation".  Who knows, someone may have a better idea or improvement in your change. 3. Draw a picture, workflow, diagram or something that you can show people. 4. Watch your audience to see who is getting your message and who are not. 5.  Ask who understands the resolution.  Don't ask if anyone has questions or who doesn't get it.  Ask a question that makes people...

#DOES 2015 was great.  The speakers did a excellent job of talking about more than DevOps but how they are growing their DevOps through their company.  Capital One was awesome.  They showed a video of their internal engineering conference.  Disney brought a great message of embedding DevOps across their organization with a Star Wars theme.  They were actually a late add to the schedule and rocked it.  The PowerShell guy brought a great message of never giving up and timing for culture changing ideas at Microsoft.  Netflix had another great culture talk.  I really think they may be the best DevOps culture in IT. It is just inspiring to see how large enterprises are spreading DevOps across their IT.  They all have similar stories. 1.  They started with a small team or group. 2. They got senior leadership buy in. 3. They focused on the people.  They had summits, internal DevOps days, Dojos, training and what ever it takes to sprea...

I really want people to stop talking about DevOps but I really want people to keep asking questions about DevOps.   This does not make sense right? The problem is DevOps is getting a bad name in lots of places because people don't understand it.  DevOps is not CI, CD, Infra as Code, Cloud, Agile, Lean.....  DevOps is a culture of continuous improvement and scalable IT. We really should talk about DevOps from a leadership level and talk about automation separately.  Leaders need to remove obstacles, manual tasks, and improve processes all while demonstrating people and teams working together.  These things will naturally allow people to innovate and grow towards automation. You can do automation anywhere and you should do automation.  A company could be a large enterprise with silos of people that don't trust each other with competing goals but even those can do automation like CI and Chef.  They likely are doing it at a silo level and everyone do...

Traditional IT is failing in the enterprise because people are asked to do too much and they can't scale.  Why does a DevOps culture want small full stack teams that are highly collaborative, because it can scale and succeeds.  If you need to do more, you optimize with automation, become more efficient, you adjust scope or you add more resources where it makes sense for the business need. Silos do not scale.  On the surface you think it does and many IT leaders believe it does but scaling does not happen when you have competing goals and deliverable.  You just react to everything and mostly fail in one way or many.  The team misses deadlines, create issues, or have unhappy employees who are just waiting to move to a DevOps culture. DevOps cultures should be polarized.  You either enable people to do the job or you are part of the team.  You will fail if you are in the middle.  If you work in a silo that tries to be technical, business and proj...

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 c...

I started at a new company and the people that I interviewed with had read the Phoenix Project.  That was exciting and I could relate to their goals.  After a few weeks of working there it was clear, they were the only ones that had read it.  You should already see the red flags going off about what I got myself into. I have made presentations to everyone from senior leaders to individual contributors.  The last slide in every presentation is a picture of the Phoenix Project and Web Operations.  I will talk about Web Operations in the future.  Every time I get to this slide, I see people just hang their heads. (Maybe it is just because I present badly)  Some of the people have heard how good it is but just have not made it a priority to read. I told my team it is mandatory to read it and I think any IT company should make it mandatory.  I bought 4 copies this week on Amazon to bring to work and start farming them out.  If you want to star...

How do you get DevOps going in an Enterprise?  The same way you eat an elephant but you have to keep reminding your self of two things: 1.  I am hungry. 2.  I may never finish eating. You are hungry or you would not be eating.  DevOps passion is something you have to be starving to embark on.  If you don't really want to own the message, the transformation or believe in it, just stop and do little things as you can.   If you want to own it and you know you know the org will not change, even a little, then leave.  The market is too good for people that want to do DevOps to sit and starve with an Org that is dying. The DevOps journey is never ending and you have to keep reminding yourself of that.  You will have plenty of people that get in your way. Tools will sometimes crush your spirit.  Process will sometimes seem crazy.  You just have to remember, you may never finish evangelizing DevOps.   I can't stress enough, if you ...

I recently left my company and it definitely made me think about when is it time to move on.  Here are some of my thoughts: Make sure your personal life is ready for it.  Don't just see dollar signs or a new shiny object.  Look at how it will impact you, your family, friends, your social circles and your everyday life.  You would be surprised how much you depend on your coworkers as friends and way of getting through the grind when it is going tough. I recommend leaving if you are going through several months of being unsatisfied.  If you are not growing as much as you are giving to the company, it might be time to move on.  You should be a leader and that means innovating and growing people and processes.  If you are at a point where the company can't grow like your passion pushes you, then there is nothing you can do.  This is especially important around DevOps.   Don't leave just for money.  Unless someone is going to double you...

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...