The document provides an overview of Agile, Scrum, and DevOps principles and processes. Some key points: - Agile values individuals, interactions, working software, customer collaboration, and responding to change over processes, tools, documentation, and following a plan. - Scrum uses roles of Product Owner, Scrum Master, and Development Team and artifacts like user stories, burn down charts, and impediment logs within sprints, daily scrums, sprint reviews and retrospectives. - DevOps aims to unify software development and operations through collaboration, automation, continuous integration, delivery and deployment to achieve speed, stability, and alignment with business objectives. It advocates for frequent code integration and deployment to

1. AGILE &

2. Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value the items on the left more

3. Agile Principles
1. Customer satisfaction by early and
continuous delivery of valuable software
2. Welcome changing requirements, even in
late development
5. Projects are built around motivated
individuals, who should be trusted
4. Close, daily cooperation between business
people and developers
7. Working software is the primary measure of
progress
6. Face-to-face conversation is the best form of
communication (co-location)
3. Deliver working software frequently (weeks
rather than months)
8. Sustainable development, able to maintain a
constant pace
9. Continuous attention to technical
excellence and good design
10. Simplicity—the art of maximizing the
amount of work not done—is essential
11. Best architectures, requirements, and
designs emerge from self-organizing teams
12. Regularly, teams reflects on how to become
more effective, and adjusts accordingly

4. Scrum Basis
Roles
Artifacts
Events

5. Development
Team
Product
Owner
The Development Team
do the work and manage
their own work
The Product Owner leads the
project with a vision and is
responsible for maximizing the
value of the product resulting
from the work of the
Development Team
The Scrum Master is responsible for
promoting and supporting Scrum as
a servant-leader to maximize the
value created by the Scrum Team
Scrum Roles

6. Scrum Events & Artifacts
Scrum Events
Scrum Artifacts

7. Scrum Artifacts
Project Vision
articulates the
goal of the
project and
provide focus for
the project team.
Epics are high-level functionality
or broadly defined requirements
and can be broken down into
smaller pieces, called user stories
User Stories are short and simple
statements that document the
requirements and desired end-user
functionality
Burn Down Chart is
the main metric to
assess the progress.
Impediment Log aims
to identify, track and
resolve impediment
identified during Sprint.

8. Scrum Artifacts
Project Vision
It would consist on High Level vision and strategies
It should answer the below questions:
• Why are we doing it?
• Who are we building it for?
• What are we building?
• When are we looking to deliver?
• What does it solve? - Need for the Product
Epics
It contains the requirements with fewer details and mostly
grouping business functionalities or areas.
Epics may be developed in medium timeframe (few sprints)
User Stories
These are low level of details and it can be developed in a Spring.
Stories evolves as needed during the reviews and analysis.
Stories are estimated on work required (work estimation & value)
and it may include hardware or tasks
Burn Down Chart
The project progress needs to be assets and analysed.
This chart display the team performance and effort over time
Impediment Log
A log to track all impediment, actions, issues, defects and such is
used to ease the team development and ensure Spring committed
work
Stories
Epics
Vision Island
Structures
Palace House Lighthouse
Transport
Road Truck

9. Scrum Artifacts

10. Scrum Artifacts
Project Vision
• Why are we doing it?
• Who are we building it for?
• What are we building?
• When are we looking to deliver?
• What does it solve?
Epics
requirements with details and group
functionalities
Epics may be developed in medium timeframe
(few sprints)
Create a New ePhone 12 with better camera and foldable
• This new version will be the first foldable phone in the market
• Our teams in China will do the hardware, India will do the camera
• New ePhone will have 4 lens camera and would be
• New ePhone will be in the market in 1 year
• It will increase sales, market share and standup on competitors
Epics
Two main areas:
- New 4 lens camera
- New foldable screen

11. Scrum Artifacts
User Stories – Foldable ePhone
• As a user, I want the phone to be folded by half
• As a user, I want to be able to select which screen to be active when the phone is folded
• As a user, I want the battery last the same time as previous model
• As Product Manager, I want to reuse the hardware of previous version if possible
• As a QA, I want the phone to maintain the resistance and durability as previous model
• As hardware engineer, I would need to investigate the best material for the screen
3.- As hardware engineer, I would need to investigate the best fold system to maintain robustness
4.- As a Soft Dev, I would need to include an option in setting to set a screen by default
1.- POC for material XXX
2.- POC for material YYY
5.- As a Soft Dev, I would need to include an option in setting for the user to choose a screen
6.- As hardware engineer, I would need to investigate to increase the side of battery
7.- As hardware engineer, I would need to investigate to add an extra battery of previous model
8.- As hardware engineer, I would need to investigate if previous phone case can be reused
9.- As hardware engineer, I would need to investigate the material XXX

12. Scrum Artifacts
User Stories – 4 lens ePhone
• As a user, I want a camera with Gran Angular Len
• As Product Manager, I want to reuse the previous model hardware if possible
• As a QA, I want Camera cover to maintain the resistance and durability as previous model
1.-
5.-
6.-
8.-
• As a user, I want a camera with Macro Len
2.-
• As a user, I want a camera with High Speed Len
3.-
• As a user, I want a camera with Wide Len
4.-
• As a Product Manager, I want the Camera settings with minimum changes and user friendly
7.-

13. Scrum Artifacts – Stories (Kanban)

14. EPICS TO DO DOING TESTING DONE RELEASE
FOLD
Material
XXX
Material
YYY
Default
Screen
1 Battery Robust
Screen
choice
2
Batteries
Reuse
case
CAMERA Gran
Angular
MacroHigh
Speed
High
Speed
Wide Case
Reuse
Soft
Setting
Resistance
Durability
Scrum Artifacts – Stories (Kanban)
Scrum
Master
Software
License
Jira
Install

15. Scrum Artifacts – Stories Estimation
Stories
How can Stories be estimated?
There are several techniques and the most used follows:
• Team gather and review the stories
• Team plays Poker cards to estimate each story or
• Team estimate using scales such:
or
Normally used up to 21 points

16. Scrum Artifacts – Stories Estimation
Estimate the below stories
• As a user, I want to be able to select
which screen to be active when the
phone is folded
4.- As a Soft Dev, I would need to include an
option in setting to set a screen by default
5.- As a Soft Dev, I would need to include an
option in setting for the user to choose a
screen
• As a Product Manager, I want the Camera settings with
minimum changes and user friendly
7.- As hardware engineer, I would need to investigate if
current IOS can be updated with extra Lens settings

17. Scrum Events
is one time boxed (2-4
weeks) iteration of a
continuous
development cycle.
Daily Scrum is the daily team
meeting to answer:
• What did you do yesterday?
• What will you do today?
• Are there any impediments?
Sprint Review aims to assess the
progress of the development at the
end of the Sprint and agree the
release.
Sprint Retrospective aims
to identify any
improvement on
behaviour or techniques.
Sprint Planning is the meeting to
identify the user stories to be built
and delivered during the
oncoming Sprint.
Project Retrospective
aims to identify any
improvement on team
behaviour or techniques.
Release Plan is a high level plan
of functionalities to be deliver on
each Sprint.

18. Scrum Game

19. Scrum Game
I am a Dictator and bought an island that
need to be built.
The island is in middle of ocean and it would need
structures, buildings and some amusements.
I will need 3 teams to build my Empire.

20. Scrum Game - Teams
Product
OwnerScrum Master
Dev Team
Course assistants will gather in 3 teams (3 minutes)
Teams will choose the roles (PO, SM & Dev)
between members (3 minutes)
PO will control the requirements and show to team
(3 minutes)
Scrum Master will make sure to lead all the events
and take notes

21. Scrum Game - Start the cycle
Rebuild a new Island
Build structures, transport and some amusements.
Structures:
• Palace (P1+V200)
• House (P2 + V50) “D”
• Lighthouse (P3 + V100)
Transports:
• Road (P1 + V50) “D”
• Truck (P2 + V100) “D”
• Shop (P3 + V100) “D” Amusements:
• Park (P1 + V50) “D”
• Cinema (P2 + V200)
• Fountain (P3 + V50) “D”

22. Dev Ops – Life Cycle

23. What is Dev Ops? DevOps = Dev (Development) + Ops (Operations)
DevOps is a software engineering culture and
practice that aims at unifying software
development (Dev) and software operation
(Ops)...
Dev Ops - Basis
Dev and Ops have different and opposing goals Development Operations
Speed
Stability
DevOps culture is about collaboration between
Dev and Ops to work together and share the
same goals
Development & Operations
DevOps aims at shorter development cycles,
increased deployment frequency, more
dependable releases, in close alignment with
business objectives.”
Speed & Stability

24. Dev Ops – Story of Traditional Dev
• Devs write code
• Dev and Ops are black boxes to each other, which leads to finger pointing
• Dev and Ops have different priorities, which pits them against each other
• Even if they WANT to work together:
• Dev is measured by delivering features, which means deploying changes
• Ops is measured by uptime, but changes are bad for stability
What went wrong
OperationsTestersDevelopers
• Finally, it is ready for production
• “throw it over the wall” to QA
• Code bounces back and forth between Dev and
QA as QA discovers problems and Devs fix them • Each group’s domain is a “black box” to the other
groups
• Oh no! There’s a problem. Ops throws it back over
the wall to QA and Dev
• “Our systems are fine; it’s your code!”
• “But the code works on my machine!”
• Operations starts working with the development

25. Dev Ops – Story of Dev Ops
• Devs write code • Oh no! The latest deployment broke something in
production!
Build Integrate Test Deploy
Build Integrate Test Deploy
Production
• Dev and Ops worked together to build a robust way of
changing code quickly and reliably
• Automation led to consistency
• Good monitoring, plus the swift deployment process,
ensured problems could be fixed even before users
noticed them
What went RIGHT
• QA can get their hands on it almost immediately
• Code commit triggers automated build,
integration, and tests
• Once it is ready, kick off an automated
deployment to production
• Deployments can occur much more frequently,
getting features into the hands of customers
faster
• Devs, QA and Operations work together as a
team in a work flow
• An hour later, the dev team was able to deploy a fixed
version of the new code
• Fortunately, automated monitoring notified the team
immediately
• The team does a rollback by deploying the previous
working version, fixing the problem quickly

26. Dev Ops – Life Cycle
build test release deploy operate monitorcodeplan
DevOps Plan aims to identify the
code to be developed in a timeframe
DevOps Code aims deliver the
committed development
DevOps Build aims gather and
put together all code and required
software/hardware
DevOps Test aims ensure quality
of code package
DevOps Release aims release the
package in control manner
DevOps Deploy aims deploy
package in environments X
DevOps Operate aims to operate
the package
DevOps Monitor aims to monitor
and report any issue on the package
AUTOMATION
CONTINUOUS DELIVERY & CONTINUOUS DEPLOYMENT

27. Dev Ops – Automation
What is Build Automation?
• Automation of the process of preparing code for deployment to a live environment
• Depending on what languages are used, code needs to be compiled, linted, minified,
transformed, unit tested, etc.
• Build automation means taking these steps and doing them in a consistent, automated
way using a script or tool
• The tools of build automation often differ depending on what programming languages
and frameworks are used, but they have one thing in common: automation!
What Automation looks like?
• Usually, build automation looks like running a command-line tool that builds code using
configuration files and/or scripts that are treated as part of the source code
• Build automation is independent of an IDE
• Your code should be able to build on someone else’s machine the same way

28. Dev Ops – Automation
Why to build Automation?
• Build automation is FAST - Automation handles tasks that would otherwise need to be
done manually
• Build automation is CONSISTENT – The build happens the same way every time,
removing problems and confusion that can happen with manual builds
• Build automation is REPEATABLE – The build can be done multiple times with the
same result. Any version of the source code can always be transformed into deployable
code in a consistent way.
• Build automation is more RELIABLE – There will be fewer problems caused by bad
builds
• Build automation is PORTABLE – The build can be done the same way on any
machine. Anyone on the team can build on their machine, as well as on a shared build
server

29. What is Continuous Integration?
• Continuous Integration (CI):the practice of frequently merging code changes done by
developers
• Continuous integration means merging constantly throughout the day, usually with the
execution of automated tests to detect any problems caused by the merge
• Merging all the time could be a lot of work, so to avoid that it should be automated!
What Continuous Integration looks like?
• Continuous integration is usually done with the help of a CI server
• This can occur multiple times a day
• If there is any problem with the build, the CI server immediately and automatically
notifies the developers
Dev Ops – Continuous Integration
• When a developer commits a code change, the CI server sees the change and
automatically performs a build, also executing automated tests

30. Why Continuous Integration?
• Early detection of certain types of bugs – If code doesn’t compile or an automated test
fails, the developers are notified and can fix it immediately. The sooner these bugs are
detected, the easier they are to fix!
• Eliminate the scramble to integrate just before a big release – The code is constantly
merged, so there is no need to do a big merge at the end
• Makes frequent releases possible - Code is always in a state that can be deployed to
production
• Encourages good coding practices – Frequent commits encourages simple, modular
code
• Makes continuous testing possible – Since the code can always be run, QA testers can
get their hands on it all throughout the development process, not just at the end
Dev Ops – Continuous Integration

31. Dev Ops – Continuous Delivery & Deployment
What is Continuous Delivery?
• Continuous Delivery (CD): the practice of continuously maintaining code in a
deployable state
• Regardless of whether or not the decision is made to deploy, the code is always in a
state that is able to be deployed
• Some use the terms continuous delivery and continuous deployment interchangeably, or
simply use the abbreviation CD
What is Continuous Deployment?
• Continuous Deployment: the practice of frequently deploying small code changes to
production
• Continuous delivery is keeping the code in a deployable state. Continuous deployment is
actually doing the deployment frequently
• There is no standard for how often you should deploy, but in general the more often you
deploy the better!

32. What Continuous Delivery & Continuous Deployment looks like?
• Each version of the code goes through a series of stages such as automated build,
automated testing, and manual acceptance testing. The result of this process is an
artifact or package that is able to be deployed
• When the decision is made to deploy, the deployment is automated. What the
automated deployment looks like depends on the architecture, but no matter what the
architecture is, the deployment is automated
• Rollbacks aren’t a big deal because the developers can redeploy a fixed version as soon as
they have one available.
• If a deployment causes a problem, it is quickly and reliably rolled back using an
automated process (hopefully before a customer even notices the problem!)
• No one grips their desk in fear during a deployment, even if the deployment does cause
a problem
Dev Ops – Continuous Delivery & Deployment

33. Why Continuous Delivery & Continuous Deployment?
• Faster time-to-market – Get features into the hands of customers more quickly rather
than waiting for a lengthy deployment process that doesn’t happen often
• Fewer problems caused by the deployment process – Since the deployment process is
frequently used, any problems with the process are more easily discovered
• Reliable rollbacks – Robust automation means rollbacks are a reliable way to ensure
stability for customers, and rollbacks don’t hurt developers because they can roll forward
with a fix as soon as they have one
• Lower risk – The more changes are deployed at once, the higher the risk. Frequent
deployments of only a few changes are less risky
• Fearless deployments – Robust automation plus the ability to rollback quickly means
deployments are commonplace, everyday events rather than big, scary events.
Dev Ops – Continuous Delivery & Deployment

34. Dev Ops – Life Cycle
build test release deploy operate monitorcodeplan
DevOps Plan aims to identify the
code to be developed in a timeframe
DevOps Code aims to deliver the
committed development
DevOps Build aims to gather and
put together all code and required
software/hardware
DevOps Test ensures quality of
code package
DevOps Release aims to release
the package in control manner
DevOps Deploy aims to deploy
package in environments X
DevOps Operate aims to operate
the package
DevOps Monitor aims to monitor
and report any issue on the package
AUTOMATION
CONTINUOUS DELIVERY & CONTINUOUS DEPLOYMENT

35. Dev Ops Cycle & Scrum
plan
code
build
test
release
deploy
operate
monitor

36. Dev Ops Game – Next Level
This game target to:
• Apply DevOps
• Scale Scrum
Structures:
• Palace (P1+V200)
• House (P2 + V50) “D”
• Lighthouse (P3 + V100)
Amusements:
• Park (P1 + V50) “D”
• Cinema (P2 + V200)
• Fountain (P3 + V50) “D”
Transports:
• Road (P1 + V50) “D”
• Truck (P2 + V100) “D”
• Shop (P3 + V100) “D”
The game aims to build all the Dictator features but each
team would build each area.
Team 1 Team 2 Team 3
• Stories are the same with priority and value
• Each team will need to negotiate what to do in
each Sprint

37. Dev Ops Game – Next Level
plan
code
build
test
Build the item
Ensure it fulfil expectations
release
deploy
When Items are ready,
release them to other teams
When all team are ready,
deploy to Production
operate
monitor
I will use the items
and communicate if
they fit the purpose
Team will seek
for improvements
SPRINT 1

39. Dev Ops – Tools
There are increasing the number of tools used in DevOps. These are the main and most used

40. Dev Ops – Tools
Hereby is a compressive list of tools and areas of usage. Most tools can integrate to each other.

41. Dev Ops – Tools Integration
Hereby is an integration capabilities table with the most common tools
Some of the tools have cross functional capabilities and development lifecycle such
Atlassian suite with Jira, Bamboo, Bitbucket and big amount of plugins available.
HIGH – integration by plugins or standardized
code.
MEDIUM – integration requires extra effort by
coding and is supported by well documented
processes. LOW – poor integration or not well documented

42. Scrum:
https://www.scrum.org/
https://www.visual-paradigm.com/
https://medium.com/
https://www.mountaingoatsoftware.com/
http://www.velocitycounts.com/
https://www.quickscrum.com/
DevOps
https://www.splunk.com/
https://www.paradigmadigital.com/
https://www.ibm.com/es-es/cloud/devops/get-started
Tools
http://www.velocitycounts.com/
https://www.atlassian.com/es/software/jira
https://xebialabs.com/
THANK YOU
Passions
albgoncal20@gmail.comContact
2009
2012
2010
2018
2019
PSM I – Professional Scrum Master
PSPO I – Professional Scrum Product Owner
SPS – Scaled Professional Scrum (Nexus)
2020 In progress