- So now I'd like to introduce the basic
constructs of the Scaled Agile Framework.
What is SAFe?
Well we like to think of it as knowledge
for people building the world's most important systems,
big systems, cyber-physical systems, satellites,
medical devices, large scale software applications,
CRM systems, the type of systems used everyday,
mission critical systems, systems, banking,
financial services, places where were a failure
of a system is as unacceptable economic consequences.
In order to do that, we've had to scale Agile
to the full program and portfolio level.
What is SAFe?
It's a freely built knowledge base
of integrated, proven patterns for enterprise
Lean-Agile development.
We've learned things in the field.
We've applied Agile at the team level.
We've applied Agile at the program level.
We've applied Agile throughout the enterprise,
and what we've learned we've recorded,
tried to make it available and in an interactive
knowledge base that you can use and learn from every day,
and you can do that for free, there's no pay wall
involved to get to SAFe.
Here's a basic look at the big picture of SAFe.
This is the full view.
We'll show you narrower views later,
or different slices and different perspectives
on the framework.
What do we believe in?
We believe in things like built-in quality.
It's not just a nice to have, it's a must to have.
You can't go fast, the Lean Paradigm
has a explicit understanding that every step
of a process has to build quality in,
because you have revisit steps you're gonna
introduce massive delays and rework.
If we can't execute large scale programs better,
we can't build that satellite or that web service
farm, or that application, quickly and effectively,
we're not gonna have the trust of our stakeholders,
we don't have the trust of our key stakeholders,
that never works out very well for us.
We get that in part by alignment.
We simply all have to agree that we're building
the same thing, it's not a matter of,
so much of, management direction, it's a matter
of management and the teams who build the systems
coming to agree that we need to build
this thing in this way.
And that alignment is really valuable,
is a really valuable commodity and a thing
that we consistently strive to achieve and save.
And transparency, what we wanna build in is trust,
but we can't really program trust into a system.
We can make a system transparent,
so you can know, where you are at any point in time,
and all facts are friendly, all the data is visible.
You can make the right corrections
as an individual practitioner, as a system architect,
as somebody involved in the leadership role,
you know what to do based upon the fact
that you are in alignment, quality is being built in,
and you have transparency in the process.
So, you see a picture here, you see things,
you see people for sure, you see various activities,
you see things like P.I. planning,
or maybe sprint planning, you see the roles
of product owner etc., you see other constructs,
you see features and you see user's stories,
these are kind of common terms.
Let's take a second and do a quick demo of SAFe
so you can see how it's interactive,
and give you a better understanding
of what this knowledge base does for you.
Okay, let's take a quick look at the SAFe website,
and dive deep; I think we can get you a better
understanding of how SAFe works by exercising it
a little bit, and by talking
about it with Powerpoint slides.
We'll have plenty of time for that.
So here we are, arrived at the Scaled Agile framework,
ScaledAgileFramework.com, first thing's first.
You might be working on our prior rev,
and your enterprise may be involved in a 4.0
transformation, so if you want to find SAFe
4.0, click on SAFe 4.0,
and this brings up the full site.
It's still there, everything you're used
to working with, looks like an old picture to me now,
but a few months ago it seemed really fresh,
and really new.
Everything you're working for in 4.0 is there,
but that's not the purpose of today.
We're gonna talk about version 4.5,
so if you're in the the middle of a SAFe 4.0
rollout, you don't have to migrate
to SAFe 4.5 immediately, we support not just the product
and the framework, but all the course we're
associated with version four.
But I strongly encourage you to move,
and this has been the last, almost two years
driving innovations in Lean Startup, Lean UX,
Dev Ops, and Continuous Delivery,
Lean Portfolio Management, and other ways
to think about helping large enterprises
drive innovation as if they were smaller.
So let's take a look at version 4.5.
Now, this is a simpler view, and the reason is
that I chose to display essential SAFe,
so essential SAFe is right here,
and we can navigate essential SAFe,
we can work fully within that particular context,
so if we wanna know something, maybe you were curious
about, what's a business owner,
that seems like a different kind
of construct, who is that?
We'll bring up an article on the business owner,
typically with, hopefully an interesting quote.
This particular one, "It's hard to imagine
"a more stupid or more dangerous way
"of making decisions, than by putting
"those decisions in the hands of people
"who pay no price for being wrong."
We engage business owners in our Agile release
training to make sure that's not the case.
And you can read about business owners,
what they do, if they're engaged in an activity
like PI planning, or you could just click on PI planning
and say what's PI planning, oh that's where
we come together, and that's where the magic
is and say if any talk about the PI planning function,
but I don't want to lose my context,
I was really wanting to learn more about business
owners, so I'll read that full article.
Gosh, I might want to read about Agile Release Trains,
those are pretty powerful things.
"The more alignment you have,
"the more autonomy you can grant."
That's kind of a cool quote.
And we go on down to the specific responsibilities.
All the roles are structured in such a way
that each role highlights the specific
responsibilities of the role.
One way to look at SAFe is people do all the work,
right, we're gonna talk about that real soon,
it's a key principle of Lean.
People do all the work, but what work do they do.
And SAFe is in a sense, a set of responsibilities
and they're aligned, and they work in such
a way that they're interdependent, it's a system
of responsibilities, so if the product manager
does these functions, and the product owners
do these functions, we'll have both kind of
guidance at the program level, and the right
detail that we need to execute at the team level.
So that system responsibilities appears
in all of those articles.
And we'll talk a little bit about business value
later, complex construct now, when we get to it
it's gonna be fairly simple.
That describes the set of responsibilities
for that particular role.
So we'll close that and say well what if
we wanted to know something different,
we wanted to learn about what is continuous exploration?
We click on continuous exploration,
and we come here to, in this case,
a quote by Geoffrey Moore, the fuller pipeline
of continuous exploration, continuous integration,
continuous deployment, additional descriptions of that,
and then details, further description of that process.
We're gonna see this slide a little later
when we talk about continuous exploration.
Most articles have a few figures.
Those figures typically are turn training.
Lots of links, the first mention of any particular
SAFe icon creates a link to that article.
After that we don't bother because it just looks
like too many links.
Talk about the roles and responsibilities
of collaboration, what happens there,
how you build the vision roadmap and on like that.
And then typically, you get to learn more
at the end of every article, there're references to,
I might wanna know about innovation games,
that's a way to do ideation.
I've written a lot about requirements,
and requirements workshops, and basically
processes to explore and elicit requirements from people.
Lean Startup is a key part of our working,
and other things, Gembawalks and Lean UX,
all those references are there for you,
so in your continuous learning journey
that we'll describe later, there's lots
of guidance for that.
So let's step out of that, and talk about
the configurability of SAFe, which was
one of the main release themes of this.
Prior to this, if you go to version four of SAFe,
it is what it is, there's no way to configure it, right?
I can expand and collapse one level, and that
was kind of helpful, and that's our first step
towards configurability, but it didn't give us
kind of the full configurability that we need,
so we don't wanna use that version anymore.
That's kind of old and boring.
We wanna go to the new version,
and here I configure the exact view I need.
In the introduction, we're gonna describe
these configurations briefly, but essential SAFe
is the simplest, we add the portfolio level
to that, we have portfolio SAFe, one more click
we get larger solution SAFe, which we'll explain
in some detail in a later lesson,
totally focused on that, and full SAFe
is really the inclusion of all the above,
so it's full SAFe, you have the full big picture
that might be a lot to think about initially,
I might wanna just start with two arts in a portfolio,
I might be building a big solution, I don't care
about the portfolio, essential SAFe is too small for me,
and it gives you that full set of configurability items.
When you bring up a view with a new configuration,
new articles appear, things like solution context
become important when you're building
a really big system, as we'll talk about later,
so context is the key from that comes
the understanding of everything,
and that's the article on solution context.
So that gives you the basic idea
of the navigation paradigm, a couple
of other things, if you're familiar with SAFe
and what's really is interesting to you
is what's new, click on what's new in SAFe,
and here's an article that Richard put together
that's really good description of the things that are new,
you can see things like essential SAFe
and configurability, innovation with Lean Startup
and Lean UX, Scalable DevOps and continuous delivery,
the implementation roadmap, and a lot
of other important stuff.
This is a fairly long article cuz it has
a lot to say, one of the things it has to say
is we're still backwards compatible with version four.
All the features you've done, you don't have
to redo anything, you don't have to rework
any history, you just can add the new features,
as any good product solution does.
A quick look at the configurations,
you may wanna download posters.
You may say, you know I'd like to put a picture
on my wall of that thing, so we'll go here
and we'll say what do I get?
I'd like this download portfolio SAFe is pretty cool.
Let me download that one, and away it goes
into my folder, and I have a PDF of that
I can print or use, or download any
of the other configurations as well.
Let's go back to the main menu here in SAFe,
and talk about some of the things that surround SAFe.
I'm gonna spend the whole course talking
about these aspects of SAFe: activities,
various artifacts, and various events.
So we don't need to cover that now.
You can go there at any time.
You can click on what we call the spanning palate.
Why is is span, because I could have a vision
that, a team could have a vision, art could have a vision,
portfolio or large solution.
Those things are on the spanning palate
cuz you can use them anywhere.
I'll navigate from full SAFe and show you some other things.
Of course, there's a set of menus at the top,
there's some interesting things at the bottom as well.
Is the blog, we constantly evolve SAFe.
If you look at this article, this is a new blog article,
that says there's new Lean Portfolio
management article in SAFe.
We don't change the big picture very often,
maybe annually or so, but we're constantly
creating new content, so we can do continuous delivery
of content behind the scenes, so if we're not happy
with the LPM article, it was PPM, and we didn't
get it where we wanted, we can continue to work on that,
but when we do, any change we make to SAFe will be blogged.
So we'll assure you that we won't surprise you with things
that are new and different that we don't give you
a chance, in addition I'll tweet that, so @DeanLeffingwell,
you can follow me if you like on Twitter,
and I'll make sure that if there's a change to SAFe
that you need to know about, that'll show up
on your Twitter feed, so we're not gonna surprise you
with some stuff behind the scenes, you're about
to launch an initiative or do some training
and find something new, so that's important,
that's the blog, and we, the blog is fairly informal,
it's easy for us to put up a blog post,
the blog is also organized by category,
so if you wanna find a particular category,
you can search by category and find your way
through the blog.
So that's pretty helpful.
Other particularly deep and rich environments,
the implementation roadmap.
We mentioned that very briefly.
This is actually a series of articles
so this particular article is itself a domain
into itself and has multiple articles with it.
This is the 12 stage implementation roadmap.
We're not gonna go through that in this course.
It's kind of a bridge too far, or too deep,
but you can go and read about it,
and say, hmm, I wonder how we would train teams
and launch the ART, what's that look like,
and click on that article just like any other article.
More and more, there're what we call the subdomains,
which is areas of interest that require additional
content, and additional ways to reach that content,
so not everything can appear on the big picture.
So that's implementation roadmap.
What else is important?
Case studies are important.
We love case studies.
We don't write them, that's our customers' responsibility,
so you see here case studies, consumer product
companies like fitbit, Sony Entertainment, a
big insurance company is Northwester Mutual,
Intel, been with us for years, doing really good work,
Philips, Kantar Retail, a Swiss company, Amdocs,
an Israeli company, AstraZeneca, a Swiss company,
Westpac, Australia's first bank, HP Enterprise,
lots and lots of case studies.
In addition to the case studies these are what
we call stories or honorable mention.
SAFe is being used extensively in the government now.
It's being used in places like the patent
and trademark office, this isn't a case study.
This is the homeland security article talking
about the fact that we've deployed SAFe
in that particular context, in that particular environment.
So the case studies are probably valuable for you,
especially if you're in implementation.
Other resources, let's take a look here
at some interesting things.
Books on SAFe, if you can imagine that we have those.
You could download those posters,
you could go to presentations and videos.
You can see some cool stuff, you can see various
videos of me, there's a really brief executive briefing.
There's Enbar doing SAFe in five minutes,
a bunch of recent interviews I just did some
at Agile 2017, talking about three major topics:
the future of SAFe, impediments to implementation,
and the role of projects and project managers.
What else is fun here?
One interesting thing is it's not a trivial thing
to understand SAFes, so if you go to resources,
you're gonna find the glossary.
And English may not be your first language,
which we don't translate all of SAFe, however
we provide very tight glossary elements,
and these are actually compiled from the site itself.
So this is not a separate project.
This is one of our efforts for DevOps,
to make sure that when we write a thing
we only write it once, so the glossary item occurs
in the article with tags, and then it's sucked
into the glossary itself, so the glossary
is always current, it always matches the articles.
But if this is not your first language,
maybe you wanna translate into your language
so at least you have an idea of what these major items
mean, so if you're a Hebrew speaker,
we have a couple of those, interestingly enough.
Translate to Hebrew, and you can read it in Hebrew.
There're whole hosts here, these are Google Translate,
so before we get too excited we need to recognize
that this is Google Translate's best effort
to translate into Dutch or whatever.
And it's pretty good, and it's virtually impossible
for us to compete with the velocity of that.
So another another form of DevOps for us,
another form of faster time to market
and support multiple language users
was to make sure that the glossary was tagged,
to make sure that every article was uniform
and had a glossary element, that was tagged.
That those got pulled in to a specific page,
and then they could be translated.
So we don't do any manual translations
of glossaries anymore, and we don't do any
manual production production of the glossary.
That's one of our steps toward DevOps,
and more continuous delivery.
I have to change it back to English cuz I can't
navigate this thing in Dutch.
Is there anything else?
Well probably finally there is.
You're gonna wanna know more about SAFe
you're involved right now, in a training course,
we offer additional courses, instructor led training,
things like kind of the bread and butter course
implementing SAFe, this is the four day course,
this is the implementing SAFe course, this
is the four day course for SPCs.
SPCs are trained and authorized and licensed to teach
things like leading SAFe and other courses.
So the course I'm teaching you now
is also taught by other SPCs.
That's where you can go to find,
get help, if you wanted to find out who
is teaching implementing SAFe and you wanted
to find out who that would be in Australia.
And next, let's just say in October, and do go.
We'll see if anybody's teaching that course in October.
The answer is in Australia, no events to display.
So belay that, let's go back, let's try something different.
Let's go back to find training.
Locate a class near me.
Let's make it a little bit easier here.
Let's filter by course, we wanna do implementing SAFe.
We wanna do that in the United States.
We do a search and see what we come up with,
do a little bit of work and here, we have a class
coming up in Houston August 29th, New York City,
Reston, Virginia, more and more if you click
on that class, you can register for that class right there.
We try to make it easy for you to find the knowledge
that you need to be successful with SAFe.
That's it for the demo, let's get back to class.
With that demo, you should have a pretty good understanding
of the interactivity of SAFe, and you can pause this
and go to SkilledAgileFramework.com, you don't need me
to click around, that's we made it freely revealed
and publicly facing, so feel free to browse
and look at your favorite icon or whatever.
A little bit about the history.
On a relative basis, we haven't been at this
too long, I mean, I don't know about you,
but I don't know if 2011 seems like forever ago,
or just last year.
That was when we first released SAFe.
We spent the prior years, five six years
in the field, understanding what was working
in applying Agile at Scale, and we evolved
that through version 2.0, version three, which
is certainly a seminal milestone.
We made a quick branch, we did a big experiment
off to the side with what we called
SAFe for Lean Systems Engineering.
We eventually collapsed that branch into SAFe
because we realized that nobody wants to have
two frameworks at work.
If I'm building a satellite, and there's
a ground station as a giant software,
suite of software applications, it also has
mechanical parts, well I still wanna talk
about the same things.
I wanna use the same basic processes as well.
That brought us to version four, where we merged
those two together.
Version 4.0 was available until about, gosh,
about July of this year, and then, now at version 4.5
we'll spend time in this course teaching
a pretty thorough introduction to 4.5.
But what does this slide imply?
Are you done, are we done?
I don't think so.
Together we're on a learning journey,
we're learning new things every day,
every time any of us goes into the field
we learn something new, and we intend
to continue to evolve SAFe.
I like to make a joke in class sometimes,
I really look forward to version eight,
somebody in class said, well why don't you call
this version version eight, and I said
well that'd just be cheating.
So we're on a path together, we will continue
to learn, we'll continue to apply these bodies of knowledge,
Agile development, and advances in that area,
Lean product development, kinda a late breaking
entry into understanding how to build big systems
in a lean and more agile fashion, how to reduce
the cost of delay, get time to market more quickly,
and then this, somewhat old school of systems thinking,
which is the system is greater than the sum of its parts,
and a part can't even understand
the full context of the system.
We will apply all of those bodies of knowledge together,
and we look forward to future versions.
But for now, we've just released version 4.5,
so let's dive in to that.
I showed you a pretty big picture here,
and maybe it was a little bit intimidating
with all these icons and things flying around the screen,
well they're not flying around, you saw them
fly around when we did the demo,
do you need all of that stuff, that's a fair question.
There's a lot of things there, and I've had
some very bright people, and some very capable CIOs
and VPs of technology come to me and look at SAFe
and say, I'm not sure we can do all that Dean,
we don't argue that we wanna have a better
flow of value through the portfolio,
and we kinda have a rough understanding of Lean budgets.
Do we have to do all of that to succeed?
Well the good news is, no you don't.
And in this version, 4.5 of SAFe,
we're introducing configurability.
The first element of that is essential SAFe,
and that provides the fundamental foundation for success.
I won't go through it in much detail now
because we'll definitely go through these
roles and activities and artifacts,
the things you build as you build systems,
but it is the basic foundational element.
It consists of certain roles, and certain activities.
Things you do, it supports the continuous release
of value through the continuous delivery pipeline.
It describes the DevOps culture, automation,
lean flow, measurement, and recovery,
and it has all the activities we need to build
a big system, and that's this thing here.
That's the solution we're gonna build together.
It combines teams of teams working together
to achieve that, that's essential SAFe.
Again, we'll have lots of time to talk about that further.
Essential SAFe is built on Agile teams, why?
Because nothing beats and Agile team.
I'm on an Agile team, when I teach this class live,
I always ask people, how many people here
are on an Agile team, and typically only about two thirds
raise their hand, maybe half, and I say,
how many wanna go back to not being part of an Agile team?
And nobody raises their hands.
It's just more fun, it's more dynamic,
it's faster, it's quicker, it's more responsive,
being part of a team that achieves value is great.
What are these teams?
They are empowered, self-organizing,
self-managing, and cross-functional,
lots of words, but I think you understand what that means.
Most importantly, they deliver tested, working
system software every two weeks.
Not just a working story, or code chucked
into a baseline, a system every two weeks
like a metronome, here's our new system.
What do you think of it, Mr. Customer?
What do you think of it, management team?
Is this, are we building the right system,
is this the thing we want to build.
As you probably are well aware,
there's been quite a bit of debate in the industry
over the last decade, it's like don't we like Scrum.
I like Scrum too, we think Scrum is great,
we love the time boxes, we think more in continuous
flow here, we think Scrum has too much structure
or too much rigor around it.
We'd like to have a continuous flow of value,
we like to use Kanban.
Well I attended a Scrum class, and I attended
a Kanban class, and nobody ever talked about
the actual process of creating code,
for that we need extreme programming.
So this is not a case where we're gonna pick
are we going to use Scrum, are we gonna use Kanban,
are we gonna us XP, we're gonna use them all
in the context that suits us best.
So this is the year, 2017 now folks,
and it's time to move past the method wars
about which team level model works best
and employ the best aspects of all of those
to deliver value more frequently.
Okay, maybe I fibbed a bit.
Something does beat an Agile team,
and that's a team of Agile teams.
There's nothing like the cooperative and collaborative
nature of a group of teams that are working
together as a team of teams,
to deliver value, and now the stack gets bigger,
the system gets bigger, the excitement goes up.
So you might think, well I really liked being
a stand alone Agile team and I had this great
little local environment, but I can only create
this much of a system, could only create a few features.
What if we worked together and combine
your system with my system, and we build
a great great big system, that we spend much
of our time building my piece, and the rest
of my time making sure that the pieces work together,
build a much larger system, that's more fun too, frankly.
So being part of an Agile team,
being part of a team of Agile teams, is a kick.
Also self-managing and self-organizing.
Also delivering fully tested system
increments every two weeks.
Need some things to help with that,
some vision, architecture, UX guidance, you saw
Lean UX on the picture there.
We need a couple other things as well.
We're gonna need to operate on a common cadence,
cuz this is gonna be pretty awkward if our cadences
are different, if this team is operating
on this cadence, let's say they're going really fast,
these guys are a little bit slower,
they don't line up, but when can I integrate my stuff?
I'm in the middle of an iteration,
or sprint here, they are too, they're towards the end,
it's hard to integrate, and until you get you're
complete continuous integration act together, you're
gonna wanna create the points at which you do demonstrate
that full system, so we'll align those teams
to a common set of system increments.
On the ways of estimating, does estimating create value?
Well that's a fun subject, that'll be a discussion
we'll have a little bit later.
But face to face planning for collaboration
and alignment; we're gonna hafta figure out
how to get these people to use that same
basic practice as we meet face to face to do our planning,
we wanna meet face to face to face to face
to make that team, to help that team of teams
to align and work towards a common vision.
Portfolio SAFe, so we take essential SAFe,
which is this lower level here which I described
earlier, and we add to it portfolio constructs.
Not everybody has to concern themselves with that,
we operate in a lot of environments where
they're building, you know, mission critical
systems that's part of a portfolio,
but the portfolio flow of work is not their concern.
However for many of the rest of us it is a concern,
and we need to think about how we'll align
our vision with the enterprise vision,
when we have artifacts to help us do that,
how we apply a much leaner budgeting construct,
and how we influence these various value streams.
Think of value streams as simply teams of teams
working together to deliver value of a type.
How we align that with various types of other artifacts.
So we'll spend some time talking
about portfolio SAFe for sure.
That helps us align strategy and execution.
Large solution SAFe is a new configuration.
Now what I've described here are the out of box
configurations, you saw in the demo there
that I would click a configuration
and show one configuration or another.
These are those configurations.
Large solution SAFe is kind of what grew out
of SAFe for Lean Systems Engineering.
When people that were literally building
satellites and defense systems
and large medical systems, and MRI systems, etc.,
said we like what you're doing in software.
You're providing a lot of helpful guidance,
but guess what, that's not exactly our problem.
We're building an MRI system, and yes we have
millions of lines of code, but we also have
thermal considerations, and we have electrical
properties, and optical properties,
and all kinds of things we have to worry about.
So we need some more help with that.
So we worked with those people for, gosh, I think
about a full year, and the sandbox called
SAFe for Lean Systems Engineer,
and we started talking about things like
how do you know what the solution's supposed to do?
Do we just code it and hope it works great
and record everything in a test case?
Or is there some amount of intent for the solution?
Is everything known, or are some things for sure known?
There's a fixed requirement to do this,
have to be able to support for people on that ride,
or have to be able to have to be able to have
a satellite resolution, a satellite camera
resolution of X, but some of which is variable.
Goodness, maybe I can do interpolation
of that data to achieve an apparent higher resolution.
Other things, what happens when we have
many ARTs that are necessary to build
that satellite system?
Well we're going to build a solution train,
a virtual organizational construct,
that brings the ARTs and suppliers together,
and uses typically different language
to talk about the things we need to do
to evolve that system.
We're going to plan before the ARTs,
and probably a little bit post planning,
to make sure that what we planned here makes sense
across all the ARTs, and vision, imagine that this
is a 3-D plane, with another ART behind that.
That's the large solution level.
And that allows us to coordinate our ARTs
and suppliers again, with this
virtual organizational construct.
We'll talk about virtual versus line organizations
a little later on in the course.
Full SAFe, okay well what if I'm building
a satellite and a big software system,
and I want all of the above, so maybe an example
would be, I'm building an automotive entertainment
system for one of the big automotive suppliers,
and my context is I'm building this infotainment system.
Okay, that's great, so I have for my customer
who's out here, this guy here, I have a specific
set of requirements to build that system
in a way that meets their needs.
That's fine.
Is that my only concern?
No, it turns out that this system,
the solution, is also part of my portfolio,
so I don't just ship it to that customer,
so I have to have more than the large solution context,
I need to be able to understand how that plays
in the portfolio.
So if you're in a circumstance where you're
building large solutions, that are sold
not just to a single entity,
a single user, but to multiple customers,
then you're going to have both the large solution
and the portfolio contexts.
So like I said, full SAFe has it all.
So navigable, everything's the same,
you can operate with any of these configurations
that we described with no fear of losing
any of the value.
You've seen a few other things over here.
You've seen this tool palette move around a little bit
or actually expand and collapse based
on the things you might need in that case.
You've seen the foundation not changed,
because the foundation is the same
in all the configurations of SAFe.