- You might have noticed, or you might not,
that all the configurations of SAFe
have the same foundation layer,
whether you're doing Essential SAFe,
or Portfolio SAFe, Full SAFe, or Solution SAFe,
the rules are the same.
We need our leadership support,
we have the core values I described.
Lean-Agile mindset, SAFe Principals,
the roadmap that I've described very briefly,
and SPCs as guides to help us find the way.
Let's talk now specifically about the Lean-Agile mindset.
Not surprisingly, two halves of the Lean-Agile mindset
is thinking Lean and supporting the Agile Manifesto.
What's the Lean mindset?
Well, everybody who talks about Lean
has a house of Lean.
Now, everybody has a different perspective
but they all have some things in common.
They all have a roof, a value,
they all have some pillars, the things that support value,
and they all have a foundation,
and you can see here that our foundation is leadership.
The pillars are: respect for people and culture,
product development flow, innovation,
and relentless improvement.
Let's go through each of these elements
to understand what it means to have a Lean-Agile mindset.
Starts with a goal.
The goal of Lean is very simple and always constant:
Achieve the sustainably shortest lead time.
So no matter where you are in the process of transformation,
where you are in your enterprise, or who you're talking to,
they'll all resonate with the fact,
whether it be the PMO organization,
the financial organization, managers,
those that are responsible for the current lifecycle,
those responsible for delivering the system,
we can all agree we want to achieve
the sustainably shortest lead time.
But in order to be sustainable,
we also have to make sure that
we're delivering quality and value.
So, best quality and value to people and society.
Individuals, people that do the work in our organization,
and our users that take advantage
of the systems that we build.
And high morale, safety and customer delight.
You can see, kind of some of the Japanese roots
of Lean in here.
Morale matters.
Safety wasn't just in Lean manufacturing,
that was personal safety.
That was personal, physical safety.
Now in our world it's more the safety to explore,
the safety to think and speak freely about your ideas.
And Sam Walton has told us, there is only one boss
and he can fire everybody in the company,
so we all know who we're working for.
So achieving the sustainable shortest lead time
with best quality and value to people and society,
that's the goal, that's why we're using SAFe.
If you're not trying to do that,
than you're probably in the wrong course.
But if you are trying to do that,
there's a lot more meat that we can put on this bone.
Respect for people.
I mentioned just a minute or so ago
kind of a common phrase in Lean:
People do all the work.
But guess what?
Lean differs a little bit from Agile
in your view of the customer.
Lean thinks about the full system view,
end-to-end, all the steps between
ideation and delivery,
and it thinks about, well, I might be
in the middle of one of those steps,
I'm a software developer and I work with a tester
who's able to script some automated tests around my code.
That's pretty cool.
Well, who's the first person that consumes my work.
Goodness, it's the person writing the test.
So my customer is very local to me.
My first customer is a person
on the bench next to me, metaphorically,
that's gonna consume the work and that's really important.
So, if we think about, for example, the deployment team,
if we think about IT Service management,
our solutions can't solve any problems for the customer
until it's deployed, so guess what,
they're my customer too.
So let's just use that perspective for a second.
Let's take the kind of traditional view
of a software development shop
approaching this firewall called
we're about to deploy our system into production
and think about here's my customer.
It's the people that are doing the work
to deploy the system.
What are the rules?
Don't overload them.
Don't give them too much work.
Nobody likes that.
Don't make them wait.
Don't force them to do wasteful work.
Don't impose wishful thinking.
Don't say things that turn out not to be true
because you hope they're going to be true.
So if we think about our customer in this context,
we can think about all the steps in delivering value,
and think about every one of those steps
probably has a customer that we need
to apply these rules to.
And that makes quite an interesting paradigm
because it keeps constantly in mind
that the flow through the system
involves addressing customer needs
in a way that satisfies them and engages them in the work.
A few other aspects:
build long-term partnerships based upon trust.
It's not a short-term deal where I got
the lowest possible cost for component A,
for the outsourcing resource that could
develop that feature set,
it's about the total cost of ownership over time.
In order to do that, we want our partnerships
to be based upon trust and mutual respect,
and frankly, good outcome economics for both.
Kotter notes, that cultural change comes last, not first.
To change the culture you have to change the organization.
So we won't start with a cultural flag.
We will not be waving a "here's our new culture" flag
as we head down this path.
Instead, what we will be doing,
is we'll be changing the organization
and achieving a short and sustainable lead time,
and that in turn will start to drive the cultural change
that helps make that persist.
Respect for people and culture.
People do all the work.
Flow.
A relatively newer addition to our knowledge base
if you will.
Not brand new, ten and twenty years old.
But the notion of continuous flow of value,
product development flow,
that hits us through works from Reinertsen,
it hits us through Dev Ops, and the school of knowledge
about continuously releasing value.
So flow really matters.
A few interesting things about flow.
Reinertsen notes that, "Operating
a product development process near full utilization
is an economic disaster."
I'm going to talk about that more a little bit later,
but think about that for a second.
Is your product development process,
your software development process,
your systems builder process, running at full utilization?
Probably.
If so, are you getting the right economics?
Perhaps not.
So lets talk about some additional aspects to flow.
Well, what is it?
We wanna optimize continuous and sustainable
throughput of value.
It doesn't stop, we just do it forever.
There's always work in process,
it's always limited, we're always releasing value.
We wanna get out of the start-stop-start project life.
So I've started the project, we've got an overrun,
we need to rethink that.
Why do I have a project to begin with?
I know I need something to do.
Aren't the people together?
Don't we know who could do that best?
Can't we just feed them that work?
Wouldn't that make sense?
Do I have to create a project to do that?
No project's unsafe.
I already mentioned this, build quality in;
flow depends on it.
Understand, exploit and manage variability.
Now this is different than traditional Lean thinking.
This is not Six Sigma reduction in defects.
We do want reduction in defects, but we also recognize that
I might be building the wrong thing,
or something material might have happened in the marketplace
that cause my current solution
not to become the right thing.
OK, so that variability, we have to harness that
to our advantage.
Integrate frequently.
If you're not integrating you're not flowing.
You're building working process
and assumption-driven code that hasn't yet been deployed.
And informed decision-making via fast feedback.
We'll talk a lot about fast feedback in the next module.
Innovation.
This pillar of Lean is an interesting one,
because it doesn't always exist as a pillar,
but it exists in SAFe for a reason.
We wanna call out innovation specifically.
A few interesting kind of aspects
or perspectives on innovation.
Number one, Deming notes, that, "Innovation comes
from the producer."
I'm a user of an iPhone.
It's not my job to drive their innovation,
it's their job to move me to places
that I didn't even think about.
So, the net summation of all customers inputs
does not make a strategy.
That doesn't drive innovation.
Sometimes innovation causes you to move a customer
to a place where you need them to be
and they need to be, that they may not be
quite ready to go.
So innovation comes from the producer.
However, as Eric Ries notes in the Lean startup work,
yes, producers innovate, but customers validate.
So that's the feedback we need,
the fast feedback that I mentioned earlier
that allows us to make sure that our innovation is tracking.
It's not a decent innovation until we get feedback.
I use very few words from Japanese to describe Lean,
but here's one: Gemba.
Gemba, I think, is one of the most important words
in Lean thinking, particularly with respect to innovation.
Gemba means you have to know what you're talking about
from the customer's environment.
Gemba is the place where the work is actually performed.
So, for example, if you're watching TV in Japan,
you're reading the translated captions,
you might see a detective at the scene of the crime
call his boss and say, his boss would say,
"Where are you?" and he would say, "I'm in Gemba."
What's that mean?
Gemba means, I'm standing right now
where the crime has occurred.
I am literally at the crime scene.
This is where the crime occurred.
So there's no ambiguity, I'm not hearing this third-party,
I'm witnessing with my own eyes what it is.
We talk about Gemba a lot.
We talk about the need to be in Gemba.
There's different types of Gemba.
If you're in the process of producing courseware,
there's a process that works there
and people that work there, that's their Gemba,
but that's not the customer's Gemba.
The instructor's Gemba is the class.
The student's Gemba is the environment they work in,
so get out of the office, get into Gemba,
because as Taiichi Ohno, one of the godfathers of Lean said,
"No useful improvement was ever invented at a desk."
So we think about Gemba constantly.
We're always on the look for opportunities to be in Gemba,
we always ask ourself, is that an opinion
that we created here in the office,
or did that feed directly from Gemba?
A few other things.
Provide time and space for creativity.
We have to be careful that the Agile
Tyranny of the Urgent still allows you to think.
It's OK to think in Lean development and Agile development.
We may have to even provide time to think.
Hackathons and things like that.
Apply innovation accounting.
This is a very important principal.
We can't go very deep here,
but you can read about it on the site
when you look at some other things
we're gonna talk about soon:
minimum viable products and minimum marketable features.
A challenge we have with ROI
as a metric that we use to measure business performance
is it appears really, really late.
The R appears so far after the I
that it's simply too late.
So if you don't get the right amount of R
there's nothing you can do about it
because you're already down the road a little bit.
Innovation accounting addresses that.
We'll talk about MVPs and minimum marketable features
and every one will say, how would I measure
that I'm getting the right trend for the feedback?
Are people using that feature?
Are we getting any downloads?
Is what we're doing making any sense to the user?
And then lastly, I think this word came
from Lean Startup, I'm pretty sure,
pivot without mercy or guilt.
What does that mean?
It means that you learn new things, OK.
You should never be in a situation where you're saying,
here's what we've learned in this situation
and we need to make a change based upon learning,
where people are going, well you should have known all that.
Well you might find yourself in that situation,
but yeah, well maybe I should have known it, but we didn't.
We collectively didn't know that.
So when we pivot without mercy or guilt it says,
that was a great learning,
we just invested X-thousand dollars,
or this much time, or this many million dollars,
and this initiative, but we've learned
that that's not really where we wanna go
and we need to pivot, and no guilt, no mercy,
we're going to make a change
based upon the fact pattern that asserted itself.
Very important kind of key elements
of thinking about innovation in the house of Lean.
Relentless improvement.
Lots of feedback on lots of slides, we get it all the time,
and somebody said, do you really mean danger?
Are we really trying to scare people here?
Well, number one, I didn't make this up.
This came from, I think it was one of the chairman of Toyota
about a decade or so ago,
and I ask my students, students in class like you,
are you in a competitive market?
Everybody raises their hand, yeah.
Do you have some birthright
that says you're guaranteed success?
No.
Are you kind of on the edge of the seat
about what the competitors could do
or how the market might change
to make your job, your solution, your company less viable?
If so, that's OK, because that constant sense of danger
will inform you.
I always think of Bill Gates with his constant sense
of fear and danger
and just downright paranoia
about the fact that the Windows franchise
would be taken away from him
and they aggressively defended that,
that constant sense of danger.
Have to optimize the whole, not the parts.
A key part of systems thinking
is when you optimize a component of a system
it does not optimize a system.
It could even make the system behave differently or worse.
Consider facts carefully and act quickly.
So, two things: careful consideration, quick decision,
like pivot without mercy or guilt.
Lots of Lean tools and we'll talk about those
through this course, to identify and address root causes.
This is a key part of relentless improvement.
You need the tools to be able to do that
and it's not simply a matter of
what went well what didn't?
That's a good form of retrospective,
but deep dives into corrective action
and really understanding the root causes
of the things that are causing those issues.
And of course, just like in Agile,
reflect at key milestones; identify
and address shortcomings.
You're seeing many things here
that also occur in Agile.
For example, that's a part of the Agile manifesto.
So while these are different perspectives
and each brings a lot of value,
they share certain common elements.
And I think that many of these elements appear
in both our Lean and our Agile thinking.
Leadership.
You might see some houses of Lean
that say management foundation or management support,
one of the ones that I found
when I was building this class many, many years ago,
said management support.
Nah, it's not enough.
We can't be supported, right?
We need our managers to lead.
Like Deming said, they must know what it is they must do.
So it's not a matter of, hey you folks
have my support for this.
You need that too.
It's, you have my active involvement.
What can I do to help make this thing a reality?
What impediments are in your way?
What might prevent you from being successful with that.
So we need you, in other words, to lead the change.
Why?
Deming notes, "People are already doing their best;
the problems are with the system.
Only management can change the system."
OK?
Everybody's doing their best.
I go into my office and look around
and people are working hard.
Sometimes we don't always get the results that we want.
Did I see that person goofing off?
No, I didn't see that, I saw them working really hard
and frankly getting frustrated.
There's something wrong with the system.
We need leadership to be able to change the system,
and in order to that we have to know the way.
We'll talk a little later on about life-long learning
and leader's role and responsibility to show the way.
We're building systems now that we've never built before
with technologies that are literally just a few years old,
maybe to a decade old max,
even if that solution has been built
in some other company, it wasn't your company.
So when you emphasize life-long learning
and you become a leader who is constantly
advancing their skills and knowledge set,
others will follow that model.
That's what leaders do, leaders lead.
We develop people.
We work on the systems and we advance the systems,
but we develop the people with the skills.
Inspire and align with mission;
minimize possible constraints.
This is a key element of Lean as well.
What are we trying to do?
Take that mountain, deliver this system.
A good talk by an executive in this area says,
here's the mission, there's a trade show deadline,
there's a market window, we wanna build
the best possible system we can to achieve that,
now what can you do?
We know you wanna do great work, how can you achieve that?
So we wanna do that, well we wanna minimize constraints.
And oh, by the way you can't do x, y, z, (mumbles).
There are some things you can't do.
You can't violate security protocols,
and safety protocols and things like that,
there are constraints, but the leaderships job
is to minimize the constraints and make sure
that not every cut you had in the history of the company
has scar tissue to the point
where you've written a procedure
to prevent that from ever happening again.
Because if you do that, you may prevent
that thing from ever happening again,
you may prevent anything from ever happening again.
So we need to be able to minimize those constraints.
Decentralize decision-making.
I'm gonna talk a lot about that.
We're gonna see that in multiple Quicktimes over the course.
And then finally, I'll talk about this as well,
unlock the intrinsic motivation of knowledge workers.
You've hired bright people.
They wanna come to work.
Their whole career is based on building software
and hardware and electronics and optics
and mechanical systems.
They wanna do that.
They wanna build great systems.
We have to unlock that motivation.
That's an entire module in the leadership module
that's in lesson number nine.
So, take a minute and maybe a bit of a homework here.
Assess where you are on a Lean mindset.
How are you on value delivery, are you high or low?
Respect for people and culture, how do you rate?
Great culture, great respect or (groans)
kinda treat people like cogs?
Do I understand flow or thinking about flow?
Do a quick rating and then find somebody else
in your organization.
Share just that slide with them and say OK,
how do you think we're doing here.
Are your scores comparable?
And use that.
Based upon that, network a little bit and say,
this is a Lean mindset, how are we doing on Lean?
Are we there or not?
And if you find an area where, gosh,
we're really struggling with innovation,
we used to be really good at that when we were small.
Then talk about that and say,
well, how would we regain that
and also, take a look at SAFe.
I encourage you to see what SAFe says about innovation
and ways to achieve that.
So that's a Lean mindset.
That's an introduction to Lean mindset
and it's a deep body of knowledge
so I spent maybe 20 or 25 minutes here
on a body of knowledge that goes back decades
and has literally hundreds of books.
We'll talk more in some of the principals
about some of that, but without that Lean mindset,
we're gonna have a really tough time.