View All Videos
How_to_initiate_a_DevOps_Transformation__Video__-_dev2ops

How to initiate a DevOps Transformation (Video)

5

Damon Edwards / 

Here is the full 30-minute video from the keynote I did at DevOps Days Mountain View 2013.

This talk address the single most common question I get asked:

“DevOps sounds great… but how do I go about introducing DevOps to my company?”

Which is usually followed by one or more of the following frustrated statements:

“My managers don’t get it”
“The Dev group won’t talk to me”
“The Ops group won’t talk to me”
“QA says I’m dangerous”
“I don’t know where to start”
“People say they are too busy getting real work done”
“Help! My boss told me to buy DevOps by next quarter or else”
“Everyone just argues about tools”

In this talk I give a condensed walk through of a 3 step process that we’ve found to work (who doesn’t love a 3 step process, right?):

1. Build the “why?” (the business case)
2. Build organizational alignment (the trickiest part… but there is another 5 step “workshop” process just for this!)
3. Continuous improvement loops (think: PDCA or Deming/Shewhart Cycles)

The process incorporates everything you would expect from a DevOps transformation (Lean and Systems Thinking, Value Stream Mapping, Waste Analysis, The 3 Ways, Silo busting, etc.) but it does so in a practical and approachable manner. You can even avoid using the word “DevOps” if it’s too politically charged in your organization.

This forms the core of what we do at DTO Solutions does with our DevOps Workshops (or “Service Delivery Workshops” for a non DevOps name). Through that work we’ve been fortunate enough to see this process in action at many different sizes and types of companies. But that being said, I’m always interested in more feedback and new ideas!

 



 

 

VelocityCDOTScreenGrab

How Adobe turned operations into a sevice and built a service delivery platform in the cloud

4

Damon Edwards / 

This video is from Velocity Santa Clara in June 2013. Adobe’s Srinivas Peri and SimplifyOps’ Alex Honor discuss how a packaged software tools group turned itself into an internal provider of operations services. Featured in the presentation is CDOT, the platform they built out of open source tools like Rundeck, Chef, Jenkins, and Zabbix (and non-open source technologies like AWS, Splunk, and PagerDuty) . But Beyond the tools, this is an interesting story of learning how to shift a groups mindset and figuring out what your “customers” want along the way. You can view the slides from this presentation here.

 



 

John_Willis_presenting_on_DevOps_Culture_at_SV_DevOps_Meetup__4_18_13__-_YouTube-3

John Willis Notes Notable DevOps Culture Traits

4

Damon Edwards / 

This is a great presentation by John Willis at the SVDevOps Meetup back in April. John discusses the various interesting trends and traits he is seeing in the industry. From Deming to CAMS to GitHub to Etsy… John, as he always does, paints an interesting picture of the roots of DevOps and successful DevOps cultures.

(Video: 59:02)
RD-CLUE

Will Sterling presentation on Rundeck at the April CLUE Meeting (Video)

13

Damon Edwards / 

Rundeck community member Will Sterling (from Datalogix) did a great presentation introducing Rundeck to the Colorado Linux Users and Enthusiasts meeting in Denver.

Alex Honor posted a helpful writeup on rundeck.org:

If you are new to Rundeck, watch Will Sterling give an introduction to what Rundeck can do and how he uses it to automate work at DataLogix.

Here are some notable quotes:

  • “Multi-tentant command orchestration and process automation with WebGUI, CLI, and RESTful API.”
  • “Target nodes with rich metadata. Never use hostnames again.”
  • “Process automation via multi-step jobs…Options allow users to pick one or more values.”
  • “Rundeck makes everything in the GUI available through the API.”

Besides showing off the basics, Will opened up Eclipse to step through ruby code that talks to Puppet to communicate node information to Rundeck. His code only includes nodes he can ping and have a certain class.

Will also showed off how he uses resty as nice shell based way to access the Rundeck API.

 

mudball

The key to simplicity isn’t “Know How” it’s “Know Why”

17

Alex Honor / 

Many of us technicians like to understand complex things and learn about the roots of hard problems.
We are also very well versed in technology, how it works – how to make machines and advanced sophisticated designs. But at our jobs we work in the context of the business. It’s the business outcome that is the important context to always keep foremost in our minds. Well, at least it should.

“We have to grasp not only the Know-How but also ‘Know Why…’”, – Shigeo Shingo (Toyota)

From time to time, the business comes to us asking for help to reach a desired outcome. The outcome might be to launch a new product, add new features to the web site, anticipate a bunch of new customers, open a new market, or shorten lead time for customer requests.

So, we technicians put on our thinking caps and get excited because we are going to get to make something.
“What’s the best solution?”, we ask ourselves. “It better cover all contingincies for changing scale or future concerns”, say the far thinkers. “It’s a big project with lots of moving parts”, exclaims the project manager.

What often happens? We technicians get mired in how we solve the problem, using all the tricks up our sleeves, relishing in our know how. We know how that goes. We say: “Meta-object protocols will make our solution infinitely extendable, even dynamically! This inheritance hiearchy design coupled with good component composition will ensure the software architectured is correctly multi layered.” Blank stare and reply from the business manager: “What?” We say: “Oh it’s superior technology”

Admit it. We’ve all been there saying or listening to this kind of stuff.

What stands between us and our goal is the complexity of the solution.

“The most dangerous kind of waste is the waste we do not recognize.” – Shigeo Shingo (Toyota)

Complexity is a killer. We already live in a dynamic, fast paced world and the business is always changing. Our work world is complex so why make our solutions complex? Complex solutions are fragile, hard to roll out and adopt, time consuming to fix and extend. Complex designs just make life harder. Does the business outcome depend on any of this complexity in the solution? If not, we are gold plating and are just creating a form of waste.

So, how do we avoid building the complexity? Here’s some good rules to live by:

1. Stay focused on the “Know Why”.

Be clear you understand the desired outcome the business expects. Are you sure about it? Do others agree with your interpretation. If not, you’ll be alone defending your choices or you might suffer living with your own decisions.

2. Don’t fall prey to your “Know How”.

Watch out for the inclination to create advanced/sophisticated/over-engineered designs and implementions. This just adds time, risk, and money to get the work done.

3. Be disciplined.

Building a new solution and migrating from the “old way” of doing things to the new way is by definition a transformation. The new way will require its own new “Know How” and will not be perfect/complete/usable the first time (or the 2nd, 3rd… time). If  moving to the new solution is painful, you have to stay disciplined and keep iterating to make the solution less painful.  Stay focussed on the outcome the business cares about and expects from you as your guiding principle.

4. Do the simplest thing.

Choosing products and tools that are inherently simple to use, require little Know How from everyone. Tool shininess gets the heart rate up because new is fun but this isn’t what the business cares about.

 

You know the old saying, the shortest path between two points is a straight line.

Page 1 of 2612345Last