- Learning Objective 7.3 Establish Portfolio Flow.
We talked just a few minutes ago about establishing
the funding for value streams.
We kind of pretended that argument that
you're done, you're good to go.
That's the only significant role that the portfolio
plays in funding projects.
That's an oversimplification of the case.
The reality is that no matter how my portfolio works,
and how many value streams I have,
they're gonna be some substantial initiatives
that are gonna affect the portfolio
that need to be driven from a centralized,
strategic theme, or portfolio strategy perspective.
Let me give you an example of one.
Company has a whole series of solutions
and software applications, and they want
to migrate their web server applications.
They want to move from where they are, I won't say
where they are, to JBoss.
They've decided that that is the right economics for them.
So they say, you know, we need to move everyone to Jboss.
That's a really big deal, okay?
That's a lot of money, frankly, because there's
multiple products, and some of those products are
on the wane.
Does it really make sense to go in and make that conversion
in that case, or should be just re-up our old license
for our old app server, instead of converting to JBoss?
Not really sure, but we definitely need
to reason about that.
So we need a way to communicate these large initiatives.
Single sign-on across a suite of products;
things like gosh, we need to create a mobile app
for the first time.
That might come through as a mobile app and
the technology to support that.
So there are portfolio-level concerns virtually always
that influence the entire line of business.
And we need a word for that, and the word that we picked
in SAFe is simply called Epic.
Now in some versions of Agile and Scrum,
an Epic is a thing bigger than a story.
Well it's so much bigger that we didn't use that paradigm.
We used the Story, the Feature, and the Epic.
And I really like the word Epic for that
because it's epic.
And people respect the word because of its very
connotation, that it's a pretty big deal.
And it is a pretty big deal.
So we define these Epics, and they can happen at any level,
but for now we'll just talk about portfolio Epics,
they typically cut across value streams.
Most times the ones I mentioned here, let's
just say migrate to JBoss, 64-byte back-office servers,
build a mobile device.
These are cross-cutting concerns.
There's multiple value streams that get affected by that.
So most typically that's one of the reasons
they're impactful,
is we have to communicate a lot of different things.
At the ART level, we can also have a program Epic.
We can have a big thing, indeed migrate to JBoss
for me might just be move to the JBoss app server
in my application.
That might be fine.
And that's all I really need to know.
But for this conversation we'll stick to the larger ones.
Well, do we program an Epic?
No, we don't even program features, do we?
We program stories.
But now we have a hierarchy.
It's a form of a work breakdown structure.
It's okay to say that word.
It says that this work becomes this work becomes this work.
That becomes a bunch of code and tests
and that's how we achieve that.
So now we have a way to discuss
really, really big things,
really, really medium-sized things,
and small things, in a consistent way.
That taxonomy is really valuable.
As you grow, as your company grows,
as you become more distributed,
as you acquire, as you become acquired,
a common way of talking about the work you need to do
is incredibly valuable.
And that's one of the benefits of SAFe is
it certainly has a taxonomy associated with it.
Most all the words are used in multiple context
and other locations.
That's fine, we just have to create a definition
that works for us, so that we can talk
consistently about that.
Now we're gonna look at where they go,
and we're gonna talk about Kanban system
that we're gonna use to visualize that work.
Before we do that, however, we're also gonna talk about
one of the most critical aspects of
initiating large-scale programs.
To do this I'm going to share a little vignette
that's from my recent history,
that was about the time we were releasing 4.5.
I was talking to a CIO of one of the world's
largest cable companies about frameworks and SAFe.
And he said, you know, I don't really care.
That's an IT thing.
How they build systems is up to them.
He said, all I need to know is what I'm gonna get,
when I'm gonna get it, exactly what it's gonna cost,
what the business benefits are.
Well, we've heard that story before.
In other words, I'm gonna define large initiatives,
I want a guarantee from IT that they're gonna
deliver on time, and the result's gonna be there.
We know the damage of that.
That's the iron triangle big-time, the
biggest iron triangle we can be in.
Scope is fixed, resources are fixed, timeline is fixed.
Do your best.
Okay, we don't want to be there.
We want to be at a much more interactive mode.
So I had a discussion with him because we'd just
incorporated the Lean Startup cycle,
which you can see here in the SAFe.
And I said, give me an example of such an initiative.
And he said, well we're going to accomplish foo
in the next year or so.
And I said, what's the hypothesis behind foo?
And he looked at me funny for a second, and he said,
well, what do you mean?
I said, well what will the outcomes be?
Well, we'll be able to do this, that and the other thing.
We'll have this cool capability, we'll be able to
compete more effectively with another enterprise,
et cetera et cetera.
I said, okay.
What would you have to spend to just prove that hypothesis?
What do you mean?
I said, well would you fund the whole $30 million
under the assumption that you're correct
about the hypothesis?
Well no, we wouldn't have to do that.
We could just spend a portion of that amount of money.
And if we just did this and these cable boxes
and we modified them, and we put them
in a single market place,
we could test this hypothesis pretty cheaply.
I said, okay, so you wouldn't really want to allocate
the entire budget to that Epic, and you wouldn't really
want to take the entire Epic and blow it out
into the big fat business case,
with all these requirements and all these markets served
and all these assumptions.
You'd rather build the MVP.
What's that?
Well, that's the minimum viable thing you can build,
the least amount of money you can spend,
that was his language,
to prove the hypothesis.
And then we'll evaluate that MVP.
We'll look at that MVP and say, did we do it or not?
And if the answer is no, let's not spend the rest
of the $30 million.
Oh no, of course not, we wouldn't do that.
Great, let's stop work.
Great experiment, we tried to innovate, had a good idea,
had a great learning outcome, decided not to do it, great.
You just saved $30 million.
Did you waste 5 or save 30?
I think you've saved 30.
Well what if it works?
Okay, we'll just implement additional features then,
and we'll keep going.
Now I discussed earlier, weighted shortest job first.
That's really a powerful thing.
It's kind of like a magic trick.
If we create the MVP and we launch and we evaluate that,
we then come to the next decision which says,
this is good stuff, let's continue to invest
down this direction.
I want to bring in my new features,
so let me put my backlog over here.
Here's my new feature entering the backlog, okay?
This is the one from the MVP.
This is MVP plus another feature.
Well it's now competing with somebody else's feature.
What if this other feature has more business value?
I want to do that.
So we can kind of go on auto-pilot,
because the system
is going to naturally tend to sort
based upon economic value,
the right features in the right way.
So that MVP, that Epic, will stop
at the time that it's
economically judicious to do so,
and it will stop somewhat automatically.
Now there's smart people making all these decisions.
It's not an algorithm that we plug in,
where people decide that wow, this next thing
on that MVP is really valuable.
That is the next most important one, no problem.
But we don't have to worry so much about
where the edge of the Epic is anymore.
We're just gonna execute until such time as
that feature can't compete with the next one on the backlog.
And that's a really cool thing.
Because it gives us a way to start our major initiatives
with a minimum viable product, established hypothesis,
prove the hypothesis and move forward.
I think hypothesis is a magic word.
It's a magic word that starts to make you
think about things differently.
Even in our own shop.
I had an interesting idea the other day.
People were looking at that and saying,
well you're a pretty big guy here,
if you say it's interesting, we probably should do it.
We discussed it and said, no it's a thought experiment.
It's a hypothesis.
Everybody said, oh okay.
Let's go take the hypothesis and let's
reason about it a little bit
and come back and say,
yeah okay, let's try that hypothesis or a different one.
That's great.
It gets you out of the boss said do foo, and everybody's
launched on foo, and then to the fact when the
cable guy says, hey folks.
What's the minimum amount we can spend
to test the hypothesis?
Can you imagine the reaction of developers
four or five levels deep when they hear the fact that
hey, what do we need to do to prove the hypothesis
of this next level spend initiative.
They're gonna go, boy I'm glad I work here.
Things are really starting to change.
A very powerful notion.
That's what the Lean Startup cycle does.
That's why it was so critical for us to integrate it
with the Version 4.5.
I'll stretch the point one more.
Back to what we talked about when we talked about DevOps.
That small thing, if I can't take that MVP
and get it through the pipeline quickly
because the transaction costs of deployment
are too brutal, I can't do this.
So how do you do innovation without DevOps?
Beats me.
Seems like we have to have DevOps as an optional
continuous delivery pipeline as an optional.
It's part of a larger picture, which is
how I can take what was about to be a gigantic batch size,
and deliver it in little pieces,
and get feedback on each and every feature.
Very powerful construct.
Really happy to have achieved that in 4.5.
I think you can we don't see Lean Startup and
continuous delivery as different things.
Yeah, they're different conferences.
Ten thousand go to each.
And they maybe don't communicate with each other.
We see it as one unifying paradigm.
Big initiatives, small MVP, quickly validated
in the marketplace.
That's the Lean Startup cycle.
In order to support that, you can find on SAFe
this Epic Hypothesis Statement.
For those of you who might have been around
in earlier times,
we used to have the Epic Value Statement,
but it was a little flat.
It kind of said, here's the value, we're sure.
Now we look at it slightly different.
We continue with our more derived
product position statement.
But we look at it a little bit different and we say,
okay, what is the outcome hypothesis?
And then most importantly, or at least equally importantly,
we talk about innovation accounting,
which I mentioned early on in Lesson 3:
The Lean Agile Principles.
How will we know before we've spent all the money,
that the hypothesis is tracking?
A fundamental change in the paradigm of really taking
the concepts of Agile to the full enterprise level
and allow us to flex, invest a little, invest a little more,
decide not to invest.
As we remember, when we pivot there's no blame,
there's no moral outrage, there's no guilt,
it's just the right thing to do.
It's a really big deal to start converting our enterprise
to a truly Lean Agile enterprise,
which has the ability to experiment,
make small experiments, and get feedback really quickly.
An Epic Hypothesis Statement is just a template.
But it really does drive that kind of behavior.
You know, let's take a minute.
Epics are kind of abstract, and kind of hard to think about.
They're just big initiatives.
They're different from strategic themes.
How are they different?
Take a minute right now.
Identify an Epic from one of your contexts.
What is it?
Maybe it's 64-byte back-office servers.
It could be technical Epic, could be a business Epic.
Write it down in this format.
For, who, the, is.
That's a standard format that we use a lot
for defining initiatives and future value.
Now, what's the outcome's hypothesis for that thing?
How will you know that you've achieved the business result
long before the ROI comes in?
What could an MVP be that could validate that?
So what's the minimum amount you would have to do
to prove that your hypothesis is correct?
So take a couple of minutes and write one down.
Doesn't take very long.
I'll check back in in about 3-5 minutes,
and we'll see what you came up with.
Okay, I suspect that you wrote one out.
And you probably had to think a little deeper thoughts
about the MVP and the outcomes hypothesis and
the innovation accounting measures.
Great.
It's a moral victory for all of us.
We're now thinking differently about the problem.
In the same way that we want our executives and leaders
to think differently about the problem.
We don't want to think about big bang, waterfall,
proven business case, guaranteed ROI.
We want to think about the ability to innovate
at the portfolio level.
And SAFe 4.5 delivers that capability.
Now, okay so let's say, how are we gonna approve this work?
Well, okay, we've already allocated the funding
to the value stream, but now we're going to have to
go into that value stream and say, okay, but some of that
has to be allocated to this.
So we want to take that Epic and invest
a little bit more in it.
It's not a simple matter of weighted shortest job first.
That's one measure you can establish with an Epic,
but prioritization requires other things.
Like, where are you gonna get the return,
and what makes you think you're gonna do that.
So if you go to the site and download this free document.
It's a template for the Lean Business Case.
And the Lean Business Case is derived from Lean thinking
and also traditional business case thinking,
but it's two pages maximum.
It will force you to fill in some things like
what's the outcome's hypothesis,
what's in scope, what isn't.
64-byte back-office servers,
well what about for the CRM system.
No, we don't care about that.
Well we care about it we just don't need to upgrade it.
No problem.
Okay, that's out of scope.
It will cause you to think about the parameters of that.
Now you have a thing that's defined that says
now I can consider it.
I want to consider this with respect to what?
By itself?
No, with respect to other opportunities.
In order to do that, we're gonna make that work visible.
And we're gonna exploit the incredible power
and visibility of Kanban, and where necessary,
work-in-progress limits
to make sure that we see the work coming,
we know what the work looks like,
we have a rough idea of the scope,
and we can start to anticipate.
Now maybe I'm down in the trenches as a developer,
and I'm seeing single sign-on in that portfolio.
It's coming my way.
I make decisions every day that could make it easier
or harder to implement single sign-on.
If I know it's probably coming,
I'll make the right decision.
If I have no idea, oh they're meeting independently,
they've got some new ideas up there
but we don't know what they are,
I'm gonna tend to make the wrong decision.
So we build a Portfolio Kanban for this
and then we use that to manage the flow of Epics.
You can see the benefits here.
It makes them visible.
It brings some structure to it.
There's more than one opportunity folks,
so this MVP here versus this MVP here,
which do we think is better.
Also, the fact that it's in a Kanban system says,
you're not working on it yet.
We're doing some analysis work maybe,
we're doing some prototyping work.
But it's not yet being implemented at the ART level.
And that means that we don't have unrealistic expectations.
This particular Kanban was driven by a vignette
where I was working in the field with an
enterprise that was very sharp and pretty Agile.
But because the thing had been defined,
they assumed it was getting executed.
And we went through a planning process to determine
how much they could actually implement,
they were worlds and worlds apart.
They had scoped and committed
probably three or four times the amount of work
that could actually be done by the teams,
because they didn't understand the team's local context,
and they hadn't done the right and proper job of analysis.
Now Kanban systems are configurable.
You can make them be whatever you want.
Our out-of-box one, if you will, has a few simple states.
It is a state called the funnel which is ...
Here's an idea.
If your boss comes along and says,
we should think about this big thing, say
agree with that, I think we should think about it too,
and put it in the funnel.
That's not the same as doing it.
Go through a reviewing process.
We look at the Epic Hypothesis Statement.
What is the Epic and what do we think about that?
Absolutely use WSJF.
WSJF is too light a tool for making $5 and $10 million,
or $30 million decisions.
It's the right tool for making feature decisions,
but it's one parameter of a prioritization scheme
for the larger scale Epics.
We'll move those through.
We'll analyze them, we'll figure out
what the alternatives are.
Different WSJF.
Identify the MVP.
Get them in the backlog and then we'll decide
the go-no go right here.
Are we gonna do this or not?
We'll decide based upon the capacity to actually implement.
And you can have a definition of done.
It might just be that you run the algorithm
until such time as the features aren't there.
Or achieve the business outcomes.
That's totally up to you.
But this Kanban system causes a collaboration
amongst the right people.
We haven't talked about Epic owners yet.
They're just people in the enterprise.
Portfolio people.
Could be program manager, a system architect,
a chief engineer, anybody that has some technical
background and knowledge, and knows how to
get things done around here, big things.
They might take that Epic and babysit it.
Because 64-byte back-office servers are not going to
just magically appear in production, okay?
It's gonna take time to do that.
We're gonna need somebody to shepherd it through.
They're going to work with the teams,
the solution and systems architects,
the business owners and product management,
to determine what the right set of decision is
with respect to getting that Epic done.
Visualizing the highest level work is one of the most
important things you can do in the large enterprise.
Because it gives you a chance to see the big stuff coming.
For most of us, when we take all the ideas that we've heard
back to Jeffrey Moore's statement,
we don't have a really great way to reason about strategy.
So in that office that guy thinks
this is a great initiative and I probably agree.
In that office this person thinks it a great initiative
and he probably agrees.
And the other office there's another initiative.
Nobody argues with that.
But when you add all those initiatives up,
and you pretend like that's your strategy,
you may well be doomed.
Because your appetite is bigger than your wallet,
and you won't be able to fund those things.
If we make that more visible, we're going to put some
regulators on that, so you can see that work
and make the right decisions economically.