Detail Information about Agile Process Frameworks such as SCRUM and CMMI along with agile manifesto. Comparison between scrum and capability maturity model integration

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