Accredited Agile Roles - Product Owner
Accredited Agile Roles - Product Owner Overview
This episode answers the question “what is Agile” and provides a refresh on the differences between the Agile approach to PM and traditional waterfall approaches. We also have a quick recap on the Agile manifesto and the Agile principles.
0h 27m
Welcome to ITProTV,
I'm your host [CROSSTALK].
Live from San Francisco [CROSSTALK].
[MUSIC]
You're watching ITProTV.
Welcome and thank you joining us
here at your Agile Roles series.
Specifically focusing in
on that product owner.
I'm your host, Cherokee Boose.
And today in studios we have Mrs.
Jo Peacock to bring an introduction and
really get us started and
set some ground level expectations for us.
So how you doing to day, Jo?
Absolutely great, thank you, Cherokee.
How are you?
I'm doing really well.
I've been with you in this
Agile journey so far.
We're taking a look at
individual roles and so
now we're going to be
looking at our product owner.
And boy, you have made sure that I know
the difference between scrum master,
a product owner, but
I think we're gonna spend some time
really defining that in this show, right?
Right, so we've looked at in
our other series, we've looked at
fundamentals of Agile and, by the way,
we're not gonna be covering that.
We've also looked at Agile testing and
Agile scrum master, and in
this particular series, we're gonna look
at the specific role of product owner.
And yeah, you're right, I know-
[LAUGH]
I've beaten you to death with
the difference between a product owner and
a scrum master.
Well, it's really important
to be able to define and
differentiate between those roles.
Right, yeah.
And so what we'll do is just like
the start of every single sort of Agile
series.
This particular episode, our first episode
is just gonna be a very very quick recap
over the principles of Agile and the Agile
manifesto, just to get everybody in
the mood for the series without having
to go over into any of the other series.
Okay.
Right now we're just going to do
a really really quick sort of introduction
into what Agile is and
where it comes from,
really what the methodology is all about.
And then, in subsequent episodes,
we're gonna be looking at the specific
role of the product owner, and
what the product owner has responsibility
for, and what the product owner doesn't
have responsibility for, and
what is the scrum master actually does.
I mean, you might think of these roles
as being sort of, well, fairly flexible.
That's exactly what Agile is all about it,
it's about flexibility, but
we do have some defined
responsibilities within these roles.
In other words, we have to know who to go
to if we've got a query about something.
And so
that's what we're gonna be covering.
We've got a couple of series,
one on product owners, as I said,
and we've got the one
on scrum master as well
where we'll just be looking
at those responsibilities.
You know, Joe, I had to do a little
bit more research after you left when we
concluded that last series that we had
talked about, the Agile fundamentals.
Yeah.
I was curious, I'm like okay,
so you had said look,
this is a manifesto for Agile that
was created by these individuals,
I had to do a little research.
And I thought that is so cool,
like 17 people just getting together to
come up with these ideas, and
then people actually listen to them.
So I'm working on, Jo, maybe we can
come up with something in the future,
like sit in the mountains like in Utah,
or maybe even Colorado.
[LAUGH] Can we not do Hawaii?
Yeah, Hawaii.
And we're going to come up with
some great, wonderful thing.
[LAUGH]
Yea, well,
this is not the first time
that this has happened either,
this is one of the ways that we actually
come up with our methodologies in IT.
And in terms of IT governance,
we've got methodologies such as VeriSM,
which is a methodology
looking at expanding
service management into
the wider ranging organization.
We've got methodologies such as ITIL,
now, ITIL again,
very similar to Agile, ITIL didn't
come from one particular place.
That came from a group of academics
getting together, producing white papers.
And I always say, and
I had this conversation just a little
while ago before we started this episode,
this is just common sense written down.
Everything that we talk about,
and this type of governance,
this governance sort of arena,
it's all common sense.
But you'll be surprised how much of it we
don't apply, or how much of it we don't
think about because we're too busy
thinking in the depths of the code, and
we don't actually think about
the governance of our services and
how we deliver our services.
So yeah, we could come up with something.
And Hawaii sounds fantastic to me.
[LAUGH]
I know, right?
[LAUGH]
Now Jo, what are some
of the methodologies that we'll
see being utilized here in Agile?
Well, the first thing that we gotta
remember is that Agile is not actually
a methodology in itself.
Agile is not a single approach, it's
a group of methodologies, it's really,
really sort of a pragmatic,
what it says there, pragmatic mindset.
It's all about a flexible
approach to problem, to problem,
to project management,
even not to problem management, and
you'll see here we've got
a group of methodologies there.
And this is not a definitive list.
Comprehensive list-
Yeah, there are lots and
lots of other methodologies that
may land themselves into Agile.
Agile basically means, well,
pretty much what it says, that it's agile,
it's flexible.
And it's really about delivering
product in a continuous,
continual manner, that's what it's about.
It's not a waterfall approach.
If it was traditional waterfall
approach to product delivery and
to project managements, then we have a set
time period, which is in our generally
somewhere from six months to two, three
years even, I've seen projects last for,
where we start off at the beginning with
defining what it is that our users want.
And then we go through the entire build,
and we go through the entire build in
a very chronological way, and
then we start to, as we've developed,
we then test, and then once we've tested,
then we deploy, and then once we deploy,
we have a period of hand holding, and
then we walk away as a project team.
And that's it, that project is signed off.
Well, waterfall approach works very very
well for very large implementations,
but you see, right at the very beginning
is when we have that user interaction, and
then they see nothing
potentially until very end.
So Agile looks at this slightly
differently, and Agile will say well,
okay, we've got to build up momentum,
we've got to allow for
change, which is something that waterfall
projects traditionally don't, and
we've got to be visible.
Because we've got to deliver
visible benefits, but
we've got to deliver
benefits on a regular basis.
And the one thing that we
know is that things change.
I mean, if we started off,
can you imagine, just a complete aside,
can you imagine if you've
got a cell phone and
then you had to wait three years
potentially for your next cell phone?
Can I imagine it?
[LAUGH]
I mean,
I try to get as much as
I can out of my phones.
But I'm probably an exception,
I'm a little cheap when it comes to those.
Well, look, but okay..
[LAUGH]
You can be cheap when it comes to
those, I can tell you now, right, by the
time the next one is announced next year,
I'm there.
[LAUGH]
I am there!
Well, then I know who to come to.
I'll buy all your old phones.
How about that, Jo?
Right.
Impatience, that's what this is,
it's just complete impatience..
But I'm hungry for the latest technology.
I'm hungry for new things,
I want new features.
And I'm not the only one, by the way.
I know, like I said, I think here, in
our environment I'm the exception to that
and that's because-
[LAUGH]
My budget, really.
Right, I'm not the only one, okay?
[LAUGH]
I'm just gonna walk out of this studio
and ask everybody right now, and
I'll tell you who's trying to.
Yeah, I'm always hungry for
new technology.
And so are our users as well,
and so is our organization.
And it's true to say, and I know that this
is gonna sound a bit like a story sort of
thing, but it's true to say that Over
the past few years the rate of technology
change, well, it's become more rapid,
it has increased.
And so our organizations
expect more functionality, and
they expect functionality to be
available to them when they want it.
And they expect it to be available now,
not in three years time.
In three years time, or
in two years time, even.
My needs changed.
Right, it's Moore's law.
Right.
And
we've exceeded his predictions years ago.
Yeah, right.
[LAUGH]
Agile allows for that, and
that's why we have agile as an approach
to project management, because with that
continuous delivery, then what we're
doing is we are delivering features.
So we're giving our users what they
want in that point in time, but
also we're allowing them to say, okay,
I like that, but can I have it this way?
And when you think about
the way we get our cellphones,
the way that for instance,
that's exactly how we do this now.
We update our operating systems.
And we update our app.
So probably a monthly basis.
And we expect to seeing new
functionality when we do that.
And that's an Agile approach.
So Agile is really sort of pragmatic.
And by pragmatic, I mean,
it's kind of matter of fact.
It's very, it's common sense.
And we just have to accept
the fact that things change.
And so we've got to adapt to that.
And we've got to be able
to accommodate change.
We've got to be able to accommodate
changing customer desires, and
changing customer needs as well.
Which is why we have to have
that flexible approach.
It now is by all the reasons
we've just talked about.
It's difficult to predict what a
customer's going to want in a year's time.
They don't have a year to wait.
So we have to have what we
call a flexible approach
that allows us to adapt as we learn or
rather adapt as we grow.
And adapt as we move through
the project progresses.
Now, I also wanna bring into
the bottom bullet point there that
I've just mentioned
about self-organization.
We talk about collaboration a lot in
Agile, and self-organization is really,
really key.
Because self-organization is
about that collaboration,
it's about the team working together.
It's not having a strict hierarchy and
it's also not being micro-managed,
as well.
People don't perform well when
they're being micro-managed.
If I've got somebody over
my shoulder the whole time.
And watching everything that I do,
I'm not gonna perform particularly well.
Because I'm gonna spend too much time
worrying about what's being thought of me,
and-
Right, and personally, I feel like for
me, and I feel like I've observed
this in numerous situations,
where the person that's not micromanaged.
Is going to give a little more.
A little bit extra than what they,
if they have that freedom.
Than if they were micro managed.
I want to bring into this conversation
actually the working from home.
There's a big.
And this by the way,
is kind of outside of Agile.
I'm gonna talk about
this in a little while.
We'll talk about in another episode we'll
talk about teams and their location.
But there is a misconception that working
from home people actually do less.
Well guess what, people actually do
more when they're working from home.
When you're working in your office,
you come in and you will, you'll
it's almost like be in micromanage you
come in and you come in maybe 08:30 AM and
you leave at 1630 or 1700 and
you do your day's work.
When you're working from home, sure,
you might take five minutes to go and put
the washing machine on or to go and grab
yourself some toast or make a cup tea.
I have been in the studio and
that okay [LAUGH].
All right, you might grab five
minutes here and there to do that.
But when you are working from home and
you hate your laptop because of the emails
you go and you will seat on your laptop.
And it doesn't matter what time of day or
night that is.
And I wonder,
I know I am guilty of this as well.
I'll be sitting in front of the TV
on a night, checking my emails and
things like that.
So you're actually more productive
working from home than you are when
you're in the office being micro managed.
And this is why we talk
about self-organization.
You don't have to work between
the hours of eight and 1700.
You work between the hours that
everybody else in the team is working.
And if everyone else in the team, you
know, is decided that they want to have
a meeting at 9:00 PM at night and that's
a good time for everybody then why not?
We talk about self-organization and
also that collaboration means that we
understand where different
skills lay as well.
Your skills are way more
technical than my skills.
My technical skills are in the dim and
distant past.
And so if I had something that was
specifically technical in an arena
that you outperformed in, then I would
ask you if you would help with that.
But in the same light, you know, and
hoping that you'd come to me if it was
something else to do with governance or
strategies or maybe something.
Interpersonal skills to
help with my awkwardness.
Be like Joe what do you think?
You know-
Should I leave the review?
The five star review?
Be honest.
Yeah, you know, I would.
I just need to inject a bit of Britishness
there, that's all it needs, right?
Say it as it is [LAUGH].
You know, but I've had this
discussion with people before Joe,
and I do think that it's perfect for
some people,
but there are those people that I even
know personally that they say, look,
I don't have the self discipline,
I kind of need that.
So I think also you have to be honest
with yourself when your thinking about
this too.
Yes.
I mean some people,
if they're left to organize themselves,
you'll find that they'll do nothing.
And you'll get others in the team
that will do all of the work.
Yes, there has to be somebody, but
then that's why we have a scrum master.
That is exactly what
the scrum masters role it is.
To make sure even though,
you are kind of left to your own devices,
the work is still being produced and
that is exactly why we still have
people though in a leadership role.
But these people shouldn't
be micromanaging.
Great.
So let's just take a quick
recap then if that's okay.
Over the Agile Manifesto and
just really what that means and
what it is that we are working towards?
The Agile Manifesto,
I like to call them ethics.
We officially call them values,
but I like to call them ethics.
And it really is just looking at
where we're focusing our efforts.
Where we're focusing, or
where we put value, really.
And we put value over individuals,
interactions, over processes and tools.
Now forget the myth that in Agile we
don't have any processes, because we do.
But that processes should be efficient,
and they should also be flexible as well.
When we bring in a tool,
the tool should facilitate the process.
You don't change your process
to accommodate your tool.
Again, something that I see all the time.
We're all aboard on this tool, and
this tool's gonna fix everything.
No, it's not, absolutely not.
The tool has to be able to deliver
the process that you want it to deliver.
You have to buy a tool in order to
use it as that particular tool.
You wouldn't buy a rubber hammer or
a mallet to knock a nail into the wall,
right?
You have to work out what you
want first and then you go and
buy the appropriate tool.
You don't go buy the tool and think, well
okay, now I need to find some rubber nails
cuz it's the only thing that's
gonna knock you to the wall, right?
[LAUGH]
Yeah.
I don't know.
I'm corporal when it comes to, I feel
like I've seen a rubber hammer before but
it might be for like precious.
Surfaces.
Mallet.
Mallet?
Camping.
Yeah, okay.
Camping,
hammering pegs into the ground.
Okay.
[CROSSTALK] been camping, clearly.
[LAUGH] I've been camping but
I prefer to glamp now.
Right.
[LAUGH]
Why doesn't that surprise me?
[LAUGH]
Any who.
Yeah.
Product owner, Agile.
Right, yeah.
So, tools.
Buy the right tools for the job.
And if you're glamping,
just forget it really.
[LAUGH]
You don't need anything at that point
in time [LAUGH].
Our processes have to be efficient.
That's not to say we don't want them,
they just have to be efficient.
But we value individuals,
we value the way that they work,
over our processes and over those tools.
Because sometimes we just end up with the
wrong tools and that's not what we want.
So value people, value their skills,
value their interactions.
And we're focusing on efficiency here,
I don't want you to spend your
entire day filling out paperwork.
What I want you to do is to be productive
for your entire day, and filling out
paperwork and documentation does not
mean that you're a productive person
because you're going to be developing
nothing over that period in time.
You're just going to be
filling out paperwork.
And again, let's look at the next one,
working software over
comprehensive documentation.
It's not that we don't want documentation,
but we want to keep it simple, and
we want to keep it relevant.
We are the worst in IT at producing
documentation, just for the sake of
documentation, just because we can and
that's not what we do in here in Agile.
Now, I like this one as well,
this one really hammers it home.
How many times have you taken a look
at a contract or an agreement, and
said well it's not in that agreement,
so I'm not going to do that, right?
We value customer collaboration
over contract negotiation.
It's not about what's
written on a piece of paper,
it's about having a relationship
with your customer.
I don't care what's written in that piece
of paper, what I actually want is for
us to be able to work together as a team.
Now, Cherokee, you had a situation quite
recently, where you were expecting
something to be delivered, and
it says in the piece of paper,
right, well, it's going to be
delivered between this time and
somebody's going to call you at this time.
And this is exactly what's in
the contract, but at the end of the day
what's in the contract doesn't
deliver good customer service,
it doesn't deliver a good product.
It's the attitude,
it is the performance of the person
when they eventually get there.
It is how helpful they are, and
how willing they are to work with you and
your schedules.
That's what delivers value.
It's not what's written in the contract
that delivers value, right?
So again we'll always say build
a relationship with your customer and
build a relationship with your colleagues.
That's most more valuable than
having something written down.
If you have something written down and
you're sticking to it rigidly then you
are not gonna be the only person
who is sticking to it rigidly and
there is no flexibility there at all.
And then responding to change
over following a plan.
We value responding to change more than
the plan itself, because change happens.
And a plan is only ever as
good as the next few hours, or
maybe the next few weeks.
Because our circumstances change.
I've already mentioned,
we're in the 21st century now.
And things change in the 21st
century very, very quickly.
And we've gotta be able
to accommodate that.
So these values were based on our
Agile Manifesto, or our principles rather.
The values of the manifesto,
these were based on our principles.
And we spent a lot of time going over
these in our fundamental series so
I really just wanna really just
highlight these to you right now and
I just wanna highlight what's in
purple right now, if you want to
understand a little bit more,
take a look at our fundamental series.
But we're looking at satisfying
the customer, we're looking at changing
requirements, adapting to change, and
delivering software on an iterative basis.
A repeatable basis, frequently.
We're looking at collaboration, working
together, and we want people motivated.
And that's another reason why you
don't want to stick to contracts.
You don't want to have to micro-manage.
Because if you're micro-managing them and
you're making them stick to contracts
they're not going to be motivated.
And they're certainly
not gonna give you 100%.
I like the bottom one,
face to face conversation.
It goes back to we don't want
the comprehensive documentation.
Documentation's gotta be relavant,
but it's got to be clear, concise and
unambiguous.
But you know what?
I perceive more value in
a face to face conversation.
I can get more out of you in
a face to face conversation
because I see your body language,
I understand what you're thinking.
Well, maybe not, all right.
I might not be the best candidate for
this.
[LAUGH] Poor Jo.
Yeah.
Okay, maybe I don't quite understand, but
I get to see your body language right?
And I get to sort of follow
along with where you're going.
Face to face conversation delivers
more results than a string of emails.
That email tennis that sometimes play
with the backwards and forwards and
it's please no, pick up the phone or
let's have a face to face conversation.
In ITIL terms, not Agile, in ITIL terms,
I refer to it as getting off your bum,
right?
So get off your bum, go and
see what's happening.
They call it observing directly but
I like to say just get off your bum.
Go see, you'll achieve a lot
more by doing it that way.
And then working software,
working software is what we want, and
we want sustainable development.
So what we want to achieve is development
that is sustained over a period of time.
What we don't want is development here,
and then nothing for
another six months, and
then it all goes quiet again, and
then maybe four months later
we'll deliver something.
We want sustainable development.
We want technical excellence and
we want good design.
If you get it right in
the first place and, in fact,
just before our episode today I was
talking about this with Zach actually.
If you get it right in the first place,
then you don't have to make changes.
We've had in previous series, where we've
looked at sort of both Agile and ITIL,
we've talked about the question about how
do you know if somebody's color blind?
Okay, all right, I know you're thinking to
yourself, what's that got to do with it?
If we're designing a service, you have
to understand who your user is, and
we'll come into that in
an episode a little bit later.
But you have to understand
who your user is.
If you don't know who your user is and
you don't know how they work,
then how can you ensure that you design
a service that fits their needs?
What you'll do is you'll
design what you think is good,
but then it won't deliver quality.
It won't be a good design.
You have to get to know your user first.
And you deliver, in number ten,
what you need to deliver.
Nothing else talks about
maximizing the work not done.
Stop trying to over-deliver and just
remember that anything that you deliver
over and above what you promised is
probably superfluous to requirements.
It's probably not gonna get used and
it's a wasted effort.
And we've already talk about
self-organizing teams.
And I also want to bring in number
12 there about team reflection, and
about getting the team
together on a regular basis.
We'll talk about daily stand ups
a little bit later in another episode.
But having our team look back at the end
of the day on how things have handout and
what's actually being achieve.
And then what we could
do better next time.
So as 3 pillars of Agile and again,
go back to fundamentals series and
you'll find that this
been explained to you.
As 3 pillars of Agile
transparency inspection and
adaptation, you get what you
inspect not what you expect.
Go and see it goes back again
to getting off your bum and
going to see what's happening.
And so
we wanna ensure that we are transparent,
that our entire development
team is transparent.
Now from a product owner's
perspective that's very important.
Because the product owner is the person
that is responsible for the product.
And so therefore they have got to
make sure that the team is actually
delivering what they're
supposed to be delivering.
And so transparency is really important
for a product manager, product owner.
Because the product owner has go to
see what is being developed, and
has got to make adjustments if necessary.
Bear it in mind that with each iteration,
with each sprint you've
only got up to four weeks.
There's some Agile myths here and
we've already really covered those,
about Agile doesn't require documentation
and it doesn't require planning.
Yes it does, just keep it simple.
User stories, we're going to get into
user stories in a later episode but no,
this shouldn't all be the same size.
Every single user story is going to
be different and it should be unique.
Which means that every single sprint
is going to be a different length.
We say between one and four weeks for
every single sprint but
it could be one week and
it could be for one sprint.
And the next one could be four weeks, and
then the next one could be two weeks.
That's down to the scrum master to manage,
but
the product owner's the person that
decides what goes in the sprint.
All we know is,
that whatever goes in the sprint,
we've gotta be able to achieve
that in that time period.
Whatever the time period is,
it's got to be achievable.
And here on this particular
slide you've got an overview of
an actual sprint itself.
And you will see that the product owner is
the person that prioritizes the backlog,
then we plan.
And the team then actually starts
to do the development work.
And every day we have
our daily scrum meeting.
And we also at the end of
the sprint well we'll do a review.
And we'll complete the sprint itself and
then we will either release at
that point in time or we'll not we'll
shelve that until the actual release.
And we do the retrospective,
we look back and we see what's gone wrong.
And when right and
we apply that to our next point.
So in out next episodes then what we're
going to do is we're going to expand
those activities.
The activities of the product
owner actually completes and
that they're responsible for.
And hopefully we'll see you
back in the next episode.
Great, thank you for that overview and
introduction into our series here Jo, and
thank you for joining us as well.
But for now we'll sign out,
I've been your host, Cherokee Boose.
And I'm Jo Peacock.
See you next time here at ITProTV.
[MUSIC]
Thank you for watching ITProTV.
Overview
In this series Jo and Cherokee look at the specific responsibilities and common activities of the Product Owner role in an Agile project.
Check out our overview for full content details.
Learning Style
On Demand
Length of course
4h 41m
10 Episodes
Here are the topics we'll cover
- Agile Roles - Product Owner
Learning Options
Options for this course
Train your team
Stay ahead of the curve and future-proof your business with training programs designed for you.
Channel & Reseller
Transform your experience and integrate with our unique evolving library of Audit, Cybersecurity, and Information Technology courses.
Individual learners
Learn at your own pace and get your certification training.