Real world experience from Microsoft - Deniz Ercoskun


Published on

Microsoft developer division has implemented SCRUM while developing Visual Studio 2012, and TFS 2012. In this talk we will cover information on this implementation. You will learn about why Microsoft has decided to implement SCRUM, best practices that was helpful for us. How implementing SCRUM has changed our cadence and product delivery cycle. The content will be our developer division SCRUM journey. We are not pure SCRUM put at future leavel we are. I will also discuss which part of our process is SCRUm which part still is not.

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Cover: Don't worry about swapping out the image. Shorter titles can sit on two lines.
  • Agenda: Update with what you'll be covering in your session, typically wordedthe same as your section breaks.
  • Need some really good examples here… stories.
  • Why 3 weeks?Four weeks felt like a LONG time.Two weeks was very quick. Too much overheard.Three weeks fit our cadence and our schedule – it worked in our environment.
  • Closing page: Include your contact information and any social-media handles you’d like!
  • Real world experience from Microsoft - Deniz Ercoskun

    1. 1. Real World Experiences fromMicrosoftDeniz ErcoskunMicrosoft CorporationDPE Developer Tools Lead for MEA
    2. 2. Istanbul
    3. 3. IstanbulRedmond
    4. 4. Developer Division• Visual Studio• Team Foundation Server• .net• SilverlightWhich group?
    5. 5. Quality MilestoneAfter VS 2010 shipped
    6. 6. The Box & The Service
    7. 7. The Box• Multi-year cycles• Milestones and stabilizations• Debt
    8. 8. “Firms today experience a much higher velocity ofbusiness change. Market opportunities appear ordissolve in months or weeks instead of years.“Diego Lo Giudice and Dave West, ForresterFebruary 2011Transforming Application DeliveryWhy agile in the first place?
    9. 9. 1.Our Roles2.Our Organization3.Our Teams4.Our Cadence5.Our Plan6.Our PracticesOur Experience
    10. 10. Our RolesProgram Manager – Responsible to ensure we’re building theright thing.Development – Responsible to ensure we’re building productsthat are fast, reliable, and well engineered.QA – Responsible to ensure we’re building high quality productsthat meet customers needs.
    11. 11. Our OrganizationProgram Manager Development QA
    12. 12. Our TeamsProgram Manager Development QA
    13. 13. Our TeamsQADev QADev QADev QADevPM PM PM PMCollaboration Version Control Build Work Item Tracking
    14. 14. Sprint CadenceWeek 1 Week 2 Week 3
    15. 15. What’s Changed?6 weeks10 – 12 weeks3 weeks
    16. 16. 3 Week SprintsSprint 43Sprint 44Sprint 45Sprint 4642
    17. 17. 3 Week SprintsWeek 1 Week 2 Week 3 Week 4Week 1 Week 2 Week 3Sprint PlanningBacklogGroomingDeployment!Sprint PlanningBacklogGroomingDone!
    18. 18. Sprint Mechanics
    19. 19. Same code base used for bothWork in a single branchGated checkin only buildsRolling test system, including upgrade testsDisruptive changes integrated at the beginning of a sprintMerge to production branch, quarterly update CTPsThe service and the box
    20. 20. How about at Scale?Sprint 43Sprint 44Sprint 45Sprint 4642
    21. 21. Team ChatsTeam Chats Team Chats Team Chats3 questions:1. What’s next?2. How’s the team doing?3. Any issues?
    22. 22. Team ChatsCollaboration Version Control Build Work Item Tracking
    23. 23. Our Plan18 month vision
    24. 24. What does the work look like?Scenario –Alarge initiative in a release.Experience –An end-to-end set of userstories.User Story –Arequirement capturingthe role, functionality, and value.Task – Work the team does to fulfill aStory.ExperienceUser StoryTask
    25. 25. Work Items
    26. 26. Bugs
    27. 27. Rolling Tests
    28. 28. Waterfall• Big picture planning• Design• SpecsRules We FollowScrum• Sprint Planning• Daily Standup• Cross-functional teams• RetrospectivesKanban• Visual Tracking• WIP Limits
    29. 29. Rules We Break Waterfall• We change ourminds… a lot!• Design• SpecsScrum• No Sprint Reviews• Rotating Scrummaster• Bug tracking• Deploy one week afterthe sprintKanban• WIP Limits• Iterations• Schedule
    30. 30. What is the Value?
    31. 31. Our Delivery Cadence3-week service delivery sprintsFrequent updates for on-premise/boxed productsSeptember 2012 October 2012 November 2012 December 2012 January 2013……April2013
    32. 32. Cultural changeBuild an environment where your teams will thriveShip frequently!Measure alwaysTestUse Team Foundation Server Summary
    33. 33. Thank youDeniz ErcoskunMicrosoft CorporationDPE Developer Tools Lead for MEA
    34. 34. The service and the box• Same code base used for both• Work in a single branch• Gated checkin only builds• Rolling test system, including upgrade tests• Disruptive changes integrated at the beginning of a sprint• Merge to production branch, quarterly update CTPs
    35. 35. Differences• Service scales differently• Need cost model• Multi-tenant database• All content goes to Azure Blob Storage
    36. 36. Differences• Tight loop with support• Online upgrades• Automated deployment• No down time between cycles – engineering backlog