Agile Scrum CMMI

Agile -Scrum -CMMI

Presented By:Rabi Raj KhadkaSaurav Shrestha

Agile is not• A methodology

• Way of developing software

• Framework or process

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

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

12 Principles• Customer Satisfaction

• Welcome Change

• Deliver a Working Software

• Collaboration

• Motivation

• Face to Face Conversation

12 Principles (contd.)• Measure the progress as per the working software

• Maintain constant pace

• Monitoring

• Simplicity

• Self organized teams

• Review the work regularly

वखेद त श वकास

AGILEIterative

AdaptableRapid

Cooperative

Quality-driven

Working software

Value-Driven

Planning

Cross-functionalTeams

Agility Test

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

More practicesAgile 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

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

Scrum Roles• Product Owner

• Scrum Master

• Scrum Development Team

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.

• 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

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

• Promotes improved engineering practices

• Has no management authority over the team

• Helps resolve impediments

• Has a leadership role

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

• 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

Scrum Meetings• Sprint Planning Meeting

• Daily Scrum and Sprint Execution

• Sprint Review Meeting

• Sprint Retrospective Meeting

• Backlog Refinement Meeting

Sprint Planning MeetingsAt 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

• 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)

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.

• 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

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.

• 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

Sprint Retrospective MeetingsEach 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.

• 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.

• 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

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.

Scrum Artifacts• Product Backlog

• Sprint Backlog

• Increment

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

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

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

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.

Optional Artifacts• Sprint Task

• Sprint Burndown Chart

• Product Release Burndown Chart

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.

Benefits From Scrum• Higher productivity

• Better-quality products

• Reduced time to market

• Improved stakeholder satisfaction

• Better team dynamics

• Happier employees

Scrum ToolsMyCollab Odoo Taiga

OrangeScrum Tuleap Open ALM Agilefant

Redmine ]Project Open[ Open Project

LibrePlan ProjectLibre Express

ezScrum FireScrum IceSrum

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

• 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

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

•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.

•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.

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.

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

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

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.

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.

Characteristics of Capability Levels

Level 0 Level 1

Level 2Level 3

Level 4Level 5

IncompletePerformed

ManagedDefined

Quantitatively ManagedOptimizing

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.

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.

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.

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

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.

Capability Level 5: OptimizingAn 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.

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

Comparison Agile

Comparison Scrum

Comparison CMMI

Thank You