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

      • 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
      • Types
        • All products macro-backlog
      • Prioritized by business value
    • 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
            • 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
        • 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
        • 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