Contenu connexe
Similaire à Lean entrepreneurship Agile Product Developmnet
Similaire à Lean entrepreneurship Agile Product Developmnet (20)
Plus de Sean Ammirati (20)
Lean entrepreneurship Agile Product Developmnet
- 1. Agile Product
Development
Sean Ammirati
November 26, 2012
#CMULean © Sean Ammirati, 2012
- 2. Customer Development
+
Today’s Focus
Agile Product Development
=
The Lean Startup
#CMULean © Sean Ammirati, 2012
- 5. Release Early
& Often
(example beyond software)
#CMULean © Sean Ammirati, 2012
- 6. Goals for
Innovation Happens
• Provide networking event connecting
entrepreneurs & large corporations
• Encourage entrepreneurs to focus more on
getting customers
• Create a culture of “buying local” in
Pittsburgh
#CMULean © Sean Ammirati, 2012
- 8. 7 Events
22 Months
Iterated After Each Event
#CMULean © Sean Ammirati, 2012
- 11. Why Agile
Development?
• You’re wrong more then you are right
• Key Metric: How fast can you iterate?
• Need to Predict Delivery Times
#CMULean © Sean Ammirati, 2012
- 12. Scrum This will be unique for each of you
based on your team, type of solution
being developed and personal
preferences.
Engineering Could be: XP, Feature Driven
Practices Development, Crystal, Kanban or any
other process your engineering team
is comfortable with.
(often pull aspects from each)
#CMULean © Sean Ammirati, 2012
- 13. Why we focus on
Scrum?
• Firsthand observed it transform & improve
my last software company - mSpoke
• Being used at some of the largest
technology companies in the world today
(Google,Yahoo!, Adobe, etc ...)
• Provides a great framework for entire team
to understand what is going on.
• Disclaimer: Still hard to build technology and
#CMULean
not a silver bullet © Sean Ammirati, 2012
- 15. Scrum Process
Source:
http://www.krishnabitla.com/post/2011/02/02/scrum-‐process-‐sprint-‐agile-‐software-‐methodology.aspx
#CMULean © Sean Ammirati, 2012
- 16. Product Backlog
• Prioritized list or queue of requirements
• Rough Estimates of level of effort to complete
(not all estimates need to be equally thorough /
higher priority can be more thorough)
• Ultimately Product Owner sets the priority
• Any one (customer, employee, board member,
advisor) can add to product backlog
• Should be shared with the full-team
#CMULean © Sean Ammirati, 2012
- 19. Tools / Tips for Product
Backlog
• Everyone on team should easily be able to
see the backlog
• I’ve found one “administrator” helpful
logistically
• If not using a full scrum tool, you can do
this easily in a shared spreadsheet
(eg Google Docs)
#CMULean © Sean Ammirati, 2012
- 20. Time Box / Sprint
• Each sprint:
• Lasts a defined number of days
(time box)
• Has a specific set of requirements from
backlog allocated to it (defined during
“sprint planning meeting”)
• Has specific goals for the team to achieve
(set up front) - “sprint goal”
#CMULean © Sean Ammirati, 2012
- 21. Release Sprints
• In my experience, release sprints have been
quite helpful.
• However, continuous deployment is
becoming popular in some circles
(Eric Ries http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html)
• If you do continuous deployment, Scrum
still integrates fine to manage process
(http://knowscrum.com/benefits-of-continuous-integration-in-scrum-best-
practices-in-scrum/)
#CMULean © Sean Ammirati, 2012
- 22. Tasks for a Sprint
Backlog
• Based on the sprint goal - a list of tasks are
created
• Task estimates should be roughly 4 - 16
hours of work
• Sometimes only a partial sprint backlog can
be created (ie: if one task is define an
internal architecture) - in this case leave
reminders and estimate as soon as possible
#CMULean © Sean Ammirati, 2012
- 23. Estimates
• All estimates are forward looking
• How much will it take to complete this
feature / requirement?
• Increasing an estimate based on learned
complexity is accepted by the team
• Sprint backlog estimates should be updated
regularly
#CMULean © Sean Ammirati, 2012
- 24. Velocity / Burn Down
• The average decrease in estimates for the
total effort / time remaining is a sprint’s
velocity
• Overtime velocity becomes very helpful for
planning purposes
• The chart showing daily total of time
remaining is called a burn down chart or
sprint’s signature
#CMULean © Sean Ammirati, 2012
- 28. Daily Scrum
• Each Day Team Meets to have each team member
report:
• What have you done since the last daily scrum?
• What will you work on between now and the
next daily scrum?
• What got in your way of doing work?
• Many very startups find “daily” to be overkill
because of the small nature of the team- but regular
communication still key
#CMULean © Sean Ammirati, 2012
- 29. Sprint Review
• At the end of the sprint, the team
demonstrates what they have built
• Compares against the sprint’s goals
• Retrospective to look for improvements at
the end of the sprint
#CMULean © Sean Ammirati, 2012
- 30. Exercise 2
This deliverable should explain (in whatever layout
you find most clear & concise) two things
• A specification for your Minimally Awesome
Product (or MVP) based on Exercise 1
• A product backlog of the work required to
build your M.A.P.
#CMULean © Sean Ammirati, 2012
