Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Effective Scrum
Similar to Effective Scrum (20)
Effective Scrum
- 1. Effective Scrum Székely Sipos Sándor Zolta
- 2. Agenda • Software Engineering Challenges • Agile Methodologies • Scrum • In a Nutshell - Ensure We Are All on the Same Page • Benefits and Opportunities • Caveats and Pitfalls • Best Practices • Alternatives • Conclusion
- 4. Software Engineering Challenges Challenges Understand customer needs Requirements change Tight deadlines System integration Estimation - art or science? Attitude and skills of project team members Technical debt Young Science
- 6. V Model
- 7. The Iron Triangle of Project Management Quality ? Deadline (est.) Cost (est.) Scope (fixed)
- 8. Technical Debt "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation..." Ward Cunningham, 1992 Deadline Pressure Technical Debt Code quality Tests Speed
- 9. Technical Debt • Unpredictable • If you notice it, do not try to hide it! • Act quickly! • Its consequences: Increase in software delivery time Increase in the number of bugs Decrease in customer satisfaction “Degeneration” of the product Increased maintenance costs Low performance Frustration (development team)
- 10. How to Prevent and Fight It? • Prevention, prevention, prevention… • Strict Definition of Done • Covering code quality as well • Sonar • Extreme Programming Techniques • TDD • Pair Programming • Boy Scout Rule • Clean Code principles
- 11. The Agile Manifesto Processes and Tools Individuals and Interactions Comprehensive Documentation Working Software Contract Negotiation Customer Collaboration Following a Plan Responding to Change
- 12. The 12 Principles Behind the Agile Manifesto Frequent delivery Earlyandcontinuousdelivery Close cooperation between business people and developers Working Software Self-organizing teams The art of maximizing the amount of work not done Frequent delivery Earlyandcontinuousdelivery Motivated, trusted individuals Self-organizing teams Welcomechangingrequirements Welcome changing requirements Face-to-face conversation Technical excellence and good design Adapt quickly to changing realities Simplicity Simplicity Face-to-faceconversation
- 13. The Iron Triangle of Project Management Quality (fixed) Deadline (scheduled) Cost (fixed) Scope (fine-tuned)
- 14. Challenges Waterfall VModel Agile Understand customer needs Requirements change Tight deadlines System integration Estimating is more an art than science Attitude and skills of project team members Technical debt Young Science Comparison
- 15. Definition of Scrum “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” The Scrum Guide™, Ken Schwaber and Jeff Sutherland Characteristics: Lightweight Easy to understand Difficult to master
- 16. The Scrum Framework Rules Iteration Increment Product Owner Scrum Master Development Team Roles Sprint Planning Sprint Review Sprint Retrospective Daily Scrum Ceremonies Product Backlog Sprint Backlog Reports (charts) Artifacts
- 18. Sprint – Iteration • Goal • Scope – development team decides Team commitment Product increment • Length: 2-4 weeks Photographer: Vullioud Pierre-André Source: http://www.freeimages.com/
- 19. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl Test CRImpl Impl CR Test Impl Test Test CRImpl
- 20. User Story • Represents the customer needs • Customers/users write them • Informal, non-technical language • Acceptance criteria • Size • Limited • Estimate • Time • Story points • Quantity • Complexity
- 21. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl Test CRImpl Impl CR Test Impl Test Test CRImpl
- 22. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 ImplImpl Test CR Impl ImplCR Test Impl Test Test CRImpl
- 23. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 ImplImpl Test CR Impl ImplCR Test Impl Test Test CRImpl
- 24. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl TestCR Impl ImplCR Test ImplTest Test CRImpl
- 25. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl Test CRImpl ImplCR Test ImplTestTest CR Impl
- 26. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl Test CRImpl Impl CRTest Impl TestTest CR Impl
- 27. Sprint Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl Test CRImpl Impl CRTest Impl Test Test CRImpl
- 28. The Definition of Done Source: http://geek-and-poke.com/
- 29. Acceptance Criteria • Addition to the Definition of Done • User Story • Refinement • Remember the V Model • User Acceptance Test (UAT) Defined upfront • BDD (Behavior Driven Development)
- 30. Non-Functional Requirements – NFR • System level requirements • It is a good practice to have as many NFRs being part of the Definition of Done as possible Quick feedback • Not always possible nor necessary New functionality
- 31. The Scrum Framework Rules Iteration Increment Product Owner Scrum Master Development Team Roles Sprint Planning Sprint Review Sprint Retrospective Daily Scrum Ceremonies Product Backlog Sprint Backlog Reports (charts) Artifacts
- 32. The Scrum Team Makes efforts in order to deliver at the end of each sprint the potentially shippable product increment they have committed to. • Team members: Product Owner Scrum Master Development Team Ideal team size: 5 - 10
- 33. Product Owner • Responsible to maximize the value of the product • Responsible for: • Product Backlog • Items • Unambiguous description • Prioritization • Accessible • Transparent • Understood by every key stakeholder One single person!
- 34. Scrum Master
- 35. Scrum Master Servant Leader • Makes sure Scrum is • Understood • Followed • Interaction Product Owner Development Team Organization All Stakeholders
- 36. Development Team • Self-organizing • Cross-functional • There are no titles • Everyone is a developer • There are no subgroups the whole team is responsible for their commitment Professionals
- 37. The Scrum Framework Rules Iteration Increment Product Owner Scrum Master Development Team Roles Sprint Planning Sprint Review Sprint Retrospective Daily Scrum Ceremonies Product Backlog Sprint Backlog Reports (charts) Artifacts
- 38. Sprint Planning • The Product Owner presents the Sprint Goal and the Product Backlog Items which need to be completed in order to reach the goal • What will be accomplished? • How? • Outcome: Sprint Backlog • In case of 2-week Sprints limited to 4 hours
- 39. Sprint Review • Purpose: inspect the product increment • The development team • demonstrates the completed work • answers the questions related to the increment • Informal • Open to everyone • At the end of the Sprint • In case of 2-week Sprints limited to 2 hours
- 40. Sprint Retrospective • Ensures continuous improvement • Scrum Team identifies and prioritizes • What worked well • What could be improved Outcome: Plan to improve the efficiency of the Scrum Team • When: • After Sprint Review, before next Sprint Planning • In case of 2-week sprints limited to 1.5 hours People Interactions Processes Tools
- 41. Daily Scrum • Purpose: • Maintain momentum • Identify impediments • Improve communication within the team • How: • Same time • Same place • Time boxed: 15 minutes What did you do yesterday? 1 What will you do today? What obstacles are in your way or slowing you down? 2 3
- 42. The Scrum Framework Rules Iteration Increment Product Owner Scrum Master Development Team Roles Sprint Planning Sprint Review Sprint Retrospective Daily Scrum Ceremonies Product Backlog Sprint Backlog Reports (charts) Artifacts
- 43. Product Backlog • The single source of product change requests • Requirements • Functionality • Enhancements • Bug fixes • Living document • Never complete Refinement
- 44. Backlog Refinement / Grooming • Continuous activity • Development team and Product Owner • Items: • Reviewed • Extended • Estimated • Priority changed when needed • No more than 10% of the capacity of the development team
- 45. Estimation Technique: Planning Poker Relative Size Based on Previous Data No Averages Discuss Consensus
- 46. Sprint Backlog
- 47. Scrum Ceremonies and Artifacts Potentially shippable product increment Sprint 2-4 weeks 24 hours Sprint Backlog Product Backlog Refinement Sprint planning Daily Scrum Sprint Demo Sprint Retro
- 48. Monitoring Progress - Reports • Scrum relies on transparency • Actual state of work packages Decisions to optimize value and control risk Sprint burn down Cumulative flow Velocity
- 49. Sprint Burn Down Chart 0 10 20 30 40 50 60 70 80 90 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Ideal Actual Before schedule Behind schedule Sprint Start Sprint End EstimatedTime(man-days) Sprint Days
- 50. Cumulative Flow 0 50 100 150 200 250 300 350 400 1 2 3 4 5 6 7 8 Done In Progress To Do Sprints NumberofUserStories
- 51. Velocity Chart 0 5 10 15 20 25 30 35 1 2 3 4 5 6 7 Commitment Actual Velocity: 27 NumberofStoryPoints Sprints
- 52. Cancelling a Sprint Sprint goal - obsolete, no longer relevant Company strategy changed Important market or technology conditions changed In the given circumstances it does not make sense to continue Who: Product Owner Rarely makes sense Short duration of sprints Demotivating
- 53. Scalability • Large project • A lot of functionality to implement • Tight deadlines • Mandatory: Parallelizable tasks Several teams • Approach: • Work packages independent from each other • That can be built into the product one after other or at the same time • There is enough work to keep everyone busy
- 54. Scalability – Scrum • Several Product Owners – only one Product Backlog! • Coordination • Chief Product Owner • Before refinement and planning • Synchronization between Product Owners is necessary • Sprint Review • All teams together • Separately • Retrospective • Sometimes also with the representatives of all teams • Scrum of Scrums (SOS)
- 55. Scrum of Scrums
- 56. Scrum of Scrums What has your team done since we last met? 1 What will your team do before we meet again? Is anything slowing your team down on their way? 2 3 Are you about to put anything in another team’s way? 4 Resolve problems and discuss issues on the team backlog.
- 57. What Scrum of Scrums is Not “All the ScrumMasters and the project manager would have a teleconference three times a week where the ScrumMasters would take turns giving status reports(!) and complaining about the problems they had. I was approached by some of the ScrumMasters asking me if we shouldn’t have the meeting less frequently since ‘nothing new is being said. The same problems are being brought up in every meeting.’” Morgan Ahlström: Scrum of Scrums – A Communication Thermometer
- 58. Theoretically There Is No Limit
- 59. Benefits of Scrum Source: http://nyphotographic.com/
- 60. Increased Sense of Responsibility Development Team Estimates Decision Development Team Set Their Own Limits Commitment - Together Increased Sense of Responsibility
- 61. Less “Single Point of Failure” Scrum Cross-Functional Teams Attend All Ceremonies Team Members Product Know-How Project Know-How Less Pressure on Individuals
- 62. Motivation, Creativity Scrum Clear and Common Goals Solution - Team Team Members Motivation Creativity
- 63. Commitment Big Picture Commitment Scrum Clear and Common Goals Solution - Team
- 65. High Degree of Independence Scrum Team Mixed Professional Background High Degree of Independence Cross-Functional Teams
- 66. Extreme Programming Communication, Team Spirit Photographer: Sebastian Danon Sources: http://www.freeimages.com/ Scrum Team Independent Problem Solving Communication Team Spirit Pair Progr TDDCI
- 67. Continuous Improvement Identify Opportunities Flaws in the process Plan How can the process be improved? Try out For one iteration Retrospect Did it work?
- 68. Fail Fast and Often • Does not give the possibility to failure • Can lead to a mental roadblocks Most Education Systems Suggest Hard Work Time Success
- 69. Learn from Our Failures Hard Work Time Success Failure 1 Failure n … ?
- 70. Software Bugs Found at an Early Stage of Development C o s t
- 71. The Dark Side
- 72. Scrum is Verbose Scrum ceremonies: • Sprint planning • Up to 4 h • Daily Scrum • ~10x15 minutes = 2h 30m • Sprint Review • Up to 2 h • Sprint Retrospective • Up to 1.5 h Other meetings: • Backlog Refinement • Up to 10% ≈ 8 h Scaled: • Meetings to discuss, break down and assign epics/features to teams • Scrum of Scrums *2 week sprints
- 73. Flow • Meetings Agenda Focus Participants • Choose wisely! Keep it short Meeting minutes • Alternatives • Even if short, they still interrupt developers in their creative work Flow
- 74. Daily Stand-up • Scrum framework Daily Scrum • Stand-up became a habit, a ritual, a dogma, Jon Evans calls it even cargo cult • Ideal circumstances • Development team members • Start working more or less at the same time • Are collocated • Are in the same or close time zones • Kept short (up to 10-15 minutes) Creative and Productive Morning Period Context Switchingor
- 75. … The Check-in as Alternative What did I accomplish yesterday? 1 What do I intend to do today? Are there any impediments? 2 3 Login Write Read A s y n c h r o n o u s
- 76. Adaptability and Flexibility… • “Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.“ End Note, The Scrum Guide, Ken Schwaber and Jeff Sutherland, July 2013 Processes and Tools Individuals and Interactions ?
- 77. No Changes During the Sprint • Choose the length of the Sprints in such a way that it can resist change Sprint Scrum Master Guardian of Scrum Following a Plan Responding to Change ?
- 79. Agile Keeps People Busy • Can be very tiring to the whole development team • Being iterative, it offers some moments to relax between sprints – take advantage of it! Agile
- 80. Money, Money, Money… • Courses • Workshops • Certifications • Cost a bunch of money • Expire • Need to be renewed from time to time, for even more money • They exist for most specialties but in the case of Scrum it became outrageously over-dimensioned • Evangelists, coaches preach for money the new religion
- 81. Who Became the Scrum Masters? • Mostly Project Managers • Often with no technical knowledge • They have no development experience • In any case, not with the modern way of it Scrum often simply does not work Servant Leader I n s t e a d Manager
- 82. Scrum Masters Cannot Stand on the Side Line • Scrum process – “good enough” • Scrum Master – sometimes get out of shape • Remember: agile required continuous improvement! A Scrum Master cannot stand on the side line
- 83. Part time and remote work • Part time work • Scrum ceremonies eat up the same time Barely have time for development • Remote work • Meetings Video conferencing Online real time collaboration tools Still difficult to follow
- 84. Lean Principles – 7 Wastes Partially Done Work Unnecessary Functionality Hand-offs Unnecessary Processes Delays Defects Switching Between Tasks Waiting Rework Movement
- 85. Kanban, an Alternative • Goal: improve organizational efficiency • Kanban: focus on processes • Lean principles – 7 wastes • Clearly defined process rules • Transparency of tasks • Limit work in progress • Constantly measure and improve flow
- 86. Scrum Board To Do In Progress DoneUser Story PBI #1 PBI #2 PBI #3 Impl Impl Test CRImpl ImplCR Test ImplTestTest CR Impl
- 87. Kanban Board To Do Plan Max 3 Develop Max 5 Test Max 5 Deploy Max 3 Done
- 88. Kanban • Easy to learn • Works well with other methodologies • Extreme programming • TDD • Pair Programming • Continuous Integration • Efficient at adapting to changes • Makes continuous delivery possible
- 89. Kanban • No roles • Kaizen meetings • Anyone can organize • Only affected team members participate • Focus: Kanban board • Does not prescribe estimations • Difficult to tell when specific tasks are done • Deadlines – may be written to cards but not necessary • Puts efficiency before predictability
- 90. Comparison Scrum Kanban Empirical Lean Agile Sprints Continuous flow of work Limits work in progress Focus on fast and continuous delivery Reorganization might be necessary (cross-functional teams) Current situation is the starting point Transparency Continuous improvement of processes Roles (SCM, PO) No roles Estimates Does not prescribe estimates Predictability Efficiency
- 91. Conclusion Organization Opportunities Constraints Team Skills Attitudes Project Specifics Mindset Agile Lean Process Scrum Kanban Extreme Programming
- 92. Contact Information • Name: Székely Sipos Sándor Zolta • LinkedIn: https://www.linkedin.com/in/zoltaszekely • Mail: zzolta@gmail.com
- 93. Bibliography • A Scrum Guide, Ken Schwaber and Jeff Sutherland • Introduction to Scrum, Mike Cohn • Stand up against the stand-up, Jon Evans • Lean + Agile vs Seven Wastes in Software Development, V S S N R Ram Nanduri • A Scrum keretrendszer és agilis módszerek használata a Visual Studióval, Csutorás Zoltán, Árvai Zoltán, Novák István • Essential Scrum, A Practical Guide to the Most Popular Agile Process, Kenneth S. Rubin • http://www.adaptiveconsulting.hu/kanban-vagy-scrum • https://www.linkedin.com/pulse/how-reduce-risk-missing- nonfunctional-requirements-miller-cbap
- 94. Bibliography • https://dzone.com/articles/digging-fail-fast-fail-often • http://www.seguetech.com/waterfall-vs-agile-methodology • https://blog.gate6.com/top-6-challenges-software- development • https://www.finextra.com/blogposting/6836/7-reasons- why-software-development-is-so-hard • https://www.scrumalliance.org/community/articles/2007/m ay/advice-on-conducting-the-scrum-of-scrums-meeting • https://www.wikipedia.org • http://www.freeimages.com • http://geek-and-poke.com • https://www.draw.io
- 96. Copyright Notice • You are free: • To Share―to copy, distribute and transmit the work • To Remix―to modify/adapt the work • Under the following conditions • Attribution: you must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work) • Nothing in this license impairs or restricts the author’s moral rights • For more information see: https://creativecommons.org/licenses/by/4.0/ Attribute! CC BY 4.0
- 97. Q/A
- 98. Thank You for Your Kind Attention