2009-03-25

Agile for mobile

Agile for mobile

These are my notes from a presentation I gave Saturday at MobiCamp Boston 2.

The pitch
  • ... or maybe it's in the product development, too
  • Software engineering is where you spend most of your effort, time, and money when you build your mobile app
  • Scrum can help control your software engineering effort/time/expense
  • I'll share some of my team's practices
Why Agile
  • Not because
    • It's trendy
    • It's cool
    • You think it allows you to be lazy
    • You don't like process
    • (because actually is a strict process, and it doesn't allow you to be ad hoc or lazy)
  • Because software engineering is the most expensive, most time consuming, least predictable part of product development
  • Need a way to mitigate the expense, control the cost, decrease risk, and get product into market faster
  • How: Eliminate Waste
    • Don't do things that don't have high business value
    • Don't make development team switch context frequently
    • Communicate
      • Frequently
      • High bandwidth
      • High signal:noise ratio
      • Know what to work on, what not to work on
Why Scrum in particular
  • Not XP
    • XP is great, but the practices don't scale well to the management level
    • XP is too micro-level, with individual practices like pair programming and unit testing
  • Scrum is a full framework for agile management and product development
  • Scrum framework is easier to communicate to management.
Scrum heritage
Practices
  • Backlog
  • Sprints
    • Goal: produce a unit of potentially releasable software
      • With no new technical debt
    • 2 weeks long
      • Long enough to get stuff done
      • Short enough so it feels urgent and so you can frequent feedback from customer
      • 10 work days: division by 10 is easy
    • Sprint planning meeting
      • Estimate stories
        • Estimate all unestimated stories in release backlog
        • Planning Poker
          • Avoids anchoring
          • Fun and accurate
          • Quick
      • Select, commit
        • Select highest business value items from backlog
        • Publicly, to each other
        • Based on team's known velocity
          • Review team's historic velocity to make sure commitment is reasonable.
        • Velocity per team, per day, per team member
          • Typically 4-6 hours per person per day
        • Team, not management, makes commitment
        • People tend to keep commitments that they make for themselves and that they make publicly.
      • Keep commitment stable for sprint duration
        • Don't switch context too frequently--it wastes development time (Eliminate Waste)
        • Scrum Master protects the team
    • Sprint review meeting
      • Demo
      • Retrospective
        • Team determines how to increase velocity (Eliminate Waste)
      • Gauge sprint velocity
        • Able to predict final done date after a few sprints
        • Release backlog / team velocity => # of sprints left
    • Deliver to customer on last day of each sprint
  • Burndown chart
      • Sprint burndown
      • Project burndown
      • How many hours did you commit do getting done? How many hours are left?
        • Offers clues to whether your sprint is on track.
        • Slope of graph compared to ideal linear slope
        • How close to 0 work left?
        • What sprint day is it?
        • Are you on track?
      • Able to make adjustments based on actual progress data
        • Add people
        • Remove committed items
        • Warn product owner, customer
      • Burndown hours/story points when story is Done
      • What is Done? What does Done mean?
      • Publicly track actual progress against commitments
    • Daily scrum
      • What did you get done yesterday? What do you plan to get done today? What are the impediments to getting things done?
      • Publicly track actual progress against commitments
      • Look for impediments that prevent team from meeting commitments
      • Scrum Master removes impediments
      • Communicate
    • Weekly scrum-of-scrums
      • With each customer
      • With senior management
Agile != lazy or ad hoc
  • Deliberate
  • Surprisingly detail oriented
  • Lots of communication through the Scrum rituals (burndown chart, daily scrum, sprint planning and review meetings)
  • You are not excused from excellent up front project planning
  • You are excused from anything that doesn't help the team get closer to being Done (Eliminate Waste!)
Challenges
  • Fixed fee project difficult to reconcile with Agile.
    • When will it be done?
    • How much will it cost?
  • Estimation
    • Can't estimate stories/requirements you don't know about
    • Can't properly estimate stories that change
  • Difficult to get people to prioritize backlog
Benefits
  • Eliminate waste
    • Don't work on stuff that has low biz value
    • Save, money
    • Increase velocity
      • Velocity is a vector. The direction is always "toward the most business value."
  • Backlog grooming forces people to state and agree on priorities
    • Painful but must be done
  • Able to accurately predict done date
    • After a few sprints
    • If you know team's velocity and size of backlog, you can predict done date
  • Able to tell customer not to add or change requirements
    • Easy to show customer how adding to backlog delays done date
  • Happier dev team, customer, management

No comments:

LinkWithin

Related Posts with Thumbnails