Test Management and Contracts in Agile Environments Assurance with IntelligenceSlide 1 Paul Gerrard...

24
Test Management and Contracts in Agile Environments Assurance with Intelligence Slide 1 Paul Gerrard Gerrard Consulting 1 Old Forge Close Maidenhead Berkshire SL6 2RD UK e: [email protected] m w: http://gerrardconsulting. com t: 01628 639173

Transcript of Test Management and Contracts in Agile Environments Assurance with IntelligenceSlide 1 Paul Gerrard...

Test Management and Contracts in Agile

Environments

Assurance with IntelligenceSlide 1

Paul GerrardGerrard Consulting1 Old Forge CloseMaidenheadBerkshireSL6 2RD UK

e: [email protected]: http://gerrardconsulting.comt: 01628 639173

Agile approaches are well-established “Customer Collaboration over Contract

Negotiation” sounds great as a value But none of the Agile principles provide

guidance on how contracts are created Contracts are tools for promoting ‘good

behaviour’ in project participants Lots of advice available, but are there

some universal Axioms or principles we can apply?

Introduction

Agile Values and Contracts How Testing Helps Agile Test Axioms and Contracts Test Axioms Worksheet Summary

Agenda

Assurance with IntelligenceSlide 4

Disclaimer

I am not a lawyer!These notes are based on my own experience in a range of projects.

Use them at your own risk.

Agile Values and Contracts

Assurance with IntelligenceSlide 6

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan 

There is value in the items on the right, but we value the items on the left more. 

Agile values (from agilemanifesto.org)

Assurance with IntelligenceSlide 7

Agile principles (from agilemanifesto.org)1. Our highest priority is to satisfy the customer

through early and continuous deliveryof valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Assurance with IntelligenceSlide 8

“Customer collaboration over contract negotiation” could mean:- Rather than write contracts, we’ll

communicate with our customers better

- Therefore we HATE contracts! But this distorts the meaning of the value The value promotes the importance of:

Shared goals and constant communication

Agile v contracts

Assurance with IntelligenceSlide 9

The Agile values discourage…- Developer and customer taking ‘positions’

- Negotiating a commercial ‘middle ground’

- Freezing people’s attitudes towards fixed goals

And encourage…- Developer and customer are collaborative

roles

- Goal-setting as ‘part of the process’

- Flexibility to change is the key to success.

Agile behaviour

Assurance with IntelligenceSlide 10

How Testing Helps Agile

In the following slides, I use the term INTELLIGENCE to refer to the information and evidence that is provided by testing and

testers

Agile principles and testing

Assurance with IntelligenceSlide 12

Principle Where testing fits in

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Early and continuous delivery of INTELLIGENCE of valuable software. Testing must link to and demonstrate VALUE.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Changing requirements, however ‘welcome’ will be reduced by providing EARLY test INTELLIGENCE for more reliable decision making.

3. Deliver working software frequently, from a  couple of weeks to a couple of months, with a preference to the shorter timescale.

Need to provide test INTELLIGENCE RAPIDLY with flexibility.

4. Business people and developers must work together daily throughout the project.

Better, faster appraisal of the status of delivery through ACCURATE, TIMELY INTELLIGENCE.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

See above.

6. The most efficient and effective method of  conveying information to and within a development team is face-to-face conversation.

Maybe, but developers need INTELLIGENCE to support or justify their proposed approach or position.

Agile principles and testing 2

Assurance with IntelligenceSlide 13

Principle Where testing fits in

7. Working software is the primary measure of progress.

Delivery of test INTELLIGENCE is the only way to demonstrate progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Delivery of INTELLIGENCE must be EFFICIENT.

9. Continuous attention to technical excellence and good design enhances agility.

Continuous attention to EVIDENCING progress…

10. Simplicity--the art of maximizing the amount of work not done--is essential.

Achievement of test INTELLIGENCE is a SUFFICIENT requirement so should be delivered as a PRIORITY.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

Part of the belief system.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Only with evidence of ACHIEVEMENT can effectiveness be assessed.

Mary and Tom Poppendieck (http://www.poppendieck.com/) articles/presentations

Jens Coldewey, cutter.com, “Outsourcing Agile Contracts”, “Contracting Agile Projects”

Kent Beck, Dave Cleal, “Optional Scope Contracts”, http://www.jarn.com/about/OptionalScopeContracts.pdf

Nora Sleumer et al., “Pay Per Use Contracts” see Poppendieck site Martin Fowler, several bliki posts, www.martinfowler.com/bliki Alistair Cockburn, “Agile Contracts”, www.alistair.cockburn.us DSDM Consortium, “Sample Agile Contract”,

http://www.dsdm.org/products/contract.asp Quinary, “Optional Scope Project description”, see Poppendieck site Mountain Goat Software, “Writing Contracts for Agile

Development”, http://www.mountaingoatsoftware.com/article/view/5-writing-contracts-for-agile-development

Lots of references to “Fixed Price Contracts and Agile” on the web. “They do work…”, “They don’t work…” etc.

Other references to Agile and Contracts

Assurance with IntelligenceSlide 14

Test Axioms and Contracts(see Axiom Slides)

Assurance with IntelligenceSlide 15

Each Axiom has a corollary (i.e. “If you don’t do this or ignore the axiom…”)

Usually six questions (you can add your own?)

For each question:- What project behaviour am I expecting?- How do I encourage that behaviour?- How do I instill that behaviour?- How do I enforce that behaviour?

This should give you the text you need to agree in a contract – just edit it together.

Sixteen Axioms

Assurance with IntelligenceSlide 16

No – ALL testing is Context-Dependent You need to understand your own project,

it’s goals, team culture, constraints, the ‘art of the possible’ etc. etc.

Every project, goal, culture, constraints etc. are UNIQUE

Only YOU can evaluate these to answer the questions

So let’s look as an example Axiom and questions.

So, you aren’t going to GIVE me some text for an Agile contract?

Assurance with IntelligenceSlide 17

Stakeholder Axiom:Testing needs stakeholdersSummary Identify and engage the

people or organisations that will use and benefit from the test evidence you are to provide

Corollary: You won’t have a mandate or any authority for testing. Reports of passes, fails or enquiries have no audience.

Questions Who are they? Whose interests do

they represent? What intelligence do

they want? What do they need it

for? When do they want it? In what format? How often?

Assurance with IntelligenceSlide 18

The Axioms Worksheet

Show the Word document…

Assurance with IntelligenceSlide 19

Summary

Contracts normally specify obligations and encourage certain behaviours to achieve a goal- Normally fixed costs, fixed timescales and known scope

Agile contracts assume scope is variable- Agile ‘works’ because of close collaboration,

communication and trust Testing is an information/intelligence provision

service Contracts need to specify obligations and

behaviours to deliver most valuable intelligence fast Axioms define a minimum and non-negotiable set of

behaviours for ANY testing context So can be used as the basis of testing in ANY

contract.

Agile testing and Axioms

Assurance with IntelligenceSlide 21

The Axioms specify WHAT should be done It is up to YOU to define HOW it will be done The HOW is a set of agreed processes,

procedures, deliverables, schedule, entry/exit criteria

These practices are context-dependent and must satisfy the constraints of your context- The development process- The skills, capability and culture of the people- The technology available- The time available- The specific needs of your testing stakeholders- Time and cost- Etc.

Using the Axioms

Assurance with IntelligenceSlide 22

Slide 23

The three axiom groupsStakeholder

ValueScopeFallibilityGood-Enough

Delivery

Repeat-TestSequenceEnvironmentEventNever-Finished

Design

BasisCoveragePrioritisationOracle

Testing is an information provision service Work out who your testing stakeholders are- You (as a developer), Developers, Users,

Project Management, Sponsors What do those stakeholders want? How will you (and/or your supplier) deliver

it? Contracts define and enforce behaviours Axioms trigger the right questions to ask.

Close

Assurance with IntelligenceSlide 24

Slide 25

gerrardconsulting.com

uktmf.com

Test Management and Contracts in Agile Environments

Thank You!