Agile SharePoint Development With Scrum


Published on

Provide an introduction to Agile development using Scrum and discuss how the iterative approach to development helps the customer to get the solution they want. Look at how this approach works when applied to SharePoint projects, how it helps leverage more of the core platform and focuses effort on the biggest value areas. We will look at the challenges this brings to your development team by doing early integration, dealing with upgrades and changes and understand how addressing the hard things early is the right approach. We will also discuss how Scrum gives visibility of the project and brings both good and bad news. How getting customer engagement is the primary challenge and how the flexible approach is often at odds with the way work is contracted.

Published in: Technology

Agile SharePoint Development With Scrum

  1. 1. Agile SharePoint Development with Scrum DEV338 Andrew Woodward, MOSS MVP
  2. 2. <ul><li>Andrew Woodward, MVP </li></ul><ul><ul><li>Principal Consultant 21apps </li></ul></ul><ul><ul><li>Email [email_address] </li></ul></ul><ul><ul><li>Twitter @AndrewWoody </li></ul></ul><ul><ul><li>Blog </li></ul></ul><ul><ul><li>Agile developer, recent white paper: Unit Testing SharePoint – Getting into the Object Model </li></ul></ul>
  3. 3. Agenda <ul><li>Introduction to Scrum </li></ul><ul><li>Being Agile with SharePoint </li></ul><ul><ul><li>Iterative Development </li></ul></ul><ul><ul><li>Expect Change </li></ul></ul><ul><ul><li>Upgrades </li></ul></ul><ul><ul><li>Environments </li></ul></ul>
  4. 4. Product Backlog
  5. 5. Burndown Chart
  6. 6. Sprint
  7. 7. Product
  8. 8. Product Backlog
  9. 9. Roles
  10. 10. Product Owner
  11. 11. Release Planning Release 1 Release 2 Release 3
  12. 12. Sprint ----5----10----15----20----25----30
  13. 13. Estimating 5 8 3 2 8 13 8 21 5 2 5 8 Hours Story Points Bananas Days Release 1
  14. 14. Priority 1 2 3 4 5 6 7 8 9 10 11 12 Release 1
  15. 15. Sprints Release 1
  16. 16. Potentially Shippable What is done?
  17. 17. Sprint
  18. 18. Burndown Chart Work to do Sprint duration in days
  19. 19. Burndown Chart Work to do Sprint duration in days
  20. 20. Velocity
  21. 21. Release Planning Work to do Required Velocity Go Live Date
  22. 22. Release Planning Work to do
  23. 23. Release Planning Work to do Move Go Live Date
  24. 24. Release Planning Work to do Reduce features
  25. 25. Burndown Chart Work to do Early visibility
  26. 26. Daily Scrum What I did yesterday? What I’m doing today Any problems I have.
  27. 27. Scrum Master
  28. 28. Product Backlog
  29. 29. Bugs
  30. 30. Bugs – Defect Backlog <ul><li>Create Defect Log </li></ul><ul><li>Plan to do a couple of defect sprints </li></ul>
  31. 31. Bugs - Fixed in Sprint <ul><li>Directly related to task fix in Sprint </li></ul>
  32. 32. Being Agile with SharePoint
  33. 33. Iterative Development <ul><li>Sprint </li></ul><ul><ul><li>Potentially Shippable </li></ul></ul><ul><ul><li>Face tough challenges early and often </li></ul></ul><ul><ul><li>Ability to change every Sprint </li></ul></ul>
  34. 34. Continuous Builds and QA/Testing Proving / Staging Production
  35. 35. Change <ul><li>Expect Change </li></ul><ul><ul><li>Design for change </li></ul></ul><ul><ul><ul><li>Features and Feature Stapling over Site Templates </li></ul></ul></ul><ul><ul><li>Tool Up </li></ul></ul><ul><ul><ul><li>Upgrade helper utilities </li></ul></ul></ul>
  36. 36. Upgrade <ul><li>SharePoint is a long term proposition </li></ul><ul><ul><li>More complex than traditional ASP.Net </li></ul></ul><ul><li>Deal with early in manageable pieces </li></ul><ul><li>Attend DEV372 with Robert Bogue </li></ul>
  37. 37. Environments <ul><li>Developer </li></ul><ul><ul><li>Automate refresh / consistent </li></ul></ul><ul><li>Continuous / QA / Demo </li></ul><ul><ul><li>Daily validation and Testing </li></ul></ul><ul><ul><li>Continuous customer access </li></ul></ul><ul><li>Staging </li></ul><ul><ul><li>Mirror Live, prove upgrades </li></ul></ul><ul><li>Production </li></ul>
  38. 38. Best Practice – Why? <ul><li>Expect Change </li></ul><ul><li>Face tough challenges early </li></ul><ul><li>Know what is done </li></ul><ul><li>Visibility early and always </li></ul>
  39. 39. Best Practice – When? <ul><li>You have management buy in </li></ul><ul><li>You have customer buy in </li></ul><ul><li>You understand Why </li></ul><ul><li>Your team are committed </li></ul><ul><li>Start small </li></ul><ul><ul><li>Inspect and adapt </li></ul></ul>
  40. 40. Best Practice – When its not? <ul><li>Don’t start on High Risk projects </li></ul><ul><li>Don’t start without Management buy in </li></ul><ul><li>Don’t start without Customer engagement </li></ul><ul><ul><li>Although agile can help rescue failing projects </li></ul></ul><ul><li>Don’t start if the team don’t want to </li></ul>
  41. 41. Question?
  42. 42. Thank you for attending! Please be sure to fill out your session evaluation!
  43. 44. Thank you for attending! <ul><li>Post conference DVD with all slide decks </li></ul>Sponsored by