SlideShare a Scribd company logo

Agile Project Management.ppt

•Download as PPT, PDF•
•
S
SuryaAdury1

This document provides an overview of agile software development methodologies. It describes key agile principles like small incremental changes, collaboration, and adapting to change. It outlines common agile roles like product owner, scrum master, and team member. It also explains common agile practices like backlogs, iterations, standups, demos and retrospectives. The goal of agile is to deliver higher quality software through collaboration, adaptive planning, and frequent feedback.

Related slideshows

Agile Lessons Learned From the Trenches
Agile Lessons Learned From the TrenchesAgile Lessons Learned From the Trenches
Agile Lessons Learned From the Trenches
 
Kevin Graves SCQAA-SF Scrum Presentation
Kevin Graves SCQAA-SF Scrum PresentationKevin Graves SCQAA-SF Scrum Presentation
Kevin Graves SCQAA-SF Scrum Presentation
 
Close to agile
Close to agileClose to agile
Close to agile
 
1 of 43
Agile Project Management.ppt
What Is Agile?  Agile is a group of software development methodologies  Scrum  Extreme Programming (XP)  Lean  Etc.  Key Characteristics:  Small increments  Adaptive to change  Collaborative
Principles  Attack the most important thing  Keep it simple  Stay releasable  Work as a team  Get feedback and respond to it  Defer decisions until the last responsible moment
Why Do It?  It results in better software  Higher productivity (you get what you need quicker)  Higher quality  More customer satisfaction  More visibility  Better morale
Roles  Product Owner  Scrum Master  Team Member
Product Owner  Prioritizes the backlog  Communicates what is important … and what is not  Is a proxy for the customer
Scrum Master  Responsible for the process  Facilitates agile meetings  Helps to remove road blocks
Team Member  Signs up for work  Asks questions  Collaborates with others  Communicates progress / blocking issues  Makes it happen
What Does It Look Like?  Backlog  Release  Release Planning  Iterations (1-4 weeks long)  Iteration Planning  Daily standup  Demo  Iteration Retrospective  Release Retrospective
The Backlog  A ranked list of stories  What is a story?  A scenario that we must do work to implement which results in business value  Typically in the form of: “As a <type of user>, I want <feature> so that <business value>”  Good stories meet the INVEST criteria
Example Post a Job  As a recruiter I want to be able to post a job to the web site so that I can generate interest in the position.
Prioritization Doesn’t Stop  The product owner re-prioritizes after each iteration  We’ve learned more about the business  Let’s take advantage of that  The further down the list something is, the less defined it will be and the less important it is to prioritize precisely
What Does an Iteration Look Like? 1 week to 1 month 24 hours Product Backlog As prioritized by Product Owner Iteration Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Stand up Meeting • Done since last meeting • Will do for next meeting • Obstacles Iteration Iteration Planning Meeting • Review Product Backlog • Define Iteration Goals • Estimate Iteration Backlog • Commit Demo Show off what you’ve done Retrospective Inspect and Adapt Vision and Release Plan
Iteration Planning  Define scope as a team  Define a clear understanding of “done”  Plan just enough that you can commit
Before you Start  Well Groomed Product Backlog  Prioritized  Estimated  Iteration Theme/Goal Estimated Prioritized
A Typical Iteration Planning Session  Review Iteration Goals  Discuss Logistics  Understand the Stories  Task out the stories  Commit Typical Duration: 3-8 hours Attendees: •Product owner •Scrum master •Delivery team Materials: •Stories (cards or online) •Task planning material (cards, whiteboard, online) •Planning/estimation materials (e.g. planning poker cards)
Review Iteration Goals  Product Owner  Explain the Goal (theme)  Make priority adjustments based on feedback from delivery team  Delivery Team  ASK QUESTIONS  Understand the Goal, not just the desired features
Discuss Logistics  Review Historical Velocity  Review Team Availability  Holidays / Vacations  Meetings  L3 Support, outside commitment, etc  Review the Definition of Done
Understand the Stories  Product Owner  Explain the Story  Explain the “Why” (“as a <role> I <what> so that <WHY>”)  Break down stories as needed  Elaborate on acceptance criteria/tests  Make priority adjustments based on feedback from delivery team  Delivery Team  Understand the story  Understand and question the acceptance criteria (how will you build a test for each? What about…)  Validate the size/implementability
Task out the Stories  Define tasks  Team members sign up for tasks  Estimate the task work  Validate capacity again
Commit  Everyone agrees the iteration is doable  No really…EVERYONE agrees  Use disagreement and uneasiness in team members to drive out hidden risks, tasks, and issues  Drive agreement with a fist of five  Absolutely, no question  I think this is good and will make it happen  I can support this  I’m uneasy about this and think we need to talk it out some more  Let’s continue discussing this idea in the parking lot
Managing your Tasks
Daily Standup  What did I do yesterday?  What will I do today?  What’s blocking me? Quick High Value
Demo  Show off what you got “done” in the iteration  Should be from the user’s perspective  No slides  No code  Just working software If a customer could attend your demo, you’re doing it right
Retrospective  Review the process over the last iteration  What went well?  What went poorly?  How can we do things better?  Take the top 1-3 items and make sure you make progress on them in the next iteration Improve
Estimating  Identify a medium sized story that is well understood; call it a 5  Now estimate other stories relative to that  Is it about the same, ½ as difficult, twice as difficult?  Use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21  If bigger than that or if too hard to estimate, split the story  Tackle as a team; Planning poker can help (www.planningpoker.com)
Velocity  Now that stories have sizes, you can track how many points you typically get done in an iteration  You can now use this to predict future completion rates
Structuring Teams  It is preferable to have each team have the ability to complete its work by itself  In other words, instead of a team per component, have teams with members who have knowledge of each component that will need to change to deliver something
Release Planning  Kick off / Overview  Break Out Sessions  Review Results
Release Planning Deliverables  Plan for each Iteration  Assumptions  Dependencies  Risks
Release Planning Wrap Up  Go through each iteration for each team  Are things synched up across teams?  Are you attacking the most important stories?  Does the team believe in the results?
After The Meeting  Capture the results in your tool of choice  Update after each iteration
Anti-Goals of Release Planning Release Planning is not a commitment!
Committing  Move towards themes  Commit to no more than 50%  No longer in or out but relative priority
Tracking the Release
Managing Risk Waterfall Agile  Time, scope and resources “fixed”  Changing one affects the others as well as quality  Manage the plan  Try to minimize change  Time, resources and quality fixed  Changing time or resources affects scope  Manage the priorities  Change as you learn more
Life in an Iteration  Once in an iteration, scope is fixed  Do the work in small increments  Work closely with others  It isn’t done until it is really done  If it doesn’t add value, don’t do it (or minimize)  Leave decisions to the last responsible moment It is a team effort
Feedback is key  Do a little  Get feedback  Respond to feedback by doing a little more  Automation helps decrease time to get feedback  Nightly/continuous build  Unit tests  Acceptance tests
Agile Documentation  Keep to the minimal responsible amount of doc  No more than you need at any point in time  Everything should add value  If not, try to reduce or eliminate it  Streamline so that the iteration is not interrupted  Wiki’s work well for collaborative design
Management Is Not Enough!  Engineering practices must change  Avoid specialization  Keep design simple and refactor as needed (YAGNI)  Create good automated regression tests  Integrate frequently  Peer review  Consider  Test Driven Development (or Behavior Driven Development)  Pair Programming  Co-location
Staying Releasable  Goal: Could release after any iteration  Reality: Ability to do this will evolve over time  Staying releasable gives you the ability to more easily change direction / take on new things  It also tends to improve quality  And predictability
Definition of Done  You need to define for your environment  Definition will evolve over time  Example:  Unit tests written and passed  Acceptance tests automated and passed  User facing documentation written  Checked in to the build
Questions? Walter Bodwell Planigle wbodwell@planigle.com Twitter: @wbodwell www.planigle.com www.walterbodwell.com

More Related Content

Agile Project Management.ppt

  • 2. What Is Agile?  Agile is a group of software development methodologies  Scrum  Extreme Programming (XP)  Lean  Etc.  Key Characteristics:  Small increments  Adaptive to change  Collaborative
  • 3. Principles  Attack the most important thing  Keep it simple  Stay releasable  Work as a team  Get feedback and respond to it  Defer decisions until the last responsible moment
  • 4. Why Do It?  It results in better software  Higher productivity (you get what you need quicker)  Higher quality  More customer satisfaction  More visibility  Better morale
  • 5. Roles  Product Owner  Scrum Master  Team Member
  • 6. Product Owner  Prioritizes the backlog  Communicates what is important … and what is not  Is a proxy for the customer
  • 7. Scrum Master  Responsible for the process  Facilitates agile meetings  Helps to remove road blocks
  • 8. Team Member  Signs up for work  Asks questions  Collaborates with others  Communicates progress / blocking issues  Makes it happen
  • 9. What Does It Look Like?  Backlog  Release  Release Planning  Iterations (1-4 weeks long)  Iteration Planning  Daily standup  Demo  Iteration Retrospective  Release Retrospective
  • 10. The Backlog  A ranked list of stories  What is a story?  A scenario that we must do work to implement which results in business value  Typically in the form of: “As a <type of user>, I want <feature> so that <business value>”  Good stories meet the INVEST criteria
  • 11. Example Post a Job  As a recruiter I want to be able to post a job to the web site so that I can generate interest in the position.
  • 12. Prioritization Doesn’t Stop  The product owner re-prioritizes after each iteration  We’ve learned more about the business  Let’s take advantage of that  The further down the list something is, the less defined it will be and the less important it is to prioritize precisely
  • 13. What Does an Iteration Look Like? 1 week to 1 month 24 hours Product Backlog As prioritized by Product Owner Iteration Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Stand up Meeting • Done since last meeting • Will do for next meeting • Obstacles Iteration Iteration Planning Meeting • Review Product Backlog • Define Iteration Goals • Estimate Iteration Backlog • Commit Demo Show off what you’ve done Retrospective Inspect and Adapt Vision and Release Plan
  • 14. Iteration Planning  Define scope as a team  Define a clear understanding of “done”  Plan just enough that you can commit
  • 15. Before you Start  Well Groomed Product Backlog  Prioritized  Estimated  Iteration Theme/Goal Estimated Prioritized
  • 16. A Typical Iteration Planning Session  Review Iteration Goals  Discuss Logistics  Understand the Stories  Task out the stories  Commit Typical Duration: 3-8 hours Attendees: •Product owner •Scrum master •Delivery team Materials: •Stories (cards or online) •Task planning material (cards, whiteboard, online) •Planning/estimation materials (e.g. planning poker cards)
  • 17. Review Iteration Goals  Product Owner  Explain the Goal (theme)  Make priority adjustments based on feedback from delivery team  Delivery Team  ASK QUESTIONS  Understand the Goal, not just the desired features
  • 18. Discuss Logistics  Review Historical Velocity  Review Team Availability  Holidays / Vacations  Meetings  L3 Support, outside commitment, etc  Review the Definition of Done
  • 19. Understand the Stories  Product Owner  Explain the Story  Explain the “Why” (“as a <role> I <what> so that <WHY>”)  Break down stories as needed  Elaborate on acceptance criteria/tests  Make priority adjustments based on feedback from delivery team  Delivery Team  Understand the story  Understand and question the acceptance criteria (how will you build a test for each? What about…)  Validate the size/implementability
  • 20. Task out the Stories  Define tasks  Team members sign up for tasks  Estimate the task work  Validate capacity again
  • 21. Commit  Everyone agrees the iteration is doable  No really…EVERYONE agrees  Use disagreement and uneasiness in team members to drive out hidden risks, tasks, and issues  Drive agreement with a fist of five  Absolutely, no question  I think this is good and will make it happen  I can support this  I’m uneasy about this and think we need to talk it out some more  Let’s continue discussing this idea in the parking lot
  • 23. Daily Standup  What did I do yesterday?  What will I do today?  What’s blocking me? Quick High Value
  • 24. Demo  Show off what you got “done” in the iteration  Should be from the user’s perspective  No slides  No code  Just working software If a customer could attend your demo, you’re doing it right
  • 25. Retrospective  Review the process over the last iteration  What went well?  What went poorly?  How can we do things better?  Take the top 1-3 items and make sure you make progress on them in the next iteration Improve
  • 26. Estimating  Identify a medium sized story that is well understood; call it a 5  Now estimate other stories relative to that  Is it about the same, ½ as difficult, twice as difficult?  Use Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21  If bigger than that or if too hard to estimate, split the story  Tackle as a team; Planning poker can help (www.planningpoker.com)
  • 27. Velocity  Now that stories have sizes, you can track how many points you typically get done in an iteration  You can now use this to predict future completion rates
  • 28. Structuring Teams  It is preferable to have each team have the ability to complete its work by itself  In other words, instead of a team per component, have teams with members who have knowledge of each component that will need to change to deliver something
  • 29. Release Planning  Kick off / Overview  Break Out Sessions  Review Results
  • 30. Release Planning Deliverables  Plan for each Iteration  Assumptions  Dependencies  Risks
  • 31. Release Planning Wrap Up  Go through each iteration for each team  Are things synched up across teams?  Are you attacking the most important stories?  Does the team believe in the results?
  • 32. After The Meeting  Capture the results in your tool of choice  Update after each iteration
  • 33. Anti-Goals of Release Planning Release Planning is not a commitment!
  • 34. Committing  Move towards themes  Commit to no more than 50%  No longer in or out but relative priority
  • 36. Managing Risk Waterfall Agile  Time, scope and resources “fixed”  Changing one affects the others as well as quality  Manage the plan  Try to minimize change  Time, resources and quality fixed  Changing time or resources affects scope  Manage the priorities  Change as you learn more
  • 37. Life in an Iteration  Once in an iteration, scope is fixed  Do the work in small increments  Work closely with others  It isn’t done until it is really done  If it doesn’t add value, don’t do it (or minimize)  Leave decisions to the last responsible moment It is a team effort
  • 38. Feedback is key  Do a little  Get feedback  Respond to feedback by doing a little more  Automation helps decrease time to get feedback  Nightly/continuous build  Unit tests  Acceptance tests
  • 39. Agile Documentation  Keep to the minimal responsible amount of doc  No more than you need at any point in time  Everything should add value  If not, try to reduce or eliminate it  Streamline so that the iteration is not interrupted  Wiki’s work well for collaborative design
  • 40. Management Is Not Enough!  Engineering practices must change  Avoid specialization  Keep design simple and refactor as needed (YAGNI)  Create good automated regression tests  Integrate frequently  Peer review  Consider  Test Driven Development (or Behavior Driven Development)  Pair Programming  Co-location
  • 41. Staying Releasable  Goal: Could release after any iteration  Reality: Ability to do this will evolve over time  Staying releasable gives you the ability to more easily change direction / take on new things  It also tends to improve quality  And predictability
  • 42. Definition of Done  You need to define for your environment  Definition will evolve over time  Example:  Unit tests written and passed  Acceptance tests automated and passed  User facing documentation written  Checked in to the build