Agile is a buzzword in the industry
right now its used to describe a way of
working on software development projects
and other creative projects. The benefits
of working in an agile way are
well-documented, however some people do
have concerns about entering into an
agile contract and what that might mean
for their business. In this short video
I'm going to share my top tips for
entering into agile contracts and what
you need to be aware of, and hopefully
help make clear some of those issues.
Agile is a term that's used to cover a
broad range of offerings in the software
development world but also in the wider
context of any work done on a time and
materials basis, for software development
or in the wider creative industries. The
first thing to check is whether the
contract for services is actually agile
in the legal sense. An agile legal
contract will cover elements of the way
that the services are provided, or the
way that software is developed, that a
normal bog standard contract -
particularly for software development on
a waterfall method - wouldn't. so that's
the first thing to check, does the
contract properly reflect how you're
going to be working on the agile basis.
Or is it, and this is the worst case
scenario, just a contract for services
and not even a software development
contract at all.
One of the main benefits to running a
project on an
agile basis is it allows a lot of
flexibility, the parties can work
together collaboratively to get to an
end product. That end product might look
very different to what was imagined at
the beginning but by not setting those
functionality points, or those parameters
at the beginning, it means that there's a
lot of creativity that's allowed in the
project to get to what's usually a
better end product. You should be aware that
it also means that there's a lot of
flexibility usually in the budget and
the timeline so make sure that you allow
for that.
If you have a hard deadline when the
project has to be completed, and the
product that you're paying the developer
for has to go live, you can insist on
including this in the contract. Most
agile contracts are drafted in favour of
the developer, quite logically,
and they usually say that time is not of
the essence, that any time agreed is
not a binding term, however if you know
what to look for you can alter this in
your favour and put that hard deadline
into the contract.
The days when you can give instructions
to a software development company in
your initial meeting and leave them to
go and develop a product for you until
they've got something in beta a fast
disappearing. Instead the agile
methodology allows for a collaborative
way of working where the parties are in
continual contact, this usually means
that you'll get regular updates about
how the projects going and your input
will be expected. You're usually able to
see the way the software is developed on
a live platform or alternatively you
might get ad-hoc or regular deliveries
of the software on a weekly or
fortnightly basis in what's called
sprint's. This allows you to nip any
issues in the bud and deal with problems
straight away in the next sprint or the
next stage of the project. You should
make sure that whoever the contact is
at your organization has the time and
capacity to deal with this level of
contact on the project. They'll need to
be giving a lot of instructions and
receiving a lot of information from the
company that you're working with. You
should also be aware that acceptance
testing is a common feature of agile
contracts. The customer is expected to
perform acceptance tests on those
regular deliveries of software code and
you should make sure that your contact
at the company is skilled up enough to
be able to do this.
Will you own the rights to the software
and the rights in the product that you
get at the end of the project? This is
the key question for any agile contract.
You'll need to make sure that you are
going to own the rights in both the
software and the final product. You
should be very wary of entering into any
contracts that give you a more limited
right, or even worse, only a license over
the product or part of the product. Many
developers reuse elements of code, both
generic code and the unique code that
they developed for you, if they've
developed something that's really whizzy -
so they've done a good bit of coding and
they want to be able to reuse that again.
The contract would have to give them
the right to do this specifically. You
should make yourself comfortable with
the fact that this is very common in the
industry and it's likely to happen.
You'll want to make sure that the
parameters around how the developer
reuses code, both generic and unique, are
clearly set out and that this doesn't
affect your intellectual property rights
in the end product.
The majority of software development
projects will use some elements of open
source software. This is software that's
freely available for developers to use.
Much open source software also has the
requirement that if it's used the
developers must also make public the way
that the open source software is used
and the code that results from it. This
can have significant implications for
the confidentiality of the end product
so you should make sure that these risks
are mitigated in the contract. The
contract should also properly reflect
that open source software is to be used
and have some requirement for the
developers are tell you exactly what
open source software is used by the time
the project comes to an end. It's
generally acknowledged that the use of
open source software allows for much
quicker projects, much more efficiency
and for a higher level of technological
development which are all advantages - and
these basically outweigh any risks in
your project using open source software.
Hopefully this video has given you a
better understanding of entering into
agile contracts and what you need to be
aware of. If you'd like any further help
please get in touch with us and if you'd
like to see similar videos please
subscribe to our Channel.
