Minimum Viable Product/Value Delivery Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
3 hours 55 minutes
Difficulty
Intermediate
CEU/CPE
4
Video Transcription
00:01
>> Hello and welcome to Lesson 5.4,
00:01
minimum viable product value delivery, Part 1.
00:01
In Part 1, we'll talk about
00:01
determining value and what a minimum viable product is,
00:01
and then in Part 2,
00:01
we're going to get into some of the issues that agile
00:01
has with providing value to the organization.
00:01
I'm your Instructor Kane,
00:01
and we will go ahead and get started.
00:01
What is value?
00:01
The whole point of agile is to
00:01
bring value to the organization.
00:01
What does that mean?
00:01
What we want to get away from is
00:01
the idea that value is strictly financial.
00:01
Doesn't mean that it's not financial,
00:01
but it's not strictly financial,
00:01
so we have to determine what
00:01
business impact this solution is supposed to bring.
00:01
What problem is it going to solve?
00:01
Those are the kinds of things
00:01
that we get to when we talk about value,
00:01
so even if you work for
00:01
a non-profit organization or you work for the government,
00:01
there's still this idea of value.
00:01
It doesn't necessarily have to be
00:01
represented by numbers on a piece of paper.
00:01
That being said, money,
00:01
especially to the business owner side of the house,
00:01
money is a fantastic way of measuring
00:01
value in a universal term that everyone recognizes.
00:01
If I were to go to each one of you and say I will
00:01
give you a million dollars to do some X,
00:01
Y, and Z service,
00:01
you can all get a rough idea pretty quickly of what
00:01
that million dollars means in
00:01
relation to the work that I
00:01
need you to perform for that million dollars.
00:01
It does provide a universal value measuring system.
00:01
But it's not the end in and of itself,
00:01
it's a representation of what
00:01
that value is for the organization,
00:01
so obviously, companies like
00:01
Amazon have put a serious amount of
00:01
money and development time and effort
00:01
into building Amazon into
00:01
the global giant that it is today.
00:01
But if it was only about the money,
00:01
then it will be hard to justify
00:01
the value that Amazon has
00:01
actually brought to our society.
00:01
The value is really wrapped up in
00:01
their mastery of logistics,
00:01
how they've changed so many facets of lives
00:01
in the world really, with their offering.
00:01
People are willing to
00:01
exchange their effort in the form of money
00:01
to capitalize and leverage
00:01
the things that value that Amazon has brought about.
00:01
That's one way of looking at value.
00:01
Value can be money.
00:01
It's actually not easy to rep money,
00:01
but if you can get it into a monetary form,
00:01
it becomes very easy to make
00:01
investment minded decisions because
00:01
everything has been stripped away,
00:01
with the exception of the money.
00:01
I teach cybersecurity at a local college here.
00:01
One of the things I stress to my students
00:01
is when you're trying
00:01
to gain support for
00:01
your enterprise level cybersecurity projects,
00:01
if at all possible you want to have some a number.
00:01
Well, those of us in cybersecurity
00:01
know there's not necessarily
00:01
a specific dollar amount that you
00:01
can represent with cybersecurity.
00:01
How do you prove a negative?
00:01
Hey, I did a really good job and
00:01
none of our organization systems were breached.
00:01
Great. But that doesn't
00:01
necessarily turn into a dollar amount,
00:01
so part of the trick is,
00:01
and I'm not going to expect you
00:01
to add too deep in the weeds on this.
00:01
But if you're doing, say, an enterprise
00:01
level cybersecurity project,
00:01
you got to start getting a little bit creative,
00:01
for example, what is the average cost of
00:01
a breach for an organization
00:01
that's the size of your organization?
00:01
How many of those breaches
00:01
occur in any given year? Bubble bub.
00:01
The value that you're bringing is
00:01
risk avoidance in the case
00:01
of cybersecurity, you're saying, hey,
00:01
invest this money in cybersecurity in order to
00:01
avoid future costs from remediation,
00:01
from legal fees, from loss
00:01
of public prestige, all that stuff.
00:01
That's an example of
00:01
a non-traditional way of looking at value,
00:01
and there's got to be measurable we just talked about it.
00:01
Doesn't have to be money but if it can be money,
00:01
that is the best way to bring that information to
00:01
the business owner because they
00:01
understand money a lot more than say,
00:01
reputation or whatever the case might be.
00:01
It's also the shortest time to
00:01
market and what I mean by that is,
00:01
in order to speed an agile project up,
00:01
you need to focus on getting the product to market.
00:01
That's what starts bringing value to your organization.
00:01
If you add a bunch of things to
00:01
your agile project that are
00:01
not part of the minimum viable product,
00:01
then you're actually reducing the value that
00:01
that project is going to bring to the organization.
00:01
We'll talk a little bit more about
00:01
that in a later video as well.
00:01
What is minimum viable product?
00:01
Why do I keep bringing
00:01
this whole thing up over and over and over again?
00:01
The reason why I keep bringing it up is
00:01
because it's super important.
00:01
If you don't know what your minimum viable product is,
00:01
you don't know what
00:01
the turnaround time for the project's going to be,
00:01
you don't know when you're going to be able to
00:01
provide value to the organization.
00:01
The minimum viable product is
00:01
the fastest way to provide value.
00:01
This is really useful and what
00:01
really brought agile to the forefront of
00:01
project management methodologies is because
00:01
when we have web-based applications,
00:01
meaning the UI is rendered in a browser,
00:01
so at any given moment I can
00:01
change anything about my application.
00:01
The next time the cash
00:01
refreshes or the next user that comes and
00:01
accesses that web application
00:01
is wanting to see what those new changes were.
00:01
We don't have to have
00:01
these long software development cycles because
00:01
the ability to push changes to
00:01
the end-user is basically infinite in some cases.
00:01
In addition to that,
00:01
when you're looking at contract negotiation, legally,
00:01
you have to have some mechanism when you
00:01
go into procurement and you go into contracting,
00:01
some mechanism of identifying what
00:01
your minimum or what the contract is supporting.
00:01
I'm going to give you X amount of
00:01
dollars for Y amount of work.
00:01
Well, what is that Y amount of work?
00:01
I advocate personally for
00:01
deliverables based contracts and a lot
00:01
of organizations have moved that way
00:01
if they haven't already been doing it for a long time.
00:01
Which is basically if I'm going to hire out
00:01
services and I'm going
00:01
to go into the procurement side of project management,
00:01
I don't really care how you do what you do.
00:01
I don't care how many hours it takes for you to do it.
00:01
In some ways I do care, but in essence,
00:01
what I'm paying for is a thing.
00:01
It is a deliverable. I want my hands on this thing.
00:01
Typically, in this case, functional software,
00:01
in exchange for a certain amount of money.
00:01
That way I don't have to worry
00:01
about how the sausage is made.
00:01
But if you don't
00:01
understand what your minimum viable product is,
00:01
if you don't understand what
00:01
the least number of items there
00:01
can be in order to bring value to the organization,
00:01
then you have a hard time writing
00:01
a contract that's going to be legally
00:01
enforceable around that minimum viable product.
00:01
One of the things that's often used in
00:01
this area is MoSCoW prioritization.
00:01
We've already talked about it in a previous video,
00:01
but I wanted to bring it up with
00:01
this cool little infograph
00:01
because I really liked the Infograph
00:01
A. I'm actually going
00:01
to move my self around a little bit.
00:01
This is a really good infograph because what it shows us
00:01
is how big is the bucket and how do we prioritize work.
00:01
In this particular case,
00:01
the folks that I've built this infograph,
00:01
basically are saying the must-haves
00:01
make up 60 percent of your total effort,
00:01
so if you're budgeting a thousand hours of development,
00:01
60 percent of it must go to the must-have bucket.
00:01
Then you have your should have.
00:01
The must-haves and should haves
00:01
together is what is your business case,
00:01
is what's the business problem
00:01
that you're trying to solve.
00:01
Then you have a little bit of slack,
00:01
a little bit of contingency for all of these nice to
00:01
have features provided that the schedule supports it.
00:01
It's a good way of thinking about it
00:01
if you're actually sitting down to do
00:01
your own MoSCoW prioritization
00:01
as part of your minimum viable product,
00:01
the must-haves are the minimum viable product,
00:01
then we have the should have,
00:01
which are the items that we really
00:01
ought to be able to do,
00:01
and we're going to budget some time for those.
00:01
Then we have this extra 20 percent of
00:01
slack that we're going to
00:01
use for all those nice to have features.
00:01
By doing it this way,
00:01
I talked of previous video about agile scorecards.
00:01
This is a similar exercise in the sense that by locking
00:01
yourself into a specific percentage,
00:01
it helps force conversations during the planning phase
00:01
as to whether that thing really is a
00:01
must-have or whether it should have.
00:01
Do I need it to go live?
00:01
Is really what it boils down to.
00:01
If I don't, then it's not a must-have.
00:01
It's a must-have maybe at
00:01
some future point, and there's different,
00:01
obviously, ways of
00:01
looking at this and different limitations,
00:01
but it's just a good way of thinking about it,
00:01
and you really want to make sure that you're using
00:01
some methodology in order to
00:01
prevent the issues that come
00:01
from trying to plan out your agile project.
00:01
Put myself back over there.
00:01
In today's lesson, we talked about
00:01
how to determine value for the organization,
00:01
and we also talked about
00:01
what a minimum viable product is.
00:01
Thank you for your time, I look
00:01
forward to seeing you in the next video.
Up Next