- [Instructor] Now, we've done that work,
we've done the initial planning,
we've had the management review
and problem solving meeting,
we reset some priorities, we allocated some people.
Maybe even reshuffled things a little bit,
certainly changed priorities,
now we're ready to go back and do a final plan review,
and commit to the objectives that survive
the does this make sense does and can we do this test.
Final plan review, have kind of a small ceremony
associated with that which is we bring our plans up.
We bring them upfront and we read them.
And we say here's what we're doing,
here's the business value, very quickly,
in terms of an agenda standpoint,
I might just say, oh, is there any big change?
No, the team is still the team,
actually, we have a DBA, and another Java dev.
Wow, we have more velocity now to do that work.
What are the final objectives in business value,
and program risks and impediments,
I'll come back to those in a second.
Plan by plan, now, depending on the scope
of your situation there's a couple different ways
to do that, if you have 15 teams in your ART,
or maybe you've got multiple PI planning
happening at the same time, let's just go back to 15 teams
in the ART the probability that the 15th team
is interested in what the first team is doing,
is real, but limited, if there are seven teams
in the ART they're pretty much guaranteed
to be actively interested, the bigger it gets,
the more procedural and potentially tedious
it can be to present all these plans.
So an alternative is a science fair,
we've done that as well, put all your plans up
on the board, business owner circulate,
find the ones that you're most interested,
and collaborate and have a big discussion about that,
and provide your comments there, and then a final wrap up
of that so a combination between
this structured presentation,
and kind of a science fair project, review the plans,
can work fine.
Now we build the final plan,
kind of as follows, we take those individual objectives
and we stick them on the back wall
so that now you can really see the plan form.
You can see what this team is doing,
what this team is doing, what this team is doing.
You can see it all together,
and you're starting to see your future.
Not in terms of just the 10 futures that you brought in,
but how those are going to be accomplished
and all the other objectives that are present.
Collect those at the front of the room,
paints a picture, we're still working you know,
not in international project management tool,
not in a spreadsheet, not in Google docs,
we're working in paper so that we can have discussions,
we can point at things, we can click,
we can demonstrate things clearly
that we're interested in or animated about.
If the plan doesn't pass the review,
no worries, send it back to planning.
If it does, stick it on the front wall.
You do that until everybody's plan
is on the front of the room.
Now, during that process we've identified some things,
I made up an example before I saw that example,
which is we're dependent on the next release
of Oracle financials or we're not going
to make this big banking feature,
I can't control that, so let's have a discussion about that.
We have a critical milestone,
that's dependent upon Oracle,
they are bigger than us, and we can't ensure that.
What can we do?
Lots of choices here, we could say,
no, I just got an email, I got the release,
we're done, it's resolved.
Or somebody can say, I'm working the Oracle sales rep,
I'm confident that I can make that happen
based upon my contacts, okay, you own it.
Might be, nobody can manage Oracle,
that's another, they're bigger than us,
maybe we just have to accept that risk.
If we accept the risk and it occurs,
than the release may be compromised,
or do you have any set based ideas?
Could we mock it up, could we use the current release?
Could we use old tables, is there some stub we could do?
Could we mock up the results,
to at least kind of show our future customer
what it is, could be mitigated,
so we call that ROAMing the risks,
resolved, owned, accepted, and mitigated.
We work through them all, everybody has their say,
all risks get addressed, now,
we've said okay, we've accepted the fact
that Oracle financials, if Oracle financials doesn't ship
on time then the release is compromised,
okay, then I can't really worry about that anymore,
I mean, I know what happens if that happens.
And we can ask a different question,
which is not, are you committed to this plan,
that's a silly question, you have all these people
in the room working really hard,
imagine a room like this, which room that is,
and they're saying who here has committed the plan?
Well, number one retired so I'm committed.
Let me ask you a different question,
what is your confidence that we can achieve this?
Typically, both at the team level, and at the program level,
and this is an important commitment,
it's a commitment that comes in two parts,
and I want to be really clear about that,
the first part of that commitment,
is I as a team in my organization,
commit to do everything I can,
everything in my power to meet the objectives,
they're my objectives, they weren't hoisted upon me,
they weren't slammed down on there
and say thou must or your job's at risk,
these are the things I plan to do,
I've gone through the specific process
of identifying the stories, maybe even task out a few,
I've estimated the work, I think we can do this.
However, in the event that I discover
that some of it is not going to be accomplished,
I agree to raise the red flag immediately, okay.
If I do that, I've met the commitment.
Even if it wasn't accomplishable,
because I've informed management,
and the other stakeholders while there's still time
to make a change, what we can't do,
is the game of agile chicken, right,
which is that I think that other team's
not going to be on time so let's not stick our head up.
That's a failure in visibility,
a failure in transparency, it's a failure in agile,
it's a failure in lean, it's a failure
in every business context, what we must do,
is agree to do what we said we were going to do.
Or inform you if I can't do it.
That's fair, and that's what the commitment is,
so therefore, it should be feasible,
to have all these risks addressed,
the plan done by the people, right,
not for the people, actually their own plans,
and the risks have been addressed,
and attended to and now I can say, I think we can do this.
So we do a confidence vote,
we just simply, fist to five, all good,
four three two, there might be some low liers in the room,
there might be or a one or a two,
the RTE has a special job with respect is one or two.
What are your concerns?
And time and time again, the person that puts up
the one or two says I don't think you considered
the maintenance load right, I don't think
you considered this problem.
I think my team blustered a bit,
I think our product owner beat us badly during this process,
and said we had to do stuff we don't think we can do,
I don't think this is going to work.
This is incredibly valuable information.
A lot of it is very actionable,
what it can't be is why don't
you have confidence in the plan?
What it can be is, share with us
why you don't have confidence in the plan
after this planning cycle, here's why.
That's where the real gems are,
that's where the stuff that you are going to learn about
10 weeks from now is available and is present in the room,
if that person over there just had the courage
to raise their hand and say, I don't think so,
I don't think that's going to work.
So we need both, we need the people that, no, I get it,
and the people that say, I think there's going to be issues.
And one by one, we can address those issues,
we can listen, we can decide that hmm,
what do you think, is there something wrong with this?
I remember one person we asked them,
there were two, and they said, why?
We said, have we not addressed the risk well,
they said, this is as good a job of planning
that was ever done.
So why is your confidence low?
And they said, well, we do have our history.
And everybody laughed at that a little bit,
because prior to lean agile development,
they were never able to agree to
and commit to a set of plans that they achieved.
So that's kind of last critical element,
addressing the program risks,
reaching the confidence vote,
we see that we still do it,
this is something we put in article four years ago
but not to be forgotten, we do this every single time
in our organization, every 10 to 12 weeks
depending on our schedule we come back and we say,
do we have a set of plans,
have we mitigated the risks, are we alignment,
are we good to go?
And it really does work because when you're good to go,
people feel good about the fact
that they were actively engaged in the process,
they contributed to the magic
that is lean agile planning at scale.
Every good RTE is going to run a brief retrospective,
this is kind of interesting because you can see
the what went well and the other stuff not so good,
risk management, we never had that level of attention
to the real risks, participation,
all teams together, vision first,
over here, I don't really read some of those,
right other issues, somebody not present,
blah, blah, blah, what we can do better next time.
15 minutes maximum, if it's more than 15 minutes,
everybody's tired, they're going to think
that was an overblown retrospective.
Now the takeaway from that, I talked about
the individual plans, I won't go back to that slide,
but here's one, so what do I know now?
If I only know that there's this one objective set,
I don't know much, together, they get reintegrated,
so the RTE will typically reintegrate those,
and they'll come back to looking something
like the 10 features that went in.
But they'll be feature A, except whatever,
or they'll be, wow, we can do that demo
at the start of iteration three,
they'll be whatever the story is.
It is not 15 teams times 10,
it is not 150 objectives, it's probably 10 or 15.
Aggregates back up, this is what the business needs.
When they ask us to plan, they don't ask us to say,
here's what I have on my Sprint backlog,
and I've got 160 stories or I can accomplish
40 points from four Sprints,
I'm going to deliver 160 points with Sprint,
and it's going to be awesome,
they ask us to say, what specifically can you do
for the business, what's the business value
of the thing you're doing, and you know,
I can deliver the basic shopping cart.
I can allow the registered users
to manage their own profile, I get that,
that's cool, and that's going to come
all the way up here, 'cause that's part
of the basic, the basic mechanisms.
So we integrate, aggregate, synthesize,
and that becomes the PI plan,
that is a singularity, that is the point in time,
when everybody has agreed that based upon
all of the context all the constraints and all the issues,
this is the best we can do at that moment
and we're going to commit to that set of plans.
So in this lesson, we walk through a story board
about PI planning, you saw a short video,
I hoped I communicated to you my sense of enthusiasm
about this I certainly communicated
the nature of it which is mandatory,
if you're not doing PI planning,
you may get a lot of value out of safe,
but you're not going to get the full benefit,
so please don't call it safe.
If PI planning is attended only by the product owners
or score masters, please don't call it safe.
If PI planning is, oh, we flew six people in
from India, but their teams weren't online,
and the people here, their line managers
committed for the team, please don't call that safe.
That's not what we're talking about,
we're talking about an aggregated full commitment,
by all participants to the work that happens,
we're talking about having the people
who do the work, plan the work,
and commit to the work, and that is a really big deal,
and that is a breakthrough from traditional management
to lean agile management.
We show you how to create those plans,
how to establish business value,
and finally, how to commit to the set of objectives
that everybody can agree to.