Sharing IT Best Practices with youSharing IT Best Practices with you
Many organisations already use Agile Scrum and wonder whether or not DevOps adds value. Other organisations question themselves, what is next? Is DevOps a hoax? This article answers these questions with a business case of using DevOps and a prediction of the future.
A business case is a way of defining the benefits and costs to start a new initiative. The risks are taken into account as well since the counter measures of risks have to be paid in time and money.
The concept of Agile Scrum is defined in The Scrum Guide. It consists of three roles (product owner, scrum master and development team). The characteristics are the used time boxes and close interaction with the business. The rituals are the sprint planning, daily stand-up, sprint execution, review and retrospective. The quality controls are the Definition of Ready and the Definition of Done. The result is a potential shippable product.
First the benefits of DevOps are listed and argued. Secondly, they are compared to Agile Scrum. Other Agile approaches are not included in this article. Agile Scrum is chosen since it is commonly used, even by DevOps teams. This article finally gives an outlook to the future developments.
Agile Scrum can be used within DevOps for the development process. But DevOps is more than Agile Scrum. The following points are a benefit on top of Agile Scrum.
Ad 1. Collaboration
Working in a DevOps team means that developers have much more contact with the operations people. They learn from each other working collocated. In business DevOps teams the information management employees are also joined in the DevOps team, this adds even more value. So, the collaboration of the Agile Scrum team is about joining development skills in one team and DevOps is about joining all the skills of the complete lifecycle of a service into one team (information, application and infrastructure).
Ad 2. Affinity
Affinity is about working for the same business target while one team does service its own targets as well. While joining the skills of the complete lifecycle in one team finally the advice of Deming adopted: “Break down the walls between your IT departments”. By combining the effort of all teams for one or more services to the customer it is much easier to achieve the service norms and thus the business target.
Ad 3. Scalability
The demand for scalable ICT services is very strong. This includes not only the scalability of software but also the infrastructure. DevOps enables the scalability by addressing the technical aspects of the ICT services much better than Agile Scrum. Operations is part of Development and together they define the total construction of the service.
Ad 4. Automation
The fundament of the DevOps is the deployment pipeline. This pipeline is managed by using the Lean principles of reducing waste from the start (requirements) of the pipeline towards the end (deployments). Many parts of the pipeline are automated to gain speed. Within Agile Scrum teams often best of breed solution are chosen which do not collaborate together. Also, many manual approaches like the Scrum Board are manually maintained. One of the basic principles of DevOps however is to have the deployment pipeline to run as smoothly as possible by automate it as much as possible.
Ad 5. Faster deployment
The Agile Scrum process results in a potentially shippable product. The DoD of DevOps however is a running service. The deployment is always at the end of the DevOps cycle. This deployment is much faster than in the Agile Scrum approach which may result in many sprints not releasing software to have the service running. An example is an organisation that has a sprint of one month and a release twice a year due to the fact the Enterprise Service Buss (ESB) is required and that the software is released only twice a year. Within DevOps this is not an accepted way of working, done is live.
Ad 6. Faster feedback
Feedback means that any negative aspect of the produced service is given back to the source. In DevOps this is accomplished by the use of the Continuous Everything (Continuous Monitoring, Continuous Testing, Continuous Integration, Continuous Deployment / Delivery). One of the most important “Everything” is Continuous Integration where the developer has his/her own local environment to check-in before checking in on the central environment. But also, Continuous Testing where the build is self-testing and running regression tests. In addition, the feedback of information management and infrastructure specialists is a great aid in developing new and adjusted service provisioning for the business. Finally, the feedback from the customer who consumes the delivered services much faster will give also faster response.
Ad 7. Less failures
Due to the fast feedback failures are detected earlier in the deployment pipeline. But also, the downtime of the failures that are detected only in production is shorter due to the automatic reverse to the prior version. Also, DevOps allows Canary releasing where only a few number of users are receiving the new service.
Ad 8. Control
Where Agile Scrum focusses on the development of software products, DevOps is about the delivery of running services in production. The Ops of DevOps is about control. Where many Agile Scrum teams creates a higher tense between Dev and Ops, the DevOps approach is to explicitly integrating both worlds. So instead of pushing Ops to delivery as fast as developed, both teams work together to develop and deliver. The benefit is not only a better affinity, also the control of Ops is merged into the development. Where in many Agile Scrum teams the control of ITIL®, ASL® and BiSL® were omitted, with DevOps we see again the countermeasures of risks applied.
Ad 9. Faster Time to Market (TTM)
The approach of business DevOps, where the business is represented by information managers in the DevOps team themselves is boosting the TTM. Nowadays organisations start even to integrate the DevOps teams with the business. IT departments are shut down and the IT people integrate into the business. The business has to speed up to be able to compete in the market. The DevOps approach has the characteristics to accomplish this.
Ad 10. Cheaper
Finally, the costs involved to produce new or adjusted services is much cheaper using the DevOps approach. This is accomplished by the combination of the nine other benefits. The costs are reduced by:
Defining the business case also means that the risks of using DevOps have to be taken in consideration. Important risks to manage while introducing DevOps are:
Ad 1. Wrong transformation strategy
There are many strategies to reshape organisations. A simple approach is depicted in figure 1. The question is which approach fits the best with the culture of the organisation, what benefits and risks are included in each of them. A combination may be chosen as well. The costs of choosing the wrong one is huge since the complete transformation may be delayed or even collapse.
Ad 2. Actually, not integrating Operations
Many organisations choose to still have two teams Dev and Ops and linking them together by a linking-pin. This Ops linking-pin has to spend some time with the Dev team. The risk is that there is no strong collaboration and no affinity build up. Less knowledge is shared, resulting in extra repair costs and delay of TTM.
Ad 3. Neglecting information management
Having not the information management knowledge available in the team means slower feedback and less affinity. The risks are that the wrong interpretation is made of the business requirements. This results in loss of time, money and quality.
Ad 4. Technical Debt, Organisation Debt and Information Debt
Paying interest for debt may lead to the loss of the business case for DevOps. Technical debt must be compensated with refactoring of software to take away the errors. This may cost huge amount of money and time. Organisational debt must be compensated by organisation restructuring which may affect the DevOps teams velocity. Information debt (see article 13) requires complete reengineering legacy which is produced by starting DevOps teams who neglect to register the correct meta-date. These debts are to be paid and the longer its take the more they costs to correct. So, the short term benefits will soon be forgotten and the expected ROI will not be achieved. Extra investments have to be made.
Ad 5. Missing affinity
Successful DevOps means realizing business targets. Collaboration is often seen as enough business focus, but working together with all disciplines is key. Otherwise time and money is lost.
The future cannot be predicted. Though trends can be recognized. The following trends are visible in the market:
Based on the business case as described above, DevOps is not a HOAX. Reversing DevOps means going back to where? Can you disintegrate a deployment pipeline and gain time and money? Can you gain profit to not having collaboration and affinity? The answers are no. In the last 40 years many methods, models and frameworks have been seen, practiced and left. DevOps however is not a method or a model. It is a movement that fits into the current business demands. For sure the world will change as well the way the business operates. However, investments in DevOps will last longer than all the initiatives of the last decades.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.