Agile & SCRUM



What is Agile?

  • A group of software development methods that builds software incrementally.  
    •

  • Breaks projects down using user stories , prioritizing them, and then continuously delivering them in short cycles called sprints .

The Agile Manifesto


  • In February 2001, 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods.

  • They published the Manifesto for Agile Software Development to define the approach now known as agile software development.

Agile purpose


  • To teach teams to be Agile. 
    • While a new process can easily improve team productivity by a fraction, enabling your team to work effectively as a cohesive unit can improve productivity by several times.
    • Agility is the ability to both create and respond to change in order to profit in a turbulent business environment.
      - Jim Highsmith, Agile Project Management



Agile values


  • Individuals and interactions   over Processes and tools
  • Working software   over Comprehensive documentation
  • Customer collaboration   over Contract negotiation
  • Responding to change   over Following a plan 
"That is, while there is value in the items on the right, we value the items on the left more"
 

Scrum Framework

  • Scrum  is an iterative and incremental Agile software development framework for managing software projects and product or application development.


Roles

  • Scrum Master
  • Business Owner
  • Development Team 


Scrum Master

  • IS:
    •
    • A scrum facilitator:
      •
      • Removes impediments to the ability of the team to deliver the product goals and deliverables.
        •
      • Ensures that the Scrum process is used as intended.

  • IS NOT:
    •
    • A Project Manager: 
      • In fact, there is no role of project manager in Scrum at all, because none is needed.
      • Responsibilities of a project manager have been divided up and reassigned among the three Scrum roles.
      • Practicing Scrum with the addition of a project manager indicates a fundamental misunderstanding of Scrum, and typically results in conflicting responsibilities, unclear authority, and sub-optimal results

Product Owner


  • Represents the stakeholders and is the voice of the customer.
  • Creates the user stories, ranks and prioritizes them, and adds them to the product backlog.
  • Is combined with the role of Project Manager as they have the best visibility regarding the scope of work.

Development Team


  • Responsible for delivering potentially shippable increments of product at the end of each Sprint.
  • A Team is made up of 3–9 individuals with cross-functional skills who do the actual work.


Artifacts 


  • Backlog
  • User Story
  • Burn-down Chart


Backlog


  • Is a prioritized features list, containing short descriptions of all functionality desired in the product.
  • There are two kinds of backlog:
    • Product backlog: Contains the required User Stories for the entire project. 
      • Can grow and change as more is learned about the product and its customers.
    • Sprint backlog: Contains the requirements for the specific iteration. CANNOT GROW OR CHANGE.

User Story


  • Are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. 
  • Points and priority are assigned to them.

  • Examples:
    • "As a admin user, I can specify files or folders to backup based on file size, date created and date modified."             

Burn-down chart


  • Is a graphical representation of work left to do versus time. 
  • Is an essential part of any agile project and is a way for the team to clearly see what is happening and how progress is being made during each sprint.


Events


  • Sprints
  • Planning Meeting
  • Daily Stand Up Meeting
  • Review Meeting
  • Retrospective Meeting


Sprints


  • Is a regular, repeatable work cycle or iteration during the development process.
  • In by-the-book Scrum, a sprint is 30 days long, but many teams prefer shorter sprints, such as one-week, two-week, or three-week sprints.
    •  The important thing is that a sprint is a consistent duration.
  • A deliverable has to be defined for each sprint, at the end of the sprint the deliverable will be demoed to the stakeholders.

Planning Meeting


  • Every sprint begins with the sprint planning meeting, in which the Product Owner and the team discuss which stories will be moved from the product backlog into the sprint backlog.
  • Once the team commits to the work, the Product Owner cannot add more work or alter course mid-sprint.
  • During this meeting team will assign sizes to the picked stories, the Business Owner will let the team to assign the sizes but he/she will be in charge of priority assignation. 

Daily Stand up


  • Each day during the sprint, a project team communication meeting occurs.
    • All members of the development team come prepared with the updates for the meeting.
    • The meeting starts precisely on time even if some development team members are missing.
    • The meeting should happen at the same location and same time every day.
    • The meeting length is set  to 15 minutes.

  • During the meeting, each team member answers three questions:
    • What have you done?
    • What are you planning to do today?
    • Any blockers? 

Review Meeting


  • At the end of each sprint, a sprint review meeting is held. 
  • During this meeting, the Scrum team shows what they accomplished during the sprint (DEMO).


Retrospective meeting

  • Is the last thing done in a sprint. 
  • During this meeting two main questions are asked: 
    • What went well during the sprint? 
    • What could be improved in the next sprint?
  • At the end of the sprint, the next retrospective is often begun by reviewing the list of things selected for attention in the prior sprint retrospective.

Scrum Software


  • GreenHopper
    • https://confluence.atlassian.com/display/AGILE/GreenHopper+6.2+Release+Notes
  • Rally: 
    • http://www.rallydev.com/ 

Agile Risk Management



What is Risk Management (RM) ?
  • Risk management  is the identification, assessment, and prioritization of  risks (whe ther positive or negative) followed by an application to minimize, monitor, and control the probability and/or impact of unfortunate events  or to maximize the realization of opportunities.


Regular RM Process


  • Identify, characterize threads.
  • Assess the vulnerability of critical assets to specific threats.
  • Determine the risk.
  • Identify ways to reduce those risks.
  • Prioritize risk reduction measures based on a strategy.
    •



Some disadvantages
  • A list is created to track all the identified risks.
    • It basically is an ordered list, each risk will be ordered based on their impact on the project and the probability of that risk coming true.
    • A mitigation plan is created for the risks at the top of the list.

  • The problem with this approach is that it is not agile. 
    • This risk management is overwhelming and bureaucratic and experience tells us that teams has not the discipline to do this regularly by the book .
    • Only focus on the importnat risks only, which are common to all projects and even more they rarely manifest .

RM Process in Agile?



Risk Identification in Agile

  • Agile replaces explicit risk management with a continuous risk management.
    • The whole team does this exercise on an iterative basis. The results are recorded on white boards or flip charts.
  • Due to its iterative nature, it implicitly makes risk management a part of the project life cycle. 


Risk Identification in Agile

  • Risk gets addressed all the time as a part of daily stand-ups, iteration planning meetings, release planning meetings, retrospective and review meetings.

    • Daily Stand up meetings: team members need to answer this: Are there any blockers in your way?
    • Sprint Retrospective: allows catching all the risks associated with customer communication and requirements.

Risk Analysis


  • Qualitative analysis using judgment, intuition, and experience in determining risks and potential losses. 
  • Short development cycles and constant reviews in Agile, make this feasible and effective.
  • This is different from traditional projects where quantitative analysis is done and numbers are assigned to the damage which can occur.

Risk Mitigation in Agile


  • Scrum Master main function is to eliminate or mitigate any blocker.
  • Risks are not blocked items, instead they are on the Scrum master's watch list, as a note for things which could go wrong.
  • Agile stresses the importance of the continuous communication of the problems.
    • States that detect and talk about a risk is more than enough to mitigate it.
  • A Scrum team could sort stories by value and risk and work on the risky stories long enough to correctly identify and mitigate the risk. 

Disadvantages


  • Agile can help with risks related to change in requirement, lack of communication and under performance by team members.
  • However, risks which are external to the project need more than Agile to be resolved.
    • Lack of understanding of Scrum at the customer
    • Third party products don’t work as expected
    • External factors which the project depends on won’t happen in time
    • Data loss or corruption in team systems
  • For this risks is recommended to manage them using a regular risk process to monitor and handle those.

Questions?

Made with Slides.com