Tag Archives: agile

7348317140_e30eeda034

DevOps and the Product Owner

In a previous post we talked a lot about the “Product-centric” approach to DevOps but what does this mean for the role of the Agile “Product Owner”?

So what is the traditional role of the Product Owner? Agile author Mike Cohn from MountainGoat Software defines it thus:

“The Scrum product owner is typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management or anyone with a solid understanding of users, the market place, the competition and of future trends for the domain or type of system being developed” – Mike Cohn

The definition above is very “project-centric” – the Product Owner’s role appears to be tied to the existence and duration of the project and their focus is on the delivery of “features”.

DevOps, conversely, asks us (in the “First Way of DevOps”) to use “Systems Thinking” and focus on the bigger picture (not just “feature-itis”) and the “Product-centric” approach says we need to focus on the entire lifecycle of the product, not just the delivery of a project/feature/phase.

Whilst decomposing the “big picture” into “features” is something we completely agree with, as features should be the “unit of work” for your Scrum teams or “Agile Software Development Factory”, it needs to be within the context of the Product Lifecycle (and the “feature roadmap”).

So the key shift here then is to start talking about the “Product Lifecycle Owner”, not just the Product Owner, and ensure that Systems Thinking is a critical skill for that role.

The second big shift with DevOps is that “Non-Functional Requirements” proposed by Operations as being critical to the manageability and stability of the product across its full lifecycle “from inception to retirement” must be seen as equally important as the functional requirements proposed by the traditional Product Owner role.

In fact, we’d like to ban the term “Non-Functional Requirements” (NFR’s) completely, as the name itself seems to carry an inherent “negativity” that we feel contributes to the lack of importance placed on NFR’s in many organisations.

We propose the term “Operational Requirements” (OR’s) as we feel that this conveys the correct “product lifecycle-centric” message about why these requirements are in the specification – “This is what we need to run and operate this product in Production across the product’s lifecycle in order to maximise the product’s likelihood of meeting the business objects set for it”.

We propose the term “Operational Requirements” (OR’s) as we feel that this conveys the correct “product lifecycle-centric” message about why these requirements are in the specification.

For the slightly more pessimistic or combative amongst you the “OR” in Operational Requirements can stand for “OR this doesn’t get deployed into Production…” .

The unresolved question is do we need an “Operational Product Owner” or does the role of the traditional, business-focussed Product Owner extend to encompass the operational requirements?

You could argue that the “Operational Product Owner” already partly exists as the “Service Delivery Manager” (SDM) within the ITIL framework but SDM’s rarely get involved in the software development lifecycle as they are focussed on the “delivery” part at the end of the SDLC. Their role could be extended to include driving Operational Requirements into the SDLC as part of the continual service improvement (CSI) process however.

That said, having two Product Owners might be problematic and confusing from the Agile development team perspective so it would probably be preferable if the traditional Business product owner was also responsible for the operational requirements as well as the functional requirements. This may require the Product Owner to have a significantly deeper understanding of technology and operations than previously otherwise trying to understand why “loosely-coupled session state management” is important to “horizontal scalability” might result in some blank faces!

So in summary a “DevOps Product Owner” needs to:

  • Embrace “System Thinking” and focus on the “Product Lifecycle” not just projects or features
  • Understand the “Operational Requirements” (and just say “No to NFR’s”!)
  • Ensure that the “OR’s” are seen as important as the “Functional Requirements” in the Product roadmap and champion their implementation

In future posts we’ll examine the impact of DevOps on other key roles in the SDLC & Operations. We’ve love to get your opinions in the comments section below!

-TheOpsMgr

image source: – CC  – CannedTuna via Flickr – http://www.flickr.com/photos/cannedtuna/7348317140/sizes/m/

horizon

DevOps and the Knowledge Horizon

One of the things I love about SF novels is that they are always full of fascinating ideas that sometimes spark resonances in my own thinking (in this case, on DevOps).

Alastair Reynolds’ new novel “On the Steel Breeze” has this passage when discussing the rotation of Hyperion (one of Saturn’s moons):

“There’s a value in chaos theory, a number called the Lyapunov exponent, which tells you how to predict a chaotic systems boundary – it’s knowledge horizon, if you like. Hyperion’s Lyapunov exponent is just forty day – we can’t predict this moon’s motion beyond the next forty days. That’s the maximum limit of our foreknowledge! If my life depended on this moon’s motion, I would still not be able to say a word about its state beyond forty days”

My first thought when I read this was “Yep, sound like every IT project I’ve ever worked on… pretty much turns to chaos after about 40 days…”.

Now, the mathematics of the Lyapunov Exponent are way beyond my long-forgotten basics of high school calculus so I can’t comment on whether the author’s usage of the exponent is valid but the concept – that there is a limit on our foreknowledge beyond some sort of chaos event horizon – really stuck with me.

So what’s this all got to do with DevOps?

Well, “classical” project management takes a rather linear, deterministic view of the world – that we can accurately define a set of initial conditions that are complete (the mythical “requirements spec”) and that we can define a series of steps (the “waterfall process”) that will result in us achieving a desired end state (a working system that matches the specification AND the customer’s intent).

But what happens if software development is “non-linear”, chaotic and subject to “the butterfly effect”?

If “small changes to the initial conditions” (i.e. the spec is a tiny bit wrong, or more likely the customer changes their mind) can have a major impact on the end state (not to mention any of the other factors that might turn a project plan to “chaos” in the common usage of the term) does any given software project have a “Lyapunov Exponent” that limits our ability to predict the future?

I’d argue that it might… and this is intuitively what DevOps seeks to address in the “2nd Way of DevOps”

The Second Way is about creating the right to left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.

By shortening the feedback cycle we, consciously or unconsciously, are seeking to bring back our project cycles within our “Lyapunov Exponent”. If we can carry out our planning cycles (Sprints in an Agile development world) within that “limit of our foreknowledge” we create a system where we can correct and tweak the “initial conditions” of our next cycle to seek to keep our project “on track”.

What I also find interesting is the idea that different projects have different “Lyapunov Exponents” depending on their degree of “non-linearity” and sensitivity to initial conditions etc.

Perhaps this is why different projects can have success (or failure) with different sprint durations.

Just because a one, two or four week sprints work for project X doesn’t mean that’s the best duration for Project Y because it has a different exponent. Part of our feedback cycle also involves finding the optimal value for our “knowledge horizon” – not so far out we descend into “chaos” but not so short we spend more time re-planning than we might need to otherwise do.

Sprint Duration < “Lyapunov Exponent” = DevOps Success?

Sadly I don’t think that there is any theoretical way to determine a project (or organisation’s) hypothetical “Lyapunov Exponent” when it comes to project planning… it has to be empirical based on trial and error, but I’d be curious to know if, even anecdotally, that for a given organisation or type of project the likelihood of a “successful project” falls off a cliff beyond some planning horizon. If there was some way to determine the “Lyapunov Expontent” for a project and optimise an organisation’s feedback cycle (or sprint duration) below that limit then I think that would be of significant benefit.

-TheOpsMgr

p.s. yes, I know I’ve played fairly fast and loose with the mathematical usage of the word “chaos” compared to its vernacular usage. I apologise to any mathematicians reading this blog but I hope you’ll forgive me in the spirit of exploring an interesting concept!

image source: - CC  -  donkeyhotey via Flickr -http://farm7.staticflickr.com/6077/6144165108_8758c2a5c5_d.jpg

Continuous Delivery Adoption Barriers

For about a month, DevOpsGuys has been running a survey to understand what barriers exist for Continuous Delivery adoption. We’ve analysed the results and published our findings below. We’ve love to hear your feedback, so let us know what you think through the comments section.

barriers to cd

1. Organisation Culture (41%)

Organisational culture is probably the most important aspect to consider when adopting sustainable Continuous Delivery principles. 41% of respondents said that organisational culture was seen as the primary barrier to Continuous Delivery adoption.

Organizational culture is capable of blunting or significantly altering the intended impact of even well-thought-out changes in an organization.

Organisations seeking to adopt Continuous Delivery will primarily focus on evaluating and improving working practice, but to truly embrace Continuous Delivery, organisations must ensure that their employees encompass its primary principles. Continuous Delivery adoption is usually impossible unless management is bought in and at least some of the engineers are willing to change the way they work.

As organizations mature their Continuous Delivery adoption they must seek to embrace a culture which;

  • Is open, honest and transparent.
  • Encourages collaboration.
  • Promotes innovation, accountability and responsibility.
  • Builds and Rewards trust across organizational boundaries.
  • Enhances visibility of change and risk.

Organizational change is hard; it’s well known, theorised and documented and culture is the most difficult organisational attribute to change. For Continuous Delivery to be truly successful, the entire organisation must adopt its philosophy; to provide high-quality, valuable software as quickly as possible.

2. Lack of integrated development and operations (DevOps) (19%)

DevOps does provide an implementation strategy for Continuous Delivery principles, but neither philosophy is truly dependent on the other.  Continuous Delivery and DevOps are working towards common goals by providing business value through software delivery, within a culture that enables collaboration and understanding between the functional groups that deliver IT services where everyone is responsible for delivery.

Within the DevOps movement, Silo’s between teams are being removed so that software can be delivered quicker. That is, business value can be delivered quicker.

Developers are learning how to create production-ready software that can always be deployed, thus delivering high throughput and Operations are learning that Agile principles can enable effective and low risk change management, thus protecting stability.

recent study by Forrester Consulting and ThoughtWorks found that;

  • Companies are looking to prioritize innovation through developing software services.
  • Software development providers can’t deliver new services at the rate business leaders want.
  • Corporate culture and development process immaturity impede communication and slow service delivery.
  • Few IT organizations regularly perform advanced continuous delivery practices.

Therefore, it is not surprising that 19% of respondents consider a lack integrated development and operations capability as an adoption barrier for Continuous Delivery.

3. Technical hurdles (15%)

While Organizational Culture might be the primary adoption barrier for Continuous Delivery, there are also a number of technical hurdles to overcome. The technical challenges fall into 4 broad categories.

  • Configuration Management
  • Continuous Integration
  • Automated Testing
  • Automated Deployment

In each of these areas tools and associated best practice are becoming more advanced. Infrastructure-as-Code as promoted by OpsCode and Delivery Pipeline Management tools such as ThoughtWorks Go are being combined with an ever growing set of Cloud enabled services and platforms to make Continuous Delivery adoption easier from a technical viewpoint. However 15% of respondents believe that technical hurdles are significant in preventing adoption of Continuous Delivery.

4. Lack of understanding (15%)

Education of Continuous Delivery principles was seen as a big adoption barrier by 15% of respondents. Lack of understanding spans each of the possible responses in our survey from organisational culture through technical knowledge.

But there are more basic misunderstandings of the terminology, principles and practice of Continuous Delivery. As Paul Stack points out Continuous Delivery is not continuous deployment. Paul correctly defines Continuous Delivery as the process of having shippable software after each check in to source control, whereas Continuous Deployment is the process of shipping your product after every check in to source control. The difference is subtle but significant.

Another misconception is that Continuous Delivery and DevOps are basically the same thing. As Stephen Smith observes, Continuous Delivery and DevOps are interdependent, not equivalent. Some of this confusion may have arisen from the  misinterpretation of the DevOps principles leading to differing opinions of the relationship  between Continuous Delivery and DevOps, especially as “People often talk about DevOps and Continuous Delivery in the same breath.” as Jeff Sussna notes.

5. Business readiness to accept change at a fast pace (10%)

In many organizations, change can often feel constant. However as Isaac Asimov said “The only constant is change”. In general, people don’t like change, so methodology that promotes the acceleration of change is likely to face opposition. Only 10% of respondents saw business readiness to accept change at a quicker pace as a barrier to Continuous Delivery adoption. However, this may be influenced by the mainly technical community completing the survey.

Reducing the Mean-time-to-deploy can have significant business advantages. Continuous Delivery aims to provide high-quality and valuable software as quickly as possible. That is, to deliver business value is less time, whilst protecting the value quality. Given, respondents saw this reason as the least important factor is preventing Continuous Delivery adoption – could mean that organizations are aware of the benefits of getting to market faster.

For organizations aware of the benefits of delivering value at a quicker pace, and for those willing to embrace cultural change, Continuous Delivery provides a set of principles, which if implemented can provide significant benefit.

slide2

This week in DevOps #2

#1: The Rise of a New Kind of Administrator

Luke can see the growing trend of admin empowerment within customers and partners from his view at PuppetLabs. His outlook on tools that support admins in complex environments has always been clear, creating tools which allow “you to focus more on the business value of your work and spend a less of your brainpower on implementation details.”

This article looks at the changing role of administrators within organisations as “tools better enable people to build teams to focus on their customer instead of their technology.”

Read more: http://insights.wired.com/profiles/blogs/the-rise-of-a-new-kind-of-administrator

#2: 8 Lessons in Deployment Tooling Lessons Learned

Another great article on learning’s from the UrbanCode guys. This one gives us a history lesson on AnthillPro and what the team learned from creating and using the product. In summary the 8 lessons are;

  1. Builds are about quality and checking quality.
  2. Deployment is a serious challenge.
  3. Developers know jack about audit and security.
  4. Deployment starts with production.
  5. Deployment requires co-ordination.
  6. Deployment starts with high-availability and scalability.
  7. “Release” is more than just deployment.
  8. Multiple integrated tools are not optional.

Read more:  http://architects.dzone.com/articles/8-lessons-deployment-tooling

#3: Playing Pitfall with DevOps and CMDB’s

One paragraph in and Sam delivers a stark warning that  “there are some underlying shortcomings; some so major they might render DevOps redundant in the near future.”

In summary, he outlines the following challenges;

  1. DevOps goes against organizational culture; which advocates for the separation of responsibilities.
  2. Departure from IT Service Management Process
  3. Configuration Management Database redundancy
  4. Inadequate Automation

And so it is, that Sam leaves us with one final point to ponder “Be prepared to say goodbye to DevOps and CMDB, as they are sure to be abandoned in favor of new and improved counterparts in the face of a future IT revolution.”

In response, we ask you to consider Gene Kim’s 3 ways as the underpinning to the DevOps philosophy;

  1. The First Way emphasizes the performance of the entire system – the value stream.
  2. The Second Way is about shorting and amplifying feedback loops.
  3. The Third Way is about creating a culture that fosters continual learning and understanding.

If these truly are the essence of DevOps, are they principles that can ever be abandoned?

Read more: https://www.scriptrock.com/articles/playing-pitfall-devops-cmdbs/?utm_source=twitterfeed&utm_medium=twitter

#4: DevOps Complete Certification Kit

Only 18 Hours and you could be certified! Sounds too good to be true, well it is. As Patrick Debois commented, “they are not getting it!” The geniuses who put this material have really missed the point. We’d love to be certified “DevOps” guys, but instead we’ve focused on recognizing what the practice requires to be implemented. Don’t get us wrong, education on the background to Agile process and the challenges facing Development and Operations teams is vital, but don’t think that 18 hours of study are going to equip you with all you need to become a “DevOps” engineer (a term in itself which is entirely flawed). Remember this…DevOps is a philosophy, not a qualification.

Read more: http://archive.aweber.com/theartofservice/JxFjA/h/DevOps_Complete.htm

#5: Agile Alliance has a DevOps Track

DevOps seeks to address the challenges organizations face when applying change to high velocity environments. Speedy software development handing work over to risk-averse operations need not result in bottlenecks of pessimism. The rise of PaaS, SaaS, IaaS combined with improved understanding of systemic dependencies and business risk is changing how collaboration, automation and operations work in today’s modern enterprises. Mental models are shifting from protection mode to enabling-change mode. The track is going to cover the processes, tools and culture shifts shaping the DevOps movement. We look forward to seeing the output from this. Get submitting!

Read more: http://agile2013.agilealliance.org/program/tracks/devops/

#6: Tweet of the Week

Jesse Keating ‏@iamjkeating

#DevOps lesson: things go well when you’re environment is in an expected state. Not so well when suffering from technical debt. #Fixit

bad-idea-sign

Twelve DevOps Anti-Patterns

So you wanna do DevOps? Okay, but before you start, let’s have a look at some of the things you shouldn’t do.

In the good old days, we just called them “bad ideas”, but along came diplomacy and political correctness, out went the “brain storm” and in came the “idea shower” and with it came the “anti-pattern”.

If the “pattern” is the right way, then inherently the “anti-pattern” is the wrong – and so to stop you going wrong, we’ve compiled this list (with a little help from the DevOps community).

1. DevOps is a process

Not exactly. It’s a philosophy. It’s a way of thinking. DevOps is supported by process and tools.

DevOps according to Gene Kim, is underpinned by 3 core principles known as the “Three Ways”

The First Way emphasizes the performance of the entire system – the value stream.

The Second Way is about shorting and amplifying feedback loops.

The Third Way is about creating a culture that fosters continual learning and understanding.

http://itrevolution.com/pdf/Top11ThingsToKnowAboutDevOps.pdf

2. Agile equals DevOps?

If you’re asking this question, then you’re probably running some agile process. That’s good. You’ve got a software development process that compliments DevOps, but Agile doesn’t mean you’ve adopted DevOps.

DevOps is an agile enabler allowing operations to collaborate supporting a more continuous flow of work into IT Operations and out into production where customers can realize its value.

3. Rebrand your ops/dev/any team as the DevOps

CIO: “I want to embrace DevOps over the coming year.”

MGR: “Already ready done, we changed the department signage this morning. We are so awesome we now have 2 DevOps teams.”

Yeah great. And I bet you now have lots of “DevOps” engineers walking round too. If you’re lucky they may sit next to each other at lunch.

4. Start a separate DevOps group

Go on. I dare you. Done it? Well done. You’ve implemented DevOps. Actually what you just did is create yet another silo. Now you’ve got yourself another team you’ve got to try and integrate. Another team with walls to breakdown. Maybe you could go back and rebrand (see AP: x) and create 3 DevOps teams then you’d be super awesome.

DevOps is not about cherry picking some developers and some IT Operations people and silo’ing them off. You’ve got to embrace and embed. Collapse the development team into the ops team or vice-versa. You need to fully break down the barriers / walls / guards between the teams and mould them into a single unit with shared goals and responsibilities.

http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled

5. The hostile takeover

DevOps. So that’s a word that starts with “Dev”. That means development lead, because development comes first…… Problem?

DevMgr – “Er, we’re now doing DevOps. My guys need to learn the production systems.”

OpsMgr – “Er….ok. So who’s going to be developing the code?”

The word DevOps is clever. It’s a portmanteau. This means the combination of two words, to form a new word, which gives a new meaning. It even delivers some efficiency. It doesn’t mean we took the word operations and replaced it with the word development. So why would you try and adopt DevOps in that manner?

DevOps requires both groups to recognise their key skills. Share what needs to be shared to collaborate. Learn what needs to be learnt to improve. It does not mean retraining. It does not mean cross-skilling (however, this may be a welcome side-effect). It does mean providing feedback and visibility to improve.

http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled

6. DevOps is a buzz word

If you think DevOps is a buzz word, then you’ve probably been using “The Cloud” as a misnomer too. DevOps is a word, you got that right. Actually, it’s a portmanteau of Development and IT Operations (I’ll collect my gold star from teacher later).

DevOps is more than just a cool buzz word. It’s a state of mind. You must embrace its values, you must help others embrace its values and you must continually improve yourself and help others to improve for it to be successful. Once you throw away the BS and start collaborating you might get people to think your catchy new word “DevOps” might actually be cool.

http://www.slideshare.net/realgenekim/2012-velocity-london-devops-patterns-distilled

7. Sell DevOps as a silver bullet

DevOps is voodoo. You basically get your Development team and your IT Operations team together. They smoke some peyote and then sacrifice a chicken. Once you’ve done that your organisation will be revolutionised. You’ll be able to ship software faster than ever before. Configuration will be self-managing. Your deployment tools will become self-aware. Your development and IT Operations teams will have a new found harmony.

Get this….. DevOps is hard work! For most it requires Culture Change! That’s one of the hardest things you’ll ever attempt. For seasoned development and IT Operations teams you’re about to try and turn their world up-side down. Don’t try and do it overnight or you will fail.

8. DevOps means Developers Managing Production

No. Hell No and No again. I’m so incensed you’ll just have to read this….

9. DevOps is Development-driven release management

Let me get 2 things clear;

  1. DevOps is not development driven.
  2. DevOps is not IT Operations driven.

If you want a developer driven environment, fine, go create one. Just don’t call it DevOps. It’s not.

Take a look at this article for example.

http://www.computerweekly.com/cgi-bin/mt-search.cgi?IncludeBlogs=113&tag=release%20management&limit=20

“Within DevOps, programmers are programmers.” – Right on!

“Equally, within DevOps, operations staff are operations staff.” – We’re cooking now!

“Traditionally, getting software out to production can be either the responsibility of operations, or of the development team.”

Hang on……

“IT operations teams will have established and trusted deployment strategies in place that minimise downtime and ensure stability at the expense of agility and speed of response.”

Yep, we’re back on track…… and then bam!

“Development-driven release management” – WTF? It gets worse

“Development-driven release management goes the other way and looks at how deployment can be carried out as often and easily as possible. However, these deployments aren’t necessarily into production……………From a process standpoint, continuous delivery has two big requirements: first, the process itself has to be solid beyond development. This means that it has to be as solid as any process that a traditional IT operations team might put into place.”

No. Non. Nej. Na. Nee. Nein.

Development-driven anything may be a process. It’s just not DevOps. Replacing your IT Operations team with an automated deployment process is nonsense. Please don’t try this at home folks!

10. We can’t do DevOps – We’re Unique

Yes you are, you little beauty you! But you’re not special enough that you can’t adopt DevOps. I bet you’re the best developer out there; you code quicker than lighting, and deliver the sort of code that makes grown men cry with joy. No? Okay, so you’re the most awesome Ops Guy on planet. If Chuck Norris were an IT Operations Engineer he’d be want to be you. However, you and your organisation don’t have some unique factor that won’t allow you to adopt DevOps. So give it a go!

Jesse Robbins from OpsCode has some good advice for getting started;

  • Start Small – Build Trust
  • Create Champions
  • Build Confidence
  • Celebrate Success
  • Exploit Circumstance

http://www.slideshare.net/jesserobbins/cloud-expo-jesserobbinsopscode20130129b

https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/adoption_antipattern_we_re_special?lang=en

11. We can’t do DevOps – We’ve got the wrong people

Well why did you hire them? That’s right – they’re awesome! If you don’t think that, then you need to take a long hard look at yourself, then go and discover the real hidden talents in your team.

Someone told me recently that they couldn’t do DevOps because “they have the wrong developers or the wrong ops people…”. So they have developers who can’t code? I thought to myself, “my organisation has the wrong developers, people who can’t code, they run HR and Marketing!”

DevOps fosters a collaborative working relationship between Development and IT Operations. This collaboration can extend right through the organisation further enhancing working relationships between teams.

You don’t have the wrong people. You have the wrong thought process. Deal with it.

12. Collaboration when the S**T hits the fan

Ok genius. You f**ked up. So what? We all do it. But now you want your IT Operations guys out of bed at 2am to clean-up something they know nothing about. They are IT Operations engineers – not the “fixer” like Michael Clayton. Waiting until an error occurs during a deployment for Development and IT Operations to collaborate sucks.

It’s too late for this problem….. but maybe not for the next. You have your Development team and your IT Operations team talking (or swearing at 2am) with each other, but at least they are talking. Keep the dialog going. Get a retrospective review of what happened and how you can fix it going forward. If you have encountered this situation, then try and keep the dialog going with between your teams. Open the communication channels with Development and IT Operations early. There’s hope for you yet!

http://cdn.dzone.com/sites/all/files/refcardz/rc145-010d-continuousdelivery_0.pdf

– TheDevMgr

scream

DevOps does not equal “Developers managing Production”

I’ve had a few conversations lately, mainly with smaller start-ups or development houses, who tell me “yes, we work in a DevOps model”.

What they really mean is “We pretty much have no Operations capability at all, and we rely on the Developers to build, deploy and manage all of the environments from Development to Test to Production. Mostly by hand. Badly”.

As someone from a predominately Operations background I find this quite frustrating!

Operations is a discipline, with its own patterns & practices, methodologies, models, tools, technology etc. Just because modern cloud hosting makes it easier to deploy servers without having to know one end of a SCSI cable from another doesn’t mean you “know” how to do Operations (just like my knowledge of SQL is enough to find out the information I need to know monitor and manage the environment but a long way from what’s required to develop a complex, high-performing website).

DevOps means Development and Operations working together collaboratively to put the Operations requirements about stability, reliability, performance into the Development practices, whilst at the same time bringing Development in the management of the Production environment (e.g. by putting them on-call, or by leveraging their development skills to help automate key processes).

It doesn’t mean a return to the laissez-faire “anything goes” model where developers have unfettered access to the Production environment 24x7x365 and can change things as and when they like.

Change control was invented for a reason, and whilst change control has becomes its own “cottage industry” involving ever more bureaucratic layers of “management by form filling” the basic discipline remains sound – think about what you want to change, automate it if you can, test it, understand what to do if it screws up (roll back plan), document the change, make sure everyone knows when, where and how you are making the change, and make sure the business owner approves.

When I took over the Operations of a high-volume UK website about 8 years ago I spend the first 3 weekend working fighting fires and troubleshooting Production issues.

My first action after that baptism of fire was to revoke access to production for all developers (over howls of protests). Availability and stability immediately went up. Deafening silence from Development – Invitations to beers from the Business owners.

Next step was to hire a build manager to take over the Build and Deployment automation, and a Release Manager to coordinate with the Business what was going into each release, when etc. End result – 99.98% availability, with more releases, being deployed within business hours without impacting the users, and a lower TCO. The Business was much happier, and so was the Development Manager, as he was losing far fewer developer-hours to fire-fighting Production issues, and hence the overall development velocity improved considerably. Win-Win.

Was that a DevOps anti-pattern? Did I create more silos? Probably… but in a fire-fight a battlefield commander doesn’t sit everyone down for a sharing circle on how they are going to address the mutual challenge of killing the other guy before he kills you. Sometimes a command & control model is the right one for the challenge you face (like getting some supressing fire on the target while you radio in for some air support or artillery!).

That said, once we had developed a measure of stability we did move partway to a more DevOps pattern – we had developers on-call 24×7 as 3rd line support, we virtualised our environment(s) and gave Developers more control over them, and we increased our use of automation.

Organisationally we remained siloed however – we were incentivised in different ways (Operations emphasising availability, Development emphasising feature delivery), we remained in essentially a waterfall delivery model and Ops VS Dev was a constant struggle for manpower & resources. All the usual problems that the DevOps movement is trying to address.

In summary, what I am trying to get at is please don’t devalue the “DevOps” concept by saying you do DevOps when you don’t.

Unless you currently do both Development AND Operations separately, and do them well, AND you’re now trying to synthesise a better, more agile, more cloud-oriented way of working that takes the best part of BOTH disciplines… you aren’t doing DevOps!

– TheOpsMgr