hello and welcome to lessen 5.4 minimum viable product value delivery are one
in part. One will talk about determining value and what a minimum buyable product is. And then, in Part two, we're going to get into some of the issues that agile has with providing value to the organization.
I'm your instructor cane, and we will go ahead and get started.
So what is value when we talk about bring the whole point of agile is to bring value to the organization.
What does that mean, Right? So what we want to get away from is the idea that value is strictly financial doesn't mean that it's not financial,
but it's not strictly financial. So we have to determine
what business impact this solution is supposed to bring. What problem is it going to solve? Those are the kinds of things that we get to when we talk about values. So you and if you work for a non profit organization
or you work for the government,
there's still this idea of value. It doesn't necessarily have to be representative represented by numbers on a piece of paper.
That being said
money, especially to the business owner side of the house.
Money is a fantastic way
of measuring value in a universal term that everyone recognizes. So if I were to go to each one of you and say, I will give you a $1,000,000 to do some X Y and Z
you can all get get a rough idea pretty quickly of what
that $1,000,000 means in relation to that. The work that I need you to perform for that $1,000,000. So it's It does provide a universal, um,
value measuring system, but it
it's not. It's not the end
in and of itself if they representation of what that value is for the organization. So obviously, companies like Amazon have put a serious amount of money
into and development time and effort into building Amazon into the global giant that it is today.
But if it was on Li about the money,
then it would be hard to justify
the value that Amazon has actually brought to our society. The value is really wrapped up in their mastery of logistics. How they've changed so many fastest of lives in the in the world, really, with with their offering
so people are willing to exchange
their effort in the form of money to capitalize and leverage things of value that Amazon has brought about. So that's kind of Ah, one way of looking at value. So value can be money
is easy to rep. Mollify should not easy repent in money. But if you can get it into a monetary form, it becomes very easy to make investment minded decisions because everything has been stripped away with the exception of the money. So I teach cyber security
at a local college here
in one of the things I stressed to my students is,
when you're trying to
get game support for your enterprise level cybersecurity projects,
if at all possible,
you wanna have some kind of a number. So we all know where those of us in cybersecurity? No,
there's not necessarily a specific dollar amount that you can represent with cybersecurity, right? How do you prove a negative? Hey, I did a really good job, and none of our organization systems were breached. Oh, great.
But it doesn't necessarily turn into a dollar amount, So part of the trick is
and I'm not gonna suit you have to deep in the weeds on this. But if you're doing saying enterprise level cybersecurity project, you got to start getting a little bit creative. For example, what is the average cost of a breach for organization? That's the size of your organization.
How many of those breaches occur at any given year? Bubble boss. So the value that you're bringing is risk avoidance. In the case of cyber security, you're saying, Hey, invest this money in cybersecurity in order to avoid
future costs from remediation from legal fees, from loss of public prestige, all that kind of stuff. So that's an example of sort of a non traditional way of looking at values, and it's got to be measurable. We'd like We just talked about doesn't have to be money. But if it can be money,
that is the best way to bring that information to the business owner because they
understand money a lot more than, say, reputation or
whatever the case might be on. It's also the shortest time to market, and what I mean by that is
in order to Speed and Angela project up,
you need to focus on getting
the product to market. That's what starts
bringing value to your organization. So if you add a bunch of things to your agile project that are not part of the minimum buyable product,
then you're actually reducing the value that that project is gonna bring to the organization.
And we'll talk a little bit more about that in a later video as well.
So what is minimum viable product? What do I keep bringing this whole thing up over and over and over again?
The reason why I keep bringing it up is because it's super important.
If you don't know what your minimum buyable product is, you don't know what the turnaround time for the projects going to be. You don't know when you're going to be able to provide value to the organization,
so the minimum viable product is the fastest way to provide value. This is really useful. And what really brought agile to the forefront of project management methodologies is because when we have Web based
applications meaning the the U. I is rendered in a browser, so at any given moment I can change anything about my application
and the next time the cash refreshes or the next user that comes in and access is that Web application
is going to see what those new changes were so weak. Don't have toe have these long software development cycles because the the ability to push changes
to the end user is basically infinite. In some cases,
in addition to that, when you're looking at a contract negotiation
you have to have some sort of mechanism. When you go into procurement and you go into contracting some mechanism of identifying
what your minimum
or what the contractors supporting, I'm gonna give you X amount of dollars for why amount of work? What is that? Why Amount of work?
I I have a K personally for delivery Bols based contracts. And a lot of organizations have moved that way. If if they haven't already been doing it for a long time, which is basically, if I'm gonna hire out
and I'm going to go into the procurement side of project management,
I really care how you do what you do. I don't care how many hours it takes for you to do it.
Um, I mean in some ways, that you care. But in essence,
what I'm paying for is a thing it is a deliver, verbal. I want my hands on this thing
typically in this case, functional software
in exchange for a certain amount of money. That way, I don't have to worry about how the sausage is made.
if you don't understand what your minimum viable product is, if you don't understand what the shortest the least number of items there can be in order to bring value to the organization when you have a hard time writing a contract that's going to be legally enforceable
around that minimum viable product, right. So one of the things that is often used in this
area is Moscow pressurization. We've already talked about it
in a previous video, but I wanted to bring it up with this cool in infographics. I really liked the infographic a, um, but it's the idea that
I must remove myself around a little bit. Okay, so this is a really good infographic, because what it shows us is
how big is the bucket and how do we prioritize work? So in this particular case, the folks that that, um, have built this infographic basically, you're saying
the must haves make up 60% of your total effort. So if you grifter budgeting 1000 hours of development,
60% of it must go to the must have bucket, and then you have your should have, which is your better? Really. What the must haves and should have together is what is your business case? That's what's the business problem that you're trying to solve.
And then you have a little bit of slack, a little bit of contingency for all of these Nice toe have features provided that the schedule supports it.
So that is a good way of thinking about it. If you're actually sitting down to do your own Moscow prioritization as part of your minimum buyable product,
the must haves are the minimum viable product.
Then we have this should have, which are the items that we really ought to be able to do. And we're gonna budget sometime for those. And then we have this extra 20% of slack
that we're gonna use for all those nice tohave features and by doing it this way. And I talked to a previous video about agile scorecards.
This is a similar exercise in the sense that by locking yourself into a specific
It helps force conversations during the planning phase as to whether that thing really is a must have or whether it's a should have. Do I need to go live is really what it boils down to. If I don't that is not a must have. It's a must have, maybe at some future point.
And there's different obviously ways of looking at this and different limitations. But it's just a good way of think about it.
And you really want to make sure that you're using some sort of methodology in order to prevent the issues that come from
trying to plan out your agile project
but myself back over there.
All right, So
in today's lesson, we figured we talked about how to how to determine value for the organization, and we also talked about what a minimum viable product is.
Thank you for your time. I look forward to seeing you in the next video