From Bouvet breakfast seminar, March 2015

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

2. Contents
Why can Agile be so fragile?
Top 10 lessons to make Agile a success
What to do next
2

3. The problem with the past…
Integration
Testing
Integration
Testing
Acceptance
Testing
Acceptance
Testing
System
Testing
System
Testing
Component
Testing
Component
TestingCode
Code
Design
Specification
Design
Specification
System
Specification
System
Specification
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

4. What is Agile?
agile is a mindset
definition: “characterised by quickness, lightness
and ease of movement; nimble. Mentally quick or alert
agile is a process
an 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 principles
4

5. The Agile Manifesto
5

6. 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

7. An excuse to do things badly?
no documentation needed
documentation if value, including bug logs
producing “vague” requirements
product backlog is comprehensive
jack of all trades…
yes help, but don’t loose individual skills
no independence
testers are part of the team but should remain independent
time over quality
should report quality and cost aspects
team just work in the same way but quicker
agile is a change in culture and processes
many existing tools and techniques will not suit agile 7

8. Contents
What is Agile?
Top 10 lessons to make Agile a success
What to do next
8

9. 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

10. Lesson 2: Understand changes that are needed
…process and cultural changes you will need to make
how 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

11. Lesson 3: Don’t throw the team in the deep end…
…unless they are strong swimmers 
provide necessary training in Agile methodologies
scrum 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

12. Lesson 4: Don’t throw the baby out …
mature organisations embrace all lifecycles
requirements 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

13. Agile pitfalls/dangers
significant changes are not made
changes 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 visible
bad products will be delivered faster
doomed projects will fail sooner
13

14. Lesson 6: Understand the team profile…
and allow them to succeed
success breeds success
not everyone will adapt to agile
different “styles” of tester
use of psychometric tests (e.g. Belbin)
“testers styles” analysis
understand your strengths and limitations
mentor others using your strengths
improve your own skill set in Agile
pragmatist pioneer
analyst facilitator
14

15. 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
Howtheyresist
PassiveActive
15

16. 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

17. Lesson 8: Burn-down but don’t burn-out…
maximum velocity does not equal maximum productivity
August 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
8
3
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

18. 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

19. Lesson 9: Too much lean & you will waste away
concept of eliminating waste is good
examples
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

20. 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 hours
total: 6 hours wasted
= 60% inefficiency
suggestion: conduct meetings with etiquette
no laptops
no phones
no interruptions
start on time
20

21. 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

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

23. Contents
What is Agile?
Top 10 lessons to make Agile a success
What to do next
24

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
them
e.g. John, Susan,
Nora and George

25. 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