The Fragility of Agility: Top 10 lessons to make Agile a success

1

Contents

Why can Agile be so fragile?

Top 10 lessons to make Agile a success

What to do next

2

The problem with the past…

IntegrationTesting

IntegrationTesting

Acceptance

Testing

Acceptance

Testing

SystemTesting

SystemTesting

ComponentTesting

ComponentTestingCode

Code

DesignSpecification

DesignSpecification

SystemSpecification

SystemSpecification

Business Requirements

Business Requirements

sequential models

• requirements had to be known

• change was painful• projects were far too long• often what was delivered

wasn’t what was asked for• teams didn’t work well

together

iterative models

• evolutionary requirements

• changes were uncontrolled

• testing was not fully integrated

• delivery of software was still long

1970’s – 1980’s 1990’s – 2000’sthis led to…

3

this led to…2000’s – 2010’s

incremental delivery/agile models

• requirements known and broken down

• product developed iteratively and delivered incrementally

• change if expected and controlled

What is Agile?

agile is a mindsetdefinition: “characterised by quickness, lightness

and ease of movement; nimble. Mentally quick or alert

agile is a processan incremental delivery approach to software development

a different way of developing software (small increments)

working software is the primary measure of progress

testing is an integral part of the entire lifecycle

working together to achieve quality software as quickly as possible

high level of automated tests

highly creative and energetic

agile is based on 4 key principles4

The Agile Manifesto

5

A hybrid too far

most companies adapt Agile to suit their needs

this is okay as long as the Agile manifesto is upheld

otherwise it makes a mockery of what agile stands for…

scrum-fall~ scrum is performed but the last stages

are full system and acceptance testing

scrum-but~ we do scrum…but we don’t have testers

involved

agile-dev~ only development adopt agile principles

Need to ask the question: why did your company add or remove some of the activities?

this is okay – but don’t call

it Agile

6

An excuse to do things badly?

no documentation neededdocumentation if value, including bug logs

producing “vague” requirementsproduct backlog is comprehensive

jack of all trades…yes help, but don’t loose individual skills

no independencetesters are part of the team but should remain independent

time over qualityshould report quality and cost aspects

team just work in the same way but quickeragile is a change in culture and processes

many existing tools and techniques will not suit agile 7

Contents

What is Agile?

Top 10 lessons to make Agile a success

What to do next

8

Lesson 1: The reason must be a good one

need to ask the question “why”?because we want to deliver quality software more frequently

because our current way of working is not working

because we want more collaboration within the team

because we want more responsibility given to the team

because we want to try something new

because we want less documentation

because everyone else is going Agile

because we want to avoid “peak loads”

because our competitors are “agile”

because it is quicker

because we want to ignite a revived passion for software

because we want to embrace change in a controlled way

9

Lesson 2: Understand changes that are needed

…process and cultural changes you will need to makehow requirements are formed

the product backlog and user stories

team roles that need to change

the product owner, scrum master, “development” team

development and test manager?

how software is developed and tested

continuous integration, TDD, exploratory and automation

tools that are used

open source versus commercial

limitations of your current tool suite

collaboration of the team

co-location is key to success

10

Lesson 3: Don’t throw the team in the deep end…

…unless they are strong swimmers

provide necessary training in Agile methodologiesscrum master is not the only role

all team members need to understand

terminology

team roles

documentation produced

meetings

techniques and how to apply them

how to adapt to Agile and what needs to be done differently

maximum effectiveness

consider training the team using the

ISTQB Agile Tester qualification

11

Lesson 4: Don’t throw the baby out …

mature organisations embrace all lifecyclesrequirements can be broken down

testers and developers sit together

potentially shippable product in 4 weeks

requirements are known

testers and developers are separate

development needs to be all-at-once

requirements are unknown

customers want to try things before committing

system and acceptance testing is at the end

agile

sequential

iterative

SUGGESTION adopt my “checklist” for projects 12

Agile pitfalls/dangers

significant changes are not madechanges in attitude and culture

the business are not involved because they are too busy

testers are left out of the process

still produce the same amount and type of documentation

the use of old procedures and tools

developers do not perform any unit or integration testing

it makes all dysfunctions visiblebad products will be delivered faster

doomed projects will fail sooner

13

Lesson 6: Understand the team profile…

and allow them to succeedsuccess breeds success

not everyone will adapt to agile

different “styles” of testeruse of psychometric tests (e.g. Belbin)

“testers styles” analysis

understand your strengths and limitationsmentor others using your strengths

improve your own skill set in Agile

pragmatist pioneer

analyst facilitator

14

Some people will resist Agile

Diehards(they actively resist any

change and will seek others to help fight their

cause)

Saboteurs(actively resist by trying to undermine the transition, maybe trying to continue

to use current lengthy processes)

Followers(they think it will be a

passing fad, until Agile is the new “status quo”)

Skeptics(those who politely argue

against agile and who forget to attend stand-up

meetings)

Like the status quo Don’t like Agile

Why they resist

Ho

w t

hey

res

ist

Pas

sive

Act

ive

15

Lesson 7: Remember functionality has a brother…

the problem with agile is… there is too much focus on functionality

user stories tend to address what the user wants from a functional point of view

user stories are “done” when the functionality works

reporting is often related to functionality working

NON-FUNCTIONAL

“how well does it do it”

FUNCTIONAL“does it do what it is supposed to

do as per the user story”

SUGGESTION include a non-functional sprint or generate non-functional

user stories within the sprint

16

Lesson 8: Burn-down but don’t burn-out…

maximum velocity does not equal maximum productivityAugust 2010: productivity in the United States unexpectedly decreased in the second quarter

after employers expanded the workweek by the most in four years. Employees output

decreased by 0.9% per hour of output

7

4

52

61

8 3

9

efficiency is improved by 11.1%

BUT we cannot play the game…productivity is reduced…to zero

source: Tom DeMarco, “Slack”

7

4

52

61

83

11.1% spare capacity

Car engines work at their optimum efficiency

(mpg) at 56mph

Management’s decision:

to fill spare capacity to increase productivity

Productivity declines unexpectedly as US workweek lengthens

17

People are not a fungible resource

money is fungible:

net result: still have £100

but people are not fungible:

net result: at least 30% loss of productivity

“on average there will be a net loss of 15%

productivity due to task switching”

bank 1

£100

bank 1

£30

bank 2

£50

bank 3

£20

100% on project A

30% on project A

50% on project B

20% on project C

therefore be careful of the saying “women can multi-task and men can’t”

decide to divide money into 3 banks

management decide to divide your time into 3

projects

18

Lesson 9: Too much lean & you will waste away

concept of eliminating waste is goodexamples

meetings

emails

duplication of effort

documents not being used

maintenance of the tests taking longer than the test execution

however…sometimes cutting back too much causes more problems

19

Wastage example: meetings

10 people @ 1 hour meeting = 10 hours• 1 person arrives 6 minutes late………………………………• 4 people receive texts and respond taking 2 minutes……..• 1 person gets a call and leaves room for 15 minutes……...• 6 people on laptops responding to emails…………………..

….1 hour….80 minutes…. 25 minutes…. 3 hourstotal: 6 hours wasted = 60% inefficiencysuggestion: conduct meetings with etiquette

no laptops

no phones

no interruptions

start on time20

Lesson 10: Don’t get carried away with automation

when automation is good

when automation is bad

variety of tools to support all test activities

team can become more effective and efficient

– development will embrace automation

– complement automation with manual testing

– spending too much time in automation can loose your skills in testing

– automation should not become the goal – testing should

– rubbish tests means faster rubbish

22

Warning signs

some disturbing case studies:– company 1:

• project spent most of test effort in automation, testers became automation specialists…and lost their testing skills. Software quality was poor.

– company 2:• automation team so “locked” into providing

an automated solution, spent 1 week of effort. Manual tester took 1 hour to do the same work.

– company 3: • outsourced team had automated those

10,000 test cases all doing the same thing all they achieved was “faster rubbish”

23

Contents

What is Agile?

Top 10 lessons to make Agile a success

What to do next

24

Some suggestions for you…

• embrace all methodologies– each one has advantages and disadvantages

• one size doesn’t fit all– think about the best way to implement Agile for you

• but remember to uphold the Agile manifesto

• consider how “you” need to adapt– you as an individual and also as a company

• see change as an opportunity – rather than a threat

• provide some “slack”– and avoid multiple-projects and multi-tasking

• provide training for your teams– know their strengths and your weaknesses 27

set yourself daily goals and achieve

theme.g. John, Susan, Nora and George

Summary

• agile is a mindset that has many methodologies

• agile has processes to follow

• adapting to agile requires a change in process, attitude and development

• the need to be aware of key problems that can hinder the transition into Agile

28