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
- 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
- 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.
Practices
- Backlog
- Types
- All products macro-backlog
- Product backlog
- Release backlog
- Sprint 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
- 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
- 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!)
- 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
- 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
0 comments:
Post a Comment