module I

Introdution of DevOps
1.1 Introdution of DevOps
1.2
DevOps is basically a combination of two words- Development and Operations.
DevOps is a culture that implements the technology in order to promote collaboration
between the developer team and the operations team to deploy code to production
faster in an automated and repeatable way.
Why DevOps?
The goal of DevOps is to increase an organization’s speed when it comes to
delivering applications and services. Many companies have successfully implemented
DevOps to enhance their user experience including Amazon, Netflix, etc.
Facebook’s mobile app which is updated every two weeks effectively tells users you
can have what you want and you can have it. Now ever wondered how Facebook was
able to do social smoothing? It’s the DevOps philosophy that helps Facebook ensure
that apps aren’t outdated and that users get the best experience on Facebook.
Facebook accomplishes this true code ownership model that makes its developers
responsible that includes testing and supporting through production and delivery for
each kernel of code. They write and update their true policies like this but Facebook
has developed a DevOps culture and has successfully accelerated its development
lifecycle.
Industries have started to gear up for digital transformation by shifting their means
to weeks and months instead of years while maintaining high quality as a result. The
solution to all this is- DevOps.
How DevOps is different from Traditional IT?
Traditional IT has 1000s lines of code and is created by different teams with
different standards whereas DevOps is created by one team with intimate knowledge
of the product. Traditional IT is complex to understand and DevOps is easily
understandable.
DevOps Lifecycle
DevOps lifecycle is the methodology where professional development teams
come together to bring products to market more efficiently and quickly. The structure
of the DevOps lifecycle consists of Plan, Code, Building, Test, Releasing, Deploying,
Operating, and Monitoring.
1.2 Agile Model
The meaning of Agile is swift or versatile."Agile process model" refers to a
software development approach based on iterative development. Agile methods break
tasks into smaller iterations, or parts do not directly involve long term planning. The
project scope and requirements are laid down at the beginning of the development
process. Plans regarding the number of iterations, the duration and the scope of each
iteration are clearly defined in advance.
Each iteration is considered as a short time "frame" in the Agile process model,
which typically lasts from one to four weeks. The division of the entire project into
smaller parts helps to minimize the project risk and to reduce the overall project
delivery time requirements. Each iteration involves a team working through a full
software development life cycle including planning, requirements analysis, design,
coding, and testing before a working product is demonstrated to the client.
 Phases of Agile Model:
Following are the phases in the Agile model are as follows:
1. Requirements gathering
2. Design the requirements
3. Construction/ iteration
4. Testing/ Quality assurance
5. Deployment
6. Feedback
1. Requirements gathering: In this phase, you must define the requirements. You
should explain business opportunities and plan the time and effort needed to build the
project. Based on this information, you can evaluate technical and economic
feasibility.
2. Design the requirements: When you have identified the project, work with
stakeholders to define requirements. You can use the user flow diagram or the high-
level UML diagram to show the work of new features and show how it will apply to
your existing system.
3. Construction/ iteration: When the team defines the requirements, the work begins.
Designers and developers start working on their project, which aims to deploy a
working product. The product will undergo various stages of improvement, so it
includes simple, minimal functionality.
4. Testing: In this phase, the Quality Assurance team examines the product's
performance and looks for the bug.
5. Deployment: In this phase, the team issues a product for the user's work
environment.
6. Feedback: After releasing the product, the last step is feedback. In this, the team
receives feedback about the product and works through the feedback.
Agile Testing Methods:
 Scrum
 Crystal
 Dynamic Software Development Method(DSDM)
 Feature Driven Development(FDD)
 Lean Software Development
 eXtreme Programming(XP)
1.3 Scrum
SCRUM is an agile development process focused primarily on ways to manage
tasks in team-based development conditions.
There are three roles in it, and their responsibilities are:
o Scrum Master: The scrum can set up the master team, arrange the meeting and
remove obstacles for the process
o Product owner: The product owner makes the product backlog, prioritizes the
delay and is responsible for the distribution of functionality on each repetition.
o Scrum Team: The team manages its work and organizes the work to complete
the sprint or cycle.
eXtreme Programming(XP)
This type of methodology is used when customers are constantly changing
demands or requirements, or when they are not sure about the system's performance.
Crystal:
There are three concepts of this method-
1. Chartering: Multi activities are involved in this phase such as making a
development team, performing feasibility analysis, developing plans, etc.
2. Cyclic delivery: under this, two more cycles consist, these are:
o Team updates the release plan.
o Integrated product delivers to the users.
3. Wrap up: According to the user environment, this phase performs deployment,
post-deployment.
Dynamic Software Development Method(DSDM):
DSDM is a rapid application development strategy for software development
and gives an agile project distribution structure. The essential features of DSDM are
that users must be actively connected, and teams have been given the right to make
decisions. The techniques used in DSDM are:
1. Time Boxing
2. MoSCoW Rules
3. Prototyping
The DSDM project contains seven stages:
1. Pre-project
2. Feasibility Study
 3. Business Study
4. Functional Model Iteration
5. Design and build Iteration
6. Implementation
7. Post-project
Feature Driven Development(FDD):
This method focuses on "Designing and Building" features. In contrast to other smart
methods, FDD describes the small steps of the work that should be obtained
separately per function.
Lean Software Development:
Lean software development methodology follows the principle "just in time
production." The lean method indicates the increasing speed of software development
and reducing costs. Lean development can be summarized in seven phases.
ADVERTISEMENT
ADVERTISING
1. Eliminating Waste
2. Amplifying learning
3. Defer commitment (deciding as late as possible)
4. Early delivery
5. Empowering the team
6. Building Integrity
7. Optimize the whole
When to use the Agile Model?
o When frequent changes are required.
o When a highly qualified and experienced team is available.
o When a customer is ready to have a meeting with a software team all the time.
o When project size is small.
Advantage(Pros) of Agile Method:
1. Frequent Delivery
2. Face-to-Face Communication with clients.
3. Efficient design and fulfils the business requirement.
4. Anytime changes are acceptable.
5. It reduces total development time.
Disadvantages(Cons) of Agile Model:
1. Due to the shortage of formal documents, it creates confusion and crucial
decisions taken throughout various phases can be misinterpreted at any time
by different team members.
2. Due to the lack of proper documentation, once the project completes and the
developers allotted to another project, maintenance of the finished project can
become a difficulty.
1.5 Agile Development Models
In earlier days, the Iterative Waterfall Model was very popular for completing a
project. But nowadays, developers face various problems while using it to develop
software. The main difficulties included handling customer change requests during
project development and the high cost and time required to incorporate these changes.
To overcome these drawbacks of the Waterfall Model, in the mid-1990s the Agile
Software Development model was proposed.
The Agile Model was primarily designed to help a project adapt quickly to change
requests. So, the main aim of the Agile model is to facilitate quick project completion.
To accomplish this task, agility is required. Agility is achieved by fitting the process
to the project and removing activities that may not be essential for a specific project.
Also, anything that is a waste of time and effort is avoided.
The Agile Model refers to a group of development processes. These processes share
some basic characteristics but do have certain subtle differences among themselves.
Agile SDLC Models/Methods
 Models: Crystal Agile Software Development Methodology places a strong
emphasis on fostering effective communication and collaboration among team
members, as well as taking into account the human elements that are crucial for a
successful development process. This methodology is particularly beneficial for
projects with a high degree of uncertainty, where requirements tend to change
frequently.
 Atern: This methodology is tailored for projects with moderate to high uncertainty
where requirements are prone to change frequently. Its clear-cut roles and
responsibilities focus on delivering working software in short time frames.
Governance practices set it apart and make it an effective approach for teams and
projects.
 Feature-driven development: This approach is implemented by utilizing a series of
techniques, like creating feature lists, conducting model evaluations, and
implementing a design-by-feature method, to meet its goal. This methodology is
particularly effective in ensuring that the end product is delivered on time and that
it aligns with the requirements of the customer.
 Scrum: This methodology serves as a framework for tackling complex projects
and ensuring their successful completion. It is led by a Scrum Master, who
oversees the process, and a Product Owner, who establishes the priorities. The
Development Team, accountable for delivering the software, is another key
player.
 Extreme programming (XP): It uses specific practices like pair programming,
continuous integration, and test-driven development to achieve these goals.
Extreme programming is ideal for projects that have high levels of uncertainty and
require frequent changes, as it allows for quick adaptation to new requirements
and feedback.
 Lean Development: It is rooted in the principles of lean manufacturing and aims
to streamline the process by identifying and removing unnecessary steps and
activities. This is achieved through practices such as continuous improvement,
visual management, and value stream mapping, which helps in identifying areas
of improvement and implementing changes accordingly.
 Unified Process: Unified Process is a methodology that can be tailored to the
specific needs of any given project. It combines elements of both waterfall and
Agile methodologies, allowing for an iterative and incremental approach to
development. This means that the UP is characterized by a series of iterations,
each of which results in a working product increment, allowing for continuous
improvement and the delivery of value to the customer.
All Agile Software Development Methodology discussed above share the same core
values and principles, but they may differ in their implementation and specific
practices. Agile development requires a high degree of collaboration and
communication among team members, as well as a willingness to adapt to changing
requirements and feedback from customers.
In the Agile model, the requirements are decomposed into many small parts that can
be incrementally developed. The Agile model adopts Iterative development. Each
incremental part is developed over an iteration. Each iteration is intended to be small
and easily manageable and can be completed within a couple of weeks only. At a time
one iteration is planned, developed, and deployed to the customers. Long-term plans
are not made.
Steps in the Agile Model
The agile model is a combination of iterative and incremental process models. The
steps involve in agile SDLC models are:
 Requirement gathering
 Design the Requirements
 Construction / Iteration
 Testing / Quality Assurance
 Deployment
 Feedback

Steps in Agile Model

1. Requirement Gathering:- In this step, the development team must gather the
requirements, by interaction with the customer. development team should plan the
time and effort needed to build the project. Based on this information you can
evaluate technical and economical feasibility.
2. Design the Requirements:- In this step, the development team will use user-flow-
diagram or high-level UML diagrams to show the working of the new features and
show how they will apply to the existing software. Wireframing and designing user
interfaces are done in this phase.
3. Construction / Iteration:- In this step, development team members start working on
their project, which aims to deploy a working product.
4. Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing,
and System Testing. A brief introduction of these three tests is as follows:
5. Unit Testing:- Unit testing is the process of checking small pieces of code to ensure
that the individual parts of a program work properly on their own. Unit testing is used
to test individual blocks (units) of code.
 Integration Testing:- Integration testing is used to identify and resolve any issues
that may arise when different units of the software are combined.
 System Testing:- Goal is to ensure that the software meets the requirements of the
users and that it works correctly in all possible scenarios.
5. Deployment:- In this step, the development team will deploy the working project to
end users.
6. Feedback:- This is the last step of the Agile Model. In this, the team receives
feedback about the product and works on correcting bugs based on feedback provided
by the customer.
The time required to complete an iteration is known as a Time Box. Time-box refers
to the maximum amount of time needed to deliver an iteration to customers. So, the
end date for an iteration does not change. However, the development team can decide
to reduce the delivered functionality during a Time-box if necessary to deliver it on
time. The Agile model’s central principle is delivering an increment to the customer
after each Time-box.
Principles of the Agile Model
 To establish close contact with the customer during development and to gain a
clear understanding of various requirements, each Agile project usually includes a
customer representative on the team. At the end of each iteration stakeholders and
the customer representative review, the progress made and re-evaluate the
requirements.
 The agile model relies on working software deployment rather than
comprehensive documentation.
 Frequent delivery of incremental versions of the software to the customer
representative in intervals of a few weeks.
 Requirement change requests from the customer are encouraged and efficiently
incorporated.
 It emphasizes having efficient team members and enhancing communications
among them is given more importance. It is realized that improved
communication among the development team members can be achieved through
face-to-face communication rather than through the exchange of formal
documents.
 It is recommended that the development team size should be kept small (5 to 9
people) to help the team members meaningfully engage in face-to-face
communication and have a collaborative work environment.
 The agile development process usually deploys Pair Programming. In Pair
programming, two programmers work together at one workstation. One does
coding while the other reviews the code as it is typed in. The two programmers
switch their roles every hour or so.
Characteristics of the Agile Process
 Agile processes must be adaptable to technical and environmental changes. That
means if any technological changes occur, then the agile process must
accommodate them.
 The development of agile processes must be incremental. That means, in each
development, the increment should contain some functionality that can be tested
and verified by the customer.
 The customer feedback must be used to create the next increment of the process.
 The software increment must be delivered in a short span of time.
 It must be iterative so that each increment can be evaluated regularly.
When To Use the Agile Model?
 When frequent modifications need to be made, this method is implemented.
 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with the team all the time.
 when the project needs to be delivered quickly.
 Projects with few regulatory requirements or not certain requirements.
 projects utilizing a less-than-strict current methodology
 Those undertakings where the product proprietor is easily reachable
 Flexible project schedules and budgets.
Advantages of the Agile Model
 Working through Pair programming produces well-written compact programs
which have fewer errors as compared to programmers working alone.
 It reduces the total development time of the whole project.
 Agile development emphasizes face-to-face communication among team
members, leading to better collaboration and understanding of project goals.
 Customer representatives get the idea of updated software products after each
iteration. So, it is easy for him to change any requirement if needed.
 Agile development puts the customer at the center of the development process,
ensuring that the end product meets their needs.
Disadvantages of the Agile Model
 The lack of formal documents creates confusion and important decisions taken
during different phases can be misinterpreted at any time by different team
members.
 It is not suitable for handling complex dependencies.
 The agile model depends highly on customer interactions so if the customer is not
clear, then the development team can be driven in the wrong direction.
 Agile development models often involve working in short sprints, which can make
it difficult to plan and forecast project timelines and deliverables. This can lead to
delays in the project and can make it difficult to accurately estimate the costs and
resources needed for the project.
 Agile development models require a high degree of expertise from team members,
as they need to be able to adapt to changing requirements and work in an iterative
environment. This can be challenging for teams that are not experienced in agile
development practices and can lead to delays and difficulties in the project.
 Due to the absence of proper documentation, when the project completes and the
developers are assigned to another project, maintenance of the developed project
can become a problem.
Agile Development Models – Software EngineeringIn earlier days, the Iterative
Waterfall Model was very popular for completing a project. But nowadays,
developers face various problems while using it to develop software. The main
difficulties included handling customer change requests during project development
and the high cost and time required to incorporate these changes. To overcome these
drawbacks of the Waterfall Model, in the mid-1990s the Agile Software
Development model was proposed.
The Agile Model was primarily designed to help a project adapt quickly to change
requests. So, the main aim of the Agile model is to facilitate quick project completion.
To accomplish this task, agility is required. Agility is achieved by fitting the process
to the project and removing activities that may not be essential for a specific project.
Also, anything that is a waste of time and effort is avoided.
The Agile Model refers to a group of development processes. These processes share
some basic characteristics but do have certain subtle differences among themselves.
Agile SDLC Models/Methods
 Models: Crystal Agile Software Development Methodology places a strong
emphasis on fostering effective communication and collaboration among team
members, as well as taking into account the human elements that are crucial for a
successful development process. This methodology is particularly beneficial for
projects with a high degree of uncertainty, where requirements tend to change
frequently.
 Atern: This methodology is tailored for projects with moderate to high uncertainty
where requirements are prone to change frequently. Its clear-cut roles and
responsibilities focus on delivering working software in short time frames.
Governance practices set it apart and make it an effective approach for teams and
projects.
 Feature-driven development: This approach is implemented by utilizing a series of
techniques, like creating feature lists, conducting model evaluations, and
implementing a design-by-feature method, to meet its goal. This methodology is
particularly effective in ensuring that the end product is delivered on time and that
it aligns with the requirements of the customer.
 Scrum: This methodology serves as a framework for tackling complex projects
and ensuring their successful completion. It is led by a Scrum Master, who
oversees the process, and a Product Owner, who establishes the priorities. The
Development Team, accountable for delivering the software, is another key
player.
 Extreme programming (XP): It uses specific practices like pair programming,
continuous integration, and test-driven development to achieve these goals.
Extreme programming is ideal for projects that have high levels of uncertainty and
 require frequent changes, as it allows for quick adaptation to new requirements
and feedback.
 Lean Development: It is rooted in the principles of lean manufacturing and aims
to streamline the process by identifying and removing unnecessary steps and
activities. This is achieved through practices such as continuous improvement,
visual management, and value stream mapping, which helps in identifying areas
of improvement and implementing changes accordingly.
 Unified Process: Unified Process is a methodology that can be tailored to the
specific needs of any given project. It combines elements of both waterfall and
Agile methodologies, allowing for an iterative and incremental approach to
development. This means that the UP is characterized by a series of iterations,
each of which results in a working product increment, allowing for continuous
improvement and the delivery of value to the customer.
All Agile Software Development Methodology discussed above share the same core
values and principles, but they may differ in their implementation and specific
practices. Agile development requires a high degree of collaboration and
communication among team members, as well as a willingness to adapt to changing
requirements and feedback from customers.
In the Agile model, the requirements are decomposed into many small parts that can
be incrementally developed. The Agile model adopts Iterative development. Each
incremental part is developed over an iteration. Each iteration is intended to be small
and easily manageable and can be completed within a couple of weeks only. At a time
one iteration is planned, developed, and deployed to the customers. Long-term plans
are not made.
Steps in the Agile Model
The agile model is a combination of iterative and incremental process models. The
steps involve in agile SDLC models are:
 Requirement gathering
 Design the Requirements
 Construction / Iteration
 Testing / Quality Assurance
 Deployment
 Feedback
Steps in Agile Model
1. Requirement Gathering:- In this step, the development team must gather the
requirements, by interaction with the customer. development team should plan the
time and effort needed to build the project. Based on this information you can
evaluate technical and economical feasibility.
2. Design the Requirements:- In this step, the development team will use user-flow-
diagram or high-level UML diagrams to show the working of the new features and
show how they will apply to the existing software. Wireframing and designing user
interfaces are done in this phase.
3. Construction / Iteration:- In this step, development team members start working on
their project, which aims to deploy a working product.
4. Testing / Quality Assurance:- Testing involves Unit Testing, Integration Testing,
and System Testing. A brief introduction of these three tests is as follows:
5. Unit Testing:- Unit testing is the process of checking small pieces of code to ensure
that the individual parts of a program work properly on their own. Unit testing is used
to test individual blocks (units) of code.
 Integration Testing:- Integration testing is used to identify and resolve any issues
that may arise when different units of the software are combined.
 System Testing:- Goal is to ensure that the software meets the requirements of the
users and that it works correctly in all possible scenarios.
5. Deployment:- In this step, the development team will deploy the working project to
end users.
6. Feedback:- This is the last step of the Agile Model. In this, the team receives
feedback about the product and works on correcting bugs based on feedback provided
by the customer.
The time required to complete an iteration is known as a Time Box. Time-box refers
to the maximum amount of time needed to deliver an iteration to customers. So, the
end date for an iteration does not change. However, the development team can decide
to reduce the delivered functionality during a Time-box if necessary to deliver it on
time. The Agile model’s central principle is delivering an increment to the customer
after each Time-box.
Principles of the Agile Model
 To establish close contact with the customer during development and to gain a
clear understanding of various requirements, each Agile project usually includes a
customer representative on the team. At the end of each iteration stakeholders and
the customer representative review, the progress made and re-evaluate the
requirements.
 The agile model relies on working software deployment rather than
comprehensive documentation.
 Frequent delivery of incremental versions of the software to the customer
representative in intervals of a few weeks.
 Requirement change requests from the customer are encouraged and efficiently
incorporated.
 It emphasizes having efficient team members and enhancing communications
among them is given more importance. It is realized that improved
communication among the development team members can be achieved through
face-to-face communication rather than through the exchange of formal
documents.
 It is recommended that the development team size should be kept small (5 to 9
people) to help the team members meaningfully engage in face-to-face
communication and have a collaborative work environment.
 The agile development process usually deploys Pair Programming. In Pair
programming, two programmers work together at one workstation. One does
coding while the other reviews the code as it is typed in. The two programmers
switch their roles every hour or so.
Characteristics of the Agile Process
 Agile processes must be adaptable to technical and environmental changes. That
means if any technological changes occur, then the agile process must
accommodate them.
 The development of agile processes must be incremental. That means, in each
development, the increment should contain some functionality that can be tested
and verified by the customer.
 The customer feedback must be used to create the next increment of the process.
 The software increment must be delivered in a short span of time.
 It must be iterative so that each increment can be evaluated regularly.
When To Use the Agile Model?
 When frequent modifications need to be made, this method is implemented.
 When a highly qualified and experienced team is available.
 When a customer is ready to have a meeting with the team all the time.
 when the project needs to be delivered quickly.
 Projects with few regulatory requirements or not certain requirements.
 projects utilizing a less-than-strict current methodology
 Those undertakings where the product proprietor is easily reachable
 Flexible project schedules and budgets.
Advantages of the Agile Model
 Working through Pair programming produces well-written compact programs
which have fewer errors as compared to programmers working alone.
 It reduces the total development time of the whole project.
 Agile development emphasizes face-to-face communication among team
members, leading to better collaboration and understanding of project goals.
 Customer representatives get the idea of updated software products after each
iteration. So, it is easy for him to change any requirement if needed.
 Agile development puts the customer at the center of the development process,
ensuring that the end product meets their needs.
Disadvantages of the Agile Model
 The lack of formal documents creates confusion and important decisions taken
during different phases can be misinterpreted at any time by different team
members.
 It is not suitable for handling complex dependencies.
 The agile model depends highly on customer interactions so if the customer is not
clear, then the development team can be driven in the wrong direction.
 Agile development models often involve working in short sprints, which can make
it difficult to plan and forecast project timelines and deliverables. This can lead to
delays in the project and can make it difficult to accurately estimate the costs and
resources needed for the project.
 Agile development models require a high degree of expertise from team members,
as they need to be able to adapt to changing requirements and work in an iterative
environment. This can be challenging for teams that are not experienced in agile
development practices and can lead to delays and difficulties in the project.
 Due to the absence of proper documentation, when the project completes and the
developers are assigned to another project, maintenance of the developed project
can become a problem.

1.6 Information Technology Infrastructure Library (ITIL)

Information Technology Infrastructure Library (ITIL) is provided with a framework
of best practices for delivering IT services. The ITIL is an appropriate method to
management of IT service and also management can help businesses manage risk,
strengthen customer relations, establish cost-effective practices, and build a stable IT
environment that provides for growth, scale and change.
The Information Technology Infrastructure Library (ITIL)is used to standardize the
selection process, planning, and delivery and also standardize the maintenance of IT
services within a business. The goal of the ITIL is to improve efficiency and achieve
predictable service delivery.
Some Basics Terminology of ITIL:
Some terminology of it services which are used. These are given below:
 Service:
Service is defined as delivering value to customers without requiring the customer
to own specific costs and risks.
 Service Management:
Service management is defined as a set of specialized capabilities for delivering
value to customers in the form of services.
 Service Assets:
Service assets are defined as refers to the ‘resources’ and ‘capabilities’ which a
Service Provider must allocate in order to offer a service.
 Processes:
The process is defined as structured sets of activities designed to achieve a
specific objective. There are 4 basic characteristics of processes are:
1. The process generally transforms inputs into outputs.
2. It delivers results to a specific customer or stakeholder.
3. The process is measurable.
4. They are triggered by specific events.
Features of ITIL:
Information Technology Infrastructure Library (ITIL) has the following features:
 It is the best practice framework for managing IT services.
 It is the only extensive, openly available guidance on IT.
 It consists of the codes of practice of IT services and infrastructure for quality
management.
 It has its own definition for key terms.
 It is developed in 1980 by the United Kingdom’s Office of Government
Commerce (OCG).
 ITIL is considered as a service provision.
 It defines quality with the evolving business needs and user requirements.
 It is an industry of products, services and organisations.
 It is designed to improve management of IT services.
 It is contributed over the world by skilled IT practitioners.
Benefits of ITIL:
There are many benefits of Information Technology Infrastructure Library (ITIL)
which are given below:
 It is generally supported organizations and individuals to gain optimal value from
IT and digital services.
 It is inherently flawed perspective can lead to serious consequences.
 Best Practice provides a best framework for a common language and tools that
power collaboration within IT teams, to deliver value across a business.
 It is the global standard in IT best practice and is used globally by millions of
practitioners.
 It is a highly respected ITSM tool, utilized by IT and project management
professionals the world over.
 The fact that it was community-driven ensured that AXELOS had invaluable
insight to work with.

 Plan: Determining the commercial needs and gathering the opinions of end-user
by professionals in this level of the DevOps lifecycle.
 Code: At this level, the code for the same is developed and in order to simplify the
design, the team of developers uses tools and extensions that take care of security
problems.
 Build: After the coding part, programmers use various tools for the submission of
the code to the common code source.
 Test: This level is very important to assure software integrity. Various sorts of
tests are done such as user acceptability testing, safety testing, speed testing, and
many more.
 Release: At this level, everything is ready to be deployed in the operational
environment.
 Deploy: In this level, Infrastructure-as-Code assists in creating the operational
infrastructure and subsequently publishes the build using various DevOps
lifecycle tools.
 Operate: At this level, the available version is ready for users to use. Here, the
department looks after the server configuration and deployment.
 Monitor: The observation is done at this level that depends on the data which is
gathered from consumer behavior, the efficiency of applications, and from various
other sources.
Best Practices to follow:
 Implement automated dashboard
 Keep the entire team together
 Allow DevOps to be a cultural change
 Be patient with the developers
 Maintain a centralized unit
 Build a flexible infrastructure
Advantages:
1. Faster Delivery: DevOps enables organizations to release new products and
updates faster and more frequently, which can lead to a competitive advantage.
2. Improved Collaboration: DevOps promotes collaboration between development
and operations teams, resulting in better communication, increased efficiency, and
reduced friction.
3. Improved Quality: DevOps emphasizes automated testing and continuous
integration, which helps to catch bugs early in the development process and
improve the overall quality of software.
4. Increased Automation: DevOps enables organizations to automate many manual
processes, freeing up time for more strategic work and reducing the risk of human
error.
5. Better Scalability: DevOps enables organizations to quickly and efficiently scale
their infrastructure to meet changing demands, improving the ability to respond to
business needs.
6. Increased Customer Satisfaction: DevOps helps organizations to deliver new
features and updates more quickly, which can result in increased customer
satisfaction and loyalty.
7. Improved Security: DevOps promotes security best practices, such as continuous
testing and monitoring, which can help to reduce the risk of security breaches and
improve the overall security of an organization’s systems.
8. Better Resource Utilization: DevOps enables organizations to optimize their use
of resources, including hardware, software, and personnel, which can result in cost
savings and improved efficiency.
Disadvantages:
1. High Initial Investment: Implementing DevOps can be a complex and costly
process, requiring significant investment in technology, infrastructure, and
personnel.
2. Skills Shortage: Finding qualified DevOps professionals can be a challenge, and
organizations may need to invest in training and development programs to build
the necessary skills within their teams.
3. Resistance to Change: Some employees may resist the cultural and organizational
changes required for successful DevOps adoption, which can result in resistance,
resistance to collaboration, and reduced efficiency.
4. Lack of Standardization: DevOps is still a relatively new field, and there is a lack
of standardization in terms of methodologies, tools, and processes. This can make
it difficult for organizations to determine the best approach for their specific
needs.
5. Increased Complexity: DevOps can increase the complexity of software delivery,
requiring organizations to manage a larger number of moving parts and integrate
multiple systems and tools.
6. Dependency on Technology: DevOps relies heavily on technology, and
organizations may need to invest in a variety of tools and platforms to support the
DevOps process.
7. Need for Continuous Improvement: DevOps requires ongoing improvement and
adaptation, as new technologies and best practices emerge. Organizations must be
 prepared to continuously adapt and evolve their DevOps practices to remain
competitive.

1.7 DevOps processes explained

Continuous Integration
With Continuous Integration, application developers frequently check in their changes
to the source environment and use an automated build process to verify these changes
automatically.
Following are the typical activities that occur during Continuous Integration:
 Code or change review
 Unit test execution
 Code or change analysis
 Smoke test execution
Key benefits from practicing this process are:
 Smooth integration.
o Developers commit code frequently.

 Detect problems early.

o Early and frequent integration of code detects the following:
 Integration issues with other developer’s code.
 Unit test issues.
 Code and security analysis – based on the tool leveraged, a
wide spectrum of issues are detected.
 Test failures – leveraging scenario, UI, and integration
test functional integration issues.

 Solve problems early.

o Helps reduce the cost of issue resolution.
o Allows for focused integration testing later in the delivery life cycle as
there is a confidence that the core units of the application are validated.
Check your knowledge with the following interaction.
Continuous Delivery
With Continuous Delivery, application changes run through automated regression
testing and are deployed to a staging environment for further testing. This process
ensures that the application is ready for deployment on the production system.
The following items are the typical activities that occur during Continuous Delivery:
 Deployment to a Staging or Acceptance environment with Production, such as
configuration
 End-to-end functional regression testing
 Performance and load testing against Production, such as datasets
 Security compliance checks
 Localization testing
 Stakeholder signoff and acceptance testing
Key outcomes from adopting this process are:
 Repeatability through automation.
o Focus on automating build-package, deployment, testing, and
environment provisioning.
o Automation allows the process to be repeated as often as necessary,
daily, or even multiple times a day.
 Repeatable automation reduces the chance of human errors.
 Lower risk through faster feedback.
o Automated testing provides early feedback on potential bugs and
performance issues.
o Emphasis on testing in Production; environments provide reliable
indicators of the experience and performance in Production.
 Issues that are caught are immediately reported to the developers to address as
quickly as possible.
 Lower cost without sacrificing quality.
o Automation significantly reduces the cost of delivery due to its
repeatability.
o Automated releases enable continuous testing, ensuring that issues are
caught quickly and early in the release cycle when it is easier and
cheaper to fix.
o Delivering smaller functionality faster enables responding rapidly to
shifts in market priorities providing a competitive edge.
 o

Check your knowledge with the following interactions.

Continuous Deployment
The process is to obtain the validated application artifacts from the Continuous
Delivery phase of the DevOps pipeline and deploy them to production. The final
deployment can occur at its own schedule, which is based on a business agenda that a
stakeholder approves.
The following are the typical activities that occur during Continuous Deployment:
 Deploying only pipeline validated applications
 Stakeholder approval for Production deployment (optional)
 Smoke tests in a production-like environment
 Security validation in a production-like environment (optional)
 A/B testing for a limited production release (optional)
 Active/Passive deployments with a rolling update (optional)
 Rollback changes for failed deployments
Key benefits from practicing this process:
 Fully auditable process while deploying to production
 Deploying validated application changes provide confidence and minimize the
potential for bugs to escape
 A repeatable process with failover and rollback functionality ensures
consistency and de-risks the deployment to production
Check your knowledge with the following interaction.
The Release pipeline
A pipeline is a model for a business process. In the context of DevOps, a pipeline may
represent a Continuous Integration, Continuous Delivery, or Continuous Deployment
process.
In the following image, click the + icons to learn about the Release pipeline overview.
1.8 Release Management

As the number of people using digital resources (Internet, mobile technology, etc.)
increases, so does the demand for high-quality applications and software. This
demand creates a temptation for software companies to release new products quickly,
hoping to keep up with consumer interest and stay ahead of the competition.
However, there's such a thing as releasing new software too quickly. This dubious
practice typically results in bug-ridden apps of low quality and, in the long run, does
more damage to the organization than releasing new products more carefully and
deliberately.
That’s why we need release management. This article explores the concept of release
management, including answering the question, “what is release management?” We
will also cover the release management process, the objectives and benefits, the
release management lifecycle, and other helpful information.
But first, let’s pull back for a moment and define a release.
What’s a Release?
In simple terms, a release is new or altered software, including the process of its
creation. A release is a fully functional software version resulting from the software
development and engineering processes: most organizations release alpha and beta
versions before a release.
Although alpha and beta version launches are often referred to as releases, a release
most often describes the software's final version. In addition, releases are sometimes
referred to as launches or increments.
Most organizations identify releases with software versioning, a naming process
incorporating a unique set of numbers or letters that update sequentially (e.g.,
Windows 11).
What is Release Management in ITIL?
Release management is the process of planning, designing, scheduling, testing,
deploying, and controlling a software release. It ensures that teams quickly and
efficiently deliver the necessary applications and upgrades while maintaining the
existing production environment’s integrity.
ITIL is the most popular framework for governing IT products and services. The
framework helps organizations deliver apps and services cost-conscious, customer-
centric, and quality-driven manner. Additionally, Release and Deployment
management is one of the primary processes under the Service Transition portion of
the Information Technology Infrastructure Library (or its acronym, ITIL) framework.
History of Release Management
Release management is a relatively new concept in the world of software engineering.
The process has been a slow evolutionary change, as engineers shifted their emphasis
from project-based to product-based results.
Software developers used to consider each release as a project, not a product with a
full lifecycle. But as the software development process increasingly resembled the
product cycle, and the goal of a release was not just an end-product but a transition
point between support and revision, release management grew in importance.
Continual advances in best practices and technology have served as a catalyst for
release management’s rising importance in today’s development world.
Next, let us learn about the release management process flow.
What Is Release Lifecycle Management?
Although "release lifecycle management" sounds very similar to "release
management," there are subtle differences between the concepts. Release lifecycle
management covers a broader understanding of the release management process,
possibly including areas only indirectly associated with release and deployment
management.
Release lifecycle management casts a wider net than release management, typically
starting when the release is first named too long after the name falls into disuse. So,
for example, a marketing release could begin with a planning phase that occurs long
before anyone even starts working on the code.
Naturally, the teams must track such a far-ranging process through all its phases. That
means applying the requisite resources and placing release and deployment windows
on the calendar.
6 Steps to a Successful Release Management Process?
Here are the steps most associated with the release management process.
 Request: The process begins with recommendations for changes or new features to
existing functions, though there's no guarantee that the team will act on every
request. Next, the team evaluates each request for feasibility, reasons for existing,
and if there's a way to fulfill it by reconfiguring the existing version.
 Plan: This step is critical in the release's evolution because it defines its structure.
A solid plan ensures that the release team satisfies all requirements and stays on
track. This stage also covers creating or reusing a checklist or workflow that
stakeholders can refer to during the entire release process. The workflow should
cover the scope, milestones, and responsibilities.
 Design and Build: Here's where the requirements are converted to code. Then, the
team designs and builds the release into executable software.
 Testing: Once the release is ready for testing, the team deploys it to a test
environment. Next, the release gets subjected to non-functional and functional
testing; this includes user acceptance testing, or UAT for short. If the testing
process discovers any bugs, the release is sent back to developers to address the
problems and then tested again. This repetitive process continues until the release
is finally approved for production deployment by the development team and the
application’s owner.
 Deployment: The release is sent to the live environment and made accessible to
users. Deployment not only installs the release but also educates users on any
changes and trains them on operating the system, considering the new features.
 Post-Deployment: Finally, the release goes to the support phase. Again, bugs are
recorded, eventually necessitating requests for changes. Thus, the cycle begins
anew.

The Internal Workings of Software Release Management
We’ve seen what the release management workflow looks like, but now let’s take a
brief look at the individual components that make up the typical release management
process.


Release Pipeline
 The entire release process for the product in question, from feature planning to
final delivery


Release Value Stream

 The release processes that generate or increase value throughout the release
pipeline


Release Policy
 This policy defines the organization’s release types, standards, and governance
requirements


Release Template
 A single workflow process for the release pipeline featuring all automated and
human interaction and adheres to the business’s release policies. The template
is repeatable


Deployment Plan
 This plan names the activities needed to deploy the release to the production
environment


Release Unit
 A set of artifacts that are released together to implement a given feature


Release Package
 One or more release units combined and deployed together as a single release


Major Release
  Release packages composed of many release units and deployed infrequently.
Major releases often have a critical or significant business impact


Minor Release
 Release packages deployed more frequently than major releases, containing
fewer release units and lacking mission-critical components


Release Manager
 Not so much a component as a position, release managers schedule, coordinate
and maintain the releases across the organization, handling multiple
applications. Release managers also assist in project management, manage
risks, resolve issues, conduct release readiness reviews, and report to the CIO,
CTO, and business management.
What Are the Objectives and Benefits of Release Management?
Release management’s objectives provide valuable dividends to an organization’s app
production process. Here is a list of the goals and resulting benefits of implementing
the release management process:
 Release management increases the amount of successful releases by a business
 Release management reduces issues and problems with quality
 Release management improves communication, coordination, and productivity
 Release management enables a business to deliver software faster while mitigating
risks
 Release management helps streamline and standardize both the development and
operation processes. This benefit allows teams to gain valuable lessons from
experience and apply them to future projects
 Increased cooperation results in fewer surprises and offers more opportunities to
resolve configuration issues between the operating and development environments
quickly
 Release management helps the organization improve product delivery holistically
by eliminating team barriers across the multiple functions within the company’s IT
organization
All About Release Management Success Indicators
How do you know a release has been successful? You consult these indicators.
 The release is deployed on time
 The release stayed within budget
 The update release has little to no impact on the original release’s current users
 The release satisfies the needs of both current and new users, technological
advances, and competitive demands.
You Don't Have to Begin at Square One
So your organization has become convinced of the need for a release management
policy, where none has previously existed. Cheer up, you don’t have to start from
nothing! Most organizations have at least some elements of release management
embedded in their application management process. You can expand that information
into a full-fledged release management framework.
Change Management vs. Release Management
Change management and release management are similar, even to the point of sharing
some common elements, but there are profound differences. Change management
focuses on authorizing changes to controlled environments, usually through a change
approval board. Release management chiefly focuses on providing a project with a
schedule and execution plans.
Let’s take a closer look at them.
1.8 Change Management
The primary function of change management is to standardize the methods your team
uses and the procedures it will follow to handle every change efficiently and quickly.
The change management process governs and introduces changes to the configuration
items in the organization’s live-production environment. By standardizing these
efforts, the team can mitigate the effects of change-related incidents that could
otherwise negatively affect service quality.
Release Management
On the other hand, release management primarily focuses on how changes flow
through pre-production environments, ultimately resulting in the successful release
and deployment of any changes into the production IT environment and causing as
little disruption as possible. Series of changes are grouped into releases based on
commonly defined characteristics among the group changes. Release management
strives to create a more predictable and proactive change management process.
Three Ways to Improve Agility by Structuring Your Release Management Process
Now let’s explore the three primary requirements for improving your release
management process.
Standardizing Governance
Standardization makes automation possible, and automation dramatically improves
efficiency. Automation handles time-consuming, repetitive tasks, making the team
more productive, saving money and time, and reducing human error.

Real-Time Monitoring and Reporting

One of the essential elements of agile is the necessity of constantly monitoring a
project and providing regular progress reports. Otherwise, you may invest
considerable money and time into a critical project, only to discover that you missed
the mark too late.
Agile projects are broken down into sprints, requiring at least one objective. At the
end of a sprint, the team judges any progress made against those objectives. The
optimum way to do this is with day-to-day contact and interactions between the team
members, though processing customer feedback also helps.
Requirements Traceability
Requirements traceability is defined as the systematic linkage that allows teams to
follow business requirements and their related validation and fulfillment. This process
includes tracking the requirements backward and forwards.
Thus, you can start following business requirements beginning back to their origins.
You can then follow the business requirement through the entire development process
and specification, then continue doing so through their subsequent release and
deployment. If you continue beyond this, you can reach the requirements’ point of use
and even further on to their ongoing refinement.

1.9 Scrum
Scrum is a framework for project management that emphasizes teamwork,
accountability and iterative progress toward a well-defined goal. The framework
begins with a simple premise: Start with what can be seen or known. After that, track
the progress and tweak, as necessary.
Scrum is often part of Agile software development. It is named for a rugby formation
in which everyone plays a role. Software development Scrum roles include the
following:
Product owner. This person serves as the liaison between the development team and
its customers. The product owner is responsible for ensuring that expectations for the
completed product are communicated and agreed upon.
Scrum Master. The Scrum Master is referred to as the project facilitator. They
ensure Scrum best practices are followed. They must be good leaders and project
managers, skilled at collaboration, conflict resolution and process improvement.
Development team. Members of the Scrum development team work together to create
and test incremental releases of the final product. Developers must know Scrum and
Agile development practices.
Industry associations and other organizations provide training and certification for
these key roles. Some examples of these include the following:
 the Project Management Institute, which offers the Disciplined Agile Scrum
Master certification;
 the Scrum Alliance, which offers the Certified ScrumMaster certification;
 Scrum.org, which offers Professional Scrum Master Training; and
 Scrumstudy.com, which offers the Scrum Master Certified certification.
The Scrum team consists of the product owner, the Scrum Master and the
development team.
What is the Scrum process?
The Scrum process encourages practitioners to work with what they have and
continually evaluate what is or is not working. Good communication is essential and
is carried out through meetings, called "events."
Scrum events include the following:
 Daily Scrum. This event is a short, stand-up daily meeting that takes place in the
same place and time each day. In these meetings, the team reviews work
accomplished the previous day and plans what will be done in the next 24 hours.
This is the time when team members discuss problems that might prevent project
completion.
 Sprint. A Sprint is the time frame in which work must be completed -- often 30
days. New Sprints start right after the end of the previous one.
 Sprint Planning Meeting. In these meetings, everyone participates in setting goals.
At the end, at least one increment -- a usable piece of software -- should be
produced.
 Sprint Review. This is the time to show off the increment.
 Sprint Retrospective. A Sprint Retrospective is a meeting held after a Sprint ends.
During this meeting, everyone reflects on the process. A team-building exercise
may also be offered. An important goal of this event is continuous improvement.
What are Scrum artifacts?
An artifact is something of historical interest that warrants being reexamined. In
Scrum product development, artifacts are used to see what has been done and what is
still in the queue.
It is useful to look at Scrum artifacts in Sprint Planning Meetings. Scrum artifacts
include the following:
 Product backlog. This refers to what remains to be done. During a product
backlog grooming session, the development team works with the business owner
to prioritize work that has been backlogged. The product backlog may be fine-
tuned during a process called backlog refinement.
 Sprint backlog. This is a list of tasks that must be completed before selected
product backlog items can be delivered. These are divided into time-based user
stories.
 Product increment. This refers to what has been accomplished during a Sprint --
all the product backlog items -- as well as what's been created during all previous
Sprints. The product increment reflects how much progress has been made.
 Burn down. A burn down chart is a visual representation of the amount of work
that still needs to be completed. A burn down chart has a Y axis that shows work
and an X axis that shows time. Ideally, the chart illustrates a downward trend, as
the amount of work still left to do over time burns down to zero.
The Scrum framework shows how the elements of Scrum revolve around the Scrum
team.
Benefits of Scrum methodology
The core benefits of Scrum include the following:
 Quality products. The Sprint retrospective part of the Scrum process builds in
feedback and continuous improvement. As a result, development teams using the
methodology deliver high-quality products.
 Teamwork. Scrum creates cohesive software development teams that
communicate effectively, meet deadlines and solve problems together. Members
trust and respect one another and understand that their time is valuable. This
might mean limiting the daily Scrum to a strict timeboxed window. Some
software development teams include a hacking sprint in their process. It allows
developers to work on new concepts, try out new ideas and take ownership of
products.
 Flexibility. With Scrum, teams have to adapt their tools and processes to new
circumstances as they happen. Product definitions may change as development
progresses, and effective teams deliver those changes within a few iterations.
Regular product backlog meetings enable a team to rearrange priorities before
products are moved into the sprint.
 Reduced risk. Scrum focuses on a predictable, sustainable delivery pace and
consistent feedback that gives teams a chance to mitigate risk early and often.
Short sprints let teams fail fast if an idea doesn't work, keeping the risk of failure
manageable.
 Decreased time to market. Scrum aims to release products and their features in
predictable increments using well-defined sprints. The entire product does not
need to be done for features to be released. Sprints are designed to add shippable
features at every increment. Complete products made up of those shipped features
are known as complex products.
 Higher return on investment (ROI). Scrum's combined benefits lead to a
higher ROI. Constant feedback leads to less costly mistakes late in the process and
a better product with fewer defects. Decreased time to market and incremental
releases bring in revenue faster.
Scrum and Agile relationship explained
Agile is a development and project planning method. It has an overarching
philosophy, or framework, that informs the methodologies under it, as explained in
the Agile Manifesto. Scrum is one of several Agile methodologies.
Scrum can be thought of as a practical way to implement Agile. Like Scrum, Agile
contains a set of values and principles. Development teams incorporate Scrum into
their Agile strategy to add a layer of specificity.
One of the principles of Agile development is having team members regularly discuss
how to be more effective and then adjust their behavior accordingly. Scrum
incorporates a formal process to help teams do this. Daily meetings enable teams to
reflect on work to do in the next 24 hours and change their approach based on
obstacles expected or encountered.
Another principle of Agile is recognizing that the best work emerges from self-
directed teams. Scrum Masters play a role in making this happen. They give teams
what they need to do their work, and the freedom to set their own course. They then
act as a servant leader, coaching teams to solve problems, reach goals and resolve
conflicts.
The history of Scrum
The basis for the Scrum framework was introduced in 1986 in a Harvard Business
Review article, "The New New Product Development Game," by Hirotaka Takeuchi
and Ikujiro Nonaka. The authors described two approaches to managing product
development. Some teams are like runners in a relay race, passing the baton along as
they worked in a straight line. Other teams are like rugby players participating in a
single game and passing things back and forth, as necessary.
Takeuchi and Nonaka concluded that the relay-race approach, as used in NASA's
Phased Program Planning system, was outdated. The rugby approach would give
companies the tools they need to compete in a multinational business world, they said.
Jeff Sutherland, John Scumniotales and Jeff McKenna then tried Scrum software
development at Easel Corp., a software company, in 1993. In 1995, Ken Schwaber
and Sutherland, working with others -- including McKenna and Scumniotales --
presented a paper, entitled "SCRUM Development Process." The result was a sea
change that made developers question the effectiveness of the classic Waterfall
software development model.
According to the Digital.ai's "15th State of Agile Report," Scrum is the most popular
Agile methodology today. The survey of the global development community found
that 66% of respondents said it was their chosen methodology and 15% said they used
a Scrum derivative.
An updated version of the "Scrum Guide" by Sutherland and Schwaber was released
in November 2020. The guide includes the official definition of Scrum.
Scrum pillars and values
The three pillars of Scrum are adaptation, inspection and transparency.
1. Adaptation. The team consistently revises its approach to problems and takes on
new ones as they arise.
2. Inspection. The team consistently reflects on and evaluates its performance.
3. Transparency. The team works in an open environment, where all members have
insight into each other's process and are aware of the challenges others face.
Scrum's five core values support the pillars. They are the following:
1. Commitment. The team is self-directed, and everyone is dedicated to doing the
work that has been agreed upon.
2. Courage. The team operates as one entity and succeeds or fails together. Members
do the right thing and take on tough problems.
3. Focus. Distractions are limited, and the team concentrates on the work that must
be done today.
4. Openness. The team spends time sharing where it has succeeded and what must
be improved.
5. Respect. Team members have different strengths, and each member's strengths are
respected. No one is blamed when figuring out how to fix what is not working.
The three pillars of Scrum are sometimes known as the three pillars of empiricism.
Scaling Scrum to multiple teams
Scrum and similar Agile methods are designed for one team. When IT organizations
try to scale these frameworks across multiple teams, problems can occur. These
methods don't provide guidance on how to work across teams at the end of a sprint,
for example.
Scaled Agile Framework (SAFe) provides a set of principles, processes and best
practices to address this problem. Comparing various SAFe methodologies can
provide insight to help deal with Agile frameworks at an enterprise scale.
1. 10 Kanban
What Is Kanban?
Kanban is defined as a system of monitoring and regulating the production of
software and physical goods by using one or more instruction cards relayed across the
production pipeline.
Management of workflow differs from one organization or company to another. It is a
widely known strategy used to maintain an organized workflow and ensure maximum
productivity in any organization. Kanban is based on using visual methods to manage
workflow.
The word is of Japanese origin and means a card used to show information, such as a
signboard or a billboard. The use of Kanban began in the 1940s as a scheduling
system for the Toyota Production System. At that time, Toyota introduced a new
system called “Just In Time” manufacturing. This laid the foundation of the lean
system targeted at minimizing waste and created what would later be known as the
Kanban system.
Fast forward to the 21st century, more people in other sectors apart from
manufacturing began to realize how one could modify the Kanban system to meet the
same need of maximizing productivity and minimizing waste. Therefore, in 2007,
what is now accepted as the Kanban method emerged following a series of testing and
modeling. The Kanban method is one where work items are visualized so that
participants in the workflow can monitor, track and record the state of every task in
the workflow.
How does Kanban work?
When using the Kanban methodology, Kanban boards and Kanban cards are
indispensable. The Kanban board is the center point of all the work done by the team.
The board is used as a reference point for visualization, and this could be a physical
board or a virtual board, as used in most agile software development teams or remote
workers.
Irrespective of the nature of the board, they function to establish a standard workflow,
visualize the work process, and identify and resolve any bottlenecks. A Kanban board
is divided into three parts describing each item’s stage in the workflow – ‘To Do,’ ‘In
Progress, and ‘Done.’ The workflow can, however, be adapted to the unique demands
of an organization.
Kanban also works using Kanban cards. Each work item, for example, graphic
designs for the month of June, assembling a motor part, organizing email marketing
campaigns for the year, etc., is represented on a card, and the card is placed on the
board depending on its position in the workflow at that point in time.
That is, if the company’s design team has completed the designs for the month of
June, that card can be transferred from “in progress” to the “done” aspect of the
board. The board and card system helps every team member track what has been
done, what should be done, and how they fit in with the rest of the team.
The principles of Kanban include visualization, the limited amount of work-in-
process, focus on flow, and maintaining continuous improvement.
Pros and cons of Kanban
Just like any other methodology, Kanban has its highlights and flaws. Its pros include:
  Easy to understand and implement: Kanban is simplistic and straightforward
and can be easily learned and implemented. This is because the team’s primary
focus is on the “doing” section of the Kanban board.
 Flexibility: Kanban allows for a significant margin of flexibility. It
accommodates changes made on short notice, aligning with the overall
production goal. This means that although the team members know what is
expected on the “to-do” list, one can make modifications like adding, removing
or changing cards on the “to-do” column without causing much disruption in
the workflow.
The product manager in charge of the workflow process can also reprioritize
work items based on changing needs in the market. In this way, Kanban offers
maximum flexibility, which is advantageous to projects subject to real-time
changes.
 Promotes collaboration among team members: Kanban fosters team spirit and
cooperation. Users can easily exchange ideas and make helpful suggestions as
every team member has access to the board and knows the expected results the
organization is targeting.
 Increased efficiency: Efficiency describes how well an activity is performed
with minimal resources. When workers are focused on multiple activities, there
is a fall in efficiency and a lesser degree of accountability for resources used.
Kanban eliminates this by limiting the amount of work in progress. This helps
to identify bottlenecks while increasing efficiency.
The Kanban methodology is not without its weaknesses. Some of the downsides of
the system include the following:
 It creates an avenue for distraction: Kanban does not set strict responsibilities
for workers, so they risk losing focus on their primary goal.
 Complexity may arise: In Kanban, every step of the production process is
outlined and added to the board. This can gradually cause complex situations
where one is confused, especially when prioritization is not appropriately done.
1.11 Continuous Delivery Pipeline
The Continuous Delivery Pipeline (CDP) represents the workflows, activities, and
automation needed to guide new functionality from ideation to an on-demand release
of value. Figure 1 illustrates the pipeline’s four aspects: Continuous Exploration
(CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on
Demand.

The SAFe Continuous Delivery Pipeline The Continuous Delivery Pipeline (CDP) is
a significant element of the Agile Product Delivery competency. Each Agile Release
Train (ART) builds and maintains, or shares, a pipeline with the assets and
technologies needed to deliver solution value as independently as possible. The first
three elements of the CDP (CE, CI, and CD) work together to support the delivery of
small batches of new functionality, which are then released to fulfill market demand.
Details Building and maintaining a CDP allows each ART to deliver new
functionality to users far more frequently than traditional processes. For some,
continuous may mean daily or even releasing multiple times per day. For others, it
may mean weekly or monthly releases—whatever satisfies market demands and the
goals of the enterprise. Legacy practices often cause ARTs to make solution changes
in large monolithic chunks. However, this does not usually need to be an all-or-
nothing approach. For example, a satellite system comprises a manufactured orbital
object, a terrestrial station, and a web farm that feeds the acquired data to end users.
Some components may be released daily—perhaps the web farm functionality or
satellite software. Other elements, like the hardware components, can only be done
once every launch cycle. Decoupling the web farm functionality from the physical
launch eliminates the need for a monolithic release. It also increases Business Agility
by allowing the delivery of solution components in response to frequent market
changes. The Four Aspects of the Continuous Delivery Pipeline The SAFe CDP
contains four aspects: continuous exploration, continuous integration, continuous
deployment, and release on demand. The CDP enables organizations to map their
current pipeline into a new structure and use relentless improvement to deliver value
to customers. Internal feedback loops often identify process improvements, while
external feedback identifies solution improvements. The improvements collectively
create synergy in ensuring the enterprise is ‘building the right thing, the right way’
and frequently delivering value to the market. The paragraphs below describe each
aspect. Continuous Exploration (CE) focuses on creating alignment on what needs to
be built. In CE, design thinking ensures the enterprise understands the market problem
or customer need and the solution required to meet that need. It starts with a
hypothesis of something that will provide value to customers. Ideas are then analyzed
and further researched, leading to the understanding and convergence of the
requirements for a Minimum Viable Product (MVP) or Minimum Marketable Feature
(MMF). These feed the solution space for exploring how existing architectures and
solutions can or should, be modified. Finally, convergence occurs by understanding
which Capabilities and Features, if implemented, are likely to meet customer and
market needs. Collectively, these are defined and prioritized in the ART Backlog.
Continuous Integration (CI) focuses on taking features from the ART backlog and
implementing them. In CI, the application of design thinking tools in the problem
space focuses on the refinement of features (for example, designing a user story map),
which may motivate more research and the use of solution space tools (such as user
feedback on a paper prototype). After specific features are clearly understood, Agile
Teams implement them. Completed work is committed to version control, built and
integrated, and tested end-to-end before being validated in a staging environment.
Continuous Deployment (CD) takes the changes from the staging environment and
deploys them to production. At that point, they’re verified and monitored to ensure
they are working correctly. This step makes the features available in production,
where the business determines the appropriate time to release them to customers. This
aspect allows the organization to respond, rollback, or fix forward when necessary.
Release on Demand (RoD) is the ability to make value available to customers together
or in a staggered fashion-based on market and business needs. This approach allows
the business to release when market timing is optimal and carefully controls the risk
associated with each release. Release on demand also encompasses critical pipeline
activities that preserve solutions’ stability and enduring value long after release.
Although described sequentially, the pipeline isn’t strictly linear. Instead, it’s a
learning cycle that allows teams to establish one or more hypotheses, build a solution
to test each one, and learn from that work.
The CDP fosters continuous learning and value delivery Although a single feature
flows through the Value Stream sequentially, the teams work through all aspects in
parallel. That means that ARTs and Solution Trains, throughout every PI and every
iteration in the PI, continuously: Explore user value Integrate and demo value
Continuously deploy to production Release value whenever the business needs it Start
by Mapping the Current Workflow Value Stream Mapping Successful enterprises
already have a delivery pipeline—otherwise, they wouldn’t be able to release any
value. But too often, they are not fully automated, contain significant delays, and
require tedious and error-prone manual intervention. These factors cause
organizations to delay releases, increasing their size and scope (“We’ll release when it
is big enough”). This approach is the opposite of the SAFe Principle #6, which makes
value flow without interruption. The first step to improving value flow is mapping the
current pipeline. Fi
one enterprise’s CDP, focusing initially on new feature development. Over time, this
map would be extended to capture any change to the system, from new features to
maintenance to architectural improvements. Figure 3. A map of one company’s
delivery pipeline Once the current pipeline has been mapped, metrics can be collected
and recorded on the value stream map to understand where delays occur. These
metrics enable the ART to identify opportunities for improvement (such as
eliminating delays or reducing rework). Four primary metrics [1] are used (Figure 4):
Active time is the time it takes to complete work in any given step. For example, in
Figure 4, the ‘Design’ step takes four hours. Wait time is the time between steps when
no work is happening.
The features accepted by the Product Manager are delayed a staggering 696 hours
before being deployed to staging. Locating and eliminating excessive wait time is
critical to improving the flow of value. Percent complete and accurate (%C&A)
represents the percentage of work that the next step can process without needing
rework. Often, delays are caused by poor quality in the upstream (prior) steps. The
%C&A metric helps identify steps where poor quality might be causing delays in
value delivery. Figure 4 indicates that 20% of the time, the work moving from the
‘Design’ step to the ‘Code’ step needs to be reworked. Improving the %C&A metric
is also essential to improving the flow of value. All individual %C&A values are
summed to produce the total %C&A, which captures the likelihood that an item will
pass through the entire workflow without rework. With a cumulative total %C&A of
35%, this value stream requires most features to be reworked.
Value stream map with flow metrics Align the Current Workflow to the Continuous
Delivery Pipeline Once the current flow is understood, it can be mapped into the
SAFe CDP. Mapping helps the organization adopt a shared mental model and
efficiently communicate changes and improvements. Figure 5 removes the continuous
labels because, at this stage, the process is unlikely to resemble an automated pipeline.

SAFe’s Continuous Delivery Pipeline mapped to a value stream Identify

Opportunities for Improvement Teams look for the opportunity to improve the
efficiency of each step, consequently reducing end-to-end flow time. This
improvement includes addressing active time and quality (percent complete and
accurate) at each step.

the delay between steps is often the most significant initial factor. This process has
two considerable delays and a substantial amount of rework in the first step of the
deployment process. Reducing wait time is typically the fastest way to significantly
improve flow time. Another high-priority area to improve is any step with a low
%C&A. Reducing rework enables the ART to focus on creating value rather than
correcting defects. Subsequent opportunities for improvement focus on reducing the
batch size and applying the DevOps practices identified in each of the specific articles
describing the continuous delivery pipeline. The Team Flow and ART Flow articles
provide further guidance on how to make value flow without interruption (Principle
#6). Figure 6. Value stream maps reveal major delivery bottlenecks Tracking
Continuous Delivery Continuous delivery is an extensive process. Indeed, it may be
the most vital capability of every ART and Solution Train. Product Management and
its stakeholders should visualize and track ongoing work, even though a significant
portion of the development is automated. The ART Kanban facilitates the flow of
features through the CDP. Work in Process (WIP) limits help improve throughput and
identify and address bottlenecks. Figure 7 illustrates a typical ART Kanban, example
policies, and WIP limits governing each state.
An example ART Kanban board The Kanban systems consist of a series of states,
each of which is summarized below: Funnel – This is the capture state for all new
features or enhancement of existing system features. Analyzing – Features that best
align with the vision are pulled into the analyzing step for further exploration. Here
they’re refined with critical attributes, including the business benefit hypothesis and
acceptance criteria. Ready – After analysis, higher-priority features move to the
backlog, where they’re ranked. Implementing – At every PI boundary, top features
from the ART backlog are pulled into the implementing stage, where they’re
developed and integrated into the system baseline. Validating on staging – Features
ready for feedback get pulled into this step to be integrated with the rest of the system
in a staging environment and then tested and validated. Deploying to production –
When capacity is available, features are deployed into the production environment,
where they await release. Releasing – Features are released once a sufficient amount
of value has been created to meet market demands and the benefit hypothesis is
evaluated. Done – When the hypothesis has been satisfied, no further work on the
feature is necessary, and it moves to the done column. Enable the Continuous
Delivery Pipeline with DevOps Building, maintaining, and optimizing a continuous
delivery pipeline requires specialized skills and tools throughout the entire value
stream. Because this type of delivery system calls for the rapid delivery of complex
solutions with very short learning loops and high degrees of cross-functional
collaboration, DevOps methods are ideally suited to enable it. In other words,
continuous delivery pipelines are best implemented with DevOps, as illustrated in
Figure 8. Figure 8. DevOps enables the CDP SAFe’s CALMR approach to DevOps is
a mindset that guides continuous value delivery by improving Culture, Automation,
Lean Flow, Measurement, and Recovery. DevOps technical skills, practices, and
tooling are grouped into practice domains, represented by the model’s inner loops.
The two outer loops represent the four aspects of the CDP, each of which has four
activities.

1.12 bottleneck

In software engineering, a bottleneck occurs when the capacity of an application or a

computer system is limited by a single component, like the neck of a bottle slowing
down the overall water flow. The bottleneck has the lowest throughput of all parts of
the transaction path.
System designers try to avoid bottlenecks through direct effort towards locating and
tuning existing bottlenecks in a software application. Some examples of engineering
bottlenecks that appear include the following: a processor, a communication link,
and disk IO. A system or application will hit a bottleneck if the work arrives at a
comparatively faster pace relative to other processing components.[1] According to
the theory of constraints, improving on the occurrences of hot-spot point of the
bottleneck constraint improves the overall processing speed of the software. A
thought-provoking stipulation of the theory reveals that improving the efficiency of a
particular process stage rather than the constraint can generate even more delay and
decrease overall processing capabilities of a software.
It is impossible to remove bottlenecks completely since there is always a component
that limits the overall performance, so the usual goal is to improve the bottleneck
component so that the whole system can achieve the desired performance.
The process of tracking down bottlenecks (also referred as "hot spots" - sections of
the code that execute most frequently - i.e. have the highest execution count) is
called performance analysis. Reduction is achieved with the utilization of specialized
tools such as performance analyzers or profilers, the objective being to make
particular sections of code perform as effectively as possible to improve
overall algorithmic efficiency.