Implementing Agile     Dos and Donts    Anay Narendra Kamat  PresentSoft Technologieshttp://www.presentsoft.co.in
Takeaway• Learning from mistakes• Confidence from success stories
All the teams and people mentioned in thistalk are real and as such, could resemble tothe people living or dead and the te...
The Prime DirectiveRegardless of what we discover, weunderstand and truly believe that everyonedid the best job they could...
Why to be Agile?
What does it take to be Agile?Agile manifesto:     Individuals and interactions over processes and tools    Working softwa...
Do perfectly agile teams really exist?
TEAM A• BA formed the list of stories based on the requirements  given by the client only.• PM managed the team without ge...
TEAM B• Product owner had delegated the responsibility of  requirements and communication to one of his trusted  person• B...
TEAM C•   Team members had attended SCRUM trainings•   Each team managed the leave requests of their members•   Requiremen...
TEAM D• All the stories were written and updated in project management  tool directly by the client.• Team relied heavily ...
TEAM E• Client had no time to give or finalize requirements. BA had  to judge most of the requirements on his own.• Only P...
Quotes
Quotes• It’s been 3 months since we started following scrum.  We don’t see any improvement, but situation has  definitely ...
Do’s and Don’ts
Focus Areas•   Project planning•   Project management•   Development•   Quality analysis•   Documentation•   Skill enhance...
Project planning
Duration of sprint matters
Try to have high bus number
Have a story wall
Involve entire team in estimation            meetings
Follow continuous integration
Design the deployment strategy          well in advance.• And make it scripted
Project management
Do not micro-manage• Ensure that team understands the goal and  the big – picture and is not dependent on  stories.• Be wi...
Encourage innovative ideas
Ensure learning from “Yesterday’s   weather” is implemented
Development
Do not design too much in detail
Reuse, Reuse and Reuse
Be responsible• Ensure you are not breaking existing features• Use automated unit tests. It helps a lot.• Every feature ne...
Quality analysis
Put efforts to understand real user              behavior
Reduce manual work through      automation toolsEncourage test automation right from thebeginning
Do not use “Number of defectsidentified” as matrix to measure         QA effectiveness
Documentation
Documentation• Prefer following over text based  documentation/comments:  – Automated Unit Tests  – Automated Functional T...
Example : Using Cucumber
Skill enhancements
Skill enhancements• Pair programming helps• Encourage training within the team• Encourage and reward implementation of  in...
Questions ……
Thank you                Contact    Email: anay@presentsoft.co.inTwitter: http://twitter.com/kamatanay
Upcoming SlideShare
Loading in...5
×

Implementing Agile : Do's and Don'ts

1,723

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,723
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
44
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Implementing Agile : Do's and Don'ts"

  1. 1. Implementing Agile Dos and Donts Anay Narendra Kamat PresentSoft Technologieshttp://www.presentsoft.co.in
  2. 2. Takeaway• Learning from mistakes• Confidence from success stories
  3. 3. All the teams and people mentioned in thistalk are real and as such, could resemble tothe people living or dead and the teamsexisting in organizations.
  4. 4. The Prime DirectiveRegardless of what we discover, weunderstand and truly believe that everyonedid the best job they could, given what theyknew at the time, their skills and abilities, theresources available, and the situation at hand.
  5. 5. Why to be Agile?
  6. 6. What does it take to be Agile?Agile manifesto: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  7. 7. Do perfectly agile teams really exist?
  8. 8. TEAM A• BA formed the list of stories based on the requirements given by the client only.• PM managed the team without getting into micro- management.• Team provided and received updates during stand-ups.• Every member of the team was allowed to communicate with the client• Dev followed PP, good design pattern, TDD and Continuous Integration• QAs used automation tools to run tests• Deployment was automated as well
  9. 9. TEAM B• Product owner had delegated the responsibility of requirements and communication to one of his trusted person• BA formed the stories based on the requirements given by the client only• Only PM and BA were allowed to communicate with the client• Teams shared updates through stand-ups• Team followed PP, good design patterns, TDD and CI• QAs used automation tools• Deployment was automated
  10. 10. TEAM C• Team members had attended SCRUM trainings• Each team managed the leave requests of their members• Requirements/Stories were written by a different team• Estimates were done in ideal days• Duration of sprint was 3 weeks• Long stand-ups• Code reviews were done by members of another team.• Team did not follow TDD, PP, CI• QA members belonged to a different team• Requirements changed frequently• Team never delivered all the stories planned in the sprint.
  11. 11. TEAM D• All the stories were written and updated in project management tool directly by the client.• Team relied heavily on email communication• Only few senior members were allowed in client call updates• Estimates were done in story points mapped to idea days• Team did not follow TDD, code was completely procedural, CI was not used• Team members were divided in specialized groups• QA members belonged to a different team• Deployment procedure was separate for production and stage environments• Only few people were able to handle deployment activities on production
  12. 12. TEAM E• Client had no time to give or finalize requirements. BA had to judge most of the requirements on his own.• Only PM, BA and Architect was allowed to communicate directly with the client• Long stand-ups. Stand-up was driven by the Project Manager.• Development used to start for the stories which were not completely defined• Design decisions were taken completely by the architect• No strict code reviews. OO was not followed since management was of the opinion that it was too advanced for the team members.
  13. 13. Quotes
  14. 14. Quotes• It’s been 3 months since we started following scrum. We don’t see any improvement, but situation has definitely become worst – A team member• On estimates done using story points over the scale of 2 - 3 - 5 - 8 (and 13), team of 12 people cannot achieve velocity of more than 10 points – Scrum expert of one organization• Let’s start with the estimates, 2 point is for the story taking 1.5 days, 3 point for the stories taking 4 days … – A team lead from one organization• We learnt a great thing. Remember it, and you can implement in your next project . – PM
  15. 15. Do’s and Don’ts
  16. 16. Focus Areas• Project planning• Project management• Development• Quality analysis• Documentation• Skill enhancements
  17. 17. Project planning
  18. 18. Duration of sprint matters
  19. 19. Try to have high bus number
  20. 20. Have a story wall
  21. 21. Involve entire team in estimation meetings
  22. 22. Follow continuous integration
  23. 23. Design the deployment strategy well in advance.• And make it scripted
  24. 24. Project management
  25. 25. Do not micro-manage• Ensure that team understands the goal and the big – picture and is not dependent on stories.• Be with the team
  26. 26. Encourage innovative ideas
  27. 27. Ensure learning from “Yesterday’s weather” is implemented
  28. 28. Development
  29. 29. Do not design too much in detail
  30. 30. Reuse, Reuse and Reuse
  31. 31. Be responsible• Ensure you are not breaking existing features• Use automated unit tests. It helps a lot.• Every feature needs to be “Deployable”
  32. 32. Quality analysis
  33. 33. Put efforts to understand real user behavior
  34. 34. Reduce manual work through automation toolsEncourage test automation right from thebeginning
  35. 35. Do not use “Number of defectsidentified” as matrix to measure QA effectiveness
  36. 36. Documentation
  37. 37. Documentation• Prefer following over text based documentation/comments: – Automated Unit Tests – Automated Functional Tests – Deployment scripts – Story description and discussions from project management tool
  38. 38. Example : Using Cucumber
  39. 39. Skill enhancements
  40. 40. Skill enhancements• Pair programming helps• Encourage training within the team• Encourage and reward implementation of innovative ideas• Discourage forming of specialized groups within the team
  41. 41. Questions ……
  42. 42. Thank you Contact Email: anay@presentsoft.co.inTwitter: http://twitter.com/kamatanay
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×