Hey hey what's happening awesome people?
I hope you're having a great day today.
Welcome back to my channel. For those of
you who are new to this channel, my name
is Joshua Partogi. I'm a Professional
Scrum Trainer (PST) based in Brisbane,
Australia. Welcome onboard to our
community of passionate change makers. In
today's video, we will learn about
another complementary practice that we
can use with Scrum.
So today we will learn about how to
implement Scrum with User eXperience (UX) (UX). In
some companies who practice both Scrum
and User eXperience (UX), I noticed the UX
Professionals work one Sprint ahead of
the Engineers and when I observed closer ..
sometimes these companies end up having
a feature factory. By the way, before I
carry on, you already know what I mean by
feature factories right?
Well, if you haven't already watched my
video on feature factories, you can click
the link up here to watch that video
first. Now that you have watched that
video, I hope you can appreciate what we
want to achieve from using Scrum with UX.
So, whether you're a Scrum team member or
a UX Professional, if you want to explore
how to use Scrum with UX, stick around
because I'll be back right after this
one.
[Music]
Before we continue, I would like to let
you know up front that this is not the
video that elaborate User eXperience (UX) in
detail.
On the field, there are of course many
other User eXperience (UX) activities besides
the ones I will mention in this video.
In this video, we will only explore how
to implement Scrum with UX. As today's
video is quite long, I would also like to
let you know that I have put chapter
markers on the slider of this video to
make it easier for you to navigate to
certain topics on this video.
Okay so let's start today's learning.
[Music]
User eXperience (UX) was a term that was
coined by Don Norman during his tenure
at Apple.
Don Norman has a background in cognitive
science and usability engineering. From
my observation, just like Scrum, User
eXperience (UX) has also been widely
misunderstood. I noticed that there are
many people who think that User
eXperience (UX) is only about user interface
design and only the job of the designers.
According to Don Norman, User eXperience (UX)
is everything that touches the user's
experience when the user is with the
product and also when the user is not
with the product.
Great User eXperience (UX) is the
responsibility of everyone in the
company.
[Music]
When we look at the objective of Scrum
and UX it's actually not much different.
Scrum has an objective to deliver value
early and often to the customer through
the product, while UX has an objective to
give users the best experience when
using the product. When the UX
Professionals and the Engineers look at
the same problem in the same Sprint, they
will be able to create the most
effective solution for the customers.
That solution should generate outcomes
for the customers and also the company
you work with. In short, the objective of
using Scrum with UX is to optimize
outcomes.
[Music]
When the UX Professionals and the
Engineers collaborate in the same Sprint
to optimize outcome,
we have to acknowledge there will be
consequences. The Engineers and the UX
Professionals may complete less amount
of work or less output.
But if you're also concerned with this ...
Ask yourself this question: "what's the
point of having UX Professionals and
Engineers complete a lot of output but
the product functionalities that they
develop does not generate outcomes". I
noticed people from some cultures think
that output is the same as outcome,
that's why I have made a video that
explains the differences between outcome
and output, if you haven't watched that
video you can click the link up here to
watch that video first.
[Music]
When we implement Scrum with UX, what we
need to keep in mind at all times is the
same Scrum values and principles still
apply.
Scrum values are what makes Scrum have
that oomph.
If you haven't watched my video on Scrum
values, go check it out on my channel and
watch that video.
[Music]
When we want to implement Scrum with UX,
obviously we need to embrace the UX
Professionals to be part of the Scrum
team first. Now some people,
especially those who are new to Scrum
have misunderstood that the developers
in the Scrum team are only the people
who write the software codes.
In the context of Scrum, the UX
Professionals are considered as the
product developers too.
If we go back to history, in "The New New
Product Development Game", the paper that
inspired Scrum, Professor Hirotaka
Takeuchi and Ikujiro Nonaka wrote that
the products that they observed were
made by designers and engineers who
collaborate cross-functionally.
Here's what's interesting ... Takeuchi and
Nonaka call these designers and
engineers as development teams because
together they develop the product.
Because the term developers have been
misunderstood in some cultures I've made
a video about who are the developers in
the Scrum team. If you haven't watched
that video you can click the link up
here to watch that video. So throughout
this video, whenever I say developers, by
any means I'm not excluding the UX
Professionals. Just like the Scrum guide
2020, in this video I use the word
developers not to exclude the UX
Professionals but to simplify. And
whenever I say Scrum team, I'm also
including the UX Professionals. As
written on Scrum guide, the entire Scrum
team is accountable for creating a
valuable, useful increment every Sprint.
The UX Professionals and the Engineers
are in the same Scrum team who have the
same shared accountability.
The UX Professionals and the Engineers
work with one Product Owner. We can call
the Product Owner, the UX Professionals
and the Engineers as the product trio.
Product trio concept is quite common in
many technology or digital product
companies. Because the UX Professionals
are part of the same Scrum team, they
also join all of the Scrum events from
Sprint Planning, Daily Scrum, Sprint
Review and also retrospectives.
[Music]
When both the UX Professionals and the
Engineers work on the same product, they
have the same Product Goal.
Because the Product Goal is in the
Product Backlog, they work from the same
Product Backlog that is managed by the
same Product Owner. There shouldn't be a
separate UX backlog because by doing so
it will discourage people from owning
the same shared accountability. If you
still need further explanation on
Product Goal and Product Backlog, I've
already made a video about it. Go check
it out on my channel. Because the UX
Professionals and the Engineers work
from the same Product Backlog they
should refine the Product Backlog and
create experiments together. The UX
Professionals and the Engineers may
express the Product Backlog items that
involve experimentation as hypotheses. I
have also already made a video on how to
express the Product Backlog items as
hypotheses, if you haven't watched that
video folks go click the link up here to
watch that video. I personally think that
the majority of experiments cannot be
made by the UX Professionals in
isolation without involving the
Engineers. One example is experiments
that use the canary release model where
a small subset of the consumers will get
the latest version of the product that
is deployed on one machine while the
majority of the consumers get the stable
version that is deployed on a different
machine.
Canary release is just one type of
experiment though. There are many more
models of experiments that require the
UX Professionals and the Engineers to
put their heads down together
such as feature fake, feature flagging,
wizard of oz,
etc. The point I'm making here is, the UX
Professionals and the Engineers need to
put their heads down together in the
same Sprint so they're able to create
the most effective and low risk
experiments.
[Music]
UX activities such as field study,
ethnographic study and diary study may
take several Sprints to generate results.
I found that Kanban is a good tool to
visualize and track all of the Product
Backlog items that will span across more
than one Sprints.
Now before the whole Scrum team can use
Kanban effectively, they need to
visualize the whole process in the value
stream starting from discovery, delivery
and validation.
After they have visualised the whole
value stream, the UX Professionals and
the Engineers should track the customer
cycle time of Product Backlog items that
have been on the Kanban board for more
than one Sprints. In tools like Kanbanize,
the customer cycle time is visible on
each Product Backlog item. Now you need
to check whether the tools you currently
use have a functionality to display the
customer cycle time on each Product
Backlog item. The UX Professionals and
the Engineers should also look to the
aging work in process chart during every
Daily Scrum. Check out my video on Daily
Scrum with Kanban available on this
channel, for more explanation on this
topic. So when the Scrum team discovers
there are Product Backlog items with
cycle time that have exceeded a certain
number of Sprints and yet the outcome is
not visible, during the Sprint review
they should discuss with the
stakeholders whether these Product
Backlog items should be dropped or
whether it should stay on the Kanban
board for several more Sprints until the
outcome is visible. During the Sprint
Retrospectives, the whole Scrum team
should also have a discussion on how to
make these types of long-spanning UX
activities to be shorter in the future
Sprints.
For example, during Sprint retrospectives
the Scrum team may come up with an idea
to narrow down the scope of research or
to reduce the level of fidelity of the
product interface or the experiments.
From what I have observed, when the UX
Professionals and the Engineers manage
the same Product Backlog from the same
Kanban board, first the UX Professionals
and the Engineers will deliver the
product functionalities with optimal
customer cycle time.
I personally think that's definitely a
win for the customer because the
customer will get the product
functionality sooner and more often. And
secondly, there will be less to no
pushback from the Engineers regarding
the functionalities that will be
developed in the delivery process
because the Engineers have been involved
in the whole discovery process.
[Music]
So as we Scrum practitioners know, in
essence if we summarize Scrum into one
sentence, Scrum is about delivering
usable, releasable, valuable increments
every single Sprint.
So even though there are some UX related
activities that take more than one
Sprints to generate results, the UX
Professionals and the Engineers need to
collaborate to ensure there is at least
one usable increment delivered every
Sprint. As written on Scrum guide, only
usable increments that have value for
the customers and also for the consumers.
Work results such as research or
wireframes or mockups or customer
interviews
by itself are not valuable for the
customers and also for the consumers.
I also noticed the term increment
in Scrum can be confusing for some
people, especially those who are new to
Scrum. And because of that reason I've
also made a video about it. If you
haven't watched that video folks, you can
pause this video and click the link up
here. Now, as I have explained in that
video, the increment has a commitment to
fulfill every single checkbox on the
Definition of Done.
That means, any quality measures that are
UX related goes in the same Definition
of Done that are used by the Engineers.
The UX Professionals and the Engineers
have a shared ownership over the same
Definition of Done.
So here is an example of a definition of
done that includes UX related quality
measures. Feel free to pause this video
so you can read the texts.
As you can see the text in red are the
UX related quality measures.
To ensure there's at least a usable
increment every Sprint, both the UX
Professionals and the Engineers are
encouraged to learn from each other and
to switch hats. The UX Professionals can
look into the possibility to pair up
with the Engineers when doing any
engineering activities.
On the other side, the Engineers must
also be open to do some UX related
activities with the UX Professionals. In
most cases I have seen, the UX
Professionals will facilitate the UX
related workshops and also teach the
Engineers on how to do some UX
activities that do not require a deep
level expertise in UX and design.
[Music]
Okay .. so this was quite a long video. Even
though I can still continue talking
about Scrum with UX and make this video
even longer. But I hope the message that
has been conveyed in this video is clear.
The objective of Scrum with UX is to
optimize outcomes
for the customers and also for the
company you work with.
Having UX Professionals, designers and
Engineers work together as a true
cross-functional team is definitely
challenging, especially in cultures who
still view people as feature factories. I
feel you folks. I've been there before.
Separating UX Professionals from the
Engineers is definitely tempting, it may
look more efficient because people can
do more stuff but it often leads to
sub-optimal results. At the end of the
day I think it's a matter of values and
principles that you believe in. Do you
believe in having people who are
actually working for the same product in
separate boxes or do you believe in
having people maximize collective
intelligence and outcomes in the same
box. So I have taken my stance and I
personally believe in the latter. If you
want to learn more about Scrum with UX
you can attend the Professional Scrum
with UX (PSU) course from Scrum.org. The two
other courses I suggest you attend are
the Professional Scrum with Kanban (PSK) and
also Aplying Professional Scrum for
Software Development (APS-SD). There are quite a
lot of practical hands-on activities
taught in these three courses. Alright
folks, before you leave don't forget to
smash that like button down below and if
you haven't already subscribed to this
channel go subscribe now because I will
upload more videos in the future that
can help you improve your Scrum team's
effectiveness and most importantly your
organization state of agility. For all of
you aspiring Scrum masters out there,
don't forget to follow my podcast think
and act like a Scrum Master either on
google podcast, apple podcast or spotify.
And while you wait for my next videos or
my next podcast episodes you can click
the thumbnails here and there to watch
more videos on Professional Scrum and
other complimentary practices for Scrum.
See you until my next video folks until
then don't forget to stay safe and stay
awesome.