Modern agenda requires that software developers significantly shorten their development processes across all stages from ideation to release. More and more customers want their projects to be developed yesterday so that no one would be able to copy their ideas today. And when it comes to the budget, it's always (well, almost always) limited!
Developers have no other choice but keep streamlining and optimizing their software development processes, experiment and create smart workarounds to reduce customer's time to market. In many cases, to speed up milestone delivery, companies have to look beyond their development teams and source specialists from other corporate departments and 3rd party staffing agencies as ancillary or temporary workforce. And eventually it turns out that everyone (testers, programmers, analysts and managers) can work faster and be more productive on the project. The question is - how to make them do so?
That's where Agile methodologies and extreme programming have played a critical role lately, as they both help solve the issues with slow and poorly optimized development processes. They help, but only partially.
The Agile model envisions a very close collaboration between software development and testing teams driven by shared goals and values and aligned with common criteria of efficiency assessment. Agile development consists of a series of short cycles, aka iterations that normally last no longer than 2-3 weeks. Each iteration looks like a standalone project and includes all tasks required for successful milestone delivery such as planning, requirements analysis, design, programming, testing and documentation. At the end of each iteration the team discusses issues and success stories and re-evaluate priorities if needed.
As such, Agile software project is supposed to be ready for release at the end of each iteration. However, in the real life things happen slightly differently and projects don't progress as fast as the customer wants. Another reason why there're so many showstoppers in project development is that cross-functional teams work with different toolsets and aren't encouraged to share knowledge with each other on a regular basis. In the real life, each project team completes own tasks and uses different criteria to assess their team performance. For developers, these criteria include speed of coding and the number of functions executed; for QA engineers and testers, the number of identified errors and generated test cases matters the most, while for operations team the key criteria are stable system functioning and minimal number of incidents. Such a project development model often leads to conflict of interests: developers are doing their best to code faster and submit it for review before deadline, testers are taking their time to test every single element thoroughly and don't hurry much, and operation engineers don't hurry to accept the code, as any code changes create potential risks for the whole IT infrastructure. In many companies, operation teams are the weakest link that's always left behind the Agile model.
Image source: SolutionsIQ
To address the above issues, Agile evangelists launched a new methodology known as DevOps back in 2009 that aimed to foster interaction between development (Dev) and operations (Ops) teams and better integrate software developers and operation engineers with the same development project. The ultimate goal of DevOps is to help organizations build, deliver and upgrade software solutions and services faster and more efficiently. It should be noted that Agile isn't an essential precondition for DevOps implementation!
"Agile was instrumental in Development regaining the trust in the business, but it unintentionally left IT Operations behind. DevOps is a way for the business to regain trust in the entire IT organization as a whole." Clyde Logue, Founder of StreamStep
The three ways of DevOps
Way #1: Focus on efficiency of the entire system versus efficiency of a separate team or department. Focus on all business streams embedded in IT infrastructure that help create value.
Way #2: Focus on creating right-to-left feedback loops. Each initiative aims to enhance and shorten feedback to ensure continuous integration (CI).
Way #3: Focus on building corporate culture that would affect the two things:
- continuous experimentation (risks management and acceptance and lessons learned from successes and failures), and
- understanding that continuous practice and repetitions are key to mastering employee skills and competences.
According to many Intersog clients, the true value of DevOps implemented in their software development teams consists in the ability to have a full picture of your chosen software development model with consideration of absolutely all stakeholders, clearly defined processes and integration mechanisms.
I've asked Intersog's CTO Sergey Nemesh and COO Kate Goldberg to comment on DevOps in general and its role in more efficient software development in particular.
- Is DevOps suitable for any organization or are there certain types of companies that generate more value from DevOps than others?
Kate Goldberg (KG): I think DevOps can be applied successfully within any organization. Large and established brands can use DevOps to speed up software development, testing and product releases, while small companies can use DevOps to improve their culture and get all project stakeholders on the same page.
Sergey Nemesh (SN): If we're referring to DevOps as the culture of interaction between development and operations, where developers understand how systems work and have system administration skills and system administrators understand software development principles, then I'd say any company needs it. But if we're referring to DevOps as a set of certain practices and methods pertaining to visualization, containerization, and infrastructure management automation, then I'd say the company should first mature and grow so that overhead expenses for DevOps implementation would be lower than overheads for infrastructure management without DevOps.
2. What's the current level of DevOps understanding amongst our current clients?
KG: Many of our client companies (mostly non-technological ones) are still employing classical system administrators who don't know anything and don't care much about their product. Plus they're really afraid of implementing DevOps because this process is very laborious and requires the use of innovative technologies, which altogether leads to bloated budgets. You know, each company has its own specificities.
Some of our clients believe that DevOps is only good for processes automation and standardization and are only ready to put money here. But the general trend is that more and more technology-driven organizations are leaning towards DevOps and understand its values besides automation and optimization.
SN: I think it's a matter of months, not even years, that companies including our potential clients will start investing or invest more in DevOps implementation. At least that's what we always recommend our clients to do and are eager to help them with!
3. What're the advantages of DevOps for our clients?
SN: Having successfully implemented DevOps, our clients can expect enjoying the following benefits in the mid to long term:
- Automation and human error risk minimization
- Faster and easier coding and releases
- Fast feedback from end users (metrics, monitoring)
- Profit
KG: I'd also add happier and better motivated employees because DevOps helps eliminate chaos and make routine less boring.
4. Are there any disadvantages of DevOps?
SN: The key issue I can see now is not DevOps itself, but frenzy around each new technology or practice and the way people use them. Many technologies are used not out of necessity, but because it's considered sort of trendy. Also, some of our clients who claimed to have DevOps implemented before choosing to work with Intersog had internal processes that were much slower than those of non DevOps driven clients. It happened because they either started implementing DevOps on their own without bringing in any external consultancy for assistance, or couldn't allot sufficient resources for it.
KG: Unfortunately, DevOps isn't a silver bullet, and companies should be ready internally to implement it. There should be no resistance from top management (and DevOps is a huge change to handle and not each IT leader really wants to cope with it, especially the old school leaders) and shared vision of goals to be attained with DevOps.
Feel free to share your opinion on the subject matter and join the discussion in the Comments below! Or just send us a tweet to @Intersog.
