What is DevOps?

DevOps and Agile

Yes. Agile methodologies are based on agile software development processes. These agile processes are iterative and undertaken by cross functional teams who are empowered by their leaders to deliver software. DevOps applies agile processes to the release, configuration and deployment of software.
Digital Transformation encompasses digital customer experience and re-organisation of the enterprise, in order to ensure competitive product positioning that leverages internet and mobile platforms. DevOps is the engine that delivers the executable code at pace, as well as the ongoing support for new customer experiences.
DevOps is the continuous delivery of prioritised value to an organisation.
Agile generally refers to software development and, when practised properly, leads to the Continuous Integration (CI) of code. Standard agile processes such as Kanban or Scrum have roles such as Product Owner and Scrummaster, and standard ceremonies including the daily standup, reviews, retrospectives and estimation sessions. DevOps covers the rest of the Software Development Lifecycle (SDLC), from CI through to the final deployment and monitoring of the features that are successfully integrating to master and, from there, through automated test, configuration, release and deployment processes.
A DevOps engineer is a member of a Delivery team who is tasked with delivering software features into production at pace. The team will have all the necessary skills and tools to achieve this objective, including automation fixes.
A Development team is a group of engineers or developers who write code for the same set of features or product. They or may not undertake some unit testing but frequently they will pass their work output to a test team. Development teams will almost certainly practice some form of Continuous Integration but unless managed properly the frequency of the merges to master will be slow. This gives rise to substantial amounts of rework as release to production approaches. This rework causes too much context switching for engineers and their productivity drops significantly. It is at these times that technical debt will often accrue. Development teams are often associated with waterfall ways of working.
There is no one single definition of a Delivery Team. If, however, your definition of done is “working successfully in production” then you can conclude the following: A self organising Delivery team has all the resources it requires to get it done. This includes an agile process(eg Scrum) and CI, pipeline automation and application performance monitoring. Often the SRE team will build and maintain the pipeline but the Delivery team then owns high priority repairs to the pipeline because their focus is to get code into production and they need all the resources they can get to do so. The flow of work is as follows: Product Owners groom the backlog and prioritise the next pieces of work to be undertaken; this work is then broken into the code, test, configuration, release and deployment (automation) tasks to push code onto the staging or deployment platforms of choice; then, once deployed, it is monitored to ensure the feature is delivering the value that the business has set as its hypothesis for success. This process is followed iteratively, starting with a Minimum Viable Product and continuing until features no longer add the value. The Delivery team may well continue to own this product but the balance of skills required to maintain the end product will change from code cut to code repair and pipeline maintenance, which may or may not be undertaken by the SRE team. See below for definition of SRE.
The concept of a DevOps team is generally considered an anti-pattern. When organisations embark on a DevOps journey they will often be working in silo’s such as development, test etc. And when DevOps concepts are first mooted they will form a new team to bring in new skills for tasks such as provisioning infrastructure through coding tools like Chef or Puppet. Or building automations with tools like Jenkins. The DevOps team has the advantage of creating some safe space for engineers to learn but invariably the DevOps team turns into a bottleneck between development teams and operations teams. The development teams are looking for release scripts and the operations teams are looking for deployment scripts. You can read more about this topic in our case studies for Ryanair and the Daily Telegraph.
  • More responsive to market conditions
  • Faster delivery of value adding features
  • Reduced change failure rate
  • Faster removal of features not adding value
  • Elimination of cost through replacement of routine manual tasks with automated equivalents
  • Increased security through the ongoing execution of automated security processes
  • Reduced risk of change failure in production
  • Reduced Mean Time to Repair
  • Opportunity to move to utility cloud platforms
Change management in the context of DevOps means that people will need to change how they work day to day, due to a rapid progression in operational deployment techniques. The amount and pace of change required depends on how fast the business needs to respond to market changes. Some of the topics that are addressed in change management include:
  • New team structures and or re-organisation of IT
  • IT engagement with the business/customers
  • Agile ways of working, also known as new ways of working
  • Servant leader models
Often referred to as the most difficult part of any journey, DevOps culture refers to new ways of working. Companies’ IT departments don’t change their culture overnight. What can change is how people interact with one another and that in turn impacts culture.
A Site Reliability Engineer (SRE) team owns the centralised functions that DevOps teams need in order to get it done. This typically means building the pipeline automations and level 2 and 3 repairs. Security troubleshooting and monitoring are also key components. Google SREs are defined as engineers who spend at least 50% of their time building automations. Value Stream Mapping is A useful tool for creating a backlog of processes that are in need of some automation.
A pipeline is a set of automated processes that allow DevOps and SRE teams to reliably and efficiently compile, build and deploy their code to their production systems.
Continuous Development is CI combined with automated test and release to pre-production environments.
Continuous Development plus automated deployment is Continuous Delivery.
This means the automation of security as much as possible into the CD pipelines. In addition, many Delivery teams will have a security champion who is a satellite for the SRE security expert. The champion “owns” security at agile ceremonies and ensures other team members are aware of security as features are rolled into production.

DevOps Public Training Courses

As often as we can, once we have at least 5 persons in attendance.
In city centre locations such as hotels or specialist training rooms in London and Dublin.
Yes if you have at least 5 attendees. Please check DevOps private training.
Yes. Our trainers are certified by the DevOps Institute, g2g3 and Atlassian.
Not less than 5 and no more than 12.
For DevOps foundation there is a .pdf which is a 30 minutes read.
09.30 to 16.30.
Yes and please specify any dietary requirements on your enquiry form.

DevOps Private Training Courses

We need at least 5 attendees and up to 12.
Yes, if there is a suitable room.
Yes. Typically this is the case but it can depend on the number of candidates and training room location.
It varies depending on the level of commitment required by the mentee. Our rates start from €450 per session.
Typically a mentor meeting takes place once a month but again that can depend on the nature of the engagement.

DevOps Licenses

Our day rates start at €850 ex VAT.
We offer a free half day assessment of your Jira/Confluence implementation each year when you renew your licenses through Daysha DevOps. We offer 30 days’ credit. We offer a local contact on the phone.
There are two typical engagements. Where a company has not used the tools at all, except to download and play with them, we offer our fastrack which is designed to do as the solution name suggests. This gets you up and running with a good set of basics. The other engagement is where a company has been using the product for some time but is running into the Jira dilemma. There are many ways to do one task in Jira and directing our clients to the optimal path is a service we provide.
There are over 3,000 add-ons and we have a passing familiarity with perhaps 5 or 6 of these. We do understand the various ways in which add-ons are integrated into the Atlassian core products and we can assist you with this.

DevOps Solutions

We typically scope a Fastrack to cover just one SDLC. Many organisations will have multiple products and release trains but our objective is to build one workflow to support one product. This allows your team to upskill on the job and bring new processes and tools to other SDLC’s in your organisation. Fastrack will cost between €5,000 and €10,000 ex VAT.
It is difficult to get all parties together, but with sufficient forward planning to lock in people’s diaries and a genuine commitment from senior management to Continuous Delivery it can be done. The challenge we address is that software delivery teams are siloed and can be unaware of interdependencies until we get all relevant parties in the same room at the same time.
The DevOps Pipeline Workshop day is free. If the customer decides to seek proposals based on our one day workshop we then charge for writing these documents and any associated pre-sales activities.
The feedback from our customers is that they do not want to pay to acquaint solution providers with their SDLC. They have often engaged consulting organisations who take three or four days to gather sufficient data about their build and release processes before they can propose improvements. Our solution is to gather relevant stakeholders together in one room for one day and ensure we have scoped the workshop so that we can address one product or one release train and identify solutions quickly. Only the initial workshop is free. Thereafter we charge for writing proposals and for delivering solutions.
No fewer than 14 and no more than 25 persons can attend our DevOps Simulation.
Yes. We run a free public taster twice per year.
People who need to get moving quickly on their DevOps journey. People who prefer to learn on the job rather than in the classroom.

Are we missing a question?

Please contact us and submit your question.