Tag Archives: enterprise IT

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

Posted on by
1

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 – iTunes – Stitcher – RSS

Guest Info:

Jonny Wooldridge – LinkedIn – Twitter

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

Posted on by
6

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 – iTunes – Stitcher – RSS

Guest Info:

Jason Walker – LinkedIn – Twitter

Dan Cundiff – LinkedIn – Twitter

We don’t need no manifesto…

Posted on by
8

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

The Goat Farm

Posted on by
2

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

Wax On, Wax Off

Posted on by
3

“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

Posted on by
Reply

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.

You Build Kingdoms Because Your Mother Didn’t Love You

Posted on by
1

Mother-Child_face_to_faceDestruction of silos is all the rage in DevOps and has been since the beginning of the movement. Patrick Debois wrote a very intelligent piece on why silos exist and how they came about as a management strategy. While the post explains why hierarchy style of management came about in the US (General Motors and Sloan), it doesn’t cover some of the personal motivations as to why silos or management kingdoms come about.

Parkinson’s Law

Over the last several years Bike Shedding – or more appropriately Parkinson’s Law of Triviality – has become very popular in technology.  But in all the trivial debate, it seems more technologists have missed C. Northcote Parkinson’s other law, aptly named Parkinson’s Law.

Parkinson’s Law simply states “…that work expands so as to fill the time available for its completion.” Any life long procrastinator will immediately know this is true, as does anyone that has attempted to do any level of project management. Further, Parkinson explains that this expansion of work, also creates an expansion of people doing the work. While Parkinson was focused on governmental organizations, Parkinson’s Law can also apply to other organizations.

Parkinson attributes this expansion of work to two factors:

Factor I.—An official wants to multiply subordinates, not rivals; and

Factor II.—Officials make work for each other.

The Law of Multiplication of Subordinates

Now as work expands, for whatever reason, Parkinson explains that the worker (worker A) must find ways to handle the workload. Parkinson explains that they must find a solution and have three options:

  1. Resign
  2. Split the work with colleague B
  3. Hire subordinates.

And as Parkinson points out, any rational actor is going to choose #3, and in doing so will at a minimum hire 2 subordinates, workers C and D. Hiring one subordinate would be effectively equal to #2, splitting the work with C instead of B, and thus increasing the pool of competition (A, B, and C would effectively be at the same level at this point). Thus the rational choice is to hire 2 or more subordinates, and in doing so A can leverage C and D against one another, holding a possible promotion out as a carrot in order to keep C and D in check.

Of course, work expands, eventually C and D become too busy, and thus they must make the same choice that A had to when they were hired. Rational actors as they are, they choose option #3, each hire 2 subordinates (at least), and please welcome E, F, G, and H to the company. Worker A now has a beautiful fucking kingdom; self-loathing because of an unloving mother notwithstanding.

The Law of Multiplication of Work

As Parkinson points out, seven people are now doing what one once did. Instead of simply expanding to fill time, work now begins to multiply. Why? Well the workers begin to create busy work for each other. The example Parkinson gives follows as such:

“An incoming document may well come before each of them in turn. Official E decides that it falls within the province of F, who places a draft reply before C, who amends it drastically before consulting D, who asks G to deal with it. But G goes on leave at this point, handing the file over to H, who drafts a minute, which is signed by D and returned to C, who revises his draft accordingly and lays the new version before A.”

Parkinson continues his example documenting the busy work that this kingdom produces, much of it useless, and leaves the example with A leaving the office for the day:

“Among the last to leave, A reflects, with bowed shoulders and a wry smile, that late hours, like grey hairs, are among the penalties of success.”

Success indeed my King, Success indeed.

Sound Familiar?

If at this point, you haven’t seen the slightest reflection of an org you know, work at, or have worked for then please let us all know the magical organizational utopia that employs (or has employed) you. Snark and rage aside, this really highlights the problems of many organizations; big kingdoms built to produce very little of value other than process and busy work. And that is why the DevOps Silo Rage gets so much airtime. Process and busy work are there to further the growth of the kingdom, not feed the soul of the individuals at the bottom.

This also highlights why DevOps focuses so heavily on borrowing from things like Lean Manufacturing. Lean emphasizes getting rid of unnecessary process and waste, in order to focus on value creation activities. It also empowers the individuals – E, F, G, and H in the example above – to shape how the value creation process should actually work and what processes are wasteful.

Now reflect on A. What if (s)he came in one day and E, F, G, and H wanted to revamp all the “meaningful” process that keeps them in check. What do most kings (or queens) do when a revolt happens? Kingdom in jeopardy, they squash the rebellion and execute the leaders of the rebellion. Sometimes the monarchy throws carrots to the rebels to appease them just enough to keep the rebellion down.

And that is my rub with the Marketing Driven DevOps drivel being produced today. It’s a fucking carrot to appease the rebels in order to keep the status quo, kingdoms intact, and incumbents in bed with the monarchy. It’s an illusion to pretend you’re doing something new, and at the end of the day thinking, “All this hard work is just my price for my success.”

Parkinson’s Law – The Economist – November 19th, 1955 – http://www.economist.com/node/14116121