- [Instructor] Lead safe, lean-agile principle
number seven, apply cadence, synchronize
with cross-domain planning.
Cadence and synchronization, again this is derived
largely from Reinertsen, who I'm sure derived it
from those that went before, I think most great ideas
build on ideas that preceded them.
Cadence and synchronization together are two really
powerful tools, and by the way they're kind of process
they're activity tools, they're not tools you have to buy,
you don't go out and buy a bunch of cadence,
these are just things you can do
by changing your own behavior.
But they're different types of things.
Cadence converts unpredictable events into predictable ones,
like planning, like meeting, like reviewing work,
like reviewing, like sprint planning.
We know we needed to plan so we're going do sprint planning
on a cadence, well I know when I need to do it,
that's going to lower my transaction costs,
I can go ahead and reserve the room.
Or PI planning, good example,
or architecture teams meeting together.
They make waiting times for new work predictable.
How come?
Well, if I have a two-week sprint and my important
new thing isn't in it, I can probably get it
in the next two-week sprint, same goes for a PI,
if I have a 10-week PI, my feature didn't make it,
I can probably get it in the next PI
without disturbing the events.
Supports planning and cross-functional coordination
because I can get people together.
Limits batch sizes to a single interval,
that's kind of an abstract thought.
If my cadence is this, I can't handle
a batch bigger than this.
So, scrum doesn't opine about the importance of batch size.
Scrum says, hmmm, have a backlog,
and deliver in two-week sprints.
Convert the full backlog into the iteration backlog.
Well guess what, that's a batch size that says
I'm gonna take a small batch and move it through the system,
so it totally gets that.
Controls the injection of new work.
I saw Mike Cohn opine the other day on his newsletter
about the fact that wow it's still difficult.
If I'm going to plan to do this much work
and somebody brings me three more things
I can't actually do that much work.
If I have cadence I can do that.
And provides scheduled integration points,
so I know I'm going to integrate here.
Cadence is huge.
Now, delivering on cadence requires scope
or capacity margin, remember that for a second,
that's gonna become important.
Synchronization is something different,
and yet they work together.
Synchronization causes multiple events
to happen at the same time.
Let's go to just, for example, iteration planning.
Product owner's there, the team is there,
they have the synchronized result of the last demo,
and they're gonna plan together now,
so they're not saying where's my product owner,
they're already there.
Is the lead designer on the team there?
Or maybe it's PI planning, is the architect there?
Facilitates cross-functional trade offs.
Hey, we failed this last time because we didn't get enough
testing done, we got the stories written
but they didn't get into the main line.
Okay, we need to invest more in tests.
I'm gonna write a new test harness so that we can
take those tests, or I'm gonna create a new capability
for automated testing, or I'm gonna experiment
with a cucumber fit or bring some of those things in.
Dependency management becomes routine
because we're together on cadence,
and we have the opportunity for full system
integration and acceptance.
Multiple feedback perspectives, a good example
of that is a system demo every two weeks,
or the PI demo every 10 weeks.
At the PI demo the key stakeholders are there,
the system architect is there, the security guy is there,
business owners are there, customers are probably there,
almost certainly there, providing feedback.
Cadence and synchronization help us manage
the inherent variability in R and D, and this is R and D,
this is not simply application development.
Here's an example of how it helps.
Cadence-based planning limits variability
to a single interval.
Another kind of lofty thought,
what the heck does that mean?
Well, by example it means the following.
If I take a traditional approach,
and this is my project plan, and I have some deviation
from plan, these vectors are, to the best
of my PowerPoint ability, exactly the same,
I've some deviation from plan, but I don't re-plan,
my deviations from plan keep adding up, to the point
at some point where I go to my stakeholders and say, wow,
look at this, I have a really big deviation from plan.
A really uncomfortable day, and un-fun report.
But what if I did cadence-based planning?
Let's just say this is two weeks, or PI,
it doesn't matter, the fractal, the length fractal
doesn't really matter at all.
If it's every two weeks I'm gonna re-plan,
re-plan, re-plan, re-plan.
I never experience more than
that much lack of fidelity to the plan.
This team operated more on plan for one
and only one reason, which is they plan more frequently.
That's under your control.
So you want to have better conformance to plan,
plan more frequently, thus the insight of scrum.
Let's plan every two weeks
and we'll pretty much always be on the plan.
The inside of safe, two weeks is too short,
we needed some enterprise-level planning,
it's not two years planning or one year planning,
it's more on the order of eight or 10 weeks.
So, controlling variability with planning cadence
allows us to limit variation.
So, this equals bad, this equals much better,
we want to move from bad, poor choice of acronyms,
to better, using cadence and synchronization.
And it's free, doesn't cost you anything,
just a thinking tool, and a behavioral tool.
How do we synchronize?
We synchronize with cross-domain planning.
We're gonna talk a lot about PI planning here
in the next couple of modules.
But other lean thinkers have certainly
come to the same conclusion.
Michael Kennedy, "Future product development tasks
"can't be pre-determined.
"Distribute planning and control to those
"who can understand and react to the end results".
How do we do that?
I won't belabor this because we're gonna go into it
at some length but, we're gonna get everybody together,
we're gonna know what the mission is, we're gonna do
what we used to call joint application design,
requirements and design and architecture
and customer feedback all at the same time.
We're gonna have the right people there.
These people here were leaders,
the managers, the business owners.
And in another circumstance, it wasn't this one,
they had a sign on the desk that said help desk.
As you're planning, if you need any help come to us.
I thought that was really cool, it says we're here to help,
this is the help desk for decision making,
we'll accelerate those decisions immediately.
And teams create and take responsibility for plans.
And in so doing there's a huge hand-off of power,
authority and responsibility.
If I plan for teams and created the plan,
I own the plan, and they were kind of stuck with my plan.
What's their commitment to the plan?
Well, some level, typically pretty committed
but on behalf of the wrong purpose, my plan.
If they create that same set of plans,
if you created the set of plans, it said this is
what we think we can do in this time period,
your level of commitment is different.
And what's more I think Papanek pointed out years back,
she said, if a team creates a plan themselves,
they'll probably figure out a way to achieve the plan,
even if their initial assumptions weren't right.
So we're gonna move from management, centralized planning,
from kind of PMO- and portfolio-level planning,
into strategies and vision and roadmaps,
and the teams and the arts are gonna take on
the responsibility for planning.
So planning of outcomes is now going to be
your responsibility in this model, and that's super,
because now you can really make the right decisions
about the right way to approach the problem.