How to get your ops folks to understand agility (make them read this, for starters)

Agility is the key to success in today’s busy, mobile-first application world. It’s no longer a matter of spending months developing an application and rolling out the red carpet for one major release. The reality is that apps must be released quickly and iterated frequently so one can learn from user feedback and meet business expectations.

Many of us are familiar with agile development, a system of processes and tools that ensures the efficient development of high-quality apps. But that’s only half of the story. Once development is ready to release an application, how do we support the next stages of the release process with equally agile operations?

Agile delivery

The basis of agile delivery is when development and operations teams actively collaborate to seamlessly build and manage an application throughout its lifecycle. Several businesses have already proven just how far this approach can carry them. NYSE Euronext, in the midst of its merger, reduced their two-year web development cycle into an iterative, two-week production cycle by adopting agile delivery. They were able to release 40 new business-critical apps in 18 months as a result.

Pinterest credits release automation and DevOps smarts with being able to successfully support its 5,124 percent explosion in growth last year. Facebook releases apps twice a day and processes up to 300 changes per day for one billion users, perhaps representing the pinnacle of agile achievement.

A crisis of collaboration

However, although they are striving for more frequent releases, most companies don’t yet have the processes and tools to support agile delivery. Development and ops teams still grapple with ongoing misunderstandings because they don’t have shared visibility and accountability for an application’s success once released into production. In fact, collaboration issues are still so serious that the leading causes of application failure can be traced back to them. These include failed software upgrades, the inability to scale to meet unforeseen demand, resource exhaustion and configuration errors, according to research from Carnegie Mellon University.

All of these issues have lead to a phenomenon of blamestorming between development and operations teams. Seventy five percent of ops teams admit that development perceives them as a roadblock, or only somewhat supportive of agile development, while 72 percent of ops professionals say that development is not supportive of their goals.

Three steps to agile delivery

As big as this challenge may seem, it is not insurmountable. The solution involves bringing down the invisible wall that has traditionally separated development and operations. In its place, build a bridge of automation and collaborative workflow, the foundational components to agile delivery. This involves establishing tools and processes that maximize shared visibility and transparency, while diminishing the likelihood of errors through handoffs, as well as maintaining the security and control of the production of the production environment.

I’ve seen companies succeed when they started with three components and then built up their agile delivery from there. These components are automation, shared visibility and troubleshooting.


Automating deployments reduces the chance of error when development teams pass code and instructions to ops. In an ideal world, developers can specify the exact components that are needed for their app in a self-contained package that incorporates all of the necessary application prerequisites. The automation process enables all of these requirements to be applied as part of the application’s release package.

In the case where an application encounters significant errors, the other key element to automate is a rollback capability. Here, what a team needs is a controlled change process where the option exists to revert to a previous version with all of its associated extensions and configurations. Ideally, this process can be applied from the operations side in a simple series of clicks.

Shared visibility

Shared visibility provides the foundation for collaboration once an application has successfully moved into production. This enables a developer to know whether his app is performing or behaving in a different manner in production than it did in the dev/test environment. Without this insight, the operations team may be unaware of unusual application behavior and impending challenges.
However, there is also a question of control. The key is to find a way to give developers access to the information they need for troubleshooting and to understand an app’s behavior, without giving them hands-on access to the production systems (think “read only” visibility without the ability to change settings).


The third crucial area is troubleshooting. This is the most common cause of blamestorming between dev and ops teams.

The key here is that developers need access to production debugging information in a controlled manner, and a troubleshooting toolset so they can understand what happened on the production system. Ideally, with the visibility mentioned above, a developer can actually see why an error occurred, and avoid unnecessary experimentation to try and replicate the error.

This means going beyond ops sharing screenshots of application error pages, and finding a way to record major errors in an application’s code execution for later analysis by the developer.

Agility that goes beyond development

Organizations that embrace agile development while relying on disconnected operations processes are making the painful discovery that much of the value gained from agile development is negated. Today’s iterative development approach requires special attention to the operations and delivery side of applications. Once a business starts with these three foundational elements, they can build and refine their agile delivery even further, placing a focus on advanced application monitoring and continuous performance and scale, which I’ll discuss in my next post.

Andi Gutmans is CEO and co-founder of Zend Technologies. Founded in 1999, Zend was instrumental in establishing PHP. Today, Zend helps others create and implement back-end infrastructure for mobile and web applications. Zend Server and Zend Studio are deployed at more than 40,000 companies worldwide.

Original article published on VentureBeat

The following two tabs change content below.

    Andi Gutmans

    CEO and Co-founder at Zend Technologies
    • David Stockton

      I’ve definitely seen this. The “blamestorming” (never heard that before, but it’s a good one) and resulting stalemate definitely grinds productivity to a halt. In the places I’ve worked where that wasn’t happening, automation wasn’t in place so there was a longer cycle in getting changes pushed up. We’re working towards continuous delivery/deployment but I still feel we’re a long ways out and a lot of that is due to a lack of effective communication between all the teams required to get a product out the door.

    • spabby

      I have no opinion on this, but want my points.

    • ctankersley

      Agile delivery is very hard, and can be a time consuming process. It’s well worth the effort though.

    • Jacob Fogg

      My real question is, how can you apply this to a small team. Two developers and support that doubles as a qa team. I know practices like these can help even us, but I am constantly questioning if the extra weight can be offset by by the Benefits gained.

    • Aaron Saray

      Switching to agile is fine and dandy, but how do you get the rest of the company to support it? I work in a company that expects that IT delivers a full product. Stake holders request a product but shy away from being responsible for it (really great system, actually – I want this, and if I’m wrong, it’s IT’s fault for making it crappy).

      I would honestly like to see articles that help programmers convince the company to support fast iterations – if I released iterations like this, my company would freak out and I’d be having to look elsewhere (I love my company, it just has room to grow…). I bet a lot of these things would be solved in the dev-ops world much easier if given the support of the sales/support/marketing/owners of the products and sites.

      Like I said, I’d like to see more help from those who work in IT supporting business that isn’t just about web products… it’s easy to say what ‘should’ happen when your whole company is based around the technology you’re suggesting best practices for. What about those who use the technology to support other business?

    • Michelangelo van Dam

      Agile is awesome and can really speed up projects, but just like everything in life it’s not a one-size fits all solution to every project out there.

      Sometimes it’s important to know the different approaches to project management to know when and how to apply them for the projects you come across.

      If I can I would go for an agile approach, but most of the times I just have to deal with waterfall projects because the nature of the project, the company or the way things are done.

    • Stefan Koopmanschap

      Agile practices support your development process, especially in product-oriented environments. I’ve yet to encounter a product-oriented environment that failed to implement agile. In product-oriented organizations, it’s relatively easy to get the whole organization to join the agile workflow. It takes them perhaps a couple of months, but they will soon realize the advantages.

      Now the real problem is with project-oriented environments. This is where I’ve seen agile fail over and over. Especially the tough relationship between the sales-team and development-team(s) makes this extremely hard to implement. A close cooperation between sales and development is essential, and support from (upper) management is critical to make this work. The beauty is that when it *does* work, the advantages in a project-oriented organization seem to be even bigger than with product-oriented organizations.

    • Cal Evans

      Another great example of this is Brian Moon is in charge over there and iirc, they release 20-30 times a day. (I know…nuts)

      Good article.


    • Faraz Ahmed

      The “blamestorming” context made me chuckle. Have witnessed this myself so many times.

      However, agile development is not applicable in all the scenarios. If you are working on some project and you know exactly what you need to do (For example: You’ve already done a couple of similar projects before), waterfall model might be the right choice.

    • Daniel Rhodes

      It’s great that this article – and others at the moment – talk about bridging and automating the “hidden” layer between development and operations. I’ve always suspected that this layer existed, but I’ve never been able to vocalise it so neatly myself!

      I couldn’t agree more that easy and automated rollback is key. I’ve worked on products where all of the above points *except* for automated rollback have been in place, and it really goes a long way to actually negate a lot of the agile devOps benefits.

      A nice little article.

    • Sharon Levy

      I enjoyed reading this article. Agile sounds like the optimal way to go in terms of being productive. However, the article points out that in order to implement this style of project management, there needs to be certain processes if there is to be a real collaboration between IT and developers. The challenge is how to convince management to make changes to processes that they are happy with since they may fail to see any need for a change in the status quo.

    • Asgrim

      I think the things that are important about Agile is not the workflow, but the side-effects it produces. Automating deployments (and builds!) is a really important step that we took to streamline our process. Where I work, we don’t label ourselves with a particular model like “Waterfall” or “Agile” or “Scrum” or anything – we just get the job done, and get it done with maximum efficiency. If we spot something inefficient, we fix it.

      The other important point is simply to communicate effectively with your “Ops” team at all stages of application development – just talking about things helps massively.

      The other side-effect of Agile is openness and communication, which we have in common, and while do have a waterfall-like development process (plan carefully, collaborate, discuss, develop, sign off (x2), code review, deploy), we deploy constantly (similar to GitHub – several deployments per day usually). We deploy “per feature”, rather than in batches – it allows us to quickly pinpoint bugs.

    • Lucas Maliszewski

      Agile is ok, we have a similar approach in our company, either that or scrum. In other words, it is a lot better method for building applications than waterfall.

    • jcarouth

      Where I work we practice the concept of being able to be agile. Our philosophy is to not let tools and process get in the way. We have automated everything related to getting code from developer workstations through qa, acceptance, and out the door to production but we don’t yet support continuous deployment, we have weekly releases. I think the important thing to take away is there is not a right answer. There is not a one solution to rule them all. You have to weigh what works for you and your team and approach it in a pragmatic way.

    • Christian Wenz

      I just love the term “blamestorming” :-) Agile works extremely well in many cases, but never forget: if you have a hammer, every problem looks just like a nail.