Day 2 - Agile Process

by Mike Robinson

Introduction

  • Agile is a conceptual framework

  • Agile does have documentation

  • Agile methods have been around since the 1990s and were united by the agile manifesto.

  • Agile empowers the workers

  • Agile knows their finished when they are finished

  • Agile is:

    • Like driving a race car, you know the course but can’t account for all the variables

Agile Values

  • Individuals and interactions > process and tools
  • Working software > comprehensive documentation
  • Customer collaboration > contract negotiation
  • Responding to change > following a plan
  • Planning is more important than plans

Agile Principles

  • Highest priority is to satisfy the customer
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
  • Deliver working software frequently. 90% completion is a lie. Its either not started, working, or finished. If you do not deliver working software you are of no value.
  • Business people and developers must work together daily
  • Build projects over motivated people
  • Give developers the support they need and trust them to get the job done
  • Working software is the primary measure of growth.
  • Information is best done in face-to-face conversation
  • Agile processes promote sustainable development by not overworking people to meet deadlines.
  • The sponsors, developers, and users should be able to maintain constant speed.
  • Simplicity is really awesome. Code is a liability to any organization. The less code you can deliver the better.
  • The best architecture, requirement, and designs emerge from self-organizing teams.
  • At regular intervals the team reflects on how to become more effective, then adjusts its behavior accordingly.

Why use agile?

  • Agile lets you meet what the marketing folks want to give to customers
  • Agile means good for business so you can plan out hours better
  • Operations likes it because your updates are simpler
  • Development likes it because it empowers developers

Developers need to be respected

  • Don’t agree on schedules without developer input
  • Don’t agree on tasks without developer input
  • Developers need to be honest in describing what needs to be done
  • Get developers to demo their work to the customer!

Charging for the assessment phase

  • Bill for it
  • Tell customers that you’ll bill for planning as long as the customer is willing to pay

Roles on a team

  • Product owner: Drives the project
  • Project Manager: Handles the resources
  • Team: Developers
  • Stakeholders: Customers
  • Users: obvious

Artifacts

  • Impediment list (use stickies on the wall to be obvious)
  • Project iteration
  • Working code

Agile requirements analysis, estimating and planning

  • Identify the users

    • Gather requirements from the users via

      • Interviews
      • Questionnaires
      • Observation
      • workshops

    • Ways of documenting

      • Use cases fixed the ATM returning cards after cash

        • too big to plan for and measure with
        • prone to include UI details

      • User stories

        • a tiny bit of information.
        • You can attach these to use cases

    • Estimating development

      • Prediction is difficult!

      • You will never be 100% accurate

      • Short efforts on estimates are accurate

      • Long efforts on estimates are always off

      • Breakdown tasks into manageable chunks

      • Estimation performed by development team

      • Deriving an estimate

        • Expert opinion
        • Analogy
        • Planning poker

      • Story points are a relative measure of size of a story. 10 points is more than 5.

      • Ideal time it would take to complete a task without interruptions. A football game is 60 ideal minutes and 120 minutes with interruptions

    • Planning poker

      • Each member gets six cards
      • People put the value they think it will take down on the table. The most common value is how long it will take in story points.
      • If one person has things way off, then talk out why there is a discrepancy
      • After each task has point assigned, figure out how long a point is worth. Use previous effort to determine the length of a story point.

    • Prioritizing user stories

      • Priority assignment is the primary responsibility of the Product Owner

    • Velocity

      • Measure the rate of progress of a team

      • Amount of story points completed in the last iteration

      • Next iteration = same as last iteration (“yesterday weather”)

      • velocity corrects estimation error

      • Accommodate developer optimism

      • Burndown chart

        • Plots the amount of committed effort left against the time left to complete the iteration

Agile planning game