The purpose of this article is to add some practical
experience of Agile Contracts, further explain Agile and provide a useful pointer
for further reading to help produce better Agile Contracts.
By nature, Waterfall and Agile methodologies are very
different. The author of the Contract needs to understand the Agile delivery
method in order to build in suitable milestones and progress measures.
Software delivery failures
Projects are the means by which policy and strategy is
implemented. Making a success of projects involving information systems is
especially challenging. Decades of IS project management have failed to
guarantee project outcomes, and new methods have not yet had an impact on complex
and large projects.
The research clearly demonstrates that the larger the
project the more likely it is to fail, to run over budget, or to deliver less
than was required. The research also shows that the performance of large and
complex projects has not improved since records were first captured in the
1960s.
|
Project Size |
Scale |
Successful |
Challenged |
Failed |
|
Mega |
Over $100m |
2% |
51% |
47% |
|
Grand |
$10m to $100m |
8% |
51% |
41% |
|
Large |
$6m to $10m |
19% |
51% |
30% |
|
Medium |
$3m to $6m |
18% |
54% |
28% |
|
Moderate |
$1m to $3m |
39% |
49% |
12% |
|
Small |
Under $1m |
70% |
25% |
5% |
‘Situational Incompetence: an
investigation into the causes of failure of a large-scale IT Project’. Darryl
Carlton PhD
Pro
The Fundamental Difference between Waterfall and Agile
The traditional definition of ‘on time and within budget’ as
a measure of success of an IT project is very misleading. A project can be on
time and within budget but not provide the customer or end-user with what they
set out to develop. A more accurate measure would be ‘does the development meet
my perceived need?’. The perceived need often changes when the end-user is
given some sight of the deliverable. In a Waterfall project the first sight of
the deliverable is often at the end of the project in the User Acceptance
Testing. In Agile projects the viewing of the deliverable is provided
throughout the life-cycle of the project. A Product Owner, embedded in the Scrum, can
and will defer to the Business Sponsor and Users and will constantly refine
their requirements. Another technique to refine requirements in-flight used in
Agile Scrums is to conduct ‘Show and Tells’ when the development is at a stage
to be confidently shown to Subject Matter Experts (SME) or users.
At this stage the requirements can be refined. If the
refinement is considered to be too large to fit into the ‘committed’ Sprint
then the change can be put back into the BackLog for a subsequent Sprint. In a
traditional Waterfall project the customer and end-users do not see the
application until the end of the project. By then the requirement will have
changed, and the end-result will not meet the business needs.
By time-boxing stories into Sprints, and knowing the backlog
at all stages, prioritising the stories within Sprints and having an embedded Product
Owner and end-user inclusion with the Sprints, the risk of producing a delivery
that does not meet the user requirements is much lower.
The project may run out of budget with a sprint to go, but
having prioritised and delivered the critical stories early, the remaining
stories are of lower risk and a decision can be made from a knowledgeable
backdrop as to how to move forward. Also, at this stage some meaningful
deliverable will have been developed and can be used, meaning unlike Waterfall
a large portion of the project has been delivered and not all of it is wasted.
Cone of Uncertainty
The Cone of Uncertainty
The Cone of Uncertainty shows that at the start of the
project the scope of the project is woolly and only over the project lifetime
does scope become understood. With a traditional waterfall approach the
requirements can change widely from the projects inception. Waterfall dictates
that the requirements are not changed during the project but a Change Request
(CR) is raised and developed after the project is completed. A typical
waterfall project will have a number of CRs raised through its life-cycle.
Agile is more flexible. Very few Agile projects are pure
Agile. Pure Agile requires Continuous Integration. Continuous Integration means
that small, often discrete chunks of the project deliverables are deployed into
Production. In reality, it is true that the software is deployed to Production
in small deliverables, but the software is not turned on. It may be that it is
deployed but waiting for further deliverables before the software is turned on.
For Continuous Integration to succeed a regression testing
step is needed prior to deployment. Before the software is integrated into the
Production site it should run through a growing and evolving regression pack.
Automation in this area is becoming increasingly fundamental to providing an
Agile delivery and the level and nature of the automation being used needs to
be specified in the Contract. Also an impact statement needs to be undertaken
to determine the risk if automation isn’t used or doesn’t work. Automation is a
dependency in the Agile Project.
The regression pack reduces the risk of the Production suite
breaking with the introduction of the new integrated software.
‘Continuous’ in the context of Continuous Integration can
mean a number of things depending on the flavour of Agile that has been adopted
by the development teams. This should be defined in the Contract. ‘Continuous’
can refer to a daily integration of the developed and tested product into
Production, or it can mean that the software delivery can be deployed at the
end of every Sprint. There are different variants depending on the Agile used.
Risk-based Sprints
The contract for an Agile project must be far different from
a Waterfall contract. A book by Susan Atkinson and Gabrielle Benefield entitled
Flexible Contracts describes the creation of Agile contracts. Susan gave a
presentation to SCL members in 2010 on Agile Contracts, has written or
co-written various articles
for SCL and the new book provides a great framework for writing Agile
Contracts.
With Agile projects, the risk of failure is less than with
Waterfall projects. Failure in this context can be defined as not meeting the
customers need. Even the risk of ‘on time and within budget’ is reduced with
Risk Based Sprints.
A traditional scenario in a Waterfall project, is where the
project is 66% through but has run out of days and money to finish. Testing is
told ‘you need to perform your testing in half the time’. The response of the
test manager should be ‘Ok, which half of the system do you want tested and
which half is not to be tested’. This creates a huge risk and leads to project
failures on a catastrophic scale.
Agile Team Members
The Product Owner is an essential difference between
Waterfall and Agile methodologies. The Product Owner is the key representative
of the Customer. As a Subject Matter Expert they are responsible for communicating
the Customer’s vision of, and requirements for, the project to the Development
Team.
The Product Owner will also take primary responsibility for
the Product Backlog, including its initial development and its ongoing revision
during the project.
They will participate in meetings with the Development Team
during each Sprint, including meetings called to assess developed items. In a
well-run Agile project, with a Product Owner embedded in the scrum, the risk of
impacting the quality of the testing, reducing the coverage tested and working
long, extra hours resulting in more human error will be avoided.
A Scrum relies upon three key roles: A Scrum Master,
Development Team and a Product Owner. At the start of each Sprint, these key
team members determine what will be developed, tested and committed to in the
Sprint. The team will decide and commit to what can be achieved but selection
of the priority stories is predominately decided by the Product Owner. This
process ensures that the stories selected are the items that are required.
Typically, a project will be made up of a series of Sprints.
Often, though it is not mandatory, with a production deployment at the end of
each sprint (after a regression test). This will depend on the style of Agile which
is adopted.
The Contract Model
The
Evolutionary Contract Model
An Agile project, run properly, will reduce but not remove
the risk of the software delivery going wrong. Adoption of the techniques above,
such as risk-based prioritisation in Sprints, embedded Product Owners and
on-going business inclusion within the software delivery lifecycle, will reduce
risk.
This does not negate the need for a contract being drawn up.
Using a flexible contract or an Evolutionary Contract Model will best fit the
Agile approach, as compared to the traditional Contract Model.
As mentioned above, three fundamental roles for a Scrum are:
A Scrum Master, Development Team and a Product Owner. A key part of the Agile
Contract is to apply some rigour around roles.
Product Owner
Key issues to be addressed in the contract
- The Product Owner is the representative of the Customer,
nominated and appointed by the Customer and named in the Contract. - Assurance may be sought by the Supplier from the Customer
that the nominated Product Owner is suitably experienced in Scrum development
projects. - The contract should set out the key responsibilities of the
Product Owner, including:
- the initial development and prioritisation of the Product
Backlog; - the ongoing revision and re-prioritisation of the Product
Backlog as the project develops; and - participation, on behalf of the Customer, in the relevant
Scrum planning and review meetings
- The importance of the Product Owner role in the overall
project, should be reflected in the Contract and the contract should require
the Customer to use reasonable endeavours to ensure that the Product Owner:
- dedicates a reasonable amount of their time and efforts to
the above activities; - responds to questions from the Development Team as soon as
possible; and - is not removed from the project without good cause.
The Development Team
Key issues to be addressed in the contract
- The contract should identify the proposed Development Team
- Each member of the Development Team should be appropriately
skilled and experienced to carry out the development project. - The Customer is entitled to confirm whether or not the
proposed Development Team is acceptable. If the proposed team is not agreed by
the Customer:
- the parties should use reasonable endeavours to agree the
composition of the Development Team; and - if the parties are unable to agree the Development Team
within a specified period, then either party should be able to terminate the
contract without liability.
- The Supplier should ensure that each member of the
Development Team:
- is dedicated to the project during the development period
(unless otherwise agreed); and - is not re-assigned from the project without the prior
written consent of the Customer.
The Scrum Master
If a Scrum Master is to be used in the project then the key
role of the Scrum Master in the contract should include:
- The contract should identify the proposed ScrumMaster and
set out the level of skill, experience and qualifications required of any
ScrumMaster. - The key responsibilities of the ScrumMaster should be set
out in the contract. - The contract should require that the ScrumMaster:
- is dedicated to the project during the development period
(unless otherwise agreed); and - is not re-assigned from the project without the prior
written consent of the Customer.
Conclusion
Projects run in any variation of Agile require a different
form of Contract. The Traditional Contract will not fit. Transparency of the
BackLog, Velocity and Issues Register will provide early signs of any issues.
As with all Contracts the work is needed up-front. The
contract should clearly define the Scrum Structure, such as the Sprint
Duration, the Deployment/Integration requirements, the Agile Team structure,
with particular concentration on the Product Owner. Milestones, deliverables
and Stage Payment points.
Simon Worthy LLM MBA is an IT Consultant with extensive
knowledge in Agile working for IT Probity and a member of the SCL
