Agile and Scrum Basics

1,604 views

Published on

A compilation of the absolute basics for those who want to know about Agile Methodology with some insights on Scrum. The idea is to give enough to fuel the curiosity to learn more. It might not interest one of he / she is an Agile guru but may I ask for your review / comments / suggestions. I'd love to hear from you all...

Published in: Software, Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,604
On SlideShare
0
From Embeds
0
Number of Embeds
25
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Agile and Scrum Basics

  1. 1. Basics of Agile & Scrum Mazhar Khan
  2. 2. Agile Manifesto
  3. 3. Agile Myth #1 Agile = No documentation “Working software over comprehensive documentation” is often misunderstood with no documentation at all. But how could agile Frameworks like Scrum survive in highly regulated environments like the medical or financial industry if this were to be true. For sure there is documentation, but we don’t waste time on documents that deliver no value to the project.
  4. 4. Agile Myth #2 Agile = Anarchy The biggest fear of any manager is to lose control over their agile teams. Self organization is often interpreted as anarchy. Management is required to define clear visions and goals and the constraints of a project
  5. 5. Agile Myth #3 Agile = Faster It isn't faster just because it’s called a Sprint! Writing quality software is serious business and takes time. One cannot guarantee that doing Agile would mean delivering faster. However one could guarantee having delivered much higher value in a comparable time.
  6. 6. Agile Myth #4 Agile = Silver Bullet Agile is not the only solution know to mankind! However strong the case of merits and values can be put forth, one can’t deny that several successful products have been delivered using waterfall or other methodologies. Its not a one size fits all approach . It’s all about people after all…
  7. 7. Agile Myth #5 Agile = Simple Switch It’s more got to do with “being” Agile and not “doing” Agile. While a simple 2-day course might arm you with the basic concepts it might take long to imbibe the principles that Agile methods are based on
  8. 8. Agile Myth #6 Agile = Easy To be able to deliver a potentially shippable product every 2-4 weeks is not easy. Not many development methodologies can even attempt this. Considering Agile to be easy would be detrimental. However, once the team is Agile-mature, it does run like a well oiled engine with minimum interference.
  9. 9. Agile Myth #7 Agile = Software Development Often the agile journey starts with software development, but it should not stop there. To have an agile software development team in an non- agile environment is like planting a tree in the desert - it won’t survive. The whole company culture has to change, everybody needs to adhere to the agile principles like lean thinking.
  10. 10. Agility overcomes…  Communication Problems  The delivered solution isn’t really what the business wanted  Unused Features  Building the right thing – the business changing their mind  Delayed or late Return on Investment (ROI)  Over-engineering (‘Gold plating’)
  11. 11. SCRUM Basics
  12. 12. Scrum Roles
  13. 13. Scrum Shot!
  14. 14. Scrum Requirements
  15. 15. Scrum Requirements  User Story - A story is a self-contained unit of work agreed upon by the developers and the stakeholders. Stories are the heart of Scrum, and the building blocks of your sprint. E.g. As a salesperson, I'd like to set my password, so I can log into the system  Theme – A group of related stories contributing to a common goal or are related in some obvious way, such as all focusing on a single customer. However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific work flow or be delivered together  Epic - Epics resemble themes in the sense that they are made up of multiple stories. They may also resemble stories in the sense that, at first, many appear to simply be a "big story." As opposed to themes, however, these stories often comprise a complete work flow for a user and their business value isn't realized until the entire epic is complete
  16. 16. Scrum Artifacts
  17. 17. Scrum Artifacts  Product Backlog - Prioritized features list, containing short descriptions of all functionality desired in the product typically written by the Product Owner and the Scrum Team  Sprint Backlog – List of user stories identified during a Sprint Planning meeting by the Scrum team to be completed in a Sprint  Potentially Shippable Product - A potentially shippable product is one that is ready for distribution to anyone in the company for review or even to any external stakeholder. Adhering to a list of “done” criteria ensures that the sprint product is truly shippable
  18. 18. Scrum Ceremonies
  19. 19. Sprint Planning Meeting  WHEN – At the start of each Sprint, usually day long  WHO – Product Owner, Scrum Master and the entire Scrum team. Outside stakeholders may attend by invitation of the team  WHAT  Product Owner - Describes the highest priority features to the team  Team – Ask questions, refine the user stories, commit to a set of user stories that would be delivered in the sprint and do task break down  Scrum Master – Facilitates, servant-leader  Outcome  Sprint goal  Sprint Backlog
  20. 20. Daily Standup meeting
  21. 21. Daily Standup meeting  WHEN – Each day of the Sprint at a fixed place at a fixed time (time-boxed to 15 minutes)  WHO – Product Owner, Scrum Master and the entire Scrum team  WHAT – Each participant answers the following questions  What did I do yesterday?  What will I do today?  Are there any impediments in my way?  Outcome  Update the story board / progress  Team members make commitments to each other  Impediments list modified
  22. 22. Sprint Review / Demo
  23. 23. Sprint Review / Demo  WHEN – At the end of each Sprint (Four-hour time limit)  WHO – Product Owner, Scrum Master, the entire Scrum team, management and stakeholders  WHAT –  Demonstrate working software  No PowerPoint presentations  Presented as a natural result of the sprint vis-à-vis the set Sprint Goal  Outcome  Record feedback
  24. 24. Sprint Retrospective
  25. 25. Sprint Retrospective  WHEN – At the end of each Sprint (Three-hour time limit)  WHO – Product Owner, Scrum Master, the entire Scrum team  WHAT –  Reflect on the Sprint metrics  Discuss what went good  Discuss what needs to be improved  Discuss continuous improvements  Outcome  Record feedback and create actionable items for improvements
  26. 26. Metrics – Sprint Burn down Graphical representation of work left to do versus time
  27. 27. Metrics – Velocity Trend Velocity is how much product backlog effort a team can handle in one sprint
  28. 28. References & Vote of Thanks!  Marc Löffler - 7 Agile Myths  DSDM Handbook  Jeremy Jarrell - Stories versus Themes versus Epics  Wikipedia – Scrum (software development)  Scrum Alliance  ! - None of the images have been created and have been simply used after an preliminary assessment of their copyright. Kindly contact the author in case of any discrepancy and the image will be removed
  29. 29. Be Agile, not just Do Agile Thank you!

×