Tag: devops culture

  • How to laugh at DevOps

    How to laugh at DevOps

    Talking about DevOps is all the rage these days. But with that conversation, it’s easy to become inundated with the amount of serious discussion around the topic. I do agree that DevOps is not something we should joke around about, but since humor is an inherent part of our culture at VictorOps, it makes sense that we would be drawn to the humor of the situation.

    Below are the ten of the funniest Twitter accounts that make light of the DevOps movement. Some are obviously one-joke wonders while others continue to make us laugh. Either way, the list below is proof that you can’t take DevOps too seriously:

    DevOpsBane

    DevOpsYakov

    • @UncleDevOps – Everyone’s favorite continuously-deploying uncle. Also a little crazy.

    UncleDevOps

    • @DevOps_Jesus – Continuously delivering from evil since 4 BC.

    DevOpsJesus

    • @DevOpsGrouch – I complain. I swear. I automate. Deal with it.

    DevOpsGrouch

    DevOpsTourettes

    • @DevOpsBorat – Cultural Learnings of DevOps for Make Benefit Glorious Teams of Devs and Ops.

    DevOpsBorat

    • @DevOpsX – Always fighting the good fight for DevOps equality.

    DevOpsX

    DothrakiDevOps

    DevTylerDurden

     

    Feel free to add any that I might have missed to the comments below. And remember to laugh…it’s just DevOps after all.

  • DevOps Dirty Little Secrets

    DevOps Dirty Little Secrets

    By all outward appearances DevOps is gaining real velocity within IT shops worldwide, Duh tell you something you don’t know. I have read much on this topic as I am sure you have, but I never seem to read much with hard data results, other than we are doing great with some very broad  metrics. What are the hard numbers as compared to the legacy IT shop?  So my search begins; where in the world are devops metrics in Fortune 500/Enterprise organizations?

    What got me thinking about this were a couple of recent AppDynamics blogs “Measuring your devops success” and   “Quantifying the value of devops”.  Both blogs do an excellent job at breaking down DevOps to the implementation level. Hard data creates metrics that set a baseline with the legacy system that is the critical measurement component, without a baseline there is nothing to compare or measure against. This approach creates a meaningful way to measure the success of executing a DevOps strategy within an IT shop.  The blogs also point other factors not quite as easy to measure, particularly human elements. Many others have written on measuring DevOps, you need to adopt the approach that makes sense for you and your organization.

    At that point I figured it was time to visit Puppet Labs, when you think DevOps Puppet Labs and their survey’s comes to mind. I utilized the 2013 State of DevOps Report; the 2014 report is not available yet. I believe that in order for any new philosophy to be adopted as a true standardized practice, the C-level in Fortune 500 organizations need to embrace it. In my long experience, typically the first sign of acceptance in traditional Fortune 500 organizations is when the financial vertical embraces it.  As an example, Wall Street traders will pay good money to save two milliseconds on a trade.

    The Puppet Labs report numbers demonstrate real velocity in the adoption of DevOps as an accepted business practice. The first takeaways I had from the report were that organizations ship code 30x times faster with 50% fewer failures. The numbers paint a glowing picture for DevOps. But looking beyond the glowing numbers, I see something else. DevOps is at a critical fork in the road and needs to cross the chasm before it loses its luster and becomes just another application development tool, as opposed to a practice.

    Only 17% of the respondents were Managers or C-level, with only 22% of respondent companies having 10,000 employees or more.  It is essential to look at individual Fortune 500 companies IT shops and measure them with hard data before and after the implementation of DevOps.  I would love to read some in depth case studies of the Fortune 500 with hard numbers and metrics; I did not find anything with the legacy baseline data. A huge benefit of DevOps to the Fortune 500 is it will enable them to fail fast as opposed to continuing an implementation that will inevitably fail anyway and consume a huge amount resource in the process. Anyone who has worked for a Fortune company I am sure has witnessed this.

    In truly understanding what DevOps is and is not, certain questions need real answers; Are Enterprise/Fortune 500 companies really doing the same old thing and just need to write better code utilizing some new application development tools, does that make it DevOps or just continuous improvement? Will some IT execs change the organizations title from sysadmin to Devops Admin to protect their silo and make them seem kinder gentler Ops? Are the DevOps tools available today ready for prime time in the Fortune 500 IT environment? Is Devops about technology and metrics or really about culture? We can speculate, but time will tell us the real answers. I am looking for good metrics on what does DevOps do to a Fortune 500 company Not some so called Unicorn that was born with a DevOps spoon in its mouth, but a good old fashioned Wall Street firm who adopts DevOps. Until then call me the DevOps skeptic.

    If you would like say something; email parker@devops.com and don’t forget to comment here.

  • The DevOps Journey

    The DevOps Journey

    Maintaining a constant thirst for learning is essential for anyone dedicating their career to the IT, computer and networking industries. It’s more than just learning about the latest technologies, rather, it’s imperative we embrace new methodologies and paradigms for doing work, thinking about problems and creating solutions. Enter DevOps, which is a healthy mix of all the above.

    You might find things a bit confusing if you’re new to DevOps. There are many perspectives on what it means. For myself, there were two significant milestones on my journey to understand and embrace DevOps;  1) rethinking how we design large, dynamic applications and manage the underlying infrastructure in cloud environments such as Amazon AWS, and 2) reading the book The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford.

    At first blush, I thought DevOps suffered the “definition bloat” of so many other industry buzzwords (for example, “cloud” comes to mind.) Depending on who you talked to or what you read, DevOps definitions frequently encompassed one or more of the following:

    1. embedding development resources within business units for better alignment and reduced cycle time,
    2. high frequency software releases into production (multiple per day, hour, etc.)
    3. automating infrastructure and system administration tasks vs manual provisioning and sysadmin
    4. embedding operations functions within development organizations
    5. operations performed by developer, even doing away with traditional operations in some cases

    If these seem like a somewhat confusing, loosely assembled list is ideas, don’t fret — they struck me the same way at first too. These ideas actually fit very well together around a few core ideas essential to DevOps.

    Quicker Time To Value – Being Fast and Agile

    DevOps is about changing traditional paradigms, enabling us to more rapidly deliver production updates, new capabilities and improved operations. Outcomes include reducing software releases from months to multiple, micro releases per day, and even hours. To do this requires much more than can be achieved through traditional operational efficiencies. It requires tight alignment, coordination and execution by product, development and operations functions. Embedding multiple disciplines together helps gain this alignment, shorten communication paths, setting priorities quicker, enabling lightning fast coordination. DevOps promotes new practices like embedding development and operations functions within other parts of the business, breaking down long standing barriers between IT / Ops and development / business groups.

    Automated Provisioning, Operations and SysAdmin

    From app development to infrastructure operations, DevOps is about automation. DevOps is about faster software testing and integration, quality improvement, and working in much more dynamic and rapidly changing operating environments. For example, rather than building system images by hand (stick built), automation is used to rapidly generate and spin up new virtual environments on a small or large scale. Systems wake up, check in to learn their personality, install, configure or update code (OS, database, web server, application code revs, etc) and join the network dynamically. This can occur with a single instance or with hundreds simultaneously. Initial upgrades and feature updates can occur on smaller or isolated sections of the network, then are rapidly rolled out across the network, and rolled back quickly if necessary. Sysadmins, be they developers or ops people, use scripts, code and automation tools to manage much larger environments than would ever be possible using manual methods. Automation is an essential differentiator in any DevOps environment.

    Culture of Open Collaboration, Communication and Failing Fast

    DevOps breaks down silos and places a premium on collaboration and communications amongst all players involved. It’s no longer us vs. them or this department vs. that other department. The blame game is gone and the focus is on making work happen, and fast. Communication lines are drastically shortened and conflicts in chains of command are collapsed. It’s about how “we” get things done, no longer about what “they” didn’t do. Failures are viewed much differently. Failures happen and from them we learn and develop newer, better, more innovative solutions to solving problems and prevention problems in the future. Because of the speed DevOps can bring, recovery from failure is much quicker. If a new release into production is causing issues, we quickly flip back to a previous known-good version running on other virtual instances. Updates can also be rolled out much more quickly.

    I hope these and coming views on DevOps are valuable to you as a reader. I know our conversation will help me and the teams I work with, as we learn and grow our expertise in DevOps. Please share your ideas, disagreements and learnings as we move along this journey together into the fast moving and quickly changing world of DevOps.

  • In the DevOps Journey, Culture Comes First

    In the DevOps Journey, Culture Comes First

    Etsy, the global marketplace where people sell handmade goods, vintage items, craft supplies and more, has grown by more than 10 times since Chad Dickerson joined as CTO in 2008.

    While the organization’s success is obviously the result of numerous factors, it’s no coincidence that upon arrival, Dickerson initiated a significant culture shift in how the company’s development and operations teams deploy updates to the front- and back-end of the website.

    What kind of culture shift? If you saw my title in the byline, you probably know that I’m talking about DevOps. But before we get into why culture is so important to DevOps, let’s back up a bit and make sure we’re all on the same page about what DevOps actually means.

    At CA Technologies, we define DevOps as best-practice application delivery methods that improve communication, integration and collaboration between development and operations. In layman’s terms, this means development and operations teams work on software releases in tandem, rather than throwing code back and forth across a silo. The result? Their collaboration helps companies release high-quality software and services to market faster and at lower cost.

    The “why” of DevOps is simple: In an ultra-competitive landscape where companies are racing to release the next big thing, software quality and speed-to-market are essential for achieving business goals and creating differentiation. It’s the “how” of DevOps that can be confusing. So let’s talk about where that begins – namely, with culture.

    A Vision for Transformation

    When it comes to something as significant as a culture shift, it’s not about just getting development and operations teams in the same room for a few meetings. We’re talking about breaking down long-standing silos and changing the human fabric intertwined with them – an undertaking that requires both top-down and bottom-up strategies for change.

    I talked earlier about the change Chad Dickerson brought with him when he joined Etsy as CTO. In a blog post from his early days in the position (he’s now the company’s CEO), Dickerson talked about the importance of “intellectual honesty,” which he described as “admitting when something is not working so you can work together to figure out how to fix it” and “measuring your successes and failures so you can properly reward for excellent work and learn from your failures so you can strive to never make the same mistake twice.”

    It’s clear from his words that Dickerson had a high-level vision almost from day one for how to transform Etsy’s IT operations, even as he admitted that there would be “bumps” along the way. This kind of vision is essential for driving the DevOps journey and keeping it on track as opposition, challenges and other issues crop up. It’s been said before that DevOps takes a village, but you can’t have a village without a chief.

    Populating the Village

    Speaking of the village, if the chief is supplying the top-down vision, it begs the question, who is going to carry that vision out? This can be tough to answer, especially in organizations where development and operations teams have been entrenched in siloed practices for decades.

    In my own experience, I’ve seen the village successfully get on board the DevOps journey when its involvement begins as a grassroots movement and grows with small wins over time. In other words, the chief pulls together a group of IT professionals with similar characteristics – think driven, highly skilled, unafraid of change – and they work to transform just a single deployment scenario (e.g., pushing out Web updates). At the end of that experiment, the team shares its experiences, challenges and successes with the larger IT group in the hopes of bringing more people on board and moving up to more significant deployment scenarios. Then, it’s rinse and repeat until the culture shift has occurred.

    It’s worth noting that in situations where the development and operations silos run especially deep, a rip-and-replace option may be the only viable one for achieving DevOps. In such cases, leadership has to put forth an edict saying “this is the way it’s going to be” and expect to deal with some attrition, as there will be employees who simply refuse to change.

    A Formula for Change

    We’ve talked about the chief and the village, but I’d be remiss if I didn’t touch on the nuts and bolts that are necessary for engineering such a culture change. Yes, top-down vision and buy-in from the bottom up are important, but so are the new tools, skills and processes required to support that change.

    There’s a reason the word “journey” is so often used with DevOps – it’s a never-ending cycle of optimization among the people, processes and technologies driving development and deployment operations. So as you evaluate your own culture and think about the next stop on your DevOps journey, remember this formula: vision + expertise + tools = change.

  • Why you can’t buy DevOps in a box

    Why you can’t buy DevOps in a box

    Companies will often believe they can buy their way out of technical debt without making any substantial changes. They often think they can buy DevOps in a box. Well, unfortunately, devops isn’t for sale. For an organization to embrace DevOps it will need to adopt cultural change, adopt tools which enable automation, and change processes to include both dev and ops. I like to think DevOps can be explained simply as operations working together with engineers to get things done faster in an automated and repeatable way.

    Culture

    Organizations large and small have experienced these changes, the challenges encountered along the way, and the light at the end of the tunnel. Each organization requires their own set of tools and processes to embrace DevOps. Cultural change largely depends on the existing dynamic of an organization. In small companies, I have found it needs to come from the ground up and usually starts with adding the DevOps toolchain. In large organizations the value of DevOps needs to be sold to the executive team and then enforced from the top down. This is a daunting challenge for most large companies because it’s hard to quantify the value of DevOps.

    Most organizations only quantify failure when it comes to IT outages. How many outages? For how long and how severe? They often don’t quantify the success from 100% uptime or the resilience of failing over with zero down time. The ability to instrument and prove to an organization the value of applying DevOps is a crucial step to making it happen. DevOps teams efficiently deploy features faster with far less bugs. Also, when outages happen they respond faster minimizing the business impact.

    From developer to operations – one and the same?

    As a developer I have always dabbled lightly in operations. I always wanted to focus on making my code great and let an operations team worry about setting up the production infrastructure. It used to be easy! I could just ftp my files to production, and voila! My app was live and it was time for a beer. Real applications are much more complex. As I evolved my skillset I started to do more and expand my operations knowledge.

    Tools

    During the development phase, the operations staff normally makes sure the development environment is managed and they actively work to set up the test, QA, and Prod environments. This can take a lot of time if automation tools aren’t used. Here are some tools you can use to automate server build and configuration. In another post I will dive through the pros and cons of each tool, but as long as you apply some form of configuration management and treat your infrastructure as code you will be on the right track.

    Process

    From an operational perspective, my first instinct is to understand the application architecture so I can start thinking about the proper deployment model for the infrastructure components. Here are some of my operational questions and considerations for this stage:

    • Are we using a public or private cloud?

    • What is the lead time for spinning up each component and ensuring they comply with my company’s regulations?

    • When do I need to provide a development environment to my dev team, or will they handle it themselves?

    • Does this application perform functions other applications or services can already handle?

    Operations should have high-level visibility into the application and service portfolio. From a development perspective, my first milestone is to make sure the ops team fully understands the application and what it takes to deploy it to a pre-production environment. This is where we the developers sync with the product and ops team and make sure we are aligned.

    Planning for the ops team:

    • What tools will we use for deployment and configuration management?

    • How will we automate the deployment process and does the ops team understand the manual steps?

    • How will we integrate our builds with our continuous integration server?

    • How will we automate the provisioning of new environments?

    • Capacity Planning – Do we know the expected production load?

    Once developers have built unit and functional tests we need to ensure the tests are running after every commit and don’t allow regressions in our promoted environments. In theory, developers should do this before they commit any code, but often times problems don’t show up until you have production traffic running under production infrastructure. The goal of this step is really to simulate everything that can go wrong and find out what happens and how to remediate.

    Combining the power of developers and operations

    The focus on the developer/operations collaboration enables a new approach to managing the complexity of real world operations. I believe the operations complexity breaks down into a few main categories: infrastructure automation, configuration management, deployment automation, log management, performance management, and monitoring.

    In my next post I will walk through each one of these complexities and address how you can get your organization inline.

  • DevOps’ Chicken Or Egg Origins

    DevOps’ Chicken Or Egg Origins

    When acolytes explain the DevOps movement to the uninitiated, they usually run into a chicken and egg line of questioning. What is DevOps, really? Is it a culture? Is it a pattern of processes? Or is it a technology? What comes first?

    The ratios of the perceived importance of each of those elements may shift depending on who you talk to in the DevOps community. But the inevitable answer to these questions is usually that DevOps depends on at least a little of all of them, but probably on culture above all else.

    “I think it’s first and foremost cultural. The development team is a tribe. So is operations.  They have norms.  They have things they value.  They have things that they reward and admonish,” says Josh Corman, chief technology officer for Sonatype, a component lifecycle management firm. “Developers are incentivized to cause change.  And ops people are incentivized to prevent change, to promote stability.  So they were natural enemies.  And when they work it out and align to each other’s tools and incentives, they’re able to go faster.”

    Therein lie the historical roots of DevOps, agrees Andrew Storms, senior director of DevOps at cloud security firm CloudPassage, who explains that it is an answer to the blame game that inevitably occurs in the old model.

    “I think that existing corporations or companies or groups are probably doing DevOps in response to existing pain,” he says, explaining that in previous non-DevOps shops he worked at, it was inevitable that development would write a piece of code, throw it over the fence and let ops catch the heat when trouble brewed. “The question is, why is the person at the end of the train always feeling the pain for something that originated at the beginning of the train? To me, DevOps says, ‘There is no train.’ There’s no more division of who’s in trouble for anything. Everybody is on the same darned team.”

    It’s for this very reason that Jez Humble, a principal for the consultancy ThoughtWorks and co-author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, says that the fundamental ingredient to successful DevOps is trust.

    “You need to trust each other. Developers can’t just assume the ops people are all dumb and don’t know anything about code or are just command line monkeys. And the ops people can’t assume the developers don’t know anything about how systems work in real life,” he says. “These assumptions make it all a big finger-pointing exercise.”

    A lack of trust is the underlying roadblock to better teamwork between dev and ops, but it can be difficult to achieve within enterprises.

    “In small organizations people trust each other because they can see each other and work with each other and must learn to trust to get anything done,” he says. “But as organizations scale you lose that human contact.”

    It’s replaced instead with brittle and bureaucratic processes that only feed into those distinct walls between each tribe. However, as organizations feel the pain that’s inflicted by those bureaucracies that have evolved so far in IT and by the walls thrown up as a result, they face a choice. Engender that trust and a culture that allows  dev and ops to simplify processes and tear down the walls, or face further roadblocks that will hurt the business.

    From there, it is a matter of establishing behavioral and process patterns that are a hallmark of DevOps cooperation.

    “I think ‘patterns’ is the right word for it. People get hung up on this textbook or technical definition of DevOps.  And while there are certain common processes and things like Kanban boards and Scrums, and sometimes it’s a hybrid of Agile, sometimes not that ,” Corman says, “what matters the most is an attitude to fail fast and iterate, to continuously look for ways to increase flow, to automate, instrument and find and root out weakness. And to be responsive to new ideas of the business, or new ideas of your install base, or new market pressure.”

    According to Corman, the beauty of DevOps is that it’s a ‘jump ball’ for IT, so there are no set processes that make or break whether a shop is DevOps or not.

    “It’s in a state of flux, and the cement hasn’t dried.  It’s a singular opportunity to redefine the way we engage with the business and drive value, the likes of which we will not see again for 30 years,” he says. “It’s very, very rare.”

    And while few within the DevOps community would say it is defined by technology, it certainly is enabled by it.

    “To me it is more a cultural shift than a tool shift, but that tools shift presents a huge change in the way IT runs,” Storms says, explaining that instrumentation and orchestration tools like Puppet and Chef makes it possible to achieve continuous improvement and fast iterations. “So does it come about through the cultural change or the technical change? I think, actually, neither. I think it happens at the same time. That’s the force multiplier, that two plus two equals five kind of thing.”

    But like tectonic shifts, changes in IT happen sometimes all of a sudden, but mostly in increments.

    “One part of it is focusing on what we can do every day to make things a little better for everybody. You have to proceed incrementally and accept that it’s going to take time,” Humble says. “You can’t say, ‘Well, we’re going to adopt Agile now across the whole organization—go!’ There has to be enthusiasm from the people on the ground to do this stuff and then you have to work together though a process of experimentation and trial and error to work out how to make it work in practice, probably with a small group of people initially.”

    Even with that force multiplier, Storms says, you’ll still see positive steps forward by establishing an element of DevOps one at a time.

    “Even if you’re in a difficult situation where you can’t have the force multiplier of culture and technology changes at the same time, just one or the other is still going to be a big win,” he says. “Let’s say you just took the one piece of ‘Let’s move our dev and ops teams together and make them be friends,’ you don’t necessarily have to orchestrate and instrument like crazy to win. But you can also do the opposite and just picked the orchestration piece and say, ‘Hey, ops people, stop doing things by hand.’ You send them to Chef conferences and make them learn Ruby and guess what? Their skill sets just went through the roof.”

  • You Can’t Sell DevOps

    You Can’t Sell DevOps

    A few days ago, I made an introduction for colleague Jason Dixon (@obfuscurity) over email, and described Jason as “a leading supporter of the DevOps movement”. A mere 17 minutes later, Jason replies to me, “Are you trolling me?”.

    I was aghast. Granted, I haven’t known Jason terribly long (measured in months), but I’ve been well aware of his impact and contributions to the technical community (pulling together Monitorama , for starters). I couldn’t fathom the visceral reaction. But it did get me thinking… Why would someone so impactful want to distance themselves from the description?

    For Jason, and many like him, it’s a question of intentions. To explore that, we’ll have to go back to the beginning, and for me the beginning was 5:20pm PST on June 24, 2010, in the last session on the last day of Velocity CA… a “choose your own adventure” talk by Adam Jacob (@adamhjk ), answering the question “what is DevOps?”.

    I happened to have my flip cam handy…

    http://www.youtube.com/watch?v=Fx8OBeNmaWw

    “So here’s the thing: DevOps is a cultural and professional movement. Period. That’s it… There’s no technology, you can’t patent ‘devops’. Can you market a DevOps compliant toolset? You cannot.”Adam went on to describe the evolution of the system operation profession, and the challenges he personally found. Then came the org chart of a traditional silo approach to a technical organization hierarchy: software developers

    Adam proceeded to challenge this approach with an alternative. “So this is everybody in a big pile. What we are is peers, and friends, and mentors, and we are having fun!”. Hysterically live in one silo, reporting into a director who reports into a VP, network engineers live in a separate silo, reporting into a separate director, system administrators in a third silo, and security engineers in a fourth. Proverbial walls erected between technical contributors, isolated from one another through a formal hierarchy. Need to communicate across to a peer? Better go up the stack to go back down.

    Our hypothetical example continues of a conversation in the big pile: “Hey security dude, what’s that you’re doing?!?”, and he’s like “I’m breaking into the web site.” And you’re like “How’d you do that?!?”, and he shows you and the network engineer is like “I can stop you,” and you’re like “How?!?,” and he’s like “Firewall rules.” And you’re like “Whoa! Firewall rules?!?” and the security engineer is like “Why did you need to do that anyway, that’s a protected network”. And then everybody is having a good time. And the Directors. They’re just helping you out. They’re propping you up.” cory2

    While improvised, comical, and at best a generalization of an industry in a hypothetical example, one key point stuck in my mind from Adam’s talk: DevOps was about people, and how they were most effective and happiest working together. That was the point of the cultural and professional movement: to be more effective and happier as a team, embracing a “shared outcome.” Software developers, network engineers, system administrators, security engineers, directors, VPs, etc., we all succeed or fail together.

    That’s not something you can sell. (In this context, I’ve specifically referring to selling a tool or service.) Nor is it something you can pin down to one definition applicable everywhere. Nor is it something that you can transplant wholesale from one company to another and expect the same level of effectiveness and happiness. You can’t “bolt on” DevOps to your existing organization with only tools and services. You can’t buy a toolset and expect your challenges to be alleviated. You have to understand the role improved tooling has played for those that have found success in this field.

    Tools can certainly be enablers and facilitators, particularly when they free up person hours from manual tasks (assuming you can channel the new found time in an enabling direction), and particularly when they increase transparency as to where technical problems exist, helping to avoid the “It’s not my servers, it’s your code. It’s not my code, it’s your servers” blamefest. How we interact with them, and the patterns of behavior they impose on us as people, can lead to drastically different results from one organization to the next, even if those organizations have identical tools.

    When our tools look like the first silo org chart example above, with a different set of tools presenting different perspectives to different teams bound together by a shared outcome, the tools end up dictating and reinforcing the silo organization hierarchy for how people work together.  To break down the proverbial walls, our tools instead must help define how people should work together.

    Tools enabling configuration management, automation, improved monitoring, metrics collection, and source control won’t ensure success in isolation, because the DevOps movement isn’t ultimately about the tools. It’s about the people, and how they will work best together to succeed. The right tools can go a long way toward removing barriers, enabling the right conversations, and setting the stage for success.

    Part of the challenge is that the tools are one of the more tangible and visible aspects of how we work. In can be easy to take a stroll through a peer organization and take note of the different tools, and attribute their success accordingly. You might be sold on the idea that a tool they have has been the missing piece to your success all along. Fight this first impulse to the tangible and visible, and remember that it’s hard to see how folks really interact. It’s hard to see how well their people, processes and tools work together to produce results in sunny-day scenarios. It’s even harder to see when the sh*t hits the proverbial fan. That’s where the real test is though, and that’s where the real lessons are to be learned. 

    So let’s all be a little more focused on the lessons learned in ways to work together supported by tools than on the merits of one tool over another in isolation. No doubt, it’s a harder and deeper conversation to have, but the value is tremendously greater. If we keep it up, maybe we can make Jason proud to call himself a leading supporter of this professional and cultural movement.

    Or maybe I was trolling Jason Dixon all along.

  • Changing Organizational Culture – A Sweaty Use Case

    Changing Organizational Culture – A Sweaty Use Case

    When we think about changing organizational culture our immediate reaction is usually – yeah right, go fight city hall – and we take the Homer Simpson route, and don’t even bother trying.

    Over the course of the last year, I managed to achieve what felt like an impossible change within my organization, and I took some valuable lessons from the experience.

    It dawned on me afterwards that there were a lot of parallels in this process that we also underwent when trying to instill a DevOps culture in our organization, and I thought I’d share what I learned.

    The Epiphany

     I love riding my bikes – mostly mountain biking, and I usually am only able to do this over the weekend.  It’s something I really love to do, but in addition to my full time day job – Head of Product at my company, I’m a full time dad – a proud father of three.  All of this doesn’t leave me a lot of time to do the things I love.

    On a good day I spend more than an hour stuck in traffic, and on bad days more than an hour and a half.  This is basically dead wasted time.

    So I had an epiphany one day. Why shouldn’t I take advantage of this time to my favorite thing?  I could easily bike to work – and use this wasted time to my benefit, doing the thing I love most.  The problem lies in the way I look after an hour bike ride.  Pretty sweaty.  Here’s a pic.

    And, I know what you’re thinking – the answer is – no it wasn’t raining that day, in case you were wondering.

    The challenge though, is that I work with people, so I needed to find a way to clean up after my rides.  But, alas alack, we don’t have a shower in the office.  The plot thickens.

    So you might be wondering at this point, how this all relates to DevOps.

    DevOps is about pushing change in organizations – and not necessarily just technical ones. There are cultural organizational practices that often times need to be changed before you can even start to think about technical changes.

    So I believe this story represents a real parallel case study on the organizational changes often needed, to create a DevOps culture within an organization.  These processes many times involve a change in hardware – in this case, the shower itself.  As well as require a change in culture, actually motivating the management to realize the importance of it, and have people start choosing to do athletics before work (and preferably also ride to work).

    The Method

    And then I ran into Jesse’s Robbins’ rules. For those who don’t know, Jesse is one of the founding fathers of DevOps and web operations, and happens to also be the founder of Chef (OpsCode at the time). In one of the recent CloudExpo conferences in Europe, Jesse gave an awesome keynote about how to hack organizational culture to drive change. So working on the premise of “Jesse’s Rules” – I got to work:

    • #1 – Start small – Build trust

    Until the new shower was built, I’d shower daily with a HelioPressure shower  (you can find it on Amazon for less than $100), and I’d shower every day on Nati Shalom’s [LINK TO DEVOPS BLOG] balcony in the office.  Demonstrating I was serious and dedicated to my biking to work. Yes, it definitely raised a few eyebrows, but then again, better to shower on a balcony than walk around smelling like a sweaty rug all day…

    • #2 – Create Champions

    Doing crazy stuff yourself is the easy part. Finding like-minded individuals that will do the same, well that’s a different story. But after working hard at convincing others, I managed to find at least two people that would occasionally use my improvised spa, and this really helped me drive change in my company.

    • #3 – Use Metrics to Build Confidence

    For me there were actually a few metrics that contributed to the driver for change.  The first was that, I right off the bat, lost quite a few pounds – which was an incentive for a number of people to jump on the bandwagon – or rather bike – in this context.  The next metric was hard research that shows that people that are in shape tend to be absent from work 80% less often than employees that are not in shape. That helped me in convincing my CEO that it’s actually an investment and not just thoughtless spending…

    • #4 – Celebrate Success

    After committing to our makeshift shower for months, budget was officially allocated, and a shower was built for all the employees looking to participate in sport activity on their way to work.  Needless to say that I’m not the only one riding my bikes to work today 🙂

    Lessons Learned

    So the lessons I learned throughout the process, and my key take aways as I see them are:

    •  #1 You’ll run into a lot of skeptics along the way. IGNORE THEM.

    Many people will attempt to discourage you from your goals along the way – don’t listen to them. If I had a dollar for the amount of times I heard “it’s never gonna happen”, I wouldn’t need company budget to build a shower.  But I stuck with the plan, and it ultimately paid off.

    •  #2 Change takes time

    Rome wasn’t built in a day.  It’s a cliche – but cliches are born from common experience.  We’d been discussing building a shower for 2-3 years at the least.  It’s true that until I didn’t demonstrate that I was truly dedicated, rule #1, it wasn’t taken seriously. It took time for the company to come around, and digest the idea, until it gradually happened.   So again, if you stick to your guns, and have faith – a change ‘gone come.

    •  #3 Take it one small step at a time

    Basically start small, and be creative. Until you can achieve the big results, celebrate the small achievements too.  Adding champions to your cause, increasing awareness, possibly a meeting to discuss the changes you propose.

    •  #4 Be prepared to improvise

    I owe a lot to my colleague that came up with the pressure shower idea.  I think until I actually demonstrated that there was a really dire need for such a change, it wasn’t really considered seriously.

    •  #5 Find a management sponsor

    Luckily our CEO is athletic in orientation, and is an avid bike rider as well, and he was committed to help making this happen.  Many times it won’t necessarily be the CEO, but find a management champion that believes in your cause, and is willing to help you bring about the change.

     Bottom Line

    No matter what change you’re trying to push, these lessons and rules have proven to hold true for me in any circumstances, and I often times use this method to push significant changes in work and in life.

    Oh, and here’s a pic of the new shower.

    If you’re ever in Israel, and need a place to work, and want to bike there…you’re welcome.