devopsy.kinsta.cloud

Tag: agile

Clearing through the app backlog clutter

Development and operations teams today are under more pressure than ever to develop apps the business needs to make its workforce productive, its partners connected to the resources they need, and to deliver the apps to the marketplace that will make it competitive.

The number of production hours for development is at a precious premium as demand for apps soar and resources remain tight. According to Gartner, the demand for enterprise mobile apps alone will be a $40 billion market by 2016.

Of course, the inevitable happens and the list of designed applications gets backlogged. They get caught-up in budget requests that drag on, and then they get caught in the long list of requested apps in the development queue. A recent survey commissioned by PaaS provider OutSystems found that 85% of enterprises surveyed had an app backlog, with about half having backlogs of 10 to 20 apps.

App Backlog, agile and DevOps

Sure, development and operations teams move as quickly as they can to meet the enterprise demand for new applications, but when there is any deep app backlog, there is the potential for business costs when it comes to lost opportunity, untimely product development, and future missed sales. In a time when agile IT means competitive advantage, any amount of latency that can be cleared from the application backlog is crucial.

Agile development approaches and agile IT departments tried to remedy some of these issues, but didn’t go far enough. Fortunately, DevOps picks up where agile left off in the evolution of enterprise development. And in the face of agile IT, continuous integration, continuous deployment, and the rise of DevOps – operations, development, and infrastructure bottlenecks become minimized – and infrastructure and applications move more quickly, and existing applications are iterated more swiftly.

Of course, DevOps itself, can help to accelerate app deployment, in addition to continuous integration and continuous deployment efforts. And all of the associated deployment automation tools and deployment processes are essential to eliminating manual waste so teams can focus on pressing business demands. This waste can include time burnt on manual process, manual testing, and the configuration of the software development environment.

DevOps-driven organizations have shorter app backlogs. A recent CA Technologies study in fact found that organizations embracing DevOps report a 17 to 23 percent improvement in certain business outcomes, such as increased revenue, and faster time-to-market.

Cloud architectures and easier to master development languages also help, not just infrastructure services, but also platforms that help to free up operations teams and developers to focus on the applications that need to get out yesterday.

Even with DevOps practices in place and automation running full throttle, the business development teams still find themselves having to make difficult choices about which apps to build and deploy. Not all of these apps will survive, in fact, many apps will go unused and dormant. This means that a lot of time can be lost developing apps people don’t want to use, or are too cumbersome to bother to use.

Turning to the Minimum Viable Product

In addition to DevOps, development teams are also turning to approaches such as the Minimum Viable Product (MVP) as a way to help identify apps that have real user demand and those that do not. Essentially, the MVP app is an app that consists of only the essential. The MVP provides the essence of the app and what users need to get done and no more. The MVP is a potent way to provide the essential attributes of an app to see if users embrace it before building the app out further. If the app is used, new features can be added over time.

Not everyone is convinced that the gains made against app backlog aren’t necessarily illusion. David Mortman, distinguished engineer, says “DevOps and MVP both have the ability to create the impression that you are solving backlog issues. This is because in both cases you are enabling the development organization to get that first release as early as possible and then to keep iterating it and adding features as the dev group goes,” he says. “This however may not get you to a particular defined endpoint any faster since regardless of the organization there are always resource limitations.”

Still, “One advantage of DevOps and Agile is that they let you interweave development cycles so multiple apps can be worked on faster and each can be incremented more quickly. They also make it easier to adjust priorities between apps more quickly and more quickly identify apps that aren’t meeting the business needs and either deprioritize or eliminate the app before overinvesting in its development,” Mortman adds.

There’s no doubt, based on my discussions with enterprises, app backlog repeatedly comes up as a serious challenge to competitiveness. But by embracing continuous integration, deployment, and MVP development, organizations can go a long way to help clear through, at least the initial stages of their app backlog. What is your organization doing to help clear app backlog? We’d like to hear your experiences and lessons learned.

December 16, 2014
Organic engineering team a must for long term DevOps success

Last month I was out in Las Vegas at CA World. While there I had a chance for a one-on-one meeting with CA CEO, Michael Gregoire. In our discussion Gregoire told me that one of the things he is most proud of in his time at CA is the fact that he has instilled a culture of an “organic engineering team”. According to Michael you can’t truly be a successful software company (and just about every company is a software company today) or a DevOps empowered organization without this organic engineering team.

I don’t think any CEO would be against having a high functioning engineering team. But what does Gregoire mean by organic? My understanding is that he is talking about the team being internal. Not outsourced or acquired, but built, grown and nurtured within the organization.

So what does that mean for outsourcing? When software is eating the world, can you have a successful business when you can’t develop and operate your own software? If DevOps is a key ingredient in a high functioning IT organization, can you outsource DevOpst?

In the case of DevOps, with cultural change being such an important ingredient in the recipe, it would seem that you can’t outsource culture, it has to be organic. But if you can’t outsource cultural change and DevOps, can you import it? Can you graft a culture of DevOps into your organization?

This was exactly the conversation I had with another person at CA World and with several people thereafter. At CA World I had a chance to speak with Rohit Antao, a Principal at PwC who heads up many of the DevOps engagements that PwC is involved in. Rohit shared with me that in many of the IT advisory and transformation engagements that the firm undertakes instilling a DevOps friendly culture and process is just about obligatory.

I asked Antao how they go about grafting a DevOps branch onto the main trunk of a company’s IT tree. Like similar paths I have heard from IBM and others, he explained that their blueprint is usually to pick a few small projects to build success upon. From these small projects where DevOps is injected they seek to expand this DevOps way deeper and deeper into the organization. The idea is that after some months the DevOps way of doing things take root. It becomes organic to the organization.

Actually this kind of engagement involving coming in and transforming IT from within, then leaving behind a team and new way of doing things while you move on to the next engagement was something I first saw put in action by a company called The Feld Group. Charlie Feld in many ways pioneered modern CIO models. He and his firm would come in and turn an IT department on its head, hire in some new leadership and when things were on track leave to the next engagement. But leave behind a solid team and culture.

This type of engagement is not only the purview of IBM, PwC and other big name firms. I had a chance to speak with Laszlo Szalvay, VP of SolutionsIQ. They are an Agile Enterprise Solutions company who today announced the acquisition of Boson-based Big Visible to form the largest agile consultancy focused on enterprise transformations.

Laszlo explained to me that in his view there are two kinds of IT transformation consulting engagements. You can tell them apart by a cup of coffee. In one type of engagement the consultant tells the customer to grab a cup of coffee and leave the consultant to his work. The consultant will let the customer know when finished. In the other type of engagement the customer and the consultant sit down over a cup of coffee and plan how they will work together to accomplish the goal which ends when the consultant hands the keys back to the customer after they have worked together to instill in the case of SolutionsIQ a culture, processes and tools for an agile development team.

Funny how though the names, faces, technology and tools change, the process stays the same. The same thing the Feld Group was doing 25-30 years ago is what these companies are doing today. You can graft a new culture and a new way of doing things into organizations. If planned well and done correctly you can grow your own organic engineering team.

Can you outsource DevOps though? Can you have DevOps-a-a-Service? I am not sold on that one. I guess someone will have to convince me on that before I buy into it.

December 11, 2014
Detours Ahead: Overcoming DevOps Challenges

Saying that you’re interested in DevOps is another way of saying you’re interested in change. That’s what DevOps promises any organization. No matter the problems a company is trying to solve or the goals it’s trying to reach, DevOps depends on a willingness to embrace some big changes. Sure, it can help you streamline software deployments, but it requires shaking up a company’s usual processes and routines. As we all know, change can be complicated, so before your organization transitions to an agile culture, it’s best to prepare for the likely challenges ahead.

Breaking Old Habits for Continuous Delivery

Many of the procedures we follow at work each day are second nature, and what’s familiar carries a certain comfort with it. Even when we realize a more efficient process is within reach, old habits are tough to break. For an organization that employs hundreds, any change can be a challenge.

And DevOps offers no shortage of challenges. It entails overhauling a company’s deployment process, its communication patterns, its department structures and even the roles of individuals on a team. Yet unless an organization is willing to let go of its old habits, the benefits of continuous delivery won’t ever be achieved. When acclimating people to this new procedure, it’s important to convey that the old procedure – one team throwing code over the wall to another one – will be left behind for actual collaboration in which Development, Operations and possibly other departments work together, not just in silos.

Getting Past the Resistance to Change

Encountering some reluctance to change will be natural, and a smooth transition depends on making everyone aware of why DevOps will be a big step forward. This includes communicating what the advantages will be for individuals, departments and the company as a whole. With an agile plan in place, greater efficiencies will become the norm, and a team will have the ability to spot and fix problems more quickly, so 3 a.m. phone calls to the system admin won’t happen anymore. Once managers through C-level folks are aware of these potential advantages, resistance will gradually turn into acceptance and enthusiasm.

Combating the Myths and Rumors

Many think DevOps is only for the well-known unicorn companies, such as Etsy and Facebook, or that it’s an exact science that will produce the same results for everyone. Some even believe the rumor that DevOps only works with certain operating systems. The truth is that continuous development can take place anywhere as long as the company culture is right. As detailed in the Rackspace-sponsored e-book, The DevOps Mindset: Real-World Insights from Tech Leaders, many DevOps practitioners went through their own uphill climbs to become more agile, and they have the firsthand experience to resolve many popular misconceptions.

“You don’t have to be in Silicon Valley to embrace the DevOps culture,” says James Kenigsberg of 2U. “In fact, many new firms these days have a bad habit of building shiny technology because it is shiny, which goes against the DevOps principles of communication and transparency.”

Jeff Hackert of Chef dispels the myth that DevOps is a one-size-fits-all solution. “It is not a set of proscriptions or a recipe that will give you a defined best practices outcome,” he explains. “Your best practice is the collective wisdom of the very smart people you’ve hired to solve your problems. And if what you have is a siloed or broken environment, you want to increase the communication, not impose new rules.”

Getting Automated Without a Struggle

When an organization is considering DevOps, they may find that the opportunities for efficiency not only involve employee collaboration, but technology as well. Most IT departments would jump at any chance to save time when it comes to coding procedures, and automation is a means of making this happen. By offloading these processes to an automated system, people can tackle other tasks, and businesses that release several deployments a day can greatly simplify their rollouts. For those who might not be familiar with the ins and outs of automation, receiving some guidance from a trusted IT provider can be a good first step. Finding an advisor to guide your initial automation efforts can prevent the expense of hiring a DevOps engineer with automation knowledge.

Finding a Path Around DevOps Obstacles

Every company’s DevOps strategy will be unique, and every company’s plan for overcoming challenges will be just as unique. Whatever the circumstances, communication will be crucial to any adoption, as it ensures that everyone understands why such a change is necessary. Getting acquainted with the success stories out there will dispel any myths circulating among team members, and stumbling blocks can be avoided by the understanding that familiar silos will be replaced by more efficient collaborations.

Despite its challenges, DevOps can be the catalyst for a variety of improvements, from productivity to employee morale. Those who are the most successful at being agile will not only have the right culture in place, but be able to negotiate the challenges that DevOps has in store for those ready to embrace change.

November 19, 2014
Nationwide banks on DevOps to drive towards Continuous Delivery

The Financial Services industry is fast moving, highly regulated and customer-centric. The general perception in our industry is that any change in processes implies risk and delay, neither of which we can afford. But at the same time, we are faced by the mammoth task of needing to continually introduce new products and services to stay competitive and cater to the growing needs of our customers. This is unthinkable without a fast software delivery lifecycle, as our business is highly dependent on technology. The best way to accelerate software delivery in a complex, fast moving environment like ours is to adopt a DevOps approach.

As a speaker at a number of events, I have discussed the ongoing transformational journey at Nationwide and shared our approach with other enterprises who want to understand how they can follow suit. I recently had the opportunity to co-present with Hayden Lindsey from IBM at the DevOps Enterprise Summit (Oct 21 – 23) hosted by Gene Kim. You can watch a replay of our joint session Patterns for Enterprise Success: The DevOps Journey at Nationwide below.

From humble beginnings as a small auto insurer serving the farming community, Nationwide has grown into one of the world’s largest insurance and financial services companies. Like many businesses today, we saw that we needed a better way to respond to changing market requirements and regulations, to increase speed to market, and to support new channels for customer interaction. Mobile, cloud and big data technologies were further raising the pressure on us to facilitate rapid digital innovation. What we required was not just a solution, but a change in culture (the way we look at things), processes (the way we do things) and tools (the technology we use). DevOps gives us the capability to achieve all of this—and more.

The immediate challenge was to achieve these changes by leveraging our existing heterogeneous tool suite. We partnered with IBM DevOps, which has played a significant role in our success. We were already working towards agile transformation. With IBM’s support, we were able to use the DevOps approach to application development and delivery across our distributed and mainframe environments. While a DevOps approach as supported by IBM enables organizations to start anywhere based on their specific needs, we at Nationwide decided to address all four adoption paths across the software delivery lifecycle: Steer, Develop/Test, Deploy and Operate.

DevOps enabled our IT department to perform continuous integration of its code and continuous deployment into its development environment several times a day. Teams can also perform acceptance testing of customer requirements within the same iteration as development. IT managers can show their internal customers, in near-real time, what developers are producing. This capability became a game-changer as we became more agile as a business and more responsive to customers. We achieved a 50% improvement in code quality, a 70% reduction in system downtime and were able to move 58% of our teams into the top quartile in key productivity measures. I believe that, the more agile we can be from an IT perspective, the more agile the business can be in terms of going from the development of an idea to the deployment of a customer-facing product.?

The next step in our DevOps journey is to build on the gains generated by the adoption of Agile and Lean practices across the entire SDLC. This is where technologies such as TaskTop and UrbanCode come to the fore by providing the integrated continuous flow and visibility needed for a continuous delivery infrastructure. By creating this delivery highway, we are giving Business Areas the ability to deliver as fast as they need to based on their own determination of cost, risk and value. Time-consuming manual processes based on out-of-date information are replaced with automated deployment policies that use real-time information synched from systems of record. The combination of dashboard and dials gives the business the visibility and control to drive at a much faster pace than is currently possible. Lack of trust in development outcomes has historically been an impediment to speed. Our new automated approach is giving us the confidence to move faster to serve the business without compromising the quality of our deliveries.

IBM was a great partner for us here as they share our support of the open standards approach, which gives us the ability to work with a heterogeneous set of tools, across the full lifecycle, allowing us to determine holistically the best tools, the best architecture and the best approach to meet our goals of high quality, high productivity and faster delivery for our customers.

By balancing speed, cost, quality and risk, DevOps is helping us increase our capacity to innovate. That in turn helps us get to market faster and be more competitive. I mentioned during DevOps Enterprise Summit that the phrase “time is the new currency” resonated with our goals of optimizing the path from “concept to customer value”. We need to ensure we don’t let it slip through our fingers. We have long been dependent on manual processes, but in this new digital age they are only going to slow us down. This is the time to be agile, competitive and pragmatic. It’s time for all of us to break the age-old shackles and embrace the opportunity for change that DevOps represents.

About the Author

Carmen DeArdo is the Director of Application Development Tools and Technologies at Nationwide Insurance. Carmen is responsible for driving continuous delivery utilizing DevOps, Lean and Agile techniques across Mobile, Distributed and Mainframe and other technologies. This includes recommendations and implementation of technologies used across the development life cycle (e.g. IBM Rational tool suite, open source technologies).

November 12, 2014
DevOps with purpose: ACT-ing with greater agility

This is Part Four in a four-part series. In Part One, I focused on the critical first step of defining DevOps with a purpose by thinking about DevOps in the context of your organization’s applications. In Part Two, I provided four tips to fostering a DevOps culture in your organization. In Part Three, I discussed the role of tools and how they can amplify (or constrain) individual and team abilities as well as work across teams.

In this final fourth part of the series, I’m going to weave the three previous topics of (A)pplications, (C)ulture, and (T)ools together and will show how you can ACT with purpose to start your own DevOps transformation. Your DevOps strategy should incorporate all three aspects of applications, culture, and tools. Given the breadth of those three areas, it’s easy to feel overwhelmed from the start. Here’s a tip I learned from a mentor a few years ago. Whether you are a CEO, VP, or team leader, smart leaders set a vision (often at least two or three years out) and then they make small decisions every week with the goal of generally moving the organization or team in the direction of the vision over time.

I recommend first that you set a vision for DevOps as it relates to your Applications, your Culture, and your Tools. Let’s begin with Applications. In the first article, I shared the concept of the pace-layering model developed by Gartner. To set a DevOps vision for your applications, place each of your current applications into one of the three layers – system of record, system of differentiation, or system of innovation. Then, do the same thing for any applications you are planning to add to your portfolio.

With that context, specific to your organization, formulate a strategic vision for how DevOps will apply to your systems in each layer. Will you seek to have DevOps principles for continuous integration and continuous delivery in place for all of your systems of innovation, and if so, by when? How about for systems of differentiation? Will DevOps be the norm for each of those applications or just some, and by when? Then ask yourself the same questions about your systems of record.

Next, turn to your culture. In Part two, I discussed the importance of baselining the degree of collaboration you have between the business, dev, and ops as well as how you view work (in workstations or in end-to-end flow terms). Then I challenged you to incentivize people to modify their behavior both with respect to their roles and as individuals. With this as context, define your DevOps cultural vision. What does collaboration between the business and development look like in the future? What does collaboration look like between development and operations? How about between dev, QA, and ops? And let’s not forget security.

How will you recognize when your culture is optimized for flow? For example, I recommend documenting a set of indicators that you can measure at regular intervals (e.g. quarterly). Here are three good ones. How much work-in-process (WIP) do we have for Application X today vs. how much was there a quarter ago? What is the average time it takes from the definition of a requirement to its deployment in production today vs. a quarter ago? How often did we make updates to Application X in production this quarter vs. last quarter?

Now, let’s consider tools. Take a baseline of the tools you are using today for each step of the typical DevOps tool chain from requirements management to source code control and bug tracking through to build management, automated testing, configuration management and deployment. And don’t forget project management tools too. What is the state of your tool investment in each of these areas? Do you have gaps? Do you have multiple tools in the same area, and, if so, is that okay or do you want to standardize on one? Do your tools vary based on the applications they are used with (see pace-layering discussion above)?

Then take an inventory of your collaboration tools across dev and ops. Are you still mostly using email and sharepoint sites? What role does instant messaging play in your dev and ops teams today? What about conference calls and meetings? Once you’ve baselined where you are today, set a vision for where you want to be in the future. Are you looking to reduce the need for conference calls and meetings, and if so by how much (time or average number of participants)? What issues are you running into around email and IM communications that need to be addressed and also for SharePoint? Have you looked at the emerging class of DevOps collaboration tools and concepts such as ITinvolve and ChatOps? What role can they play in streamlining communications, keeping people informed, and presenting information to staff so they don’t have to go hunting around for it in dozens of systems or call more meetings?

With this as background, define your DevOps tools vision by setting priorities for filling identified gaps and rationalizing existing investments, then set a general target time frame for each area.

Now that you’ve set a vision in each area – (A)pplications, (C)ulture, and (T)ools, it’s time to ACT. I recommend you first pick one or two applications to begin your DevOps journey. Ideally, they should be applications that are visible to the business and where you can lay claim to the impact DevOps can have on business goals like time-to-market and responsiveness to customer needs.

Once those applications are identified, take an inventory of all the people across your organization (including the business), those responsible for the development and delivery of the applications. Develop a specific plan for how you will educate those individuals on DevOps principles (e.g. attend DevOpsDays, read The Phoenix Project, read a sets of articles and watch a set of seminar or demo recordings), and also develop a specific plan for how you will incentivize behavior changes for their roles as well as what is expected of first line managers to take individual personalities, skills, and experiences into account.

Let me also stress that you shouldn’t ignore the people who aren’t participating in this first DevOps effort as part of your communications. Educate them as well, for example through an all-hands meeting and an email from leadership. Explain why the company is investing in DevOps transformation, why these applications have been chosen, and your long-term vision across Applications, Culture, and Tools to realize the transformation. Help them understand where the organization is going and why, and how it may impact them in the future. Avoid the perception that “the best people were picked for this and you are not among them” or that this group of people is being given license to do things that others can’t (e.g. make changes outside of the standard change management process) – otherwise, you risk reducing morale, good people leaving, and even sabotage of your DevOps efforts.

Once you’ve completed the above, map the relevant tools you have in place today for managing the development and delivery of these applications as well as the tools on your vision roadmap defined above that will be added or rationalized in the next six months.

By following the above recommendations, you will now have an action plan for the near term and a long-term vision you can use to guide daily decisions to move you closer to that vision. Lastly, don’t be rigid about your short-term plan or long-term vision, recognize that everyone is learning, including you, and that one of the key principles behind DevOps is the feedback loop!

Thank you for reading this series. I hope it’s been useful to you on your DevOps journey. If you have a question or just want to share a comment, you can do so here on devopsy.kinsta.cloud or send me an email at matthew@itinvolve.com.

Best wishes on your DevOps journey!

November 12, 2014
Waterfall to Agile to DevOps: The State of Stagnant Evolution

DevOps is all the rage. The hot IT buzzword intended to heal the expanding divide between development and IT operations is being used to sell a range of services and solutions to struggling development shops and enterprises, even though DevOps can’t be sold – it’s a cultural shift that nurtures under a strong leadership.

Prior to DevOps, Agile methodology generated a similar hype that forced businesses to spend millions of dollars in revamping organizational hierarchy, deploying new solutions and hiring self-proclaimed expert consultants. The original values and principles of Agile development to deliver working solutions in small and iterative chunks were quickly forgotten. The methodology was only implemented during development phase and created backlogs for operation teams that failed to push product releases fast enough.

(more…)

November 11, 2014
The DevOps Culture Cocktail

As I have written in previous posts, I believe that IT has accumulated decades of cultural debt that is now due. We are a young industry that grew up in silo neighborhoods, each with it’s proprietary practices, language and population of like-skilled specialists. Left unchecked, the resulting “framework culture” contributed to IT’s cultural debt and is partially the motivation behind DevOps.

The goal of DevOps is not to undervalue or replace the frameworks that are in place. On it’s own, DevOps is not a framework – in fact, successful DevOps relies on combined effect of best practices such as Agile, Lean and ITSM. By recognizing and adapting the best of each, IT can formulate a potent recipe for enhancing performance and increasing customer satisfaction.

So let’s belly up to the bar and mix ourselves a DevOps Culture Cocktail by taking the best guidance from the top shelf of each of the frameworks and practices.

Ingredient 1: ‘Git R Done’ Scrum

Scrum is the most prominent of the Agile frameworks and with good reason: it focuses on getting work “done” in manageable increments while reducing work in progress.

Pair it with a Kanban Board

While deceptively simple, Kanban is a powerful method for visualizing workflow, identifying constraints and keeping a team focused.

Ingredient 2: Automation

There is a lot of debate around the balance of automation use in DevOps, but there is no dispute that automation and metrics play a key role in successful DevOps.

Ingredient 3: IT Service Management

ITSM is the deployment’s “ever after”. Agile and repeatable service management processes lead the way to stable continuous delivery and increased flow.

Ingredient 4: Lean

Let’s make it a skinny by creating more value for customers with fewer resources and less waste.

Ingredient 5: People

The most important ingredient. DevOps relies on the way people think, behave, interact and trust their colleagues. According to Lloyd Taylor, “You can’t directly change culture. But you can change behavior, and behavior becomes culture.”

Finally, add a splash of common vocabulary and a shot of the alcohol of your choice and you now have a DevOps Culture Cocktail! Serve it daily, share it with your neighbors or sip it while reading a good book like The Phoenix Project. It does get more potent with age.

I recently had the opportunity to present the DevOps Culture Cocktail Party at Fruition Partner’s FruDevCon Conference. One of the attendees, a hobby mixologist, formulated her vision for a signature DevOps Culture Cocktail during my presentation. We asked the hotel bartender to mix it up, passed it around and a new cocktail was born. Here goes:

The DevOps Culture Cocktail
1 part pear vodka
1 part St. Germain
1 part Chardonnay
2 parts simple syrup or 7 up

Top with a spear of pineapple and a cherry.

Improvement recommendations are of course welcome. Could this become a staple at all future DevOps events?

October 9, 2014
Right-Picking the First Project to Go DevOps On

One of the hardest things to do when starting a new initiative is picking the right project to work on. Should I start with App A? App B? Does it really matter as long as I get started on this DevOps thing and prove its value to management?

Yes, actually, it might.

If you think about it, one of the reasons you’re doing DevOps in the first place is not just because it’s cool (it is, of course, but that rarely flies with the business guys) but because it’s going to add value in one or more ways by improving time to market, reducing risk and lowering operating costs. If the project you choose to go DevOps on isn’t capable of showing those benefits (or isn’t capable of showing those benefits in a reasonable time frame) then you might just be choosing the wrong one to start with.

So how do you choose? Well, how about starting with an app that’s being developed using agile methodologies?

According to the “8th Annual State of Agile” survey from VersionOne 88% of respondents were practicing agile development, which means you shouldn’t have a hard time finding one.

Except, you might if you aren’t paying attention. A high adoption rate doesn’t necessarily mean a high saturation rate, however.

Dig a bit deeper into the survey and you’ll find that agile isn’t used for every project. On the contrary, there’s a good distribution of agile and traditional (waterfall ) methodologies being used. While over half of the respondents are using agile to manage more than 50% of projects, the other 48% are using some other methodology.

Which offers some interesting strategies for how to get started with DevOps on the other side of the wall (that’s you, in operations land).

On the one hand, the projects most in need of improved velocity in deployment (time to market) are likely those being developed using agile methodologies. The aforementioned survey validates that approach, with the top reason cited for adopting agile being “accelerate time to market.” The general premise of agile is fast, frequent updates, making the need to deploy into production a more pressing priority. Choosing an app that’s being developed using agile methodologies means you’ll be able to practice, refine, and optimize the processes as you work to automate the deployment. Because of the frequency with which agile-developed projects tend to need deployment, this gives you the opportunity to practice similar techniques on your automation and optimization.

You’ll be able to automate individual tasks and test them thoroughly before moving on to the next one and the next one and the next one, until you’ve got the process orchestrated (yes, Virginia, there is a difference). You’ll then have ample opportunity to optimize the process, finding redundancies or inefficiencies in the way information is gathered and disseminated into the process. Optimization of the process means greater efficiency, especially if you can knock out those all important wait times between tasks.

The key here is that you have to know which projects are being developed using agile methodologies, and which aren’t. That means communicating with developers. And not just by sending an e-mail and asking for a list, but really talking to them to understand which projects the business would benefit from improving time to market. Getting an app that is the vehicle for competitive advantage to market faster seems a bigger return on investment than the app used by just a few people for non-critical purposes. You’ve got to dig in and determine which agile projects need agile deployment the most, and then decide where to dig in.

This is not to imply that less frequently deployed apps will not benefit from agile. They most certainly will, though the benefits that DevOps brings to those apps are more about stability and consistency than they are those derived from improving time to market.

What’s important is to decide what your goals are with DevOps and what benefits will be worth the most bang for the buck (cause it ain’t going to be cheap in terms of time investment). Getting DevOps on an infrequently but mission-critical app can reduce the risks associated with rusty processes and improve stability in general. Automating the deployment of such applications can certainly save time and resources that can be redirected to agile projects in need of greater deployment velocity.

But if you’re looking to show value and return on investment, you’ll likely want to choose one of the agile-developed projects that already exists and needs some attention. Not only because it’ll show value faster, but because it’s releasing frequently enough that you’ll actually get the opportunity to refine (and one hopes optimize) your automation and orchestration.

September 25, 2014
My Little Operations: DevOps is Magic
Bear with me, it will all make sense in the end.

If you aren’t familiar with My Little Pony: Friendship is Magic (because you don’t have a child who watches it over and over and … well, over) let me sum up for you:

There’s a pony who knows something horrible is coming. She wants to stop it. She’s instead sent by management to make friends, which seems to her to be ridiculous in the face of a looming catastrophe. When that catastrophe happens, she and her new “friends” (her coworkers) set off to find the elements of harmony – the only thing that can save the world. But lo and behold, evil destroys the elements. Or so it appears. See, it turns out that the friends are the embodiment of the elements of harmony and through their friendship they create the most powerful element of them all: magic. Together, they are strong enough to defeat the evil and restore harmony to the data center. Err, I mean, to the pony world.

If we take this and apply it to operations, you should start seeing some common themes. Primarily, you might note that, like magic, the ultimate goal of DevOps – agility – can only be “achieved” by the collaborative efforts of the other elements of operational harmony, namely predictability, repeatability, composability, consistency and stability. It isn’t a tangible “thing” you can buy, it doesn’t come in a can, it can’t be delivered by Amazon.

These elements combine and, when practiced cooperatively, create a new element: agility. Which is a significant goal of DevOps based on a variety of surveys. Oh, it’s always stated a different way: we want to improve the time to market, increase frequency of deploys, reduce downtime due to errors, etc… but in general, these all fall under the need to enable the same level of “agility” in operations (and the network, but that’s a different discussion) as is present in application development today. Fast and frequent change to match application (and business) changes. Agility.

But agility, like magic, can only be achieved through friendship (or as we’ll call it, collaboration). That’s because agility requires a variety of separate concerns (qualities) to come together in concert before it can be realized:

Agility (DevOps)
- Predictability (time to deploy, important for planning)
- Repeatability (of process to other applications)
- Composability (reuse of steps in other processes)
- Consistency (important for maintainability and trust in process)
- Stability ( of the overall infrastructure )
That’s why it’s important not to look at DevOps as a set of tools. There are multiple facets to DevOps that can be enabled by tools and enhanced by tools and even monitored by tools, but DevOps is not the tools themselves any more than the elements of harmony were the gems the Little Ponies sought. The real magic of DevOps is the agility created by collaboratively working together to bring each of the elements into operations. Without stability, have you achieved agility? Or is it really chaos?

If you can’t repeat the process (apply it to other applications) have you really achieved agility or just strictly codified a single deployment? If the process isn’t consistent, and gives different results have you realized an agile environment or anarchistic one?

These elements are necessary to achieve real agility of operations, and those elements can only come about in a cooperative environment in which they all work together.

DevOps, so it seems, is magic after all.
September 16, 2014
Collaboration in Progress: Making DevOps a Reality

Everything on your company’s DevOps checklist is accounted for. It’s got the vision and the talent. It’s identified the problems and mapped out a solution. It’s got a culture that allows the flexibility that such a plan requires. Now’s the time to put the plan into action and let the benefits begin.

The truth is that it may not be that simple. A great plan won’t mean anything unless everyone understands how to achieve it. And whatever a company’s DevOps strategy consists of, collaboration is the key to making it a reality.

Collaboration is at the heart of DevOps. It’s even conveyed in the phrase itself. No matter the size of your company, this new process of teamwork and transparency relies on combining strengths between Development and Operations to achieve goals that otherwise wouldn’t be possible.

Breaking Silos with a Full-Circle Approach

With one department responsible for writing code and another responsible for implementing it, silos can naturally form as each group focuses on its job. This kind of structure is what commonly gives rise to software deployments taking longer than they should and even little or no communication taking place between the two departments.

DevOps has come about as an antidote to these kinds of siloed situations in which inefficiencies and a lack of teamwork are the norm. Yet for DevOps to take off, both Development and Operations have to participate fully and understand that collaboration requires equal cooperation from both sides. Such collaboration has to take place not just at certain stages, but throughout the life of a project. When each team is invested in the effort by providing feedback, helping identify future problems and continually learning from day-to-day deployments, a company has a great chance of seeing benefits from these new collaborative efforts. Without complete buy-in from everyone, the process will never get off the ground.

The Evolution of Collaboration

Just as DevOps is about moving beyond the assembly line process of software development, the concept of collaboration itself is evolving. DevOps-style teamwork can consist of more than breaking down the silos between different teams. In an agile infrastructure, team members can wear different hats and swap responsibilities depending on the demands of the day. Instead of a scenario in which people work on single specialized tasks without any interaction with the larger group, you’ll have contributors who can play multiple roles within a team and understand how this boosts productivity for the entire company, rather than just a single department. It’s possible that a team member can function as a developer one day and then work on deployments another. Through DevOps, an organization can advance beyond one-dimensional departments and one-dimensional contributions.

Real-World DevOps Teamwork

For many within the IT industry, DevOps is already a working reality. Breaking silos and becoming more agile are goals for companies that know how increased collaboration can help their business. A good source that lays out some first-hand experiences of DevOps practitioners can be found in the recently published Rackspace e-book, The DevOps Mindset: Real-World Insights from Tech Leaders. It features interviews with IT experts who discuss what led them to adopt a DevOps approach and recommendations for those interested in a new agile approach to software deployment.

When discussing the importance of agile teamwork, James Kenigsberg of 2U remarks that, “To achieve true DevOps collaboration, you need your employees to really think and act as one, not just be merged together in name only.” As a provider of online university programs, 2U faces a huge demand for quick, dependable deployments and underwent a transition to increase teamwork at the company. “We had to flip the model,” Kenigsberg explains, “from the idea of personal heroics and siloed responsibilities to real, cross-functional collaboration.”

Jim Kimball of fund administrator HedgeServ reiterates this cross-departmental approach. “Repeatability and scalability are our business,” he explains. “The capabilities that DevOps gives us directly enable this by encouraging collaboration within the organization to come up with better solutions.”

Forging a Partnership Between Dev and Ops

Assembling a skilled and talented group that will be the envy of your industry is the ideal every company would like to have. If you’re able to gather a team that’s the IT equivalent of the X-Men, it’s not enough to just assemble that talent and assign them siloed roles. Without frequent teamwork, not only will company goals become difficult to achieve, but solving problems will be nearly impossible.

When Development and Operations see themselves as working in partnership with each other, the foundation for greater collaboration will be in place, and company goals, such as greater speed to market, increased productivity and an all-around agile performance, will be within reach. With the right mentality, DevOps can be an evolutionary step in company functionality and reach new levels of efficiency that otherwise wouldn’t be achievable.

September 16, 2014