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

  • 2,131 views
Uploaded on

Scrum in Skype mobile software development - Challenges & Lessons learned …

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,131
On Slideshare
0
From Embeds
0
Number of Embeds
8

Actions

Shares
Downloads
0
Comments
0
Likes
1

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

Transcript

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