Primer on Agile Project Management and SCRUM


Published on

Primer on Agile Project Management and SCRUM with links to Resources

Published in: Business
  • Be the first to comment

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

No notes for slide

Primer on Agile Project Management and SCRUM

  1. 1. Basics and Breakdowns from the SCEA perspective
  2. 2. Speaker Information <ul><li>Joe Riego, PMP, Certified Scrum Master, Certified Scrum Product Owner </li></ul><ul><li>Sr. Technical Project Manager, SCEA </li></ul><ul><ul><li>Working as Project Manager/Business Systems Analyst since 1999 </li></ul></ul><ul><ul><li>Last 3 years at SCEA </li></ul></ul><ul><ul><li>SDLC and IT Project Management </li></ul></ul><ul><ul><li>SOX Audit </li></ul></ul><ul><ul><li>SDLC Project Management Consulting </li></ul></ul><ul><li>Blog and Social Networking Site </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul>
  3. 3. Working Agreements <ul><li>An attitude of what could be… Suspend what you know </li></ul><ul><li>One Conversation at a time </li></ul><ul><li>Start and Finish On Time </li></ul><ul><li>Stay on Topic </li></ul>
  4. 4. Who are you… and What do you Do? <ul><li>Name </li></ul><ul><li>Role </li></ul><ul><li>Organization </li></ul><ul><li>Favorite Comic Book Super Hero - </li></ul>
  5. 5. Purpose of the Workshop <ul><li>To provide a primer on Agile Project Management using SCRUM and to show how Agile and SCRUM address scheduling, planning, estimating, and risk management. </li></ul>
  6. 6. Road Map Overview Agile Project Management SCRUM Project/ Product Planning QA and Fun Time <ul><li>Opening </li></ul><ul><li>Why Agile? </li></ul><ul><li>Working Agreements </li></ul><ul><li>Intro - Scrum and Agile Project Management </li></ul><ul><li>&quot;The Agile Manifesto“ </li></ul><ul><li>Waterfall and Agile Project Management Bumped Comparison </li></ul><ul><li>Iterative Development </li></ul><ul><li>What is SCRUM all about? </li></ul><ul><li>The SCRUM Machine </li></ul><ul><li>Bits and Pieces of SCRUM </li></ul><ul><li>The Product Backlog </li></ul><ul><li>The Road Map </li></ul><ul><li>Velocity </li></ul><ul><li>Q and A   </li></ul>
  7. 7. So What is Scrum and Agile Project Management? <ul><li>Not going into any overly specific jargon or canned answers: </li></ul><ul><ul><li>Agile is a Project Management Methodology that focuses on </li></ul></ul><ul><ul><ul><li>Iteration </li></ul></ul></ul><ul><ul><ul><li>Interaction </li></ul></ul></ul><ul><ul><ul><li>Transparency </li></ul></ul></ul><ul><ul><ul><li>Productized Delivery </li></ul></ul></ul><ul><ul><li>SCRUM is: </li></ul></ul><ul><ul><ul><li>A meeting and project tracking format used heavily in organizations that practice Agile Project Management </li></ul></ul></ul>
  8. 8. The “Agile Manifesto” <ul><li>Individuals and interactions over processes and tools </li></ul><ul><li>Working software over comprehensive documentation </li></ul><ul><li>Customer collaboration over contract negotiation </li></ul><ul><li>Responding to change over following a plan </li></ul><ul><ul><li>Pasted from < > </li></ul></ul>
  9. 9. Traditional Project Mgmt and SCRUM/Agile Project Mgmt <ul><li>Traditional Project Management places emphasis on </li></ul><ul><ul><li>Milestones </li></ul></ul><ul><ul><li>Artifact management </li></ul></ul><ul><ul><li>Historical reporting </li></ul></ul><ul><ul><li>Minimizing Change </li></ul></ul><ul><li>SCRUM/Agile Project Management places emphasis on : </li></ul><ul><ul><li>Iteration </li></ul></ul><ul><ul><li>Product oriented delivery </li></ul></ul><ul><ul><li>Transparency </li></ul></ul><ul><ul><li>Extensive “Product Owner” Involvement </li></ul></ul><ul><ul><li>Change is expected and incorporated in the process to provide “value add”. </li></ul></ul><ul><ul><li>Does not rely heavily on historical or artifact management but rather how much work remains moving forward. </li></ul></ul>
  10. 10. Iterative Development
  11. 11. Iterative Development <ul><li>Developing End to End, a working product with the assumption that improvement and gains can be made throughout the development iterations </li></ul><ul><li>The product may not have 100% of the feature set but could be used in production </li></ul><ul><li>The general concept is to flesh out and improve over each iteration to meet the requirements/expectation of the business </li></ul>
  12. 12. SCRUM… What’s it all about? <ul><li>SCRUM is the default process for Agile Project Management and has the following assumptions in its pure form: </li></ul><ul><ul><li>Senior Team Members </li></ul></ul><ul><ul><li>Dedicated Team </li></ul></ul><ul><ul><li>100% Product Owner Involvement </li></ul></ul><ul><ul><li>Product Backlog </li></ul></ul><ul><ul><li>Sprint Backlog </li></ul></ul><ul><ul><li>Daily Meeting </li></ul></ul><ul><ul><li>The Burndown </li></ul></ul><ul><ul><li>Sprint Planning Meeting </li></ul></ul><ul><ul><li>Pigs - Committed </li></ul></ul><ul><ul><li>Chickens - Not Committed </li></ul></ul>
  13. 13. The SCRUM Machine Source:
  14. 14. Pigs and Chickens
  15. 15. The Daily Meeting <ul><li>15min or less </li></ul><ul><li>What are we doing? </li></ul><ul><li>What is planned? </li></ul><ul><li>What is blocking us? </li></ul><ul><li>Take a look at the &quot;Burn Down&quot; or whatever graphical representation of the project the team uses </li></ul><ul><li>That’s it. No muss no fuss </li></ul>
  16. 16. The Pitfalls of the Daily!!! <ul><li>&quot;Lets talk about implementation details&quot; - Good Idea, wrong time </li></ul><ul><li>&quot;Logorreha&quot; - The idea is to keep meetings short so the communication used is supposed to be boiled down, too much talking and team members not on your portion of the sprint loose interest and slows morale </li></ul><ul><li>&quot;What are we supposed to be doing&quot; - No product owner no sprint is what I say, he's the guy/gal that breaks ties on what has to happen and should be the definitive authority on the project Prioritizing and Deprecating as the process moves forward. </li></ul><ul><li>&quot;Scrum Master does that? Right?&quot; – Scrum Master doesn't do very much but act as the alarm for the team and escalate issues and run interference for the development team (Pigs and Chickens) </li></ul>
  17. 17. A common misconception of Agile…
  18. 18. More Common Misconceptions <ul><li>Not a Silver Bullet </li></ul><ul><li>Does not mean no oversight </li></ul><ul><li>There is no plan nor a schedule </li></ul><ul><li>It’s easy - its actually pretty hard </li></ul><ul><li>It can’t scale </li></ul><ul><li>Teams Self Manage so that means they don’t need managers </li></ul>
  19. 19. The Burn Down <ul><li>This is the Graphical Representation of Agile it measures velocity of completing a sprint. </li></ul><ul><li>It looks to work remaining as the metric as opposed to how much is done. </li></ul><ul><li>Seems counter intuitive but from a line perspective it allows the resource to see what is remaining and how much its going to take as opposed to looking at the Gantt and seeing what was done and have no idea how much its going to take given the current time frame. </li></ul>
  20. 20. The Product Backlog <ul><li>Analogous to WBS </li></ul><ul><li>Continually Pruned and managed </li></ul><ul><ul><li>Priority </li></ul></ul><ul><ul><li>Business Value </li></ul></ul><ul><ul><li>Size </li></ul></ul>
  21. 21. The Roadmap <ul><li>Fuzzy Estimates the Further we get out </li></ul><ul><li>The Product Backlog stretched over time </li></ul><ul><li>Thematic and High level </li></ul>
  22. 22. Velocity – When will we be done? <ul><li>Planning Points </li></ul><ul><ul><li>Complexity, Effort, Difficulty </li></ul></ul><ul><li>How many Points can Be done over an Ite.ration/Sprint = a teams velocity </li></ul><ul><li>How many points are in the Backlog </li></ul><ul><li>Given current Velocity the remaining work in back log will take X# of iterations. </li></ul><ul><li>What about time? – Time Boxing = 1 month = 160h no matter what. Or whatever iteration duration. </li></ul>
  23. 23. Agile Resources <ul><li>Rally Dev – </li></ul><ul><li>Blog - The Agile Executive – </li></ul><ul><li>Blog – Agile Game Development – </li></ul><ul><li>Mountain Goat Software – </li></ul><ul><li>Agile (Like Ninjas) Project Management Group – </li></ul>
  24. 24. Question 1: <ul><li>Are Unplanned items usually unexpected production support related issues? What else is unplanned? </li></ul><ul><ul><li>Well from the SCEA perspective we prioritize the production issues and weigh them against the constraints to hitting the sprint as negotiated by the product owner. </li></ul></ul><ul><ul><li>If the product owner says this product support issue trumps a feature; the issue gets the appropriate development effort and the feature gets pushed to the product backlog for reallocation to a future sprint. </li></ul></ul><ul><ul><li>Remember because of the Transparency (in this case finite resources and product owner involvement) Delivery expectations match what the product owner wants. </li></ul></ul><ul><ul><ul><li>Note : As soon as the Product Owner assigns the task to a sprint and gives it a priority it stops being unplanned. </li></ul></ul></ul>
  25. 25. Question 2: <ul><li>If we determine part of the way into a sprint that existing code (Created before the Sprint) needs refactoring, should that be included as an unplanned item </li></ul><ul><ul><li>In the sprint the, User Story should take into account potential unplanned tasks and reflect it in the Complexity Points (If you use them). </li></ul></ul><ul><ul><li>This should at the very least be brought up as a blocker in the Daily for discussion on inclusion into the sprint and requiring Product Owner resolution. </li></ul></ul>
  26. 26. Question 3: <ul><li>If we start work on a story and realize the initial estimate of the story was way off, do we modify the total number of points in the sprint? </li></ul><ul><ul><li>I wouldn't. </li></ul></ul><ul><ul><li>This should be brought up in the daily that the sprint as it currently sits is in jeopardy and that the product owner needs to re-assess the Sprint as a whole and reprioritize the Tasks/User Stories approriately. </li></ul></ul>
  27. 27. Question 4: <ul><li>If we start work on a sprint and the product owner decides he/she doesn’t want a story anymore do we modify the number of points in the sprint? </li></ul><ul><ul><li>Yes. </li></ul></ul><ul><ul><li>However it's been my experience that the Product Owner never wants to take things off without adding more. The reason is typically to assign more work. </li></ul></ul>
  28. 28. Question 5: <ul><li>What sort of requirement gathering process do you go through before you start a new sprint? </li></ul><ul><ul><li>I have a pre-planning meeting: </li></ul></ul><ul><ul><ul><li>Attending </li></ul></ul></ul><ul><ul><ul><ul><li>Product Owner </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Lead Engineer(s), </li></ul></ul></ul></ul><ul><ul><ul><ul><li>We review the product backlog, and then pick the brains to identify additional work. </li></ul></ul></ul></ul>
  29. 29. Question 6: <ul><li>If we have a project that is only 1-2 weeks worth of work would you recommend setting this up as a sprint? If not how would you choose to handle it? </li></ul><ul><ul><li>I would assess is it really an independent initiative or if </li></ul></ul><ul><ul><li>I could roll it up as a User Story in the forthcoming sprint. </li></ul></ul>