Your SlideShare is downloading. ×
From waterfall to rapids - an experience report
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

From waterfall to rapids - an experience report

136
views

Published on

Presented at SQGNE Jan 9th meeting.

Presented at SQGNE Jan 9th meeting.


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
136
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • CalmSereneBeautifulConsistant
  • MeRolePerceptiveEveningWhat not to expect ?What is agile.Debate Agile principlesYou How many people are actively engaged in an Agile environment ?How many are planning to start their transition soon.How many non –traditional QA background ?
  • This is the most profound question you need to answerWhy are you doing this?The reason doesn’t matter- at least not to meBut you need to know that and understand it wellEverything that happens post this- will be driven by your reason to changeFor this will set in motion how you execute your transition and where do you end up
  • Transparency was very importantTransparency within the team- as to what your fellow team member is doing as well as within the organizationFor team to know what the organization needsAnd for the org to know what the team is uptoImagine being the toast in a toasterEvery minute or so- someone pokes you and takes you out to see if you are done.Now look at thisWouldn’t you love to be a toast in this toaster ?Everyone knows when you are ready – no more poking ?This is more or less what we had in our organization.And Agile holds lots of promises with respect to that
  • We all would like to be done quickly.So we can start the next big project.The total time needed to deliver a project can perhaps not be reduced, but Agile does offer a smarter way of managing the project- so that you can release faster and more frequently.
  • We have our share or problemsThis is one of the best things I like about AgileConstant Inspect and AdaptDon’t like something ? Try something different. Worked ? Carry on.Didn’t work ? Try something else.As simple as that
  • When I was in Hyderabad- one thing I noticed was all developers ate lunch together and all testers went for lunch together- at different times.I found this very disturbing.We are all one team. We are not two teams within one team.
  • This was one of the most disturbing this I observed when I first joined Perceptive.In my team- there were 3 developers and 4 testersAnd since I was the manager- and wouldn’t do anything- it effectively left 2 developersAnd at one time – one developer left and there was a single developer-who was able to churn enough work to keep 3 testers busyTo me this was a very unhealthy ratio to have in a team.
  • Probably somewhat related to the previous slide.We have awesome developers- and awesome testers.However…Developers are lacking in domain knowledge and testers in technical stuffAnd since we have those silos I talked about- this doesn’t get betterTesters and developers remain in their own respective silos – not getting any better.And because developers lack in domain knowledge, it comes in their way to make a quality productAnd since testers do not have the technical knowledge, we have little to none automation
  • Finally the dreaded QA phaseAt Perceptive- we have exceptionally QA heavy process.And this is in some ways related to everything else that I have said so farThis is what we want to changeSpend a healthy time in QA doing effective testing and not necessarily longer testing phase- which doesn’t automatically ensure quality
  • ConferencesRead booksWent to user groupsEngaged with people online- twitter, forums etc.Gave presentations
  • Very experimentalWith toolsProcessesIdeasSpend little time debating them
  • You cant successfully go Agile- unless you change your engineering practicesCont IntegrationTDDBDD
  • Co-location helpsSmall things like – eating lunch together
  • Transcript

    • 1. From waterfalls to rapidsan experience report © 2009 Perceptive Informatics, Inc. A PAREXEL® Company
    • 2.  Calm Serene Symmetry Beautiful Peaceful Inside ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 2
    • 3. Prelude© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 3
    • 4. Introductions Me You Raise your hand if… – You have little idea about Agile or scrum – You are working in Agile environment – You are a non-tester© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 4
    • 5. Interruptions solicited© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 5
    • 6. Agenda why how where© 2012 Perceptive Informatics, Inc. A PAREXEL® Company 6
    • 7. Why ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 7
    • 8. Transparency© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 8
    • 9. Shorter release cycles Reduce inventory Feedback Quality Reduce total time ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 9
    • 10. Inspect and Adapt Retrospectives Customer feedback© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 10
    • 11. Dev-Test Silos Who do you eat lunch with ? Two teams working as one team or one team ? Team interactions or individual interactions ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 11
    • 12. Dev-Test ratio What is a healthy ratio ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 12
    • 13. Exclusive ownership Who own the assets ? Do developers test ? Do Testers change code ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 13
    • 14. “Technical” test staff© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 14
    • 15. Long endgame QA phase Lack of automation Lack of domain knowledge Cemented dev-qa silos QA documentation© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 15
    • 16. How ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 16
    • 17. Top to bottom Management initiated Team initiated© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 17
    • 18. © 2009 Perceptive Informatics, Inc. A PAREXEL® Company 18
    • 19. Time and energy Expensive Commitment© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 19
    • 20. Learnings© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 20
    • 21. Experimental Processes Product© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 21
    • 22. Tools Basecamp SeeNowDo Pivol Tracker Rally White-board© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 22
    • 23. Extreme Programming Unit Testing Pair programming TDD BDD Continuous Delivery Code reviews© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 23
    • 24. Culture Process or culture ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 24
    • 25. Where ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 25
    • 26. Success !© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 26
    • 27. Dev-QA ratio© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 27
    • 28. Shorter QA phase© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 28
    • 29. Self reliant teams© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 29
    • 30. Automation© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 30
    • 31. Joint ownership Quality is everyone’s responsibility Joint exploratory testing Pairing© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 31
    • 32. Better collaboration Developers <- Domain knowledge Testers <- Technical help© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 32
    • 33. crossover© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 33
    • 34. Limited success !© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 34
    • 35. Transparency ? Not so much© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 35
    • 36. Gimmickry of scrum© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 36
    • 37. Documentation burden© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 37
    • 38. Challenge of changing culture© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 38
    • 39. Too many meetings ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 39
    • 40. Lessons learned© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 40
    • 41. Lessons learned Don’t follow scrum by book Don’t over sell it Be wary of vendors - but do seek help© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 41
    • 42. © 2009 Perceptive Informatics, Inc. A PAREXEL® Company 42
    • 43. Factors The domain The customers Technology Nature of the application Your market Who initiated the transition Human factor© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 43
    • 44. Closing thoughts Quite a ride Next job : Agile again Startup vs. Not-so-startup Developers ?© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 44
    • 45. Contact www.rajivnarula.com rajiv@rajivnarula.com @rajivnarula© 2009 Perceptive Informatics, Inc. A PAREXEL® Company 45
    • 46. © 2009 Perceptive Informatics, Inc. A PAREXEL® Company 46
    • 47. © 2009 Perceptive Informatics, Inc. A PAREXEL® Company 47