SlideShare a Scribd company logo

Ssw forte-agile-seminar

•
•
S
SSW

This document provides an overview and summary of Steve Forte's half-day Agile seminar presented by SSW. The seminar covers topics including an introduction to Agile and Scrum, Agile estimation, Agile and offshore teams, and Agile tools. Attendees can ask questions throughout the interactive seminar.

1 of 63
Steve Forte Half-day Agile SeminarPresented by SSW
Agile Tools and TeamsStephen Fortewww.stephenforte.netStevef.hk@gmail.com
Session.About.ToString();Would like to implement Agile at your organization or have done so and would like to get more out of itAssume you know something about Agile, but a complete novice is ok“Agile Presenting” The goal is to be interactiveSuccess of the seminar depends on your questions!Ask a question at any time!
Speaker.Bio.ToString();Chief Strategy Officer of TelerikCertified Scrum MasterActive in the Community:International Conference Speaker for 13+ YearsRD, MVP and INETA Speaker Co-moderator & founder of NYC .NET Developers Group http://www.nycdotnetdev.comWrote a few books: SQL Server 2008 Developers Guide (MS Press)MBA from the City University of New YorkPast:CTO and co-Founder of Corzen, Inc. (TXV: WAN)CTO of Zagat Survey
Agenda Introduction To Agile and Scrum Agile EstimationAgile and OffshoreAgile Tools Summary
What is AgileA methodology that stresses communication and deliverablesA set of practices:XPScrumDDDTDDContinuous Integration
Agile ManifestoCustomer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances
We’re losing the relay race“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirementsHirotaka Takeuchi and IkujiroNonaka, “The New Product Development Game”, Harvard Business Review,January 1986.
What is Scrum?Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. Stresses communicationIt allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
CharacteristicsSelf-organizing teamsProduct progresses in a series of month-long “sprints”Requirements are captured as items in a list of “product backlog”No specific engineering practices prescribedUses generative rules to create an agile environment for delivering projectsOne of the “agile processes”No religion here please
Scrum
Product ownerDefine the features of the productDecide on release date and contentBe responsible for the profitability of the product (ROI)Prioritize features according to market value Adjust features and priority every iteration, as needed  Accept or reject work results
The ScrumMasterRepresents management to the projectResponsible for enacting Scrum values and practicesRemoves impediments Ensure that the team is fully functional and productiveEnable close cooperation across all roles and functionsShield the team from external interferences
The teamTypically 4-9 peopleCross-functional:Programmers, testers, user experience designers, etc.Members should be full-timeMay be exceptions (e.g., database administrator)Teams are self-organizingIdeally, no titles but rarely a possibilityMembership should change only between sprints
SprintsScrum projects make progress in a series of “sprints”Analogous to Extreme Programming iterationsTypical duration is 2–4 weeks or a calendar month at mostA constant duration leads to a better rhythmProduct is designed, coded, and tested during the sprint
Sprint planningTeam selects items from the product backlog they can commit to completingSprint backlog is createdTasks are identified and each is estimated (1-16 hours)Collaboratively, not done alone by the ScrumMasterHigh-level design is considered
A sample product backlog
Product backlogThe requirementsA list of all desired work on the projectIdeally expressed such that each item has value to the users or customers of the product Prioritized by the product ownerReprioritized at the start of each sprintThis is the product backlog
Managing the sprint backlogIndividuals sign up for work of their own choosingWork is never assigned (never is a harsh wordEstimated work remaining is updated dailyAny team member can add, delete or change the sprint backlogWork for the sprint emergesIf work is unclear, define a sprint backlog item with a larger amount of time and break it down laterUpdate work remaining as more becomes known
A sprint backlog84816124108161181612888884Add error logging8TasksMonTuesWedThurFriCode the UICode the middle tierTest the middle tierWrite online helpWrite the foo class
No changes during a sprintChangePlan sprint durations around how long you can commit to keeping change out of the sprint
The Daily ScrumParametersDaily10-15 minutesStand-upNot for problem solvingHelps avoid other unnecessary meetingsGreat way to manage remote teamsPrevents teams from wasting time
123What did you do yesterday?What will you do today?Is anything in your way?Everyone answers 3 QsThese are not status for the ScrumMasterThey are commitments in front of peers
The sprint reviewTeam presents what it accomplished during the sprintTypically takes the form of a demo of new features or underlying architectureInformal2-hour prep time ruleNo slidesWhole team participatesInvite everyone
Sprint retrospectivePeriodically take a look at what is and is not workingTypically 15–30 minutesDone after every sprintWhole team participatesScrumMasterProduct ownerTeamPossibly customers and others
ScalabilityTypical individual team is 7 ± 2 peopleScalability comes from teams of teamsFactors in scalingType of applicationTeam sizeTeam dispersionProject durationScrum has been used on multiple 500+ person projectsScrum of Scrums
Agile Estimation
Estimation Wikipedia: Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.Problem is that estimates become a unbreakable schedule, where any deviation is considered bad
Problem #1 with EstimatesEstimate for our project:1 month for design and architecture4 months for development 1 month for testingScenario:Your first estimate is wrong by 1 week (design)What do you do?
The Estimation ProblemWhen you come up with a project idea, your first estimate is off by +/ 4xNot enough details are knownTraditionally too much time is spent on building a specification which is not complete Again, not enough details are knownAs time progresses, more details emerge about the system and its detailsThe cone of uncertainty
The Cone of Uncertainty
Agile EstimationWikipedia: Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.Problem is that estimates become a unbreakable schedule, where any deviation is considered badAgile Estimation throws this logic away and always re-estimates a project after each iterationDifferent value system, deviations are not deviations, they are more accurate estimationsUses the cone of uncertainty to your advantage
How to EstimateUser StoriesPlanning PokerStory PointsProduct BacklogVelocityRe-estimation
User StoriesUsers break down the functionality into “User Stories”User Stories are kept smallUser Stories include acceptance criteria
Planning PokerAfter all the user stories are written, get a list of stories and do a high level estimateEstimate is for setting priorities, not scheduleNOT a time based estimation Super hard, Hard, Medium, Easy, Super easyDone by consensus To get there you play planning pokerWhy? No pressure.
Story PointsBreak down user stories to units of relative size So you can compare featuresAlternative to timeStory Points are not a measurement of duration, but rather a measurement of size/complexityStart with 1 standard feature and then other features are either 1x, 2x, etc larger or smaller than that relative feature in size/complexity
Product BacklogAll story points are put into a bucketThis represents all of the tasks for the project (work items)Backlog will have an item and its estimateRemember this estimate is not time based, but point basedBacklog can also contain the priority
Sprint 1Developers will commit to XX story pointsWarning, they will usually over commitAfter the end of sprint 1, you have your first velocity number
Team Velocity Velocity is the number of story points per sprint completedYou calculate velocity to predict how much work to commit to in a sprintVelocity only works if you estimate your story points consistency Over time you will know: team has a velocity of 32 story points per sprintOver time this will self-correctOver time you will be able to predict the project schedule (and release)
Calculating Team VelocitySelect a regular time period (sprint) over which to measure VelocityAdd up the story point estimates 100% completedAt the end of the sprint, the figure you have is your VelocityYou can then use your Velocity as a basis for your future commitments
Velocity ChartsTrue way to see the health of a project
Re-estimationAs you complete more sprints, your velocity will changeVelocity changes because of minor inconsistencies in the story point estimatesTeam velocity will typically stabilize between 3 and 6 iterationsRe-estimation of the entire project happens after each sprintNew VelocityNew story points added and removed (completed)Use the cone!
Agile and Offshoring
Agile and OffshoringMost methodologies (XP, Scrum) will work just fineJust have to change the rules a littleSometimes the customer demands an Agile methodology but do not understand what Agile is all aboutAgile can not be done unless you have full buy-in from the customer
Agile and Off-shoringDaily Scrum best way to keep offshore team on targetIncreases the communicationReduces the red tapeUse IM, Skype
Agile Tools and Teams
Why use tools?Tools help make a developer or team more efficient in a specific taskSome tools are like “crack cocaine” for developersTools are not a “silver bullet” or solution for a lack of process or bad processIf you have a poor process, the tools will make it worse
Why use tools?Tools are most effective when used to supplement an existing process or methodologyNever conform to a tool, find a tool that accelerates something that you already do
Types of ToolsTools for requirements and designTools for collaborationTools for construction
Upfront: Design and RequirementsUsing tools to aid in the discovery and design phaseMany different approachesUser StoriesWaterfall analysisIterative design
Popular Tools for Design/ReqBrainstormingMindJetMindManagerhttp://www.mindjet.com/Design/MockupsBalsamiqhttp://www.balsamiq.com/User StoriesWord, Excel, Pen and PaperWikisEstimationPlanning PokerExcel
CollaborationCollaboration falls into two categoriesProject ManagementContinuous Integration
Popular Tools for Project MgntTFS/Team ExplorerDon’t put your work items into TFS too soonScrum templates for TFSMany but Conchango is most popularhttp://scrumforteamsystem.com/en/default.aspxTelerik Work Item Managerhttp://www.telerik.com/products/tfsmanager-and-tfsdashboard.aspxAgile Project management toolsThoughtWorksMingle http://studios.thoughtworks.com/mingle-agile-project-management
Popular Tools for Project MgntAnd the most popular project management tool of all time:ExcelTons of Excel templateshttp://agilesoftwaredevelopment.com/2006/11/scrum-backlog-templates-and-examples
DEMO
Tools for Continuous Integration CI has changed the way we workYears ago we use to spend too much time on “enforcement”Proper CI builds on top of a good foundationTFSIBM Jazz http://jazz.net/
Tools for Continuous Integration CI automates the following:Source ControlUnit TestsDatabase TestsBuildStyle EnforcementStandards EnforcementBug/Build Reporting
Tools for Continuous Integration So many CI tools!Source Control: TFS, SubversionUnit Tests: MSTest, nUnitDatabase Tests: DataDude, dbUnit (http://www.dbunit.org/), RedGateBuild: MSBuild, ANT, etcStyle Enforcement: StyleCopStandards Enforcement: FXCop, etcBug/Build Reporting:TFS Project Dashboardhttp://www.telerik.com/products/tfsmanager-and-tfsdashboard.aspx
Tools for ConstructionPair ProgrammingCOLA: Real time shared editing (Eclipse only) http://www.vimeo.com/1195398Refactoring/ProductivityCodeRush (www.devexpress.com), Resharper (www.jetbrains.com), JustCode (www.telerik.com)
Tools for ConstructionTest Driven Development: TDDMSTest, nUnithttp://www.nunit.orgMockingRhinoMockshttp://www.ayende.com/projects/rhino-mocks.aspxJustMockDependency Injection/IoCUnity http://www.codeplex.com/unity
Recommended Reading Agile/Scrum:Agile Project Managementwith Scrum by Ken SchwaberAgile Software Development with Scrum by Ken Schwaber and Mike BeedleScrum and The Enterprise by Ken SchwaberEstimating:User Stories Applied by Mike CohnAgile Estimating and Planning by Mike CohnCI, TDD:CI TDD
Questions?
Thank You!Sydney | Melbourne | Brisbane | Adelaideinfo@ssw.com.auwww.ssw.com.au

More Related Content

Ssw forte-agile-seminar

  • 1. Steve Forte Half-day Agile SeminarPresented by SSW
  • 2. Agile Tools and TeamsStephen Fortewww.stephenforte.netStevef.hk@gmail.com
  • 3. Session.About.ToString();Would like to implement Agile at your organization or have done so and would like to get more out of itAssume you know something about Agile, but a complete novice is ok“Agile Presenting” The goal is to be interactiveSuccess of the seminar depends on your questions!Ask a question at any time!
  • 4. Speaker.Bio.ToString();Chief Strategy Officer of TelerikCertified Scrum MasterActive in the Community:International Conference Speaker for 13+ YearsRD, MVP and INETA Speaker Co-moderator & founder of NYC .NET Developers Group http://www.nycdotnetdev.comWrote a few books: SQL Server 2008 Developers Guide (MS Press)MBA from the City University of New YorkPast:CTO and co-Founder of Corzen, Inc. (TXV: WAN)CTO of Zagat Survey
  • 5. Agenda Introduction To Agile and Scrum Agile EstimationAgile and OffshoreAgile Tools Summary
  • 6. What is AgileA methodology that stresses communication and deliverablesA set of practices:XPScrumDDDTDDContinuous Integration
  • 7. Agile ManifestoCustomer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances
  • 8. We’re losing the relay race“The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirementsHirotaka Takeuchi and IkujiroNonaka, “The New Product Development Game”, Harvard Business Review,January 1986.
  • 9. What is Scrum?Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. Stresses communicationIt allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
  • 10. CharacteristicsSelf-organizing teamsProduct progresses in a series of month-long “sprints”Requirements are captured as items in a list of “product backlog”No specific engineering practices prescribedUses generative rules to create an agile environment for delivering projectsOne of the “agile processes”No religion here please
  • 11. Scrum
  • 12. Product ownerDefine the features of the productDecide on release date and contentBe responsible for the profitability of the product (ROI)Prioritize features according to market value Adjust features and priority every iteration, as needed  Accept or reject work results
  • 13. The ScrumMasterRepresents management to the projectResponsible for enacting Scrum values and practicesRemoves impediments Ensure that the team is fully functional and productiveEnable close cooperation across all roles and functionsShield the team from external interferences
  • 14. The teamTypically 4-9 peopleCross-functional:Programmers, testers, user experience designers, etc.Members should be full-timeMay be exceptions (e.g., database administrator)Teams are self-organizingIdeally, no titles but rarely a possibilityMembership should change only between sprints
  • 15. SprintsScrum projects make progress in a series of “sprints”Analogous to Extreme Programming iterationsTypical duration is 2–4 weeks or a calendar month at mostA constant duration leads to a better rhythmProduct is designed, coded, and tested during the sprint
  • 16. Sprint planningTeam selects items from the product backlog they can commit to completingSprint backlog is createdTasks are identified and each is estimated (1-16 hours)Collaboratively, not done alone by the ScrumMasterHigh-level design is considered
  • 18. Product backlogThe requirementsA list of all desired work on the projectIdeally expressed such that each item has value to the users or customers of the product Prioritized by the product ownerReprioritized at the start of each sprintThis is the product backlog
  • 19. Managing the sprint backlogIndividuals sign up for work of their own choosingWork is never assigned (never is a harsh wordEstimated work remaining is updated dailyAny team member can add, delete or change the sprint backlogWork for the sprint emergesIf work is unclear, define a sprint backlog item with a larger amount of time and break it down laterUpdate work remaining as more becomes known
  • 20. A sprint backlog84816124108161181612888884Add error logging8TasksMonTuesWedThurFriCode the UICode the middle tierTest the middle tierWrite online helpWrite the foo class
  • 21. No changes during a sprintChangePlan sprint durations around how long you can commit to keeping change out of the sprint
  • 22. The Daily ScrumParametersDaily10-15 minutesStand-upNot for problem solvingHelps avoid other unnecessary meetingsGreat way to manage remote teamsPrevents teams from wasting time
  • 23. 123What did you do yesterday?What will you do today?Is anything in your way?Everyone answers 3 QsThese are not status for the ScrumMasterThey are commitments in front of peers
  • 24. The sprint reviewTeam presents what it accomplished during the sprintTypically takes the form of a demo of new features or underlying architectureInformal2-hour prep time ruleNo slidesWhole team participatesInvite everyone
  • 25. Sprint retrospectivePeriodically take a look at what is and is not workingTypically 15–30 minutesDone after every sprintWhole team participatesScrumMasterProduct ownerTeamPossibly customers and others
  • 26. ScalabilityTypical individual team is 7 ± 2 peopleScalability comes from teams of teamsFactors in scalingType of applicationTeam sizeTeam dispersionProject durationScrum has been used on multiple 500+ person projectsScrum of Scrums
  • 28. Estimation Wikipedia: Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.Problem is that estimates become a unbreakable schedule, where any deviation is considered bad
  • 29. Problem #1 with EstimatesEstimate for our project:1 month for design and architecture4 months for development 1 month for testingScenario:Your first estimate is wrong by 1 week (design)What do you do?
  • 30. The Estimation ProblemWhen you come up with a project idea, your first estimate is off by +/ 4xNot enough details are knownTraditionally too much time is spent on building a specification which is not complete Again, not enough details are knownAs time progresses, more details emerge about the system and its detailsThe cone of uncertainty
  • 31. The Cone of Uncertainty
  • 32. Agile EstimationWikipedia: Estimation is the calculated approximation of a result which is usable even if input data may be incomplete or uncertain.Problem is that estimates become a unbreakable schedule, where any deviation is considered badAgile Estimation throws this logic away and always re-estimates a project after each iterationDifferent value system, deviations are not deviations, they are more accurate estimationsUses the cone of uncertainty to your advantage
  • 33. How to EstimateUser StoriesPlanning PokerStory PointsProduct BacklogVelocityRe-estimation
  • 34. User StoriesUsers break down the functionality into “User Stories”User Stories are kept smallUser Stories include acceptance criteria
  • 35. Planning PokerAfter all the user stories are written, get a list of stories and do a high level estimateEstimate is for setting priorities, not scheduleNOT a time based estimation Super hard, Hard, Medium, Easy, Super easyDone by consensus To get there you play planning pokerWhy? No pressure.
  • 36. Story PointsBreak down user stories to units of relative size So you can compare featuresAlternative to timeStory Points are not a measurement of duration, but rather a measurement of size/complexityStart with 1 standard feature and then other features are either 1x, 2x, etc larger or smaller than that relative feature in size/complexity
  • 37. Product BacklogAll story points are put into a bucketThis represents all of the tasks for the project (work items)Backlog will have an item and its estimateRemember this estimate is not time based, but point basedBacklog can also contain the priority
  • 38. Sprint 1Developers will commit to XX story pointsWarning, they will usually over commitAfter the end of sprint 1, you have your first velocity number
  • 39. Team Velocity Velocity is the number of story points per sprint completedYou calculate velocity to predict how much work to commit to in a sprintVelocity only works if you estimate your story points consistency Over time you will know: team has a velocity of 32 story points per sprintOver time this will self-correctOver time you will be able to predict the project schedule (and release)
  • 40. Calculating Team VelocitySelect a regular time period (sprint) over which to measure VelocityAdd up the story point estimates 100% completedAt the end of the sprint, the figure you have is your VelocityYou can then use your Velocity as a basis for your future commitments
  • 41. Velocity ChartsTrue way to see the health of a project
  • 42. Re-estimationAs you complete more sprints, your velocity will changeVelocity changes because of minor inconsistencies in the story point estimatesTeam velocity will typically stabilize between 3 and 6 iterationsRe-estimation of the entire project happens after each sprintNew VelocityNew story points added and removed (completed)Use the cone!
  • 44. Agile and OffshoringMost methodologies (XP, Scrum) will work just fineJust have to change the rules a littleSometimes the customer demands an Agile methodology but do not understand what Agile is all aboutAgile can not be done unless you have full buy-in from the customer
  • 45. Agile and Off-shoringDaily Scrum best way to keep offshore team on targetIncreases the communicationReduces the red tapeUse IM, Skype
  • 47. Why use tools?Tools help make a developer or team more efficient in a specific taskSome tools are like “crack cocaine” for developersTools are not a “silver bullet” or solution for a lack of process or bad processIf you have a poor process, the tools will make it worse
  • 48. Why use tools?Tools are most effective when used to supplement an existing process or methodologyNever conform to a tool, find a tool that accelerates something that you already do
  • 49. Types of ToolsTools for requirements and designTools for collaborationTools for construction
  • 50. Upfront: Design and RequirementsUsing tools to aid in the discovery and design phaseMany different approachesUser StoriesWaterfall analysisIterative design
  • 51. Popular Tools for Design/ReqBrainstormingMindJetMindManagerhttp://www.mindjet.com/Design/MockupsBalsamiqhttp://www.balsamiq.com/User StoriesWord, Excel, Pen and PaperWikisEstimationPlanning PokerExcel
  • 52. CollaborationCollaboration falls into two categoriesProject ManagementContinuous Integration
  • 53. Popular Tools for Project MgntTFS/Team ExplorerDon’t put your work items into TFS too soonScrum templates for TFSMany but Conchango is most popularhttp://scrumforteamsystem.com/en/default.aspxTelerik Work Item Managerhttp://www.telerik.com/products/tfsmanager-and-tfsdashboard.aspxAgile Project management toolsThoughtWorksMingle http://studios.thoughtworks.com/mingle-agile-project-management
  • 54. Popular Tools for Project MgntAnd the most popular project management tool of all time:ExcelTons of Excel templateshttp://agilesoftwaredevelopment.com/2006/11/scrum-backlog-templates-and-examples
  • 55. DEMO
  • 56. Tools for Continuous Integration CI has changed the way we workYears ago we use to spend too much time on “enforcement”Proper CI builds on top of a good foundationTFSIBM Jazz http://jazz.net/
  • 57. Tools for Continuous Integration CI automates the following:Source ControlUnit TestsDatabase TestsBuildStyle EnforcementStandards EnforcementBug/Build Reporting
  • 58. Tools for Continuous Integration So many CI tools!Source Control: TFS, SubversionUnit Tests: MSTest, nUnitDatabase Tests: DataDude, dbUnit (http://www.dbunit.org/), RedGateBuild: MSBuild, ANT, etcStyle Enforcement: StyleCopStandards Enforcement: FXCop, etcBug/Build Reporting:TFS Project Dashboardhttp://www.telerik.com/products/tfsmanager-and-tfsdashboard.aspx
  • 59. Tools for ConstructionPair ProgrammingCOLA: Real time shared editing (Eclipse only) http://www.vimeo.com/1195398Refactoring/ProductivityCodeRush (www.devexpress.com), Resharper (www.jetbrains.com), JustCode (www.telerik.com)
  • 60. Tools for ConstructionTest Driven Development: TDDMSTest, nUnithttp://www.nunit.orgMockingRhinoMockshttp://www.ayende.com/projects/rhino-mocks.aspxJustMockDependency Injection/IoCUnity http://www.codeplex.com/unity
  • 61. Recommended Reading Agile/Scrum:Agile Project Managementwith Scrum by Ken SchwaberAgile Software Development with Scrum by Ken Schwaber and Mike BeedleScrum and The Enterprise by Ken SchwaberEstimating:User Stories Applied by Mike CohnAgile Estimating and Planning by Mike CohnCI, TDD:CI TDD
  • 63. Thank You!Sydney | Melbourne | Brisbane | Adelaideinfo@ssw.com.auwww.ssw.com.au