My name is Erwin and I want to talk today about the difference between the
products and projects, which is very interesting when we're talking about
Scrum and the context that it's in. So what we sort of have here is
a product and that's of the lifecycle of a product. Right. We started, we work it
and eventually we take the product out of to the market. Usually the way that
we have been developing products is often through projects and so we have
these projects over here that are relatively short-lived to make changes
in that sort of product over here. And what I want to talk to you today is why
projects are such terrible ways of delivering products. And the first thing
that we have is that projects the time horizon of a project is very different
than the time horizon of a product. And that's important. But have you ever
been on a project where a decision was made that was the objectively good for
the project but objectively bad for the product. Everyone has one of those
experience in software development. One of those things is "automated testing" for
example. You don't get the benefit from automated testing inside your project
but obviously there's a massive benefit over the lifecycle of a product. So one
of the challenges that you have with projects to deliver products is that the
time horizon of your project is very different than time horizon of your
product, which leads to sort of weird decisions.
But even more importantly than that is, the success criteria on a project are
very different than the success criteria of a product. When was the last time you
walked into a store, saw something you wanted to buy and then walk to the
counter to sort of pay for it and just before you pay for it you went like:
"Ah, almost forgot. Teller, do you know if this thing was
developed on time, in scope and on budget?". Of course no one has. Because no one cares!
No customer cares about whether your project was delivered on time, on budget
and in scope. So the success criteria are entirely different between a product and
a project. So what projects basically become is this sort of amount of scope,
this amount of work that we've decided up front and whether we can deliver that
within the timeframe that we have. So it's just basically something burning
down that's sort of timeframe. And it almost completely ignores everything we learned
throughout that project. So have a think. Project management has a very
specific term for learnings during a project. And that term is change request.
When you talk, when you sort of think about it like, what is a change
requests? Change request is a change in the scope, we learned that
we didn't want something that we thought we wanted or we learned that we want to
save it differently. So project management has an entire process
dedicated to minimizing the effect of learning on your project. And that's why
projects are such terrible ways of delivering products. The time horizon is
different, the success criteria are different and there is very little
room for learning during projects. Thanks.