Agile SCRUM

1
Agile (SCRUM) CMMI

• Presenter Soma Ghosh

2
Agenda

• Overview of Agile
• Basics of Scrum
• Agile Implementation in SISL
• CMMI Agile
• Q A

3

• The agile process is based on the empirical
  approach, accepting the complexity of the problem
  and addressing it through frequent inspection and
  constant adaptation Ken Schwaber

4
Agile Overview

• What does it mean to be AGILE?
• What qualifies to be an Agile software
  development process?
• How can we fit agile into our organisation?

5
Waterfall Insights
This is the place we least want to find any
defects
Project Timeline
Start
Finish
Start
Analysis
Code
Test
Design
Finish

The design of waterfall means that we will always
be at our most vulnerable just when we least
want to be and that defects will be found when
they are the most expensive to fix.
6
The Shunt Effect
4 weeks
40 weeks
4 weeks
4 weeks
analysis
design
test
code
Construction
4 weeks
5 weeks
42 weeks
1week
analysis
design
code
test
As each phase of the project is delayed, the
remaining phases get moved back but the deadline
remains the same, causing compression in the last
stages. Delays are often caused by individuals
who are reticent to sign-off the preceding stage.
7
Traditional approach
Months
1 2 3 4 5
6 7 8 9
10 11 12

Analysis Design
Code
Test Deploy

Software Development
8
An alternate approach
Increment multiple Sprints
Months
1 2 3 4 5
6 7 8 9
10 11 12

Release
Each Sprint is a time boxed mini waterfall!
9
Basis for Agile

• adaptive and responsive to change
• increase productivity and identifying and
  prioritizing high value features
• .positive emergent culture that allows for
  continuous improvement
• .avoid the pitfalls of waterfall

10
Where is Agile needed?
unknown
chaotic
difficult
COMPLEX
requirements
simple
difficult
known
unknown
technology
Defined suitable for known and predictable
domains Empirical for high-change and unstable
domains
11
When where to use agile?

• Agile approach is recommended when
• Domain Technology are evolving
• Requirements change
• Short timelines for delivery
• With a hard release date, it does not matter if
  the business model followed is Fixed price or TM.

12
Agile Manifesto
Individuals Interactions over Process
Tools Working Software over Comprehensive
Documents Customer Collaboration over Contract
Negotiation Responding to Change over Following a
Plan
Things on the right are important. Things on the
left are more important!!
13
Spirit of Agile

• The highest priority to satisfy the customer
  through early and continuous delivery of software
• Welcome changing requirements. Agile processes
  harness changes for customers competitive
  advantages
• Deliver working software frequently, from couple
  of months to couple of weeks, with a preference
  for shorter time scale
• Business people and developers must work together
  throughout the project
• Build projects around motivated people. Give them
  the environment and support to get the job done
• Most effective method of getting information
  around in the team is face-to-face
  conversations
• Working software is the primary measure of
  progress
• Maintain a constant work pace
• Continuous attention to technical excellence

14
Agile Methodologies

• Feature Driven Development (FDD)
• Extreme programming (XP)
• Crystal
• Lean Development
• SCRUM

15
Basics of Scrum
16
What is SCRUM

• Scrum is an agile, lightweight process that can
  be used to manage and control software and
  product development using iterative, incremental
  practices
• Wrapping existing engineering practices,
  including Extreme Programming and RUP, Scrum
  generates the benefits of agile development with
  the advantages of a simple implementation
• The name scrum comes from a strategy used in
  rugby for getting an out-of-play ball back into
  play
• It is adaptive, quick, self-organizing and have
  few rests

17
Characteristic

• Self-organizing teams
• Product progresses in a series of month-long
  sprints
• Requirements are captured in a list of product
  backlog
• No specific engineering practices prescribed

18
Roles Responsibilities

• Product Owner
• Defines the features of the product, decides on
  release date and content
• Is responsible for the profitability of the
  product (ROI)
• Prioritizes features according to market value
• Can change features and priority every 30 days
• Accepts or rejects work results
• Scrum Master
• Ensures that the team is fully functional and
  productive
• Enables close cooperation across all roles and
  functions and removes barriers
• Shields the team from external interferences
• Ensures that the process is followed. Invites to
  daily scrum, iteration review and planning
  meetings

19

• Team
• Cross-functional, seven plus/minus two members
• Selects the iteration goal and specifies work
  results
• Has the right to do everything within the
  boundaries of the project guidelines to reach the
  iteration goal
• Organizes itself and its work
• Demos work results to the Product Owner

20
Key Artifacts

• Product backlog
• List of requirements issues
• Owned by Product Owner
• Anybody can add to it
• Only Product Owner prioritizes
• Sprint Goal
• A short theme for the sprint, typically one
  line summary
• For example, Make the application run on Oracle
  in addition to SQL Server
• Declared by Product Owner
• Accepted by team

21
Key Artifacts

• From Sprint Goal to Sprint Backlog
• Scrum team takes the Sprint Goal and decides what
  tasks are necessary
• Team self organizes around how theyll meet the
  Sprint Goal
• Manager doesnt assign tasks to individuals
• Managers dont make decisions for the team
• Sprint Backlog is created
• Sprint backlog
• List of tasks
• Owned by team
• Only team modifies it
• Blocks list
• List of blocks unmade decisions
• Owned by Scrum Master
• Updated daily

22
Key Meetings

• Sprint Planning Meeting
• Hosted by Scrum Master ½-1 day
• In Product Backlog, existing product, business
  technology conditions
• Select highest priority items in Product Backlog
  declare Sprint Goal
• Team turns selected items into Sprint Backlog
• Out Sprint Goal, Sprint Backlog

Product Owner
Scrum Team
Customers
Management
Sprint Planning Meeting
Product Backlog
Sprint Goal
Existing Product
Business Conditions
Sprint Backlog
Technology Conditions
23
Key Meetings

• Daily Scrum
• Hosted by Scrum Master
• 15 30 minutes stand-up meeting
• Attended by all pigs (scrum team) and chickens
  (others), but only pigs can talk
• Same time every day three questions
• What did you do yesterday?
• What will you do today?
• What obstacles are in your way?
• Team updates Sprint Backlog Scrum Master updates
  Blocks List

24
Key Meetings

• Sprint Review Meeting
• Hosted by Scrum Master, attended by
• Customers
• Management
• Product Owner
• Team
• Team presents what it accomplished during the
  sprint
• Team demos Increment
• 2-hour
• Hold retrospective
• Announce next Sprint Planning Meeting

25
Burndown Chart

• Scrum uses "burn-down" charts to monitor
  progress during a sprint. In a burn-down chart,
  remaining work is plotted on the Y axis, and time
  proceeds along the X axis. As tasks are
  completed, the line slopes down.
• Burndown Chartthe velocity of turning
  requirements into potentially shippable
  increments of functionality.

26
(No Transcript)
27
Some Guiding Philosophy

• Stabilization through continual integration
• The success of continual integration is founded
  on a sound and effective verification strategy.
• Migrate to test driven development in the near
  future.
• In the meanwhile, usher in the practice of
  coverage directed testing
• Coverage goal (line coverage) to be 100 for
  newly added/modified code, with a minimum of 50
  for the entire code base
• A five percent improvement in coverage expected
  with every new iteration
• Automated testing is a pre-requisite for success
• Explore usage of Service Tester as framework for
  carrying out deep unit testing.
• Regular testing at unit level is helpful in
  realizing better coverage

28
Requirement ElaborationPriming the Pipeline

• The analysts job, becomes an effort to create
  mature features/requirements from immature
  ones,
• Before the development team needs to add them to
  a Sprint.
• Analysis can be a just-in-time effort,
  elaborating only what is needed, when its
  needed.
• Some developer time is allocated to assist with
  elaboration even during development sprints.

Analysis/Elaboration
Requirements are made mature and then passed to
development for selection in a Sprint
mature requirements
Development
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
29
Handling Larger Project Staffs in a Scrum

• As project staff size increases, Scrum expands in
  a hierarchical collaboration
• Called a Scrum of Scrums, each Scrum team sends
  a representative to a second daily meeting

Scrum of Scrums
Scrum teams
30
SCRUM CMMI
31
CMMI-SE/SW Level 2 Assessment

• Requirements Management
• Requirements management is addressed in Scrum.
• The requirements are kept in the Product
  Backlog.
• Before a Sprint starts, the Product Owner, Scrum
  Master, and Scrum Team hold the Sprint Planning
  Meeting to select the features to be implemented
  in the next scrum. This means the commitment of
  the requirements is obtained from the project
  participants.
• During a Sprint, new requirements or changes are
  not added in the Sprint Backlog. However, they
  are maintained in the Product Backlog, and will
  be taken into consideration in the next Sprint.
• In the Sprint Review Meeting, the work products
  developed in the Sprint is reviewed to ensure the
  consistency with requirements.

32

• Project Planning
• Scrum addresses project planning in the Sprint
  Planning Meeting.
• The features in the Product Backlog are estimated
  and the project team selects the features to be
  implemented in a 30-day Sprint.
• The project plan is established in the meeting.

• Project Monitoring and Control
• Scrum addresses project monitoring and control
  with the Sprint Burndown Chart. The Sprint
  Burndown displays the amount of effort required
  to finish the project. Maintained by the Scrum
  master, this chart provides the project leader a
  daily feedback on progress.
• At the end of a Sprint, the Sprint Review Meeting
  is held to review the progress. If a deviation
  from the project plan is noticed, the corrective
  action is taken .

33

• Supplier Agreement Management
• Scrum does not mention anything about supplier
  agreement management.
• Measurement and Analysis
• Scrum project can be measured by the Sprint
  Goals. The Scrum Master updates the Sprint
  backlog when the team completes a goal. At the
  Sprint Review Meeting, the backlog is reviewed
  with the stakeholders.
• Process and Product Quality Assurance
• QA activities take place within sprints. Checking
  is done in the beginning of the Sprint to ensure
  that work-products are maintained as defined. At
  the end of the sprint, a QA check is done to
  ensure that the review and testing defects are
  tracked to closure and whether the completion
  criteria is met.
• Quality assurance is performed by design
  inspection and code inspection .The designs and
  codes are inspected with other team members to
  ensure they follow the process description and
  standards.
• Configuration Management
• A single place where all the source code lives
  and from where anyone can obtain the current
  sources from previous versions and a build
  process so as to build the system from the
  sources is a must

34
CMMI-SE/SW Level 3 Assessment

• Organizational Process Focus, Organizational
  Process Definition, Organizational Training
• These are Organization Level Process Areas and
  implementing the scrum related processes in the
  QMS suffices.
• Scrum defines the assets for the project
  development process, i.e., the backlogs.
• Scrum team has to be adequately skilled to
  perform the tasks.
• Requirements Development
• In Scrum, Product Backlog keeps all the
  requirements. Some amount of time is left aside
  for analysis in sprint backlog. Only obvious
  requirements are put in the Product Backlog.
  Further requirements are developed in the Sprint
  Review Meeting after the 30-day development.

35

• Technical Solution
• The designs (and alternative designs, if any) are
  developed by the designers, and inspected with
  other scrum team members.
•  Product Integration
• Unit tested and inspected code are promoted to
  the build. This is the integration point for the
  entire features.
•  Verification
• Reviews are held with other project members to
  verify the correctness of the design and the
  implementation.
•  Validation
• In a Sprint Review Meeting, the results are
  assessed against the Sprint Goals, which are
  developed from the Sprint Backlog. This ensures
  that the developed products meet the
  requirements.

36

• Integrated Project Management
• Project is managed using the Project Plan.
• Contributions are made to the organizational
  process assets and they are also used for
  planning
• Co-ordination is done with stakeholders to
• To address product and product-component
  requirements, issues and risks.
• To fulfill their commitments.
•  Risk Management
• Risk management is done at Sprint level.
•  Decision Analysis and Resolution
• Within a Sprint, DAR can be applied to address
• Alternate designs
• To build or to re-use

37

• The core issue is not whether CMM-like or
  Agile-like practices are best, the core issue is
  building an organizational culture with a balance
  of practices that support innovation, discipline,
  and adaptability.
• - Jim Highsmith
• Agility does not contradict discipline. Agile
  methods have disciplined processes, and the
  processes are well defined. The CMMI is not an
  impediment to quick response. Instead, the CMMI
  states what to do to improve the organizations
  processes. Organizations should design their own
  process based on their business value. Agile
  methods and organizational process improvement
  should be taken into consideration for the
  organization to achieve agility and process rigor
  at the same time.

38
Q A