Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
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…
Integration
Testing
Integration
Testing
Acceptance
Testing
Acceptance
Testing
System
Testing
Sy...
What is Agile?
agile is a mindset
definition: “characterised by quickness, lightness
and ease of movement; nimble. Mentall...
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
othe...
An excuse to do things badly?
no documentation needed
documentation if value, including bug logs
producing “vague” require...
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 f...
Lesson 2: Understand changes that are needed
…process and cultural changes you will need to make
how requirements are form...
Lesson 3: Don’t throw the team in the deep end…
…unless they are strong swimmers 
provide necessary training in Agile met...
Lesson 4: Don’t throw the baby out …
mature organisations embrace all lifecycles
requirements can be broken down
testers a...
Agile pitfalls/dangers
significant changes are not made
changes in attitude and culture
the business are not involved
beca...
Lesson 6: Understand the team profile…
and allow them to succeed
success breeds success
not everyone will adapt to agile
d...
Some people will resist Agile
Diehards
(they actively resist any
change and will seek
others to help fight their
cause)
Sa...
Lesson 7: Remember functionality has a brother…
the problem with agile is… there is too much focus on
functionality
user s...
Lesson 8: Burn-down but don’t burn-out…
maximum velocity does not equal maximum productivity
August 2010: productivity in ...
People are not a fungible resource
money is fungible:
net result: still have £100
but people are not fungible:
net result:...
Lesson 9: Too much lean & you will waste away
concept of eliminating waste is good
examples
meetings
emails
duplication of...
Wastage example: meetings
10 people @ 1 hour meeting = 10 hours
• 1 person arrives 6 minutes late………………………………
• 4 people r...
Lesson 10: Don’t get carried away with
automation
when automation is good
when automation is bad
variety of tools to suppo...
Warning signs
some disturbing case studies:
– company 1:
• project spent most of test effort in
automation, testers became...
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 a...
Summary
• agile is a mindset that has
many methodologies
• agile has processes to
follow
• adapting to agile requires a
ch...
Prochain SlideShare
Chargement dans…5
×

Lloyd roden the fragility of agility

604 vues

Publié le

From Bouvet breakfast seminar, March 2015

Publié dans : Technologie
  • Soyez le premier à commenter

Lloyd roden the fragility of agility

  1. 1. The Fragility of Agility: Top 10 lessons to make Agile a success 1
  2. 2. Contents Why can Agile be so fragile? Top 10 lessons to make Agile a success What to do next 2
  3. 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. 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. 5. The Agile Manifesto 5
  6. 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. 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. 8. Contents What is Agile? Top 10 lessons to make Agile a success What to do next 8
  9. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. Contents What is Agile? Top 10 lessons to make Agile a success What to do next 24
  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. 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

×