Real world experience from Microsoft - Deniz Ercoskun
•
1 gefällt mir•2,185 views
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.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Real world experience from Microsoft - Deniz Ercoskun
Ähnlich wie Real world experience from Microsoft - Deniz Ercoskun (20)
Mehr von AgileSparks
Mehr von AgileSparks (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Real world experience from Microsoft - Deniz Ercoskun
- 1. Real World Experiences from Microsoft Deniz Ercoskun Microsoft Corporation DPE Developer Tools Lead for MEA
- 2. Istanbul
- 4. Developer Division • Visual Studio • Team Foundation Server • .net • Silverlight Which group?
- 5. Quality Milestone After VS 2010 shipped
- 6. The Box & The Service
- 7. The Box • Multi-year cycles • Milestones and stabilizations • Debt
- 8. “Firms today experience a much higher velocity of business change. Market opportunities appear or dissolve in months or weeks instead of years.“ Diego Lo Giudice and Dave West, Forrester February 2011 Transforming Application Delivery Why agile in the first place?
- 9. 1.Our Roles 2.Our Organization 3.Our Teams 4.Our Cadence 5.Our Plan 6.Our Practices Our Experience
- 10. Our Roles Program Manager – Responsible to ensure we’re building the right thing. Development – Responsible to ensure we’re building products that are fast, reliable, and well engineered. QA – Responsible to ensure we’re building high quality products that meet customers needs.
- 11. Our Organization Program Manager Development QA
- 12. Our Teams Program Manager Development QA
- 13. Our Teams QADev QADev QADev QADevPM PM PM PM Collaboration Version Control Build Work Item Tracking
- 14. Sprint Cadence Week 1 Week 2 Week 3
- 15. What’s Changed? 6 weeks 10 – 12 weeks 3 weeks
- 16. 3 Week Sprints Sprint 43 Sprint 44 Sprint 45 Sprint 4642
- 17. 3 Week Sprints Week 1 Week 2 Week 3 Week 4 Week 1 Week 2 Week 3 Sprint Planning Backlog Grooming Deployment! Sprint Planning Backlog Grooming Done!
- 18. Sprint Mechanics
- 19. 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 The service and the box
- 20. How about at Scale? Sprint 43 Sprint 44 Sprint 45 Sprint 4642
- 21. Team Chats Team Chats Team Chats Team Chats 3 questions: 1. What’s next? 2. How’s the team doing? 3. Any issues?
- 22. Team Chats Collaboration Version Control Build Work Item Tracking
- 23. Our Plan 18 month vision
- 24. What does the work look like? Scenario –Alarge initiative in a release. Experience –An end-to-end set of user stories. User Story –Arequirement capturing the role, functionality, and value. Task – Work the team does to fulfill a Story. Experience User Story Task
- 25. Work Items
- 26. Bugs
- 27. Rolling Tests
- 28. Waterfall • Big picture planning • Design • Specs Rules We Follow Scrum • Sprint Planning • Daily Standup • Cross-functional teams • Retrospectives Kanban • Visual Tracking • WIP Limits
- 29. Rules We Break Waterfall • We change our minds… a lot! • Design • Specs Scrum • No Sprint Reviews • Rotating Scrummaster • Bug tracking • Deploy one week after the sprint Kanban • WIP Limits • Iterations • Schedule
- 30. What is the Value?
- 31. Our Delivery Cadence 3-week service delivery sprints Frequent updates for on-premise/boxed products September 2012 October 2012 November 2012 December 2012 January 2013 … … April 2013
- 33. Cultural change Build an environment where your teams will thrive Ship frequently! Measure always Test Use Team Foundation Server Summary
- 34. Thank you Deniz Ercoskun Microsoft Corporation DPE Developer Tools Lead for MEA
- 35. 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
- 36. Differences • Service scales differently • Need cost model • Multi-tenant database • All content goes to Azure Blob Storage
- 37. Differences • Tight loop with support • Online upgrades • Automated deployment • No down time between cycles – engineering backlog
Hinweis der Redaktion
- 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!