Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

3

Share

Download to read offline

Effective Scrum

Download to read offline

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Effective Scrum

  1. 1. Effective Scrum Székely Sipos Sándor Zolta
  2. 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
  3. 3. Scrum is Popular
  4. 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
  5. 5. Waterfall Model
  6. 6. V Model
  7. 7. The Iron Triangle of Project Management Quality ? Deadline (est.) Cost (est.) Scope (fixed)
  8. 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. 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. 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. 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. 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. 13. The Iron Triangle of Project Management Quality (fixed) Deadline (scheduled) Cost (fixed) Scope (fine-tuned)
  14. 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. 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. 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
  17. 17. Iterative and Incremental Development Functionality Iteration TasksRequirements
  18. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28. The Definition of Done Source: http://geek-and-poke.com/
  29. 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. 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. 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. 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. 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. 34. Scrum Master
  35. 35. Scrum Master Servant Leader • Makes sure Scrum is • Understood • Followed • Interaction  Product Owner  Development Team  Organization  All Stakeholders
  36. 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. 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. 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. 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. 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. 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. 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. 43. Product Backlog • The single source of product change requests • Requirements • Functionality • Enhancements • Bug fixes • Living document • Never complete  Refinement
  44. 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. 45. Estimation Technique: Planning Poker Relative Size Based on Previous Data No Averages Discuss  Consensus
  46. 46. Sprint Backlog
  47. 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. 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. 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. 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. 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. 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. 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. 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. 55. Scrum of Scrums
  56. 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. 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. 58. Theoretically There Is No Limit
  59. 59. Benefits of Scrum Source: http://nyphotographic.com/
  60. 60. Increased Sense of Responsibility Development Team Estimates Decision Development Team Set Their Own Limits Commitment - Together Increased Sense of Responsibility
  61. 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. 62. Motivation, Creativity Scrum Clear and Common Goals Solution - Team Team Members Motivation Creativity
  63. 63. Commitment Big Picture Commitment Scrum Clear and Common Goals Solution - Team
  64. 64. Scrum Transparency Transparency Sprint Review (Demo) Discuss User Stories
  65. 65. High Degree of Independence Scrum Team Mixed Professional Background High Degree of Independence Cross-Functional Teams
  66. 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. 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. 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. 69. Learn from Our Failures Hard Work Time Success Failure 1 Failure n … ?
  70. 70. Software Bugs Found at an Early Stage of Development C o s t
  71. 71. The Dark Side
  72. 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. 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. 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. 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. 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. 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 ?
  78. 78. Agile Mindset Organization Agile Mindset
  79. 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. 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. 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. 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. 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. 84. Lean Principles – 7 Wastes Partially Done Work Unnecessary Functionality Hand-offs Unnecessary Processes Delays Defects Switching Between Tasks Waiting Rework Movement
  85. 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. 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. 87. Kanban Board To Do Plan Max 3 Develop Max 5 Test Max 5 Deploy Max 3 Done
  88. 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. 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. 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. 91. Conclusion Organization Opportunities Constraints Team Skills Attitudes Project Specifics Mindset Agile Lean Process Scrum Kanban Extreme Programming
  92. 92. Contact Information • Name: Székely Sipos Sándor Zolta • LinkedIn: https://www.linkedin.com/in/zoltaszekely • Mail: zzolta@gmail.com
  93. 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. 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
  95. 95. Recommended Reading
  96. 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. 97. Q/A
  98. 98. Thank You for Your Kind Attention 
  • powerirs

    Feb. 14, 2017
  • choeungjin

    Feb. 7, 2017
  • RahulKumar608

    Feb. 2, 2017

Views

Total views

853

On Slideshare

0

From embeds

0

Number of embeds

54

Actions

Downloads

21

Shares

0

Comments

0

Likes

3

×