![Scrum Tools
MyCollab Odoo Taiga
OrangeScrum Tuleap Open ALM Agilefant
Redmine ]Project Open[ Open Project
LibrePlan ProjectLibre Express
ezScrum FireScrum IceSrum](https://image.slidesharecdn.com/agile-scrum-cmmi-170707132128/85/Agile-Scrum-CMMI-46-320.jpg)
Agile Scrum CMMI
- 1. Agile -Scrum -CMMI Presented By: Rabi Raj Khadka Saurav Shrestha
- 2. Agile is not • A methodology • Way of developing software • Framework or process
- 3. Agile is • our guiding principles that lay the foundation for building better software. • a mindset and a way of thinking and acting, based on 4 core values and 12 principles • a philosophy
- 5. More Values -Individuals and interactions | Processes and tools -Working software | Comprehensive documentation -Customer collaboration | Contract negotiation -Responding to change | Following a plan Set of Values less Values
- 6. 12 Principles • Customer Satisfaction • Welcome Change • Deliver a Working Software • Collaboration • Motivation • Face to Face Conversation
- 7. 12 Principles (contd.) • Measure the progress as per the working software • Maintain constant pace • Monitoring • Simplicity • Self organized teams • Review the work regularly
- 8. वखेद त श वकास AGILE Iterative Adaptable Rapid Cooperative Quality-driven Working software Value-Driven Planning Cross-functional Teams
- 10. Agility Test
- 11. Agile Practices • Pair Programming == Working Together • Test Driven Design == Creating our own hypothesis • Automated Acceptance Testing == Giving the customer what they asks for • Refactoring == Cleaning up after ourself • Emergent Design == Learning on the job
- 12. More practices Agile modeling, Agile testing, Backlogs (Product and Sprint) Behavior-driven development, Business analyst designer method , Continuous integration, Cross-functional team, Domain-driven design, Information radiators (scrum board, task board, visual management board, burndown chart), Iterative and incremental development, Planning poker, Retrospective, Scrum events (sprint planning, daily scrum, sprint review and retrospective), Story-driven modeling, Timeboxing, User story, User story mapping, Velocity tracking
- 13. Scrum • is the most popular way of introducing Agility • is light-weight agile process tool • uses fixed-length iterations, called Sprints. • scrum teams try to build a potentially releasable product increment every Sprint • provides a structure of roles, meetings, rules, and artifacts
- 15. Scrum Roles • Product Owner • Scrum Master • Scrum Development Team
- 16. Product Owner • Single person responsible for maximizing the return on investment(ROI) of the development effort • Responsible for product vision • Constantly re-prioritizes the Product Backlog, adjusting any long term expectations such as release plans • Conveys the overall mission and vision of the product which the team is building.
- 17. • Considers stakeholder interests • Final arbiter of requirements questions • Decides whether to release and whether to continue development • May contribute as a team member • Has a leadership role
- 18. Scrum Master • Works with the organization to make Scrum possible • Ensures Scrum is understood and enacted • Creates an environment conducive to team self-organization • Shields the team from external interference and distractions to keep it in group flow
- 19. • Promotes improved engineering practices • Has no management authority over the team • Helps resolve impediments • Has a leadership role
- 20. Scrum Development Team • Cross-functional • Self-organizing / self-managing, without externally assigned roles • Plans one Sprint at a time with the Product Owner • Has autonomy regarding how to develop the increment • Intensely collaborative
- 21. • Most successful when located in one team room, particularly for the first few Sprints • Most successful with long-term, full-time membership. Scrum moves work to a flexible learning team and avoids moving people or splitting them between teams. • 6 ± 3 members • Has a leadership role
- 22. Scrum Meetings • Sprint Planning Meeting • Daily Scrum and Sprint Execution • Sprint Review Meeting • Sprint Retrospective Meeting • Backlog Refinement Meeting
- 23. Sprint Planning Meetings At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting • to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. • Product Owner is responsible for declaring which items are the most important to the business • Development Team is responsible for selecting the amount of work they feel they can implement without accruing technical debt
- 24. • The team determines how it will accomplish the work. • Team pulls Product Backlog Items to Sprint Backlog • Timebox: Eight hours for a four-week sprint, proportionately shorter for shorter sprints • Attendees: The complete Scrum team, including all roles • Most important: Team capacity and DoD (Definition of Done)
- 26. Daily Scrum Meetings • Total of 15 minutes inspecting the progress toward the Sprint goal, and creating a plan for the day. Share • what they did the previous day to help meet the Sprint goal, • what they’ll do today, • and what impediments they face.
- 27. • During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals. • Impediments caused by issues beyond the team’s control are considered organizational impediments. • Itis intended to disrupt old habits of working separately. • Timebox: Fifteen minutes is standard • Attendees: The complete Scrum team, including all roles • Most important: To speak about any impediments
- 29. Sprint Review Meetings • To demonstrate a working product increment to everyone who is interested, particularly outside stakeholders. • Should feature a live demonstration, not a report. • Product owner reviews the items selected during the sprint planning meeting and explains which items are considered done. • Incomplete items are returned to the Product Backlog and ranked according to the Product Owner’s revised priorities as candidates for future Sprints.
- 30. • The Scrum Master helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner. • For Stakeholder it is an opportunity to inspect and adapt the product as it emerges. • Timebox: Four hours for a four-week sprint, proportionately shorter for shorter sprints • Attendees: The complete Scrum team, including all roles, plus any other stakeholders who are interested in the project success • Most important: Demo of working software and assessing the feedback
- 32. Sprint Retrospective Meetings Each Sprint ends with a retrospective. At this meeting, • The team reflects on its own process. • They inspect their behavior and take action to adapt it for future Sprints. Process of meetings • Set the stage, gather data, generate insights, decide what to do, close the retrospective.
- 33. • Scrum Masters should use a variety of techniques to facilitate retrospectives, including silent writing, timelines, and satisfaction histograms. • In all cases, the goals are to gain a common understanding of multiple perspectives and to develop actions that will take the team and organization to the next level. • A common impediment to full transparency on the team is the presence of people who conduct performance appraisals.
- 34. • Another impediment to an insightful retrospective is the human tendency to jump to conclusions and propose actions too quickly • A third impediment to psychological safety is geographic distribution • Timebox: Three hours for a four-week sprint • Attendees: The complete Scrum team, including all roles • Most important: To brainstorm and agree on what is working and what is not
- 36. Backlog Refinement Meetings • Most Product Backlog Items initially need refinement because they are too large and poorly understood. • While Backlog Refinement is not a required event, it is a required activity. • Most Scrum Teams find it useful to take a short time out of every Sprint for this activity. • Large vague items are split and clarified, considering both business and technical concerns.
- 38. Scrum Artifacts • Product Backlog • Sprint Backlog • Increment
- 39. Product Backlog • Prioritized list of desired functionality • Visible to all stakeholders and Any stakeholder can add items • Constantly re-prioritized by the Product Owner • Constantly refined by the Scrum Team • Items at top should be smaller (1/4) than items at bottom
- 40. PBIs • Describes the what more than the how of a customer-centric feature • Often written in User Story form • Has a product-wide definition of done to prevent technical debt • May have item-specific acceptance criteria • Effort is estimated by the Development Team, ideally in relative units
- 41. Sprint Backlog • Consists of selected PBIs negotiated between the team and the product owner during the SPM • No changes are made during the Sprint that would endanger the Sprint Goal. • Team will discover additional tasks needed to meet the Sprint Goal during Sprint execution • Visible to the team • Referenced during the Daily Scrum Meeting
- 42. Increment • The product capabilities completed during the Sprints • Brought to a usable, releasable state by the end of each Sprint • Released as often as the product owner wishes • Inspected during every SRM.
- 43. Optional Artifacts • Sprint Task • Sprint Burndown Chart • Product Release Burndown Chart
- 44. Scrum Rules • Completely up to the team and governed by what works best for their processes. • The best is to start with the basic scrum events listed above and then inspect and adapt based on team’s unique needs so there is continuous improvement in the way teams work together.
- 45. Benefits From Scrum • Higher productivity • Better-quality products • Reduced time to market • Improved stakeholder satisfaction • Better team dynamics • Happier employees
- 46. Scrum Tools MyCollab Odoo Taiga OrangeScrum Tuleap Open ALM Agilefant Redmine ]Project Open[ Open Project LibrePlan ProjectLibre Express ezScrum FireScrum IceSrum
- 47. CMMI • CMM measures the maturity of the software development process on a scale of 1 to 5 • CMMI is the successor of the CMM • more matured set of guidelines and was built combining the best components of individual disciplines of CMM • CMM describes about the software engineering alone
- 48. • Capability Maturity Model Integration is a quality management framework • Describes both software and system engineering. • CMMI also incorporates the Integrated Process and Product Development and the supplier sourcing. Need to measure organization in terms of their overall capability and maturity • to demonstrate repeatable quality of software work they do
- 49. Objectives of CMMI • Produce quality products or services • Create value for the stockholders • Enhance Customer Satisfaction • Increase market share • Gain an Industry-wide recognition for excellence
- 50. •Provides a proven sequence of improvements, each serving as a foundation for the next. •Permits comparisons across and among organizations by the use of maturity levels. •Provides a single rating that summarizes appraisal results and allows comparisons among organizations.
- 51. •Allows us to select the order of improvement that best meets our organization's business objectives and mitigates our organization's areas of risk. •Enables comparisons across and among organizations on a process-area-by-process-area basis.
- 53. Maturity Level 1 - Initial • Processes are usually ad hoc and chaotic. • Success depends on the competence and heroics of the people in the organization and not on the use of proven processes. • characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes.
- 54. Maturity Level 2 - Managed • Ensures that requirements are managed and that processes are planned, performed, measured, and controlled. • Helps to ensure that existing practices are retained during times of stress. • Commitments are established among relevant stakeholders and are revised as needed • Focuses on Basic Project Management
- 55. Maturity Level 3 - Defined • An organization has achieved all the specific and generic goals of the process areas assigned to maturity levels 2 and 3 • Processes are well characterized and understood, and are described in standards, procedures, tools, and methods • Processes are typically described in more detail and more rigorously than at maturity level 2 • Focuses on Process Standardization
- 56. Maturity Level 4 - Quantitatively Managed • An organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, and 4 and the generic goals assigned to maturity levels 2 and 3 • Sub processes are selected that significantly contribute to overall process performance • Quality and process performance measures are incorporated into the organizations measurement repository to support fact-based decision making in the future.
- 57. Maturity Level 5 - Optimizing • An organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, 4, and 5 and the generic goals assigned to maturity levels 2 and 3. • Processes are continually improved based on a quantitative understanding of the common causes of variation inherent in processes. • Focuses on continually improving process performance through both incremental and innovative technological improvements.
- 58. Characteristics of Capability Levels Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Incomplete Performed Managed Defined Quantitatively Managed Optimizing
- 59. Capability Level 0: Incomplete • Process that is either not performed or partially performed. • One or more of the specific goals of the process area are not satisfied and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.
- 60. Capability Level 1: Performed • Process that is expected to perform all of the Capability Level 1 specific and generic practices. • Performance may not be stable and may not meet specific objectives such as quality, cost, and schedule, but useful work can be done. • This is only a baby-step, in process improvement.
- 61. Capability Level 2: Managed • A managed process is planned, performed, monitored, and controlled for individual projects, groups, or stand-alone processes to achieve a given purpose. • Managing the process achieves both the model objectives for the process as well as other objectives, such as cost, schedule, and quality.
- 62. Capability Level 3: Defined • Process is characterized as a "defined process.“ • A defined process is a managed (capability level 2) process that is tailored from the organization's set of standard processes
- 63. Capability Level 4: Quantitatively Managed • Process is characterized as a "quantitatively managed process." • A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. • Quality and process performance is understood in statistical terms and is managed throughout the life of the process.
- 64. Capability Level 5: Optimizing An optimizing process is a quantitatively managed process that is improved, based on an understanding of the common causes of process variation inherent in the process. It focuses on continually improving process performance through both incremental and innovative improvements.
- 65. Appraisal • An organization cannot be certified in CMMI; instead, an organization is appraised • To determine how well the organization’s processes compare to CMMI best practices, and to identify areas where improvement can be made • To inform external customers and suppliers of how well the organization’s processes compare to CMMI best practices • To meet the contractual requirements of one or more customers
- 66. Comparison Agile
- 67. Comparison Scrum
- 68. Comparison CMMI
- 76. Thank You