lloyd roden the fragility of agility
Post on 18-Jul-2015
133 Views
Preview:
TRANSCRIPT
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
top related