View All Videos

Improving Flow: Fix the Handoffs to Remove Your Worst Bottlenecks

1

Alex Honor / 

Minimizing time to market and getting faster feedback from customers are primary concern for businesses who want to stay competitive. You need to be able to go from a business idea to a customer-facing running service as quickly, reliably, and effortlessly as possible. This as a flow of work that crosses many organizational silos.

Where does this flow often bog down? Handoffs. Whether the handoffs are within a team (e.g. Dev to Dev) or between teams (e.g. Dev to Ops), there is always the need to pass work from one stage of the lifecycle to the next.

http://www.flickr.com/photos/seven13avenue/2791099838/in/photostream/

At DTO Solutions, our clients are often already aware that they have flow problems when they ask us to for help. When we use techniques like Value-Stream Mapping to learn how the work flows, handoff problems are prominent forms of waste that jump off of the page. The diagram below uses pie charts to highlight the relative time lost due to difficult handoffs during the product life cycle.

What are common reasons for difficult handoffs?

  • Conversations, email, multitudinous wikis, spreadsheets, and trouble ticket systems are used to describe, in human language, how to process work. Words are open to interpretation and documents often lag behind current operating procedure. Just imagine being the person planning or performing the work and traversing the information across these various tools.
  • Software product artifacts differ between stages of the process. Sometimes software resides in a directory on a file share and other times it’s a TAR file. The software handoff may contain the same bits, but must be handled or converted by the downstream stage of the software delivery process.
  • Work can be considered “done” yet be unfinished or in a non-working state.The lack of a test or means to verify the work was done correctly often leads to products not ready for the next person down the line. This can leave the person in the downstream stage with what is essentially scrap that has to be rejected or redone.
  • Ad hoc procedures or loose scripting often lead to different approaches and implementations for what should be standard operating procedure. This can lead to silo-specific utilities with different levels of quality and testing.

Handoff problems affect organizations, both big and small. Obviously, one answer to solving handoff problems is to minimize them. But if you are in an organization larger than just a handful of people, that just isn’t a realistic option. To decrease time to market and enable fast feedback, you are going to have to roll up your sleeves to solve the handoff problems.

Where are good places to start making handoffs smoother?

Here are a few of the top fixes that we find important for solving handoff problems at their source:

  • Consistent packaging
    • The most direct way to simplify software handoffs between Dev and Ops is using a common system package format like RPM or Debian. Using a system package format also aligns application deployment and system provisioning practices.
  • Encapsulated procedures
    • Rather than loose scripts or team-specific ones, choose a framework that enables modular automation. Using a modular approach results in a shared tool box of utilities and captured process.
  • Converting information flows into artifact flows
    • Rather than rely on human read text as the product for the downstream process to handle, formalize it as an automation product and build on the idea of encapsulated procedures.
  • Procedure verification tests
    • Verification testing should not be dominated by manual checks described in text documents. Building on the idea of converting information into artifacts, implement verification using a test automation framework. Most apps have some level of testing to verify functionality. Build a testing framework to verify an operation (eg, software deployment) procedure was successful by executing an automated test.

In subsequent posts, we’ll address each one of these fixes.

 

Defining and Improving DevOps Culture (Videos)

1

Damon Edwards / 

Culture. It’s the most mentioned and the most ignored part of the DevOps conversation.

Lots of lip service has been paid to the importance of culture (“It all starts with culture”, “DevOps is a cultural and professional movement”, “Culture over tools”, etc..). But just as fast as everyone agrees that culture is supreme, the conversation turns straight to tools, tools, and more tools.

Recently, John Willis, my fellow dev2ops.org contributor and DevOps Cookbook co-author, let this tweet fly:

John has been as big of a culture warrior as anyone — constantly fighting to elevate the importance of and the discussion around DevOps Culture. He later said that this tweet was part exasperation and part challenge.

It was obvious to John that the difference between high performing and low performing companies was their DevOps culture, not the tools. But rather than be satisfied by the default explanation of DevOps Culture maturity being either that a company “gets it” or “doesn’t get it”, John was challenging the community to dive deeper into the issue.

During the week of Velocity London and DevOps Days Rome, there were finally some presentations that answered that call and were all about the culture. I did a presentation on defining DevOps Culture and what high performing companies do to reinforce it (based on the work of DTO Solutions). Michael Rembetsy and Patrick McDonnell gave a great peek behind the scenes of Etsy’s transformation to a company with a fast moving and high performing culture. Mark Burgess (CFengine) gave an interesting talk on the importance of, and science behind, relationships.


(slides were updated after the presentation)

 

 

(when you watch Mark’s video you will understand why there are no slides posted here!)

Update: John Willis knocks it out of the park talking about the importance of culture and the classic influence of Deming on this recent episode of the Food Fight Show.

DevOps Transformation Workshop for Technical Managers

Damon Edwards / 

DevOps problems, by their very nature, are organizational issues. DevOps problems live in the “white spaces” between people and groups. Like all organizational issues, it’s ultimately the responsibility of management to solve DevOps problems.

It’s no easy task to manage a DevOps transformation initiative. Not only are you addressing people, process, and tooling issues that span multiple silos, you are also balancing current business commitments, resource constraints, and good old fashioned human dynamics.

 

Where do you start? What are the traps you’ll need to avoid? What are the best practices to adopt? How do you work across roadblocks like functional silos and entrenched culture? And ultimately, how do you avoid this becoming another failed transformation project that could put you or your business at risk?

DTO Solutions repeatedly addresses these issues across it’s diverse client base. Either as coaches, architects, or change agents, stepping up to the responsibility for making DevOps transformations successful is at the heart of DTO’s business.

I don’t normally use this form to directly promote the services of DTO Solutions. But I believe that this is a special case as it is a unique offering that I’ve seen make a positive impact for our clients.

DTO Solution’s has taken it’s best practices and methodology for managing DevOps transformations and turned it into a 2-day workshop for managers. What was previously only available to client’s within broader engagements is now available as a stand alone public class.

You can read about the details and register here:
http://www.devopstransformation.com

Use DevOps to Turn IT into a Strategic Weapon

8

Damon Edwards / 

As I’ve worked on the DevOps Cookbook with my co-authors, I’ve become increasingly conscious of the emphasis of focus of the DevOps community. Lots of attention has been paid to the effects of DevOps within the walls of an IT organization. Far less attention has been paid to the effects of DevOps across the broader company. Almost no attention has been paid the effects of DevOps outside the walls of the company, specifically in relation to other companies and the markets in which you are competing.
Read more →

Andie Nordgren recaps the CCP Games internal DevOps conference

Damon Edwards / 

The following is a guest post by Andie Nordgren, Technical Producer at CCP Games in Reykjavik, Iceland. Andie recently wrote this post as a recap of their internal DevOps conference (for which she was the primary organizer). I thought it was a great overview of what an internal DevOps conference is all about and asked her to share it with our community.
-Damon

Read more →

Integrating DevOps tools into a Service Delivery Platform (VIDEO)

2

Damon Edwards / 

The ecosystem of open source DevOps-friendly tools has experienced explosive growth in the past few years. There are so many great tools out there that finding the right one for a particular use case has become quite easy.

As the old problem of a lack of tooling fades into the distance, the new problem of tool integration is becoming more apprent. Deployment tools, configuration management tools, build tools, repository tools, monitoring tools — By design, most of the popular modern tools in our space are point solutions.

Read more →

Page 3 of 2612345Last