Agile-curious? Learn agile mtgs in 1 hour. @DianaofPortland


  • iterative and incremental structure for developing software
  • not a method - a category of methods
  • producing increments of delivered software

Iterations / (Sprints if using scrum)

  • 1 week to 30 days in length
  • 2 week sprints most common

For development team, there are 4 meetings

  1. Planning
  • team meets with person representing the customer. Decides WHAT gets built.
  • at beginning of each iteration, that person is present
  • Decide on what the sprint goal is
  • whole team looks at the work that remains which that customer has assessed as the highest prioritization that is capturable
  • team assesses how much can get done in two weeks
  • team takes those pieces, decomposes into tasks
  • “self organizing” teams
  • team doesn't decide what should be built - they're in charge of HOW
  • Done/Done: it's been coded, it's been tested, and the customer has accepted it
  1. Daily Standup Meetings
  • Most teams this happens once a day. Some teams this happens more than once a day. Need to happen frequently.
  • Members discuss “what I've been working on”, “here's what I'm planning to do next”,

“here's what's in my way” (impediment/obstacle - get dealt with after the meeting since often don't involve all team members)

  • those are the 3 questions
  • also a potential 4th question - “on a scale of 1-10, what is my level of confidence that we're going to meet our iteration goal?” 10 total confidence
  • 15 minutes - no more. Could be shorter
  • Distributed teams with people working from home, team members even stand up
  • keeps transparency and visibility into what is happening
  • anybody can show up, but only the team gets to talk
  • power of public declaration of progress - keeps people focused
  • story points - effort linked, not time
  • some teams pick what they call “an ideal programmer day” and give that a 1. “Ideal Day”
  • some teams say “this is a typical thing that we need to develop”, and give that a 1
  • just important that the points remain reletive to each other
  1. Product Demo
  • at end of every iteration, demonstrate running, working software
  • Ron Jeffries - “the lash of Jeffries” - you have to produce running software, show that it works, demonstrate to the customer in order to get feedback
  • opportunity for customer to tell you early and often if it's meeting their needs, missing something
  • time for team to demonstrate “here is what we got to 'done'”
  • if you can't demo it, it doesn't count as done
  • may also have additional blackbox testing or testing by users
  • user testing, regression testing, uat testing was all done during the iteration
  • another opportunity for team to identify what got in their way from doing what they wanted to do
  • team lead responsibility to remove the impediments
  1. The Retrospective
  • at end of every iteration
  • 12th Principle is that at regular intervals, the team stops in order to give itself feedback on itself, how it's working together, what kinds of things are coming up over and over again
  • opportunity to see patterns on how the team is working together
  • Serves the purpose of: allows you to look at things over time
  • teams who've worked together for a long time may choose not to do The Retrospective every time, but should never go more than 1 month without one
  • half a day or less. Minimum 90 minutes - need that time in order to get value out of it. Opportunity for destructive things to be identified.
  • always have a focus, get everybody ready to do the work
  • quick check in, “how did this last iteration go for you?”
  • spend time gathering data. Get everybody's perspective. Everybody comes in thinking they knew what all was going on, but collective picture gives the whole view.
  • Timeline vs. radar graph
    • ways to pull out this information
  • get a shared set of data
    • seperate the team from the data. Whiteboards and flip charts come in handy. Have people write stuff on sticky notes.
    • becomes “you and me against the problem written down over there”
    • make a decision as a group about what's going to be done
  • get that and go on to….
  • …“so what does this tell us?”
  • …“so what are we going to do about this?” Action planning state
  • experiment we'd like to try?
  • change up pairing rotation?
  • things within the team's control or outside the team's control?
    • if outside, bumping up against organization's culture then need to determine a workaround
    • example of the Wildcard VP who would continually cause havok, disrupt the team's plan
    • team couldn't change the guy
    • team could control how they responded even if they couldn't control the nature
  • hopefully no more than 1 action item comes out from The Retrospective
  • needs to be something important enough that you can make a case to the customer that they're going to benefit from the action item
  • stopped using “which of these is most important” - too absract
  • now uses “which of these will have the biggest impact?”, which leads then to “which of these do we have the most energy for?”
  • Now know action plan. Close the retrospective. “How did the retrospective go?” = a restrospective on the retrospective. generally quick
kqw.txt · Last modified: 2009/09/01 09:30 by