Behind The Phoenix

Behind the Phoenix

Affinito Alessandro#1

#1IT cloud engineering consultant
Italy, Rome, Oct 2019

Abstract— Interruptions, errors, and reactions drive rework, make it difficult to focus and get things done. In doing work, the goal is to build quality in, but measuring this is difficult. Where did errors slip through?
Those that develop and deliver quickly are better able to experiment with ways to increase customer adoption and satisfaction, but what if the thing you have to deliver is a working architecture and not a single product?

DevOps is almost eleven years old now [1]. Statistics proving its efficiency can be found everywhere, and if efficiency is not enough, employees in high-performing DevOps teams were 2.2x more likely to recommend their organization as a great place to work [2].

Here I try to sum up a few of those statistics, highlighting the issues that can be found in big corporations that are still skeptical about Agile and its derivatives.

Keywords— DevOps, Waterfall, Rework, Automation, Delivery

  1. Introduction

According to Forrester Research [3], only 13% of organizations have implemented DevOps, with 50% piloting or conducting proof of concepts. Another 27% plan to implement DevOps within the year, while 9% are interested but have no plans to adopt DevOps within the next 12 months.

IT departments grow in 2018

Findings from a fall 2017 survey [4] identified people-related issues as top barriers to DevOps adoption. Some 19.7 percent listed limited budgets as the top barrier, 9.4 percent cited company culture, 7.9 percent said limited IT skills, and 7.4 percent listed lack of executive buy-in.

Low performers are struggling to keep up, widening the gap [5].

Low performers are doing the worst on all dimensions in terms of value-add vs. non-value-add time. Respondents who agreed that they met the following characteristics were 23 times more likely to be in the elite group than those in the low performing group [5]:
1. On-demand self-service: consumers can provision computing resources as needed, automatically
2. Broad network access: capabilities are available through heterogeneous platforms
3. Resource pooling: Provider resources are pooled in a multi-tenant model, with physical and virtual resources dynamically assigned
4. Rapid elasticity: capabilities can be elastically provisioned and released to rapidly scale
5. Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability

Some company introduces just a few of the theoretical concepts found in Agile methodologies like Scrum, to sell themselves as modernized companies. But ignoring the technical shift and the culture transformation will create a false sense of agility, and increase the technical debt over time. What they could do, instead, is to develop proficiency in two steps of the transformation [6], for the first couple of years at least:
1. Focusing on work visibility, stopping to think as software layers and team self management (Scrum, Kanban)
2. Delivering faster with higher quality (Extreme Programming, DevOps).

  1. ISSUES

High performers do significantly less manual work across all vectors, spend more time doing new work, and spend less time remediating security issues or defects than their low-performing counterparts. Because they build quality in, they spend less time fixing problems downstream, freeing up more time to do value-add work.

Another issue to consider is the technology needed for automation tasks. In consultancy corporations, tools consist mostly in proprietary software managed by specialized teams, with vertical knowledge. When a product is not available or not sellable to the customer, a custom code could be developed in isolation by a tech specialist or from a remote development team.

DevOps maturity is often measured in deployments per day, which becomes a hard metric to collect when most of the work is done by different teams in terms of configuration more than actual developments (CRM, SQL, DB REST services, ERP..). Even when a custom development is done in a SaaS, this will be hardly versioned since people working on these tasks often don't come from a development background, and/or a CI/CD pipeline is not expected from the SaaS management. Best practices suggests to always leave the product as standard as possible, but during the project this will hardly remain true.

State of the art

Here there are some of the current issues that I think are slowing the most Agile adoption:
- dev, ops, security and QA are distinct teams, rarely co-located
- dev and ops teams use a common set of tools but don't have visibility into each other's work
- project prioritization is mostly scheduled with a minimum planning cadence of weeks, firefighting increase over the time
- deployment stability is far above deployment throughput
- manual testing with environments separated from development
- late delivery on production environments
- low transparency [7] at the lower gerarchies.

To-Be
Anyway there are some low impact changes that could be adopted in the next few years to start a real shift to a more efficient way of development.
Indeed it would be feasible to start delivering by single business functionalities, reducing the iteration time slot from 7/8 weeks to 3/4, where the last week should be dedicated to defining a small share of SIT, business test cases and UAT with the customer.
An inter-team, Kanban fashioned, dashboard could be used to make work visible across all teams.
Remote support should be more engaged with videoconferences, right after support requests, explaining in detail the context of the requested fix/new feature.

Far far away

The following are DevOps or Scrum methodologies I see hardly doable in less than five years:
- Site Reliability Engineers doing incident management and practice ChatOps for conversation-driven development
- Incidents and alerts automatically routed
- Officially dedicated time for experimentation of new techniques and processes
- Chaos Engineering: experimenting in production in order to build confidence in the system's capability to withstand unexpected conditions.
- DevSecOps: automating some security gates to keep the DevOps workflow from slowing down [8].
- Data Ops.: as big data [9] and streaming architectures become more popular people will want and need more data logistics in their organizations because of ML adoption.

III. CONCLUSIONS

DevOps requires some fundamental rethinking. People feel comfortable in the way they’ve been working and not everyone is a change agent.
I believe a shift is possible if coming from the top management, but it should be mandatory for managers and team leaders to attend it, officially reserving time to train and workshop to shield them from the daily firefighting.

The gap between high and low performers seems to continue to increase. I think in a few years we will come to the point that big corporations could not ignore devOps anymore, but being late on the market, their only chance will be to acquire smaller companies that have become an elite in these years.

REFERENCES

  1. John Allspaw, Engineer, Researcher, Founder, 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr - https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
  2. State of DevOps Report - CIO summits 2016 - Dora - https://www.ciosummits.com/Online_Assets_Puppet_2016_State_of_DevOps_Report.pdf.
  3. Dave Bartoletti, https://go.forrester.com/blogs/predictions-2019-cloud-computing/.
  4. Press Release PR Newswire https://markets.businessinsider.com/news/stocks/pensa-survey-finds-top-devops-barriers-involve-cost-complexity-and-legacy-it-1002996792.
  5. State of devops - Dora - https://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State%20of%20DevOps.pdf
  6. Diana Larsen, James Shore, The Agile Fluency Model,https://martinfowler.com/articles/agileFluency.html
  7. Ken Schwaber and Jeff Sutherland, https://www.scrumguides.org/scrum-guide.html#theory
  8. Red Hat, What is devSecOps, https://www.redhat.com/en/topics/devops/what-is-devsecops
  9. Martin Fowler, Thinking about Big Data, https://martinfowler.com/articles/bigData/

Further readings

  1. Bartosz Jedrzejewski, The journey to DevOps, Driving value in the public sector https://govtechglobal.co.uk/wp-content/uploads/2019/09/The-Journey-to-DevOps-White-Paper.pdf, 2019
  2. Chasioti, K., BizDevOps: A process model for the Alignment of DevOps with Business Goals, https://dspace.library.uu.nl/handle/1874/383196, 2019
  3. Jez Humble, What is Continuous Delivery?, https://continuousdelivery.com/
  4. Martin Fowler, Software Delivery Guide, ,https://martinfowler.com/delivery.html
  5. Gene Kim, The unicorn Project, 2019 https://itrevolution.com/book/the-unicorn-project/