Today at DevOps Days Austin, Dell corporate strategist Michael Cote gave a presentation on what DevOps teams can learn from product development. You can find his slides here, but I’m going to try to summarize and synthesize his presentation as best I can.

Cote is basing the presentation on work done by the Crowbar team at Dell. Crowbar is an open source deployment tool that can provision OpenStack from bare metal up to higher level Chef configuration. It can be expanded using plugins called “barclamps,” which add support for tools like Cloud Foundry and Zenoss. Dell can then leverage this platform for building solutions on top of it, such as its Apache Hadoop solution.

Crowbar is an interesting case of a useful open source tool being built by a large company – one not necessarily known for software – and Cote applies the lessons to getting DevOps going at a large company.

Find Good Non-technical Metaphors for What You’re Doing

Not everyone is going to understand DevOps right away, so it’s important to find ways to help explain the idea to people. The Crowbar team uses the metaphor of soup and sandwiches to explain their project. You could just use images for provisioning servers, but what if you don’t want every image to be the same? Images are like soup – you can make big batches of it, but the ingredients in each bowl are the same. You can’t customize a bowl of soup. Sandwiches, on the other hand, can be made to order. It takes more time, but you can get exactly what you want. Crowbar is like a sandwich.

Cote also suggests speaking through your customers (or users), which brings us to:

Get Customers/Users Right Away

Once you have some customers, you can use their stories and use cases to explain and evangelize your product. In the case of DevOps, this may actually be less about “getting users” and more about racking up some success. The important thing will be developing some metrics for success and taking them to decision makers to prove that this DevOps thing is working out. You can find out more about this in my previous piece 7 Lessons Learned in the DevOps Trenches, which covers J. Wolfgang Goerlich’s advice for DevOps projects, including which metrics to track.

Decide What Trade-Offs You Have to Take

Here’s Cote’s take on the Iron triangle:

It’s a classic predicament: there are three things you can be, and you can only pick two (“cheap, fast, and good” are another typical iron triangle). Cote says it’s better to be “awesome than on time” when you’re working on something as new as DevOps. I don’t fully agree. If you’re building a DevOps product like Crowbar, then yet it’s better to ship late but have a high quality product with all the bells and whistles so that no one can dismiss it as being half-baked.

But if you’re making the case for agile/DevOps in the enterprise, then I think the real trade off is features. You want to iterate quickly and work out the bugs. Perhaps the trade-off is somewhere else: for example, you trade the manageability of a traditional waterfall deployment with an agile process with fuzzier delivery times.

Always be Coding (or Deploying), but Sometimes be Educating/Evangelizing

Once you have some success, you’re going to be asked to do a lot of educating/evangelizing. People will want to know what this whole DevOps thing is, and how they can do it too. That can lead you astray. It’s important to focus on what makes you successful: writing and deploying code, maintaining systems, etc. As Cote says, sometimes it’s easier when no one knows they should care. Taking time to “hide” within the organization, with the understanding that you’re working on something awesome, can be a huge benefit.

That said, you’ve got to do some amount of evangelizing or you risk being shut down. In the product world, PR people need to hear the stories from the technical people, and often people want to route around the PR people and go straight to the horse’s mouth. You need to make sure the story being told is the right one.

Find the right Context for Evangelism

On the subject of evangelism: don’t over promise, and always watch for the right time. Sometimes it’s best to just skip the metaphors and talk directly about how you can solve a problem. Cote gives the example of a customer who started talking about the need for a system that configured the BIOS on bare metal servers. The Crowbar team didn’t stop to explain the soup vs. sandwich metaphor – they had the perfect opening to explain what they were doing and how they could solve the customer’s problem.

I’ve written previously that to start doing DevOps in an enterprise, you need to find small projects where you can carve out some success, usually with a small cross-functional team. Find the best contexts within the enterprise to apply DevOps methodologies: for example an important project that’s been delayed too many times.

Don’t Share Junk

I love this image from Cote:

Why didn’t this stuff from a free box just go directly into the trash? Cote uses it to illustrate a point about open source: you don’t want to put broken, useless or abandoned code out on to GitHub, it just makes you look bad, and it promotes the idea that open source is where failed products go to die.

I’d apply this to DevOps in the realm of documentation. Don’t put half-finished articles in a Knowledge Base. Don’t put up an internal wiki if it’s not useful and well-maintained. If you’re going to share something with the rest of your organization, make sure it isn’t junk.

Your Angle

What else, if anything, can DevOps learn from product development? Are Cote and I dead wrong about any of the above? Leave a comment to let us know what you think.