Running Internal Events – The Goat Farm – S1E5

A guy in Belgium inspires a bank in the Netherlands to hold an internal DevOps Days. A weekly newsletter in the UK picks up a presentation from that internal event, and a team in Minneapolis, MN is inspired to hold their own event.

Internal events are becoming more and more popular in Enterprise IT. Cloud Symposiums, Automation Symposiums, DevOps Leadership Summits, and DevOps Days are all internal events I have participated in this year alone. Ross and I talk to Heather Mickman (Target), Brent Nelson (Target), and Mark Heistek (ING Bank) about the events they have run in their organizations, how they got started, what challenges they faced, and any tips for people wanting to run their own events.

If you’d like to see some of the tweets and activities from Target’s last two DevOps events, you can search twitter for the hashtag #dotgt.

We also talk briefly about “The Prince of DevOps“, and reviews we’ve gotten about the podcast (sorry for the heavy breathing last time).

Download MP3 – iTunesStitcherRSS

Guest Info:

Heather Mickman – LinkedInTwitter

Heather Mickman is the leader for the API and Integration team at Target and a DevOps enthusiast.  Throughout her career, Heather has continuously embraced hard technology challenges from consulting large Fortune 50 companies on Supply Chain approach, implementing warehouse automation technologies, running large Ops & Support organizations, and establishing enterprise security approaches.  She has a passion for technology, building high performing teams, driving a culture of innovation, and having fun along the way.  Heather lives in Minneapolis with her 2 sons and 2 dachshunds.


Brent Nelson – LinkedInTwitter2014-ProfilePic

Husband, father and life-long resident of Minnesota. I’ve been with Target for 26+ years and for the last year have been an internal DevOps collaboration and social media evangelist involved in hosting internal DevOpsDays events, creating/delivering internal educational materials, co-curating the #make_awesome_happen Flipboard ezine and much more.


fotoMarkHeistekMark Heistek – LinkedInTwitter

Father of two children, sport fanatic, having fun in life and working at ING Bank Netherlands since 2008. Currently in a continuous delivery team to facilitate in an enterprise continuous delivery pipeline. Furthermore a Continuous Delivery and DevOps evangelist in and outside ING.

Taylorism, Hating Agile, and DevOps at CSG – The Goat Farm – S1E4

It’s time for another episode of The Goat Farm. On this episode Ross and I talk about: Why do Managers Hate Agile?Taylorism, hiring and the problems with specialization, and we chat with Scott Prugh about his experiences with DevOps at CSG.

We also touch on the idea of running internal conferences to help spread the word of new technologies within the company, and Ross shares his excitement over the wildly successful DevOps Days at Target. Stay tuned for an upcoming episode where we will talk more about running your own events.

Download MP3 – iTunesStitcherRSS

Guest Info:

Scott Prugh, Chief Architect – TwitterLinkedIn

Scott is responsible for the overall Platform Architecture and Development in North American Cable. Scott led the architecture teams in developing many of CSG’s next generation assets including Product Configurator and Order Capture.  Scott has been instrumental in leading change at CSG implementing Lean, Agile and DevOps practices.  These changes have resulted in 90% reductions in release impact. Scott is a Lean Practitioner and certified as a Scaled Agile Framework Program Consultant. Previously, Scott was CTO of Telution and built the core runtime and billing architecture for the COMx product suite.

Here is Scott’s talk at the DevOps Enterprise Summit 2014

 

Jonny Wooldridge on Enterprises vs Startups – The Goat Farm – S1E3

In this episode Ross and I talk to Jonny Wooldridge, formerly of Marks & Spencer and currently at The Cambridge Satchel Company. We ask Jonny his thoughts on what DevOps is like in an Enterprise vs a Startup, how to jumpstart adoption, how to handle “legacy systems”, and get his thoughts on concepts such as “Pace Layering” and “Bimodal IT”.

Ross and I also talk about why the language we use is important when talking about DevOps and DevOps concepts.

Download MP3 – iTunesStitcherRSS

Guest Info:

Jonny Wooldridge – LinkedInTwitter

Jonny Wooldridge is CTO of The Cambridge Satchel Company and has a history of leading agile cross-functional teams in dynamic and fast paced start-ups in London including lastminute.com, Opodo.com and Photobox.com. Prior to joining The Cambridge Satchel Company he was Head of Web Engineering at the British multinational retailer M&S. He was instrumental in introducing DevOps to the enterprise whilst working on a 3 year / £150 Million project to re-platform the website, order management systems & customer service tools.

He is passionate about Lean and DevOps topics, particularly in challenging environments (like the average enterprise!) and earlier this year started a blog at enterprisedevops.com.

DevOps at Target – The Goat Farm – S1E2

In this episode of The Goat Farm we talk with Jason Walker and Dan Cundiff of Target Corporation. Jason and Dan have been instrumental in bringing DevOps to Target. Ross and I talk with our guests about the need for DevOps manifestos, the role tooling in DevOps transformations, reward structures in organizations, and hiring for DevOps.

Download MP3 – iTunesStitcherRSS

Guest Info:

Jason Walker – LinkedInTwitter

Dan Cundiff – LinkedInTwitter

We don’t need no manifesto…

“If you don’t eat your meat, you can’t have any pudding. How can you have any pudding if you don’t eat your meat?” –Voltaire

3229643937_13bddcbf8e_oRecently there was a post on O’Reilly Radar that cited an “identity crisis” in the world of DevOps. The post called out a number of issues: namely that there are cliques in DevOps, there is nothing new in DevOps, and there is no product messaging and positioning in the world of DevOps. It ended with the call for DevOps to define itself through a manifesto, similar to the Agile Manifesto or maybe even The Cathedral and the Bazaar.

There has long been a desire to “define DevOps”. Every few months a blog post pops up that says, “Define It,” and goes on to slam the “Knights Templar of DevOps” for holding on so close to the lack of a definition. What many of these “revolutionaries” are not aware of is that the need to define DevOps has already been addressed. The de facto definition exists on Wikipedia, and it was agreed upon by the “Knights” that Wikipedia would hold the definition. This allows the definition to evolve and change over time as the industry evolves and changes. (At this point I should mention that there are no “Knights Templar of DevOps.”)

This also prevents one person or company from being the “definer of DevOps.” It gives ownership of the definition to the community. Compare that with something like ITIL, where the definitions are owned by a company and haven’t evolved much since 2007.

The definition on Wikipedia also gives guide rails for individuals and companies to work inside. If a manifesto is needed, the manifesto is up to the individual organizations that wish to transform themselves. A one-size-fits-all manifesto, as some have asked for, really isn’t effective. Each organization is different, and the guide rails give you the guidance needed to define what works best for your organization.

The DevOps Community has seen tremendous growth over the last several years. 2013 and 2014 were defining years for the community. Looking at the growth of DevOps Days, there is a clear inflection point in 2013 that shows tremendous growth in the conference series.

Screen Shot 2015-01-15 at 7.38.18 PM

Having participated in 9 DevOps Days events myself, I can attest to the fact that the growth of the community is nothing short of phenomenal. At many of these conferences I have attended, over 70% of the attendees were new to the DevOps community. Other DevOps conferences have also popped up, such as Camp DevOps and DevOps Enterprise Summit. Couple this with many conferences now having DevOps specific tracks, and I ask, “What cliquey echo chamber?”

And speaking of the DevOps Enterprise Summit, if DevOps is so poorly defined, ambiguous, and amorphous, how can there be an entire conference focusing solely on success stories of large Enterprises? The last thing enterprises want to implement is something that is untested and unproven. Yet somehow many have begun a DevOps journey and have been successful at it.

DevOps is a cultural and professional movement. It is not a product, solution, or something you can buy off the shelf. As such, it’s rather obvious that there wouldn’t a product messaging or marketing positioning. Product and marketing positioning is obviously important when you are  tryingto sell something. It is irrelevant in the context of a community oriented movement focused on transformation.

One of the most  fascinating changes I have seen over the years in technology is the interest in other areas outside of technology. When you look at transformation, it’s important to look outside of the bubble that you live in for ideas of how to change. Yes, DevOps is often focused on ideas that have been discussed at length in other circles. That is a refreshing change in some circles of tech that think that they are the end-all be-all of significant ideas. “Nobody can teach me how to do this better,” was a common refrain when I entered the IT industry, and it still is today. When I did my MBA, the most amazing experience was learning something outside of technology, and thinking about how I could take this learning and make our industry better. Looking outside, learning, and bringing that knowledge back into the community is a defining feature of DevOps.

While the original post makes some interesting points, it seems to be proposing solutions to problems that don’t exist. In some cases, these supposed problems are defining features of the movement (lack of a firm manifesto; no product definition; old wine, new skin.) which has built a vibrant and effective community that is fundamentally transforming the way companies do IT, in spite of any challenges it faces as a growing movement.

Every synthesis of old ideas and new approaches makes some people uncomfortable and others skeptical. Results are what drive adoption, and the results from a DevOps practice are well-documented at this point. Instead of seeing challenges and hoping for a central authority to solve them, let’s continue on the path of sharing our best ideas with one another and constantly improving.

Thanks to Pete Cheslock, Bridget Kromhout, Stathy Touloumis, and George Miranda for the feedback on this post.

Welcome to the Farm – The Goat Farm – S1E1

Welcome to the first episode of The Goat Farm. In this episode Ross and I chat about our backgrounds, our thoughts about DevOps, why the world needs another podcast, and DevOps in the Enterprise. If you want to find out how the idea for this podcast came about you can read this post or just listen.

Download MP3  – iTunesStitcherRSS

TL;DL: With The Goat Farm Ross and I hope to expand the content around DevOps in the Enterprise, with the specific focus around real world case studies and successes in the Enterprise.

The Goat Farm

goats

There’s been a lot of focus on DevOps in the Enterprise as of late. The DevOps Enterprise Summit showed that DevOps in the Enterprise is a hot topic, and that large enterprises can be successful with DevOps.

One thing that critics say we need more of is prescriptive guidance on implementing DevOps in the Enterprise. This has created this pseudo-movement known as “Enterprise DevOps” to try and fill the perceived gap.  But what the DevOps Enterprise Summit has shown us is that there is sufficient guidance out there to transform enterprises with the ideas of DevOps.

However, a recent podcast highlighted to me that it is often hard for some people to find the information they need to get started with DevOps. That is why the DevOps Enterprise Summit was great. It consolidated Enterprise success stories into one place, and is easier to find.

In continuing this vein, I am happy to announce that I’ll be starting a new podcast on DevOps in the Enterprise. I am also excited to be joined by Ross Clanton on this journey. Ross is an Ops leader at Target, brings years of experience in Enterprise IT, and has been a champion of DevOps transformation. Ross and I will focus on real world DevOps transformations in the Enterprise by interviewing leaders in the space.

We will launch our podcast in mid December, so watch this space for our first few episodes of “The Goat Farm”.

DevOps in the Duck Production Industry

This is a collaborative blog post written by attendees at DevOps Days Belgium 2014. As such, feel free to repost under a Creative Commons Attribution-NoDerivatives 4.0 license. Please retain this header as well.

release-the-quackin-memeIn my 25 years of experience in DevOps, there has never been such a defining movement as DevOps for Ducks. Devops for Ducks is showing up in Gartner’s magic quadrant for the first time this year.  Traditionally, the problem with Ducks are that they are fowl and are not goats. DevOps makes everything better. Even food.

But as we look at the production of quality Duck in the world we begin to understand that it is fundamentally broken. That’s where DevOps comes in. DevOps, has the power to change how we produce ducks in several environments. It allows people to collaborate on the Ducks. Zhang Chi Woo of China, creator of the Duck Production System – or DPS for short — has revolutionized not only Duck production, but the entire way the world thinks about Ducks.

Metrics and Duck Logs

When initially planning the pipeline for Duck production, you must take the “Duckly Metrics Factor” into consideration. As the “DMF” is defined, it will provide insight into the duck and allow you to make sure it is DevOps.

Most importantly, no one should forget that if it walks like a duck, and quacks like a Duck, then it is certainly a Duck, so we should define a metric for how our production Ducks are walking and quacking. Try Graphite. Ducks love it. There is even a collectd plugin available for duck egg incubation systems (well the only problem is all the native dependencies it pulls in).

The recently created DuckCare system closely monitors all the Ducks and can notify based on key log entries. If a Duck needs attention care workers are dispatched right away through DuckDuty.

Deployment Pipeline

Whereas before we often had to wait for eggs to hatch, a process which takes valuable productive time away from the duck producing units, we now foster a culture of continuous duck production. This way of working will inevitably lead to things that break. But that’s ok. We don’t point the finger at somebody who made a mess of dropping duck eggs in the kitchen. In the DevOps culture, we do a standup, avoiding the sticky part of the floor, and then we all get a mop, clean up and go release some more ducks in the water.

An important part of the DPS, is constant exercise of Duck functional testing at any stage of the producing unit, because we all value quality. With visual duck analytics we see that people in the industry are finally getting all their ducks in a row. As in many things, visualizing your work is important, and visual duck analytics allows this.

Cross Duck Collaboration

At “Duckly”, we’ve been using Flowduck to speak to Ducks on a daily basis. It replaced the previously used HangDucks (which is just mean), Hipduck (which was nice at the beginning), IRDucks (which eventually made the ducks radioactive), Duckfire (OI!) and Duckmail (which is way faster than snail mail of course).

Collaboration becomes hard when trying to control more than 2 or 3 teams producing Ducks on a daily/decadely basis. That’s why we wrote “Duckme”. Duckme (http://duckhub.com/duckly/duckmemore). is an open-source DevOps-is-everything tool. It provides an easy and accessible way to create “Duck Correspondants”. Those DC’s, are in charge of making sure DuckDevs and DuckOps talk to eachother (and to ducks). Duckme provides a DUCKLESS API for sending eDucks and altering Ducks.

Duck Culture

You don’t need culture to produce ducks (especially DevOps). A toxic culture will also work just fine. Make sure you put high pressure on the Ducks at all times.

Ducker

As part of these worldwide changes to the flow of Ducks, new tooling for Ducks has evolved. Ducker provides the containerization of Ducks through lightweight methods known as Rubber Duckies. While the technology for Rubber Duckies has been around for many years, Ducker makes Rubber Duckies easier to consume through technologies such as DuckerHub. Additionally, Ducker overcomes the limitations of traditional Duck Virtualization Platforms (DVP), and Duck Configuration Management (DCM) systems.

Ducks For Developers

To make duck development accessible to all (DevOps), we’ve developed Duckrant. Duckrant lets you spin up virtual ducks, provision them and destroy them once you’re done (The virtual ducks, not the ducks themselves, mind you. WE LOVE DUCKS! is our moto.)

http://duckhub.com/duckly/ducks/ contains an unimaginable amount of base ducks for you to experiment on (e.g. Duck with Chef, Duck with Ducker, Basic Ducks and the notorious Duck Quickstart.)

Duck Future

With the growing movement of DevOps for Ducks (initially started by Patrick Duckois), it’s important that we begin to think about the worldwide implications of the free flowing of ducks. With the great ducks come great responsibility, and that is the great challenge as we begin to think more about what we call DuckOps.

Wax On, Wax Off

“Wow, you’ve run an ultramarathon. That must have been hard.”

“Kinda, I guess.”

That’s often how the conversation goes when someone finds out I’ve run an ultramarathon (any race over 26.2 miles). It’s an interesting conversation because people are often fixated on the execution of a single event in my life. An event that lasts 7.5 hours over the course of one day. What people don’t say is, “Wow, you trained for six months, five days a week, in the cold and snow, spending 7-8 hours a week running, cross training a fewtimes a week in order to run that far at one time?”

People are often focused on the event, and not what it takes to get to the event. Society focuses on the next great shortcut to achieve something better, cheaper, faster. The thing many of us don’t want to recognize is that the tried and true method of achieving something is hard work and perseverance. You can’t effectively run a marathon or ultra without putting in the hard work of training. You must spend hours a week training. You must slowly build up your miles. You must not over train or else you will get hurt. Sure, there are different methods of training, such as Crossfit Endurance which focuses less on running and more on building endurance, but you still have to train. Anything else will result in failure.

I’m reminded of The Karate Kid (the 1984 original). Daniel was bullied and felt he needed to learn karate. He found Mr. Miyagi, who was willing to teach him. Mr. Miyagi sets Daniel to work painting his house, waxing his car, and staining his deck. Daniel doesn’t want to be a servant; he wants to learn karate! In his overanxiousness to learn, he confronts Mr Miyagi about doing all these chores. We end up finding out that Daniel was learning karate all along.

And now, like with everything, people want the shortcut to DevOps. They want the secret sauce that they need in order to transform their business and IT. They want the certification they can earn in a few hours of work to prove they can DevOps. They get frustrated when we tell them there is no easy path. They get frustrated when we tell them that they need to just start doing something, anything to start improving their work. As with the runner, you just have to start running to start training for a marathon.

We now have over five years of history in the DevOps movement. There is plenty of information available for “how to get started”, but the single most important thing a newcomer needs to realize is that it takes a curiosity, a desire to learn, and a willingness to listen to other people that might be different than you. As Aneel Lakhani said in his below ignite talk, “…the single strongest signal that we have something to learn is the fact that a difference exists.”

And there’s the rub with the “classification of DevOps” that people are undertaking. This classification seeks to alienate groups because differences exist, not unite them because they have something to learn from each other. After reading the latest post on the subject, a friend tweeted about going through those exact same things in a 100 person company right now. If enterprises solve problems in their own little world of DevOps, how do we ensure that this knowledge flows down to the “non-enterprise” DevOps practitioner? This stratification divides us rather than unites us.

When we willfully disregard core tenets of the movement, such as Collaboration and Sharing, we are essentially back to where we’ve always been, and no one moves forward. That is why hearing the stories coming out of the DevOps Enterprise Summit is encouraging. Large companies are opening up and telling their stories of transformation. Large companies are proving that the ideas of DevOps work, no matter your size.

Veteran of the Process Wars

Tokyo. I’m still in Tokyo. I wake up, rub the sleep from my eyes, and roll out of bed. As I rise I take a quick look at my watch for any new emails. Nothing. There’s not much email anymore. Not since the process wars of 2016.

Many people won’t talk about the process wars. They changed the way most of the InfoTech industry works and how we are allowed to think of our jobs. In the past, I might have been responsible for running hundreds of servers. Now, the machines are in charge. I’m only allowed to feed the machines code.

We are grouped together in small teams that write code as a unit. We are “kept in line” by dogs that are trained to attack us. They say it’s for our own good. That it’s for the betterment of industry. If we try to touch the servers, if we try to do anything other than write code and feed it to the machines, the dogs will bite us.

We are kept in line by process and controls, but not like we used to be kept in check. Before, we used to have weekly meetings reviewing the work we wanted to perform. The meetings were always a joke amongst my peers. Typically they were run by a VP that had no clue what we wanted to change on the machines. If we wanted something bad enough, we could social engineer our way to what we wanted.

No more today. When we write the code to feed the machines, we have to write tests. They tell us these tests are for our own good. The tests confirm that the machines are set up exactly how they want them to be. We actually write the tests first, and they always fail the first time through. Then we write code to bring the tests into compliance.

If the tests weren’t bad enough, we also have automated tests to make sure our code conforms to “Style Guidelines”. They tell us these guidelines are to ensure conformity and consistency. I say they are there to hold us down and control us. They also require us to “lint” our code before we feed it to the machines. This once again is to ensure “conformity”.

Even with all of this verifying for conformity, we still aren’t allowed to directly feed the code directly to the machines. We must check the code into a repository where more machines take over to verify that we have successful tests and we meet the conformity guidelines. The machines also verify that our code works with code written by others, in my group and other groups.

Then, a Conformity Checker reviews my changes to make sure they are compliant with the policy. We are no longer independent; we are no longer allowed to game the review board. We feed the machines compliant code or else we end up on the streets. Three strikes and we’re out.

Which is why I’m in Tokyo. I’ve had two strikes at my company in the United States. They shipped me over to the Tokyo division for reeducation. Japan culture is heavily based on order and process. During the process wars they helped lead the revolution. Many of the compliance tools were written by or enabled by Japanese technology leaders. Yukihiro Matsumoto (codenamed Matz) was responsible for designing the programming language I now feed to the machines. Gosuke Miyashita wrote the tools that I am required to use to test my code before feeding it to the machines. And then there was Kohsuke Kawaguchi, the creator of the master machine that ensures all the code is compliant, automatically with no humans to game the process.

It’s all very neat and orderly now. I take requests for code from the owners of the machines, I write compliant code, and the machines automatically verify my work. Eventually the machines apply my code, and the owners get exactly what they want. I’ll wake up the next however many hundreds of mornings and do just this. No more, no less. It’s all very neat and orderly now.