Scrum in Skype mobile software development - Challenges & Lessons learned @ MoMo Tallinn 06.06.11

2,562 views

Published on

Scrum in Skype mobile software development - Challenges & Lessons learned
Ervins Grinfelds
Skype
@ Mobile Monday Estonia "Mobile Development requires Agile approach?", Tallinn 06.06.11

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,562
On SlideShare
0
From Embeds
0
Number of Embeds
891
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Scrum in Skype mobile software development - Challenges & Lessons learned @ MoMo Tallinn 06.06.11

  1. 1. Scrum in Skype mobile software development - Challenges & Lessons learned<br />Ervins Grinfelds<br />Product Engineering Manager – Skype<br />ervins.grinfelds@skype.net<br />
  2. 2. Android for operators & OEMs<br /><ul><li> Operators – Verizon (US) , KDDI (Japan), Hutchison (UK, Ireland, Australia)
  3. 3. OEMs – HTC, Samsung, LG, Sharp, Sony Ericsson, Motorola</li></li></ul><li>BlackBerry for operators & OEMs<br /><ul><li>Operators – Verizon (US) , Hutchison (UK, Ireland, Australia)
  4. 4. OEMs – RIM</li></li></ul><li>Java ME for Operators & OEMs<br /><ul><li>Operators – Hutchison (UK, Ireland, Australia)
  5. 5. OEMs – Nokia, Sony Ericsson, ZTE, LG, Samsung </li></li></ul><li>Transition to Scrum<br /><ul><li> Quick transition
  6. 6. Trainings/workshops
  7. 7. Teams started to work in Agile Scrum in OCT 2010
  8. 8. Working in Scrum for more than 7 months</li></li></ul><li>Getting complexity points accurate<br /><ul><li> Complexity points are key to successful velocity calculation
  9. 9. Inaccurate velocity will prevent to execute effectively and in most cases will result in failed sprint</li></ul>Lessons learned <br /><ul><li> Getting very clear baseline (eg. what is complexity for 3 points)
  10. 10. Discuss until it’s understood by every team member
  11. 11. Refer to baseline estimations as much as possible. </li></li></ul><li>Urgent/unplanned requests from Operators or OEMs <br /><ul><li> We must remain flexible & respond quickly to critical operator/OEM requests – even if outside of Sprint commitment. </li></ul>Lessons learned <br /><ul><li> Mandatory content – features/bug fixes that are mandatory for successful sprint. Typically ~ 60% of velocity.
  12. 12. Optional content – lower priority tasks
  13. 13. If unplanned request comes in, part or all optional content is replaced by new requests.
  14. 14. If no unplanned request – team delivers both – mandatory and optional content. </li></li></ul><li>Getting burn down chart to work<br /><ul><li>Burndown - visibility of sprint progress</li></ul>Lessons learned. <br /><ul><li> Break down as much as possible
  15. 15. smaller tasks
  16. 16. Continuous integration is mandatory
  17. 17. Nightly builds
  18. 18. Daily automated regression tests & reports
  19. 19. Daily manual verification of changes</li></li></ul><li>Definition of done – when to close sprint task<br /><ul><li> “Done” – state when sprint task can be closed (when it reflects on brundown chart)</li></ul>Lessons learned. <br /><ul><li> Done may vary between teams
  20. 20. Discuss, define & communicate definition of done as clear as possible until fully understood by team.
  21. 21. In Android, BlackBerry, Java ME task is done when:
  22. 22. Development complete
  23. 23. Code review by peers complete
  24. 24. Regression tests successful
  25. 25. Functional QA verification successful
  26. 26. Test cases & documentation (if applicable) changed. </li></li></ul><li>Summary<br /><ul><li> Visibility
  27. 27. Efficiency
  28. 28. Flexibility
  29. 29. Discipline
  30. 30. Quality </li></li></ul><li>Thank You!<br />Ervins Grinfelds<br />Product Engineering Manager – Skype<br />ervins.grinfelds@skype.net<br />

×