SlideShare a Scribd company logo

Introduction to Agile & scrum

•Download as PPT, PDF•
•
Elad Sofer
Elad Sofer

The document discusses key concepts in Agile and Scrum project management frameworks. It outlines some common misconceptions about Agile, describes Scrum roles and ceremonies like sprint planning and review meetings, and emphasizes that adopting Scrum requires changes to team dynamics, skills, and work habits.

1 of 30
מבט לפרויקט סדרת הרצאות Introduction to Agile & Scrum Elad Sofer - Agile coach http://www.TheScrumster.com [email_address]
 
Changes in basic assumptions 1/2 Division of work to specialized teams (specification, design and testing) is efficient It is possible to “collect” or even “know” all the requirements up-front The harder we plan and analyze in the beginning, the less there’s change in the project and the more successful the project. Multiple parallel programs speed up the development Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation Requirements evolve as customers’ and our knowledge increases – based on experience Cross-functional teams reduce the amount of handovers and are more productive
Changes in basic assumptions 2/2 Product development process can be defined as a predictable and repeatable process Product development is an evolving and adaptive process You can save time by “good-enough” development. Any technical debt will slow development down and thus we don’t allow technical debt to accumulate. It’s possible to transfer information effectively on written documents without much of human contact. Essential knowledge is lost in every handover and human interaction is needed to overcome it. Resource usage and cost optimization is the key to increased productivity Concentrating on value stream optimization, removing waste and sustainable flow increases productivity
Wishful thinking No matter how hard you try, it ain’t gonna happen
Values
Agile Principles 1/2 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements , even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to a shorter timescale. Business people and developers must work together daily throughout the project. Build project around motivated individuals . Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within development team is face-to-face conversation .
Working software is the primary measure for progress . Agile processes promote sustainable development . The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams . At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Principles 2/2
Misconceptions Don't believe anything you hear
Agile does not mean: No planning No requirement analysis No visibility to end target No documentation No processes No design Hacking
Agile development means: Adaptive planning Evolving requirements Good design Sufficient documentation High degree of self-discipline skillful software engineering Adaptive processes
 
Philosophy behind scrum Understanding that we cannot predict the future. One size does not fit all. Constant improvement. Transparency Team work As simple as possible & as little as possible. Prioritizing – Industry statistics show: 65% of all features are rarelyever used. Empirical approach Fun !!!
Scrum process overview Product backlog Business Vision Customer Sprint backlog Working software Feedback 2-4 weeks 24 hours
Product backlog List of features, Technology, issues. Items must deliver value for customer. Constantly prioritized & Estimated. Anyone can contribute. Visible to all. Derived from business plan, may be created together, with the customer. Can be changed every sprint!!! Customer is not “programmed” to think of everything in advance.
Product backlog example Backlog item Estimate As a user I would like to register 20 As a user I would like to login 13 As a buyer I would like to make a bid 8 As a buyer I would like to pay with a credit card 20 As a seller I would like to start an auction 20 ... …
Burndown chart – project tracking made easy
The scrum master. Responsible for the scrum process. Protects the team. Helps removing impediments. He is standing at the nexus between: The product management that believes that any amount of work can be done. Developer’s that have the willingness to cut quality to support the managements belief.
The meeting takes place prior to every sprint. The sprint backlog is defined by understanding and agreeing on the sprint goal(s) and selecting the appropriate items from the product backlog. The goal is determined by the customersroduct owneream. The team compiles a list of tasks that are needed in order to complete the sprint goal(s). A task should be as small as possible and should not exceed a time period of 2 days (time not effort). If a task X can not be defined, there will be a task to define the task X. The sprint backlog can be modified throughout the sprint. Sprint planning & Sprint Backlog
Sprint Backlog - Example As a user I would like to register Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)
The responsibility is in the teams hands. Biggest concept change is: The team decides how much it can do, and how to do it. The team is responsible for the quality. All of the other roles in the scrum are there to provide the team all of the things it needs to get the job DONE in time. If the job is not DONE, the team is responsible.
The team Typically 5-9 people Cross-functional: Programmers, testers, UI designers, etc. M embers should be full-time May be exceptions (e.g., database administrator) Teams are self-organizing Membership should change as little as possible only between sprints
The sprint The sprint is the productive part of the scrum It is a fixed, predefined, period of time. During this time the work load, the scope or nature of work must not be changed. The only “manager” of the scope is the sprint backlog. The team is free to accomplish the sprint goal as it see’s fit, within the limits of the team’s procedures and the time limits. During the sprint, the team has total freedom over how it works: Work as many hours as it wants. Hold meetings whenever it wants During the sprint the team is accountable for only two things Daily scrum Sprint backlog.
Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... Requirements Design Code Test ...Scrum teams do a little of everything all the time
Sprint review meeting At the end of each sprint there is a meeting called the sprint review. The purpose of the meeting is to let the “captain” to know where the ship is heading and where it is in it’s route. In addition all new features will be presented to the product owner. During this meeting the team presents to the managementustomerssersroduct owner, what work has been DONE and what was not. The only form of “automated” presentations allowed is working software, Slideware is banned. The things that were not accomplished will be returned to the product backlog.
What is “DONE” ? We have in Scrum – DOD – Definition of Done. Terms of satisfaction of the PO Only DONE items count Success is well defined Example: Unit tested, integrated refactored, deployed.
Scrum process revisited Sprint planning Sprint review Sprint retrospective Daily scrum meeting Ceremonies Product owner ScrumMaster Team Roles Product backlog Sprint backlog Burndown charts Artifacts
What you need to know before starting scrum. Requires investment (Time & Money) Management commitment is a must. May require reorganization Collective codeesign ownership. Team dynamics change. Requires lots of self-discipline Learn new skills & change work habits. Embrace new values.
"Scrum is easy..." Ken Schwaber - co-creator of Scrum "... Dealing with the problem it exposes is very very very hard"
 

More Related Content

Introduction to Agile & scrum

  • 1. מבט לפרויקט סדרת הרצאות Introduction to Agile & Scrum Elad Sofer - Agile coach http://www.TheScrumster.com [email_address]
  • 2.  
  • 3. Changes in basic assumptions 1/2 Division of work to specialized teams (specification, design and testing) is efficient It is possible to “collect” or even “know” all the requirements up-front The harder we plan and analyze in the beginning, the less there’s change in the project and the more successful the project. Multiple parallel programs speed up the development Multiple programs create big management overhead and risk of overloading the pipeline, R&D works most efficiently in continuous mode There is change always and responding to it is vital. Uncertainty is best reduced by learning from actual implementation Requirements evolve as customers’ and our knowledge increases – based on experience Cross-functional teams reduce the amount of handovers and are more productive
  • 4. Changes in basic assumptions 2/2 Product development process can be defined as a predictable and repeatable process Product development is an evolving and adaptive process You can save time by “good-enough” development. Any technical debt will slow development down and thus we don’t allow technical debt to accumulate. It’s possible to transfer information effectively on written documents without much of human contact. Essential knowledge is lost in every handover and human interaction is needed to overcome it. Resource usage and cost optimization is the key to increased productivity Concentrating on value stream optimization, removing waste and sustainable flow increases productivity
  • 5. Wishful thinking No matter how hard you try, it ain’t gonna happen
  • 7. Agile Principles 1/2 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements , even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to a shorter timescale. Business people and developers must work together daily throughout the project. Build project around motivated individuals . Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within development team is face-to-face conversation .
  • 8. Working software is the primary measure for progress . Agile processes promote sustainable development . The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing the amount of work not done – is essential. The best architectures, requirements, and designs emerge from self-organizing teams . At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Principles 2/2
  • 9. Misconceptions Don't believe anything you hear
  • 10. Agile does not mean: No planning No requirement analysis No visibility to end target No documentation No processes No design Hacking
  • 11. Agile development means: Adaptive planning Evolving requirements Good design Sufficient documentation High degree of self-discipline skillful software engineering Adaptive processes
  • 12.  
  • 13. Philosophy behind scrum Understanding that we cannot predict the future. One size does not fit all. Constant improvement. Transparency Team work As simple as possible & as little as possible. Prioritizing – Industry statistics show: 65% of all features are rarelyever used. Empirical approach Fun !!!
  • 14. Scrum process overview Product backlog Business Vision Customer Sprint backlog Working software Feedback 2-4 weeks 24 hours
  • 15. Product backlog List of features, Technology, issues. Items must deliver value for customer. Constantly prioritized & Estimated. Anyone can contribute. Visible to all. Derived from business plan, may be created together, with the customer. Can be changed every sprint!!! Customer is not “programmed” to think of everything in advance.
  • 16. Product backlog example Backlog item Estimate As a user I would like to register 20 As a user I would like to login 13 As a buyer I would like to make a bid 8 As a buyer I would like to pay with a credit card 20 As a seller I would like to start an auction 20 ... …
  • 17. Burndown chart – project tracking made easy
  • 18. The scrum master. Responsible for the scrum process. Protects the team. Helps removing impediments. He is standing at the nexus between: The product management that believes that any amount of work can be done. Developer’s that have the willingness to cut quality to support the managements belief.
  • 19. The meeting takes place prior to every sprint. The sprint backlog is defined by understanding and agreeing on the sprint goal(s) and selecting the appropriate items from the product backlog. The goal is determined by the customersroduct owneream. The team compiles a list of tasks that are needed in order to complete the sprint goal(s). A task should be as small as possible and should not exceed a time period of 2 days (time not effort). If a task X can not be defined, there will be a task to define the task X. The sprint backlog can be modified throughout the sprint. Sprint planning & Sprint Backlog
  • 20. Sprint Backlog - Example As a user I would like to register Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)
  • 21. The responsibility is in the teams hands. Biggest concept change is: The team decides how much it can do, and how to do it. The team is responsible for the quality. All of the other roles in the scrum are there to provide the team all of the things it needs to get the job DONE in time. If the job is not DONE, the team is responsible.
  • 22. The team Typically 5-9 people Cross-functional: Programmers, testers, UI designers, etc. M embers should be full-time May be exceptions (e.g., database administrator) Teams are self-organizing Membership should change as little as possible only between sprints
  • 23. The sprint The sprint is the productive part of the scrum It is a fixed, predefined, period of time. During this time the work load, the scope or nature of work must not be changed. The only “manager” of the scope is the sprint backlog. The team is free to accomplish the sprint goal as it see’s fit, within the limits of the team’s procedures and the time limits. During the sprint, the team has total freedom over how it works: Work as many hours as it wants. Hold meetings whenever it wants During the sprint the team is accountable for only two things Daily scrum Sprint backlog.
  • 24. Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... Requirements Design Code Test ...Scrum teams do a little of everything all the time
  • 25. Sprint review meeting At the end of each sprint there is a meeting called the sprint review. The purpose of the meeting is to let the “captain” to know where the ship is heading and where it is in it’s route. In addition all new features will be presented to the product owner. During this meeting the team presents to the managementustomerssersroduct owner, what work has been DONE and what was not. The only form of “automated” presentations allowed is working software, Slideware is banned. The things that were not accomplished will be returned to the product backlog.
  • 26. What is “DONE” ? We have in Scrum – DOD – Definition of Done. Terms of satisfaction of the PO Only DONE items count Success is well defined Example: Unit tested, integrated refactored, deployed.
  • 27. Scrum process revisited Sprint planning Sprint review Sprint retrospective Daily scrum meeting Ceremonies Product owner ScrumMaster Team Roles Product backlog Sprint backlog Burndown charts Artifacts
  • 28. What you need to know before starting scrum. Requires investment (Time & Money) Management commitment is a must. May require reorganization Collective codeesign ownership. Team dynamics change. Requires lots of self-discipline Learn new skills & change work habits. Embrace new values.
  • 29. "Scrum is easy..." Ken Schwaber - co-creator of Scrum "... Dealing with the problem it exposes is very very very hard"
  • 30.  

Editor's Notes

  1. http://agilemanifesto.org/
  2. http://agilemanifesto.org/principles.html
  3. http://agilemanifesto.org/principles.html