- Before I dive in, I want to make a comment here.
As we've been involved with safety implementations now
for SAFe flag early on, implementations for about a decade,
we see a couple things consistently.
We see struggles in the areas of Lean-Agile leadership:
convincing and teaching people like me to take on a
different style of management, to really be a
true servant leader and to understand lean and flow
and agile development.
We also see issues in basic practices and when we see
issues in basic practices, we typically see things like,
"that won't work here because",
"we tried that and that didn't work."
And the question becomes why didn't it work?
Is there something wrong with that practice or is there
something wrong with the implementation of the practice?
So you constantly come back to try to understand,
what are the principles of SAFe?
What are the things that, if I do right, for sure,
whether I adopt that practice or have that role,
I'm gonna be successful with.
So I would pause that here that this next module
may be the most critical module in all of the course
because if you and your leaders and your peers
get this right, you'll be armed with the thinking tools
you need in addition to a Lean-Agile mindset
to really address and adopt the right patterns
so they can be successful in your organization.
So what are they?
There's nine.
Number one is to take an economic view.
Number two is to apply systems thinking.
Number three is to assume variability and preserve options.
That sounds interesting. Doesn't it?
Number 4: Build incrementally with fast,
integrated learning cycles.
That sounds like agile-lean all jammed together.
Number 5: Base milestones on objective evaluations
of working systems
We are going to show you how you can do that
even early in development and how those milestones
of working systems bring a lot more value than our
traditional kind of software development lifecycle
Stage-Gate milestones.
Visualize and limit WIP, reduce batch sizes,
and manage queue lengths.
You'll note we've got a pretty power packed principal there.
That's probably three in one but it looks better as one,
plus it makes the shape nice for the principles.
Apply cadence, and synchronize with cross-domain planning.
Unlock the intrinsic motivation of knowledge workers.
We mentioned that briefly, now it comes back as a principle.
And, in the same way, decentralize decision-making
comes back as a leadership and a management principle
to help achieve fast delivery of value.
So let's dive in.
Let's talk, first of all, wait,
why do we have these principles?
Found this really cool quote from Deming, "A common disease
that afflicts management the world over is the impression
that our problems are different."
I'll bet you've heard that.
For those of you who are consultants and have been
in the field working with other enterprises
you know, for sure, that the common response to
"that won't work here because our problems are different."
And Deming goes on to say, "They are different to be sure,
but the principles that will help to improve quality
of product and service are universal in nature."
And that's where he spent his life, coming up with
the principles that improve quality of service.
So, we know that the Lean-Agile transformation with SAFe
can deliver many benefits but it's a pretty big change
and every implementation is different.
So we might have to tailor and we might have to tune.
We might have to say, well, why does that practice
not work here?
Why does it work here?
Understanding why the practices work is part of
a leadership's mandate to know what it is they must do.
And most importantly, if a practice needs to change,
understanding the principles will assure that the change
moves the enterprise in the right direction.
We can make a change but we want to be
more lean and agile, not less.
Now occasionally we might have to adapt to an existing
circumstance or constraint but we know that the direction
of change has to move forward.
And we have this incredible body of knowledge.
We have, I don't know what the count is anymore,
125 or so books that have contributed directly to this.
Great books like "Product Development Flow",
"The Lean Machine", Reinertsen's book,
and the Lean start up series.
I've contributed a book or two over time.
It's a credible body of knowledge.
Well, they all basically say principles over practices
and that will help us drive these implementations
so that's the background.
We synthesize these principles that people like
Dan Oosterwal spend x time writing The Lean Machine
and tells you a 5 year story
of transforming Harley Davidson using Lean thinking.
He distills that down to a couple hundred pages.
We pull out of that what we need to succeed with SAFe
and that's one of the ways we create the IP
behind the framework because we read, practice in the field,
learn, synthesize, distill and basically repurpose
and provide that information back to you.
Number 1, take an economic view.
Okay, we often talk about agile is better than waterfall.
We believe it is, but why?
Is it just better because it's better, it's more fun to be
part of an agile team?
Well, it is more fun to be part of an agile team.
But I think the fundamental economic paradigm
is a little simpler than that.
I think the fundamental economic paradigm is as follows;
If our model focused on these things, and these phases,
one cannot argue the fact that value is delivered here.
It's just a fact.
It all comes together.
It gets integrated.
Now, it's easy to make fun of waterfall development
as if we haven't used it to get to this point and haven't
built incredible systems with it but let's not think about
making fun of it so much as understanding it and
understanding the basic value proposition here is
the fact that value happens here, however you measure it.
It happens here.
Nothing happens in between.
So, if I approached somebody in the PMO organization
who is literally chartered with evaluating programs
with respect to the waterfall model and ask 'em a question,
I say, if I have a choice, if I pick this point in time
and said if I have a choice between delivering you
a comprehensive set of requirements documents or
delivering you the first part of a system that reflects
our best understanding of that time as to how the system
should behave, which would you choose?
Every time they'll say, "well I'd rather have the system
but I didn't know I could have it because I didn't know
what the requirements were.
We have enough. We have a vision.
We'll take a first step.
And, if we just, migrate through time doing that,
and we don't worry so much about when design is complete
because, gosh, this part of the design wasn't complete
until here so it's awfully tough to say oh my design
has to be complete here.
Well I haven't really proven much yet.
Well swap, anytime, this set of proxy elements
for the real system.
Well what happens to economics?
Let's say it's a think that could actually deliver.
Even if I can't deliver it, I'm getting value because
I'm getting feedback, but let's pretend like it's a small
think I can deliver.
Well, immediately, in the first, let's just say
these are iterations, and the first interation,
well, I worked pretty hard for a couple weeks
I learned some things and we communicated well
but I didn't really give you anything.
I didn't give you a new feature.
I didn't deploy this one, small toolkit that we delivered.
I didn't deploy even the first set of slides.
I don't have any guidance for it.
I don't have an enablement video but I put the slides on
the platform where SPCs can use it.
Is that the full value delivery?
No, but guess what?
They can start using it.
So let's just say they start using those slides
and we come back later on and say well the slides
weren't perfect and we've now added to that the instructive
presenter's notes for the slides.
Well that's pretty cool.
We've added video to that so this person delivered
the slides here.
They delivered the slides here.
They delivered the slides here and the value is accumulating
so I'm giving this stair step.
Now, if I didn't take that, pretend like I erased
all that and start over and say well we don't do that.
We do this.
Then no value is delivered until the end state,
and even then, only if it's perfect.
If the deadline is perfect, I get value here.
So what is this?
This is the integral value of agile development
versus waterfall.
That's basic economics.
That says, even if you did waterfall perfect,
you can't compete with the economics of agile development.
Now that requires some thinking and you have to think
differently about the problem.
That's when I go oh, if that's the case,
I want to rethink this.
I'm not sure I want to think so much about that.
I want to think about enough design, enough requirements,
enough architecture to be able to deliver
that small piece of value.
And, if you wanna see how this works in kind of a fun,
interactive way, hit pause and go
to the marshmallow challenge.
You can see it here on youtube.
It's a short, seven minute video about experimentation
and prototyping and how to build a system with everybody
from kindergarteners to MBAs to executives.
It's really fun and that'll teach you a little bit
about agile development so, if you don't mind,
take that seven minutes, grab a glass of water,
and watch that video and then come back.
Isn't that a cool video?
Didn't you like the part where the kindergarteners seemed
to do best because they made no assumptions about
the final output?
I think you also appreciated the fact that, hey,
engineers and architects did pretty well, too.
I think we're thankful for that because they do think
about how to build the system.
And you learned about how things, like, executives
do terrible unless they're working with an admin
or somebody who helps them coordinate their activities.
Gosh, that sounds familiar.
But a really neat way to think about additive learning.
Take the marshmallow challenge.
Now, I described how,
that entered a process.
Having a marshmallow be this high, it delivers value.
Having just a set of slides, go out to an SPC,
without all the full products around provides value.
Let's talk about that from a slightly different perspective.
I would like you to do this exercise.
So let me set it up and then I'll do the conclusion for you.
You can do this by yourself or in a group.
Here's the exercise.
You have two scenarios so you're gonna create a chart.
Right? Of scenario one and scenario two.
On the x axis is time.
On the y axis is value.
I'm giving you the easy part, time and value.
Then we're gonna have months, we're going to have
four months like that and value like this.
So this is one unit of value, two units of value,
three units of value.
So that's the set up.
So now when we look at this exercise, you have three
features, you can deliver them serially or
you can do them in parallel.
Now these are important projects.
Features, projects, whatever.
It doesn't really matter.
We are just trying to show you how to think through this
problem and, most importantly, to get together your
key stakeholders and do this exercise because this is
really an eye opener.
So what it asks you to do is to plot the difference
between value delivery
with serial and parallel approaches to projects.
In other words, starting three things at once or just
doing one at a time.
So take about five minutes or so to do that.
I hope you had fun with that exercise.
When we do it in class,
people tend to struggle a little bit.
They typically start off thinking, oh there's some value
here but, you know what, I've got to get at least
a full slide deck out there or maybe it's the feature,
haven't been able to deliver that.
So when you take the project serially, we go, well nothing
really happens here so we have to basically agree
no value in that first iteration.
But, wow, right here, I get a unit and that's pretty cool.
And what happens at the end of the next month?
I get another unit.
That's pretty cool as well.
And what happens at the end of the next month?
I get another unit.
This diagram is starting to look familiar.
It's like what we had earlier.
So this is that incremental value delivery,
kind of dot dot dot, dot dot dot, two units of value,
three units of value.
Pretty good stuff within a very short period of time,
a single sprint or a single PI or a few days,
whatever you're context is.
You've been able to deliver value.
That's the serial case.
So this is the serial case.
It looks like this.
For those of you who are thinking ahead and have some
familiarity with Lean you also recognize that's a
working process limit of one project.
We are only gonna do one project at a time.
We are not going to start three.
So these things are gonna start to come.
Now let's do the parallel case next and people start
thinking about it and they go, well you know it might look
like this and we go, oh it doesn't really look like that.
And I ask a question, if you're working on all
three projects, what value is delivered at the end
of the first month?
Nothing because I picked the funky way to do it.
How about the second month over here?
Nothing. Well that's not helpful.
What about end of the second month, end of the third month?
Still nothing.
It's getting depressing, isn't it?
We're doing all this work month in and month out and
nothing is happening.
Now what about at the end of the fourth month?
Oh! Finally, I get a dot right here. Nope.
What about that 20 percent tax?
That multiplexing tax real so if I had the multiplex
from project to project, I mean, do you do it every day,
every hour? Gosh only knows.
Is there a time, cost and context switching?
You know there is
if you had to leave that project and go to another one.
So if it's 20 percent, maybe it's here.
Holy cow.
So this guy, even, passed this boundary.
So they have all this value being delivered in the serial
case and now I reach this deadline
and I haven't delivered anything yet.
Well that's pretty painful.
That's terrible economics.
So simply, serializing the work, limiting work in process,
delivering incrementally, is far better economics
and it's a little bit worse than that.
Let me tell you why.
What happens to the requirements fidelity
over the course of time?
If I say, you know, I really understand the requirements
at this point, is that steady?
It's absolutely flat or is it more likely that each
period of time, the market changes a little bit,
requirements change, it decays a little bit.
So let's just pretend, for the sake of argument,
that we have five percent decay here on each of these.
And if that's the case, there's this tiny little delta.
Well that's no big deal.
I can fix it here pretty readily.
It's just a quick correction.
Wow, we got feedback at the demo and they said we need to
change that.
We got feedback at the demo.
Let's take the other case now.
Let's take the case where this five percent, we start
on the parallel and we start over here and assume
that we have that same five percent decay over time.
Well, when I end up at the end, I have, fifteen percent
decay in requirements fidelity so I have a much bigger
correction to make later.
Wow. What that means is I need to think about my
requirements as live and changing and evolving.
And I need to build a model that allow me to determine
the requirements at the last responsible moment because
here the last responsible moment was the time when I started
all projects.
Here, the last responsible moment is each time I started
a new project, so it's even worse than the raw math
would indicate because of the multiplexing cost and the
fact that requirements fidelity kicks in.
So they understand that in manufacturing, Lean manufacturing
and that's called just in time.
Do not give me fifty little widgets when I only need ten
because by the time I go to manufacture that, there's been
an engineering change order applied against that widget
that basically says, that's not exactly the widget anymore
that you want to build with.
So a really critical and important lesson.
The basic economics of agile development versus
waterfall development is not waterfall is kind of
old-fashioned, sucky stuff that doesn't really work
and agile is hip and cool.
It's that we deliver incrementally and that's where the
economics come from.
If you like the economics topic, you can dive into
Reinertsen's work, "Principles of Product Development Flow,"
one of my favorite pieces and you'll learn more about things
that are even deeper thoughts, sequence jobs for
maximum benefit, we're gonna talk about that.
It's called weighted, shortest job first.
Do not consider money already spent.
Remember pivot without mercy or guilt, same thing.
We spent a million dollars on this project.
It's another million to complete it but that same million
dollars spent on a different initiative could provide
a higher overall cost.
People are going, but wait, we spent the million,
we have to recover that.
You can't recover it.
Now if that million means that the next million produces
great value, compared to another larger project, great,
then you'll proceed.
But if not you're gonna pivot.
What did we learn about our economic choices?
It has to happen all the time.
We have to build that in kind of real time.
Empower local decision making and then one key Reinertsen
takeaway and one that we're gonna want to build on,
if you only quantify one thing, quantify the cost of delay.
I wouldn't be much of an instructor if I didn't put some
real understanding behind that key principal and I'll
do that in a later module.