Introduction to Agile & scrum
2 likes644 views
The document outlines principles and practices of Agile and Scrum methodologies, emphasizing flexibility, customer satisfaction, and continuous improvement in software development. It critiques the traditional waterfall model and advocates for iterative processes that adapt to changing requirements and foster collaboration among cross-functional teams. Key roles such as the Product Owner and Scrum Master are described, highlighting their responsibilities and traits necessary for successful Agile implementation.
![Elad Sofer Agile coach CSM \ CSP http://blog.thescrumster.com [email_address] Introduction to Agile & Scrum Inspect Adapt Do](https://image.slidesharecdn.com/jobinfointrotoagilescrum-110503044330-phpapp01/85/Introduction-to-Agile-scrum-2-320.jpg)
![The waterfall development model originates in the manufacturing and construction industries The first description of waterfall is a 1970 article by Winston W. Royce Royce presented this model as an example of a flawed, non-working model "I believe in this concept, but the implementation described above is risky and invites failure" [Royce 1970]](https://image.slidesharecdn.com/jobinfointrotoagilescrum-110503044330-phpapp01/85/Introduction-to-Agile-scrum-5-320.jpg)
Introduction to Agile & scrum
- 2. Elad Sofer Agile coach CSM \ CSP http://blog.thescrumster.com [email_address] Introduction to Agile & Scrum Inspect Adapt Do
- 4. Requirements Design Implement Test Acceptance Analysis Deliver
- 5. The waterfall development model originates in the manufacturing and construction industries The first description of waterfall is a 1970 article by Winston W. Royce Royce presented this model as an example of a flawed, non-working model "I believe in this concept, but the implementation described above is risky and invites failure" [Royce 1970]
- 6. Changes in basic assumptions 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. 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 Product development process can be defined as a predictable and repeatable process Product development is an evolving and adaptive process
- 8. Values
- 9. 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 .
- 10. 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
- 11. Scrum
- 12. Philosophy behind scrum Not a methodology!!! – Problem exposure framework. Understanding that we cannot predict the future. One size does not fit all. Constant improvement. Transparency Team work Empirical approach Fun !!!
- 14. spiral (waterfall) vs. iterative
- 15. Scrum product owner - Responsibilities Defines the features of the product Defines release dates and content Responsible for ROI. Prioritizes features Can change features and priority once every predefined interval. Decides what will be worked on in each iteration Accepts or rejects results.
- 16. Scrum product owner – Characteristics Visionary. Leader & Team player Not a control freak Good business understanding. Good communication skills With teams. With customers. Comfortable with change.
- 17. The scrum master - Responsibilities 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.
- 18. The scrum master - Characteristics Natural leader & Team player Does not require formal authority. Very good “soft” skills. Communication. Influence. Understanding of Scrum\Agile. Certification has nothing to do with it! Teacher \ Facilitator. Open minded. Problem solver.
- 19. The team - Responsibilities Typically 5-9 people Cross-functional: Programmers, testers, UI designers, etc. Members 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
- 20. The team member - Characteristics A REAL team player. Willing to try and learn new skills. Shares openly, admits problems, reliable. Cares about others and . Respects & appreciates diversity. Win-Win mindset: Not afraid of conflicts but thrives for consensus. (not compromise) A listener.
- 21. Scrum is fit for… Projects that want to: Deal with changes. Increase profits. Increase quality. Projects sizes such as: 1 team. 100 teams. Organization that: Want to improve. Willing to learn. Want to succeed.
Editor's Notes
- #3: Title slide Used as a prompt to start the presentation Insert footnotes as appropriate. Nokia Siemens Networks has four information confidentiality classes: Public, For internal use, Confidential, Secret " Public " - May be distributed to anyone. Usually public information shall be available for everyone. " For internal use " - May be distributed to anyone employed or having a business relationship with the company under a valid non-disclosure agreement. The disclosure of small amounts of this information to the public will not cause meaningful damages to the company. ‘’For internal use’’ is the default class for Nokia Siemens Networks information, this should be included e.g. in all MS Office (master) templates. (Previously Nokia: Company Confidential, Siemens: Internal use) " Confidential " - May be distributed only to people who have a valid business need. The validity of the business need can be judged by anyone who is authorised to possess the information. Unintentional disclosure of this information to the public will cause significant damages to the company. ‘ ’Confidential’’ is the default class for any customer information. (Previously Nokia and Siemens: Confidential) " Secret " - May be distributed only to people who are specifically authorised by the owner of the information. Disclosure of this information to the public will cause serious damages to the company. (Previously Nokia: Secret, Siemens: Strictly confidential) All documents in Nokia Siemens Networks shall be labelled according to this confidentiality schema.
- #9: http://agilemanifesto.org/
- #10: http://agilemanifesto.org/principles.html
- #11: http://agilemanifesto.org/principles.html