The first practice that we just saw goes together with
small releases practice. This idea that instead of having a big
release at the end of a long development cycle, we try
to release very often. And there are many advantages to small
releases and to releasing often. The first one is that
we deliver real business value on a very short cycle. And
what that means is that we get business value sooner, and
that in turn increase our customer confidence and makes the customer
more happy. So more releases also mean rapid feedback. We
release the software soon, we get feedback from the customer soon,
and we can in this way do exactly what we
were saying before, steer instead of driving, adapt weekly to possible
changes in the requirements. We avoid working for six months
on a project and find out six months later that the
customer wanted something else and we got the wrong requirements. In
addition having small releases, so seeing your product deployed and released
soon produces a sense of accomplishment for the developers.
And in addition, it also reduces risk because again,
if we're going down the wrong path, we will
know right away. If we're late, we will know right
away. So these are just additional advantages of having
this quick cycle and more releases. And finally, as we
also said before, we can quickly adapt in the
case our requirements change our code to the new requirements.