High-performance IT delivery is an approach that enables cross-functional teams to continuously improve the products, process and people that are required to deliver value to the end users. If there is no continuous feedback about quality and risks, the development approach cannot be seriously called iterative, because the result of an iteration is only shippable if the stakeholders can establish their confidence based on proper information. [Tort 2019]
In this section two high-performance IT delivery models will be explained in more detail: Scrum and DevOps.
Other "models" that we have also classified under high-performance IT delivery are Lean, Agile, Kanban and Spotify, which doesn't mean you cannot use these "models" in other IT delivery models. Based on our experiences, we see that the meaning of these models and possible relationships between these models are not equally clear to everyone. For this reason, a brief overview is presented on how we regard these modelsin the section "Other high-performance IT delivery 'models'".
Scrum is a framework with which people address and solve complex problems in an adaptive manner, while delivering the highest value products in a rewarding and creative way. According to Schwaber and Sutherland, the authors of the Scrum guide [Scrum 2017], Scrum is:
- simple to understand
- difficult to master.
Scrum is a framework that creates value for the client in an Agile way. Scrum is not a process or technique for developing software products; it is a framework within which you can apply various processes and techniques.
The Scrum framework is built upon Scrum teams and their corresponding roles, events and products. Scrum assumes that knowledge arises from experience and taking decisions based on what is known. The team size could vary from three to nine people, excluding the Scrum master and the product owner. Scrum uses an iterative, incremental approach to optimize transparency and control risks.
The Scrum framework consists of roles, events and artifacts.
The Scrum team consists of a product owner, a Scrum master, and the development team. The term "development team" causes a lot of confusion because the team is not just responsible for development but for all activities necessary to deliver business value. Therefore, we prefer to refer to "team" or "Scrum team". Scrum teams are self-organizing and cross-functional. Self-organizing teams make their own choices when deciding on the best way to implement their work, instead of being instructed by someone outside the team.
Scrum makes use of prescribed events to give the team structure and regularity, and to ensure that the sprint runs smoothly. Scrum makes use of timeboxes, so that every occurrence is bound by a maximum duration, and the most important matters (e.g. highest business value, highest risks, most refined) are dealt with first. When the timebox has expired, the most important matters have been covered, and insight gives a clear indication of what is still necessary. This ensures that the proper amount of time is spent on planning without loss of value ("waste") in the planning process. The events have been specifically designed to enable transparency and to create a fixed rhythm for the team. Not implementing one of these events results in a decline of effectiveness and transparency. Scrum supports the events: sprint, sprint planning, daily Scrum, sprint review and sprint retrospective.
Many teams see a backlog refinement as a useful addition to the Scrum events.
When multiple teams have to work together, they may implement a scrum-of-scrums where a representing member of each team gathers to align between teams.
Scrum works with the following artifacts: product backlog, sprint backlog, and products ("increment"). In addition, Scrum works most effectively when a "Definition of Done" has also been formulated. Although this is not mentioned in the Scrum guide, a Definition of Ready (both Business Ready and Sprint Ready) and a Definition of Shippable are also used by Scrum teams. Burndown charts are often used by the teams for transparency regarding progress.
DevOps is a cross-functional systems engineering culture that aims at unifying systems development (Dev) and systems operations (Ops) with the ability to create and deliver fast, cheap, flexible and with adequate quality, whereby the team as a whole is responsible for the quality. Usually, other types of expertise, like Business Analysis and Quality Assurance (including testing), are integrated in the team.
DevOps is aimed at solving inefficiencies within the systems manufacturing process. A DevOps culture has an Agile mindset that can be supported/implemented by, for example, the Scrum framework.
DevOps is an elusive phenomenon. There are discussions about who is the founder of DevOps and what a DevOps delivery model should look like. To avoid this discussion, we use a "simplified" model in this book based on which most common activities are plotted.
We identify six DevOps activities: Monitor, Plan, Code, Integrate, Deploy and Operate. These activities provide excellent support to explain the integration of DevOps activities with the quality assurance and testing activities ("topics"). See "Topics plotted on the IT delivery models". Below we give a brief overview of the DevOps activities, for more in-depth descriptions please refer to other parts of this book (especially Part 3 and Part 4).
- Collect data and provide analytics. Commonly used indicators are (for more indicators please see section 'indicators'):
- Non-functional indicators
- CPU usage, memory usage, diskspace usage
- Functional indicators
- Heartbeat check, health check, metrics (e.g. http response status and http response time), auditing
- Non-functional indicators
- Inspect the performance of the CI/CD pipeline and improve where necessary to increase the productivity of the development and operations teams.
- Measure the team performance as a basis for continuous improvement.
- Collect requirements and feedback from stakeholders and customers, and use input from monitoring.
- Build a product roadmap for delivery of the pursued business value.
- Write epics, features and user stories together with the criteria to be fulfilled at the end of each DevOps activity. Of course, other ways to describe functionality can also be used, such as use cases.
- Build a backlog.
- Plan iterations (when using a Scrum board) and allocate tasks or use another approach like Kanban.
- The list of epics, features and user stories must be maintained and adapted to new insights.
- Write code for epics, features, user stories, et cetera from the plan.
- Automate processes (e.g. deployment and test automation).
- Commit code to a shared repository, that allows historical viewing, branches, versioning, and more.
- Define and run the automated unit tests.
- An important part of this activity is confidence. Developers will store code in a code manager. Besides this, each piece of software must include its own automated tests.
- The code is integrated to a deployable and testable application, the so-called build.
- Perform a series of manual and automated tests. For instance:
- run automated integration and end-to-end tests.
- run traditional – manual – user acceptance test (UAT) which must give confidence that the software doesn't fail or negatively impact other pieces of software, the acceptance criteria are met, and – possible – anomalies identified.
- run security and performance tests.
- check for changes in infrastructure.
- Release the build – automatically – into production using a CI/CD pipeline (see Chapter 6).
- When done manually: Continuous Delivery.
- When done automatically: Continuous Deployment.
- The new release is live and used by customers.
- This is where the business value is experienced.
- Create a feedback loop and use tooling with which customers can give feedback on the services.
- Use the feedback for updating the backlog.
Prerequisites that are often mentioned together with DevOps are:
- Service flow
- Cross functional
- 100% Allocated
Jez Humble, co-author of The DevOps Handbook [Humble 2016], mentioned CALMS as a conceptual framework for the integration of development and operations team functions and systems within an organization. The CALMS framework is often used to evaluate whether an organization is ready for DevOps.
Organizations embrace system thinking and a "learn fast" culture. This makes interdisciplinary and cross-functional collaboration easier. For example, business, development, quality assurance & testing, operations and architecture work together within integrated development and delivery processes.
By automating DevOps processes, these processes are anchored in the organization. From the automation of continuous integration and cloud provisioning to the automated performance of regression or performance tests.
Processes become more efficient and flexible. Firstly, it stimulates productivity. Secondly, it makes it possible to respond quickly to current customer requirements.
Measure continuously. For example, the change failure rate, mean time to recover, the total lead time and the customer responses to improvements. Measurement thus forms the basis for continuous improvement.
By sharing tools, knowledge, an architecture or code, an open culture is realized inside and outside the team. DevOps as the engine of digital transformation requires a new way of working, whereby Development & Operations go hand in hand with efficient, flexible processes supported by suitable applications. This is how the digital organization continuously learns, responds quickly to developments, and becomes and remains agile.
The main goal for an organization to implement DevOps is to enable continuous delivery of value to the end users. That is why in DevOps, a CI/CD pipeline is implemented to be able to deliver the pursued business value to the users. Continuous Integration (CI) handles possible problems caused by multiple people developing in parallel and thus introducing dependencies in the code.
CI/CD is the backbone and an enabler of DevOps. It bridges, maybe even closes, the gap between development and operations teams by automating the building, testing, deployment of applications and provisioning of infrastructure. In addition to CI/CD, there are of course other aspects (pillars) that bridges the gap between Dev and Ops.
Because CI/CD implementation is common in DevOps, Building Block "CI/CD pipelines", explains the continuous activities and discusses how to set up such a pipeline and often-used tools.