Finally! I can get out and see the sun and also the beach after staying at home
for almost two months. Wow! I've been staying at home for almost two months.
It's been that long? Hey what's up awesome people. Welcome back to my channel.
Joshua Partogi here. In today's video I'm gonna be talking about "How to
use Scrum with DevOps". Yes I do know that Scrum and DevOps does not conflict with
each other and in fact they complement each other. But from time to time I keep
on getting questions from people whether they should use Scrum or DevOps. So in
today's video I'm gonna bust the myth that you cannot use Scrum and DevOps
together. If this is something for your appetite, stay tuned don't go anywhere
folks.
A lot of people think that DevOps is only about tools. Well it really depends
on who's promoting DevOps. Most tools vendors will emphasize DevOps as tools.
But as we will learn on today's video DevOps is not more than attitudes and
behaviors. In 2008, during Agile conference in Toronto, Canada, Patrick
Debois presented a talk about agile infrastructure and operations. As someone
with sysadmin and infrastructure background Patrick envy agile software
development teams who is agile in their delivery. He wanted the infrastructure
teams to be as agile as software development teams. He brought some agile
software development concepts into infrastructure such as infrastructure as
code, refactoring, test-driven infrastructure and also continuous
deployment not only for applications but also for operating systems, virtual
machines, databases, and application servers. In his presentation he also
shared how the infrastructure team should also be part of the Scrum team
and how development teams should also have more infrastructure skills. By
breaking down the silos and merging infrastructure and software development
into one combined team organizations can increase their agility in delivering
value to customers. Patrick then extended his talk further by organizing the first
conference about agile infrastructure and operations but he found the name was
too long and he fell for the term DevOps instead. The first DevOps days
conference was held in Ghent, Belgium in 2009. In 2013 Gene Kim, Kevin Behr and
George Spafford extended the idea of DevOps by merging not only the
infrastructure and operations team with the development team, but also the
business team into a one cross-functional team. They wrote this
idea in their famous book called the Phoenix project. In this book they also
came up with the DevOps three ways. The first DevOps way is about optimizing
the flow of value from left to right. To be able to optimize the flow of value
from left to right we must first define the whole value stream, that is starting
from when the idea emerges or starting from when customer give feedback until
that idea or that feedback becomes something valuable for the customers.
After we have defined the whole value now we need to have a team who's able to
process the work that is flowing from left to right into something valuable
for the customers. If the team is not cross-functional they will be
dysfunctional. If the team is dysfunctional they will not be able to
deliver value to the customers. So I've I already made a video on team
compositions in Scrum and the importance of having cross-functional team in Scrum,
if you haven't watched that video click the link up here to watch the video.
Limiting the number of Product Backlog items that flows through the whole value
stream from left to right is another strategy to optimize the flow of value.
Some teams may do mob programming to ensure there is a single piece flow
rather than big batching. Refining the Product Backlog items that's flowing
through the value stream into a fine granular level is one of the strategy to
optimize the flow of value from left to right because smaller piece of work will
flow faster than a bigger chunk of work. Awesome Scrum teams as written on Scrum
guide will spend at least 10% of their time within the Sprint to refine the
Product Backlog items for the upcoming Sprint. Automate everything that can be
automated, starting from automated build, automated
tests, automated deployment, and even automated provisioning is another
strategy to optimize the flow of value from left to right. Every automations
that will be done by the Scrum team should be listed in the Definition of
Done. So I've already made a video on the Definition of Done, if you haven't
watched that video click the link up here to watch the video. The whole Scrum
team should also collaborate to remove any impediments that's blocking the flow
of value from left to right because removing impediments is not only the
Scrum Master's job. The second DevOps way is about optimizing the flow of information
from right to left or in other words to amplify feedback. To be able to amplify
feedback, we need to have feedback loops. What's so interesting is Scrum already
has built-in feedback loops called the Sprint and also the Daily Scrum. At the
end of the Sprint there are two opportunities to gather feedback. The
first one is the Sprint Review which is to gather feedback about the product's
performance in the market. The best way to run a Sprint Review is to use an
outcome driven metric as an input rather than just discussing the features
completed within that Sprint. The whole audience mindset during Sprint Review
should always be about outcome over output.
Besides the Sprint Review, the Sprint Retrospective is also an opportunity to
gather feedback. The purpose of the Sprint Retrospective is to gather
feedback regarding people's interactions and also process from the Sprint that
has just finished. Besides the Sprint review and the Sprint
Retrospective, the Daily Scrum itself is also a feedback loop. The purpose of the
Daily Scrum is for the development team to inspect their progress towards
achieving the Sprint goal. So I've already made a video on how to create an
outcome driven Sprint goal. Having an outcome driven Sprint goal will make your
Sprint Review really different. Your Sprint review will not look like that
boring User Acceptance Test (UAT) event. If you haven't watched that video click the
link up here to watch the video. Besides doing Sprint Review, Sprint Retrospectives
and also the Daily Scrum, the Scrum team can also add additional feedback
loops within the Sprint by doing daily deployments. By doing daily deployments
the whole Scrum team can generate outcome driven metrics to be discussed
during Sprint review much earlier. Another strategy to amplify feedback is
to practice test-driven development (TDD) because by practicing test-driven
development the development team will be able to get feedback about the quality
of their code and also whether they have broken something in their existing code
base. Practicing test-driven development is one of the fastest way to amplify
feedback. The third DevOps ways is about optimizing learning and experimentation.
To be able to optimize learning and experimentation we need to do
experimentation deliberately within the Sprint. Scrum itself is about continuous
improvement. Sprint Retrospective is an opportunity for the whole Scrum team to
improve the people interaction and process for the next Sprint. Scrum
requires that at least one actionable item to go in the next Sprint Backlog
and must be implemented in the next Sprint. This is to ensure that the whole
Scrum team is improving from Sprint to Sprint. Another strategy to optimize
learning and experimentation is to practice hypothesis-driven development.
The first step to do this is for the Scrum team to convert their Product
Backlog items into hypotheses to be validated
rather than just features to be implemented. So I've already made a video
on how to create your Product Backlog items as hypothesis, if you haven't
watched that video click the link up here to watch the video. To ensure
learning and experimentation is optimized, the Scrum Master must
influence everyone in the organization, including the management, so that
psychological safety is embedded within the organization. A psychologically safe
organization is where people do not have fear of taking risks and also do not
have fear of getting blamed for making mistakes. The Scrum team have a Sprint
retrospective which usually occur at the end of the Sprint but there is nothing
stopping the Scrum team to have an ad-hoc retrospective and also blameless
post mortem in the middle of the Sprint. Having ad-hoc retrospective and
blameless post-mortem in the middle of the Sprint is another strategy to
optimize learning and experimentation. So that is all from me today folks I hope
you enjoyed today's video. If you enjoyed this video don't forget to smash that
like button and don't forget to subscribe to my channel so that you
won't miss any of my videos in the future. And also don't forget to share
today's video so that more and more people can understand how DevOps
actually complements Scrum. All right that is all from me today folks. See you until
my next video. In the meanwhile I'm going to enjoy the sun and my day out now. Scrum On!
[Music]