Agile Software Development


Published on

An introduction to Agile principles, Values, Scrum, Sprints, Agile design practices and XP

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Software Development

  1. 1. agile @ enterpriseAdnan MasoodSr. Software Architect / Doctoral
  2. 2. what is Agile?2
  3. 3. What is Agile?Agile is not a methodology.It is a collection of 4 values and12 principles that describe howprocess, practices, and peoplework together in Agile softwaredevelopment.3
  4. 4. These values and principlesare used as guidance for ateam or organization whendeciding how a situationthey are brought upagainst should behandled.4
  5. 5. Agile values• Individuals and interactions– over processes and tools• Working software– over comprehensive documentation• Customer collaboration– over contract negotiation• Responding to change– over following a plan5
  6. 6. Agile principles• Customer satisfaction by rapiddelivery of useful software• Welcome changing requirements,even late in development• Working software is deliveredfrequently (weeks rather thanmonths)6
  7. 7. Agile principles• Working software is the principalmeasure of progress• Sustainable development, able tomaintain a constant pace• Close, daily co-operationbetween business people anddevelopers7
  8. 8. Agile principles• Face-to-face conversation is thebest form of communication (co-location)• Projects are built aroundmotivated individuals, who shouldbe trusted• Continuous attention to technicalexcellence and good design8
  9. 9. Agile principles• Simplicity- The art of maximizingthe amount of work not done - isessential• Self-organizing teams• Regular adaptation to changingcircumstances9
  10. 10. Agile Practices workwithin an organizationto enable these valuesand principles10
  11. 11. Agile approaches shorten thefeedback cycle betweencustomers, developmentteam, and working software.11
  12. 12. Agile teams manage theirdevelopment efforts to getworking software in thehands of customers so theycan touch and feel it andprovide feedback.12
  13. 13. Short iterations with feedbackfrom the customers increasethe possibility that thesoftware will align withcustomer desires andexpectations.13
  14. 14. Agile projectmanagement14
  15. 15. Scrum is a projectmanagementframework inventedby Jeff Sutherland atEasel Corporation in1993.15
  16. 16. Scrum highlights the differencesbetweendefined (plan-driven)andempiricalprocess control models.16
  17. 17. Defined process controls assumethat the work can be fullyunderstood up-front.– But, software projects are morecomplicated.– They contain surprises throughout allaspects of the developmentprocess.17
  18. 18. Empirical process controls usean “inspect and adapt” progressmonitoring to managecomplexity in softwaredevelopment.18
  19. 19. In Scrum, there are three roles:• Project Team• Product Owner• Scrum Master19
  20. 20. ScrumScrum starts when a ProductOwner comes up with aproduct vision.The Product Owner thengenerates the Product Backlogthat describes this product visionin more detail.20
  21. 21. ScrumThe list of items containedin the Product Backlog isprioritized in stack-rankorder and estimated bythe Project Team.21
  22. 22. Sprint Planning MeetingWhen the Product Backlogcontains enough work for theProject Team to implement in asingle time-boxed iteration,called a Sprint, then theyconduct a Sprint PlanningMeeting to decide what to workon.22
  23. 23. Sprint Planning MeetingThe Product Owner describeshighest priority Product Backlogitems to the Project Team.The Project Team members askquestions about the ProductBacklog items to gain clarity ofthe feature requirements.23
  24. 24. Sprint Planning MeetingThe Project Team focuses oncoming up with a plan on howthey will deliver those ProductBacklog items in their own SprintBacklog.24
  25. 25. Sprint Planning MeetingThe Project Team• Breaks down the Product Backlog itemsinto smaller Tasks– Architecture– Coding– Integration– Testing– Documentation– Etc.• Commits to a Sprint Backlog aftertasking out a set of ProductBacklog items to work on.25
  26. 26. The SprintAfter the Project Team commitsto a Sprint Backlog, they startwork.It is common to conduct Sprintsin three, two, and even one-week increments.26
  27. 27. The SprintDuring the Sprint, the Project Team getstogether each day for a time-boxedmeeting called the Daily Scrum.–They discuss• what they have done since lastmeeting,• what they plan to do, and• any impediments blocking their work.27
  28. 28. The SprintThe focus of the Daily Scrum is notgiving status but rather for theProject Team to figure out if theyare still on track to deliver on theircommitments for this Sprint.If they are not on track then action canbe taken immediately.28
  29. 29. Product Owner DemoAt the end of the Sprint, the ProjectTeam demos the software created.The demonstration is to theProduct Owner and any otherinterested stakeholders that attendthe Sprint Review Meeting.29
  30. 30. Product Owner DemoThe team is expected to havecreated a Potentially ShippableProduct Increment that• Contains all of the quality that ashippable product would include• Gives the Product Owner theopportunity to decide to deploythe software to the users.30
  31. 31. Sprint RetrospectiveAfter the Potentially ShippableProduct Increment is reviewed,the Project Team conducts aSprint Retrospective where theylook at the process used thisSprint looking for ways toimprove.31
  32. 32. Sprint RetrospectiveThe Sprint Retrospective resultsin a list of improvements theProject Team will take on thenext Sprint, which starts the nextday with a Sprint PlanningMeeting.32
  33. 33. Scrum33
  34. 34. ScrumApplying this simpleframework has shownto be incredibly difficultfor many organizations.34
  35. 35. ScrumSome organizations try to applyScrum “by the book”–but don’t comprehend thefocus on “inspect and adapt”.35
  36. 36. ScrumOthers incorporate a subset of theScrum framework and call it “Scrum”.This is referred to as “Scrum but”, as in:– “we do Scrum but we don’t meet fora Sprint Retrospective”.– “we do Scrum but we do coding inone Sprint and then do testing in thenext Sprint”.36
  37. 37. ScrumEffective use of Scrum enables projectteams to deliver increments ofsoftware that are potentiallyshippable in 30 days or less.The Product Owner then decides ifthere is sufficient value in what hasbeen delivered for deployment tothe software’s users.37
  38. 38. ScrumIt’s common for ProductOwners to find early releaseopportunities.These early releases minimizethe amount of investmentneeded to give additionalvalue to the users.38
  39. 39. Agile Teams39
  40. 40. Six characteristicsofproduct development teamsathighly innovativeandsuccessful companies:40
  41. 41. Characteristics of Highly Innovative TeamsBuilt-in instability:Management provides achallenging goal to a teamand gives them extremefreedom to implement aproduct that meets the goal.41
  42. 42. Characteristics of Highly Innovative TeamsSelf-organizing project teams:Teams are introduced to theproduct goal and mustorganize around this workacross functional disciplines.42
  43. 43. Characteristics of Highly Innovative TeamsOverlapping developmentphases:• Optimizes functional phases ofproduct development• Teams synchronize their delivery• Forces interactivity betweenfunctional roles to meet deliverygoals– As opposed to the relay race or hand-offapproach43
  44. 44. Characteristics of Highly Innovative Teams“Multi-learning”:Involves learning at multiple levels• Individual• Team• CorporateTeam members• interact closely with external entities andwithin their team• Acquire new knowledge and skill sets to assessand use this new knowledge quickly.44
  45. 45. Characteristics of Highly Innovative TeamsSubtle control:• Emphasis is on a team’sinternal self-control.• Management providescheckpoints to minimizeinstability, ambiguity, andtension in pursuit of achallenging goal.45
  46. 46. Characteristics of Highly Innovative TeamsOrganizational transfer oflearningTeams work to transfer theirlearning to others outside thegroup.46
  47. 47. “The best architectures,requirements, and designsemerge from self-organizing teams”–Principles behind the Agile Manifesto47
  48. 48. Self Organizing Project TeamsMultiple functional roles are representedon an Agile Scrum Project Team:• Analysis• Architecture• Design• Testing• Programming• User experience• Database• Other roles, depending on the project48
  49. 49. Self Organizing Project TeamsAgile teams look for ways toimplement features that areverified and validated eachiteration cycle.This entails high degrees ofcollaboration between people infunctional roles during the iteration.49
  50. 50. Self Organizing Project TeamsIf appropriate functional roles for theproject are not represented orlimited on the team, it will show in thesoftware delivery.– Team members will either have tocover the work conducted in thisfunctional area or let the work pile upto be done later.– When work is left for later it becomesmore complicated, overwhelming, anderror-prone.50
  51. 51. Self Organizing Project TeamsIn Scrum, the entire team,including Product Owner andScrum Master, are a self-contained unit.Well-defined interfaces into theteam enable the Scrum team toact as an autonomous unit.51
  52. 52. Self Organizing Project TeamsAutonomy• External involvement is limited toguidance, money, and moralsupport.• Top management rarelyintervenes in the team’s work.• The team is able to set their owndirection on day-to-day activities.52
  53. 53. Self Organizing Project TeamsSelf-transcendence• The team seems to be continuallystriving for perfection.• Teams set their own goals thatalign with top managementobjectives and devise ways tochange the status quo.53
  54. 54. Self Organizing Project TeamsCross-fertilization• Teams have members withdifferent functional specializations,thought processes, and behaviorpatterns.• These differences enhance theproduct development once teammembers start interactingeffectively.54
  55. 55. Self Organizing Project TeamsThe Scrum Project Team isexpected to makeincremental improvementsto transcend their existingsoftware delivery processthat result in better qualityand faster throughput offeature delivery.55
  56. 56. Agile design practices56
  57. 57. A common misconceptionabout Agile teams is that theydo not perform designactivities.This perception is a result ofassociating design withtraditional design documenttemplates and “Big Design UpFront”.57
  58. 58. Consider:The reason forspecifying businessrequirements andtechnical design beforeconstruction is toreduce risk.58
  59. 59. But…Customers don’t know all of therequirements up front.Requirements emerge duringimplementation.The people that create businessrequirements and design specificationsare not easily accessible onceconstruction of the software begins.59
  60. 60. The problems with Big DesignUp Front are a symptom offeedback cycles that are toolong in duration.The time needed to analyze, specify, anddesign software before constructing itallows requirements and designs to growstale before they are implemented.60
  61. 61. Development teams ofteninterpret business requirementsincorrectly.Business needs change frequently.Requirement details specifiedweeks or months prior are notnecessarily valuable today.61
  62. 62. Creation of designdocumentation has notassured the development ofwell-crafted software thatevolves in parallel withchanging business needs.62
  63. 63. Also, writing designdocumentation, and thepractice of evaluating thesoundness of these designs,slows the developmentprocess and delays essentialfeedback from stakeholdersand users.63
  64. 64. Instead of taking anup front designapproach, Agileteams design all thetime.64
  65. 65. “Continuous attention totechnical excellence andgood design enhancesagility.”- Manifesto for Agile Software Development65
  66. 66. Filling out designdocumentation, such asdetailed designs, hasbecome synonymous with“good” design.Yet most software is riddledwith defects and decay.66
  67. 67. Agile methods identifypractices, process, andtools to enableevolutionary design.This is not synonymous with undisciplined or“cowboy” coding of software.67
  68. 68. In Agile softwaredevelopment teams, designis continuously attended towhile implementing features.There is less focus ondocumentation and hand-offs.68
  69. 69. People who havetraditionally provided designsare expected to work closerwith the teams duringiterations.The best way to do this is bepart of the team.69
  70. 70. When documentation isnecessary or supports thecontinued maintenance ofthe software, it is createdalongside theimplementation of featuresthat made visible theneed.70
  71. 71. Agile teams do not always generate“pretty” diagrams so that they can beuseful today and into the future.Most diagrams– are short-lived– offer just enough information toget a small group of peoplealigned about how to moveforward71
  72. 72. Agile teams think about howthe diagram will be used andmake decisions about howformal an approach forcapturing it should be used.72
  73. 73. Making diagrams “pretty” is awasted effort in most situations.For short-lived diagrams, Agile teams usetransitory mediums– Whiteboards– pieces of paper– the back of a napkinThese are sufficient to make thediagram visible to the group.73
  74. 74. The basic idea is to allow diagramsthat are transient in nature to beerased, thrown away, or deletedwhen you are finished with them.If the diagram is not going to be used inthe future, then we can throw it away assoon as it no longer adds value.74
  75. 75. When diagrams are going tobe useful either forcommunicating essentialmodels or for creatingexecutable artifacts it is goodto make them usable forfuture reading andmaintenance.75
  76. 76. When working with people inremote locations, a virtualwhiteboard application orsharing of applications acrossthe network could supporteffective collaborationaround a diagram.76
  77. 77. Agile architecturepractices77
  78. 78. Agile teams are asked to thinkbroader than a single componentor application when planning,implementing, and testing features.It is important that they include anyintegration with externalapplications into their incrementaldesigns.78
  79. 79. An Agile team looks forways to consolidate theirefforts into practical focusareas that aremanageable from iterationto iteration as theapplication and its designevolves.79
  80. 80. Agile teams are also asked tocontinually incorporateenhancements to quality attributesof the software:– Suitability: Functionality is suitable to all end users– Interoperability: Functionality interoperates withother systems easily– Compliance: Functionality is compliant withapplicable regulatory guidelines80
  81. 81. – Security: System is secure: confidentiality,integrity, availability, accountability andassurance– Maturity: System components are proven stableby others– Fault Tolerance: System continues operatingproperly in the event of failure by one or more ofits components– Recoverability: System recovers from failures insurrounding environment– Operability: Ability to keep a system in a functioningand operating condition– Performance: Perceived response is immediate– Scalability: Able to handle increased usage on theappropriate amount of resources81
  82. 82. – Understandability: Able to use system with littletraining– Learnability: Supports learning of system functionalitywith little external interfacing– Analyzability: Ability to figure out how the systemfunctions– Changeability: Ability to change the systemcomponents to meet new business needs– Testability: Ability to create repeatable and specifictests of the system and potential for some to beautomated– Adaptability: Ability to change out systemcomponent functionality quickly– Installability: Ease of installation and reinstallation– Conformance: Conformance to industry andoperational standards– Replaceability: Ability to replace system82
  83. 83. Agile Application Architecture83
  84. 84. Agile technicalpractices84
  85. 85. Extreme ProgrammingeXtreme Programming (XP) is adevelopment process based onvalues of communication,simplicity, feedback, andcourage.Invented by Kent Beck, Ron Jeffries, and WardCunningham during the Chrysler ComprehensiveCompensation (C3) System project around 1997.85
  86. 86. Extreme ProgrammingCommunication is important sinceMost problems occurbecause the right peopledid not speak at the rightmoment during aproject.86
  87. 87. Extreme ProgrammingCommunication:Teams should sit together in close proximityso they can communicate quickly aboutissues.The customer should also remain close tothe team so they can answer questionsearly in the delivery.– This reduces the amount of churn a team goesthrough deciding on how the customer wantsthe functionality to behave.87
  88. 88. Extreme ProgrammingSimplicity is doing the “simplest thingthat could possibly work”.• This is difficult because traditionaldevelopment methods tell us toanalyze and design a solution beforeimplementing it.• In XP, disciplined use of practices helpreduce complexity in softwaredevelopment.88
  89. 89. Extreme ProgrammingFeedback is an essential element of XP.• Within seconds during a pairprogramming session you getfeedback about the code beingwritten.• Within minutes we are executingtest cases successfully for newfunctionality.89
  90. 90. Extreme ProgrammingFeedback is an essential element of XP.• Within days we are gettingfeedback from users about newfeatures put into the software.• Within weeks we are deploying toproduction and getting feedback onhow it works for the end users in theirdaily lives.90
  91. 91. Extreme ProgrammingCourage to do what is right during a softwarerelease cycle can be difficult for teams.• Having the courage to throw it out orrewrite it.• Trying out a new design with justenough discussion to start codingand proving its ability to solve an issuethrough code.91
  92. 92. Extreme Programming92
  93. 93. Extreme ProgrammingXP focuses on reducing thecost of change duringfeature developmentthrough the use of twelvepractices.93
  94. 94. Extreme ProgrammingThe Planning Game– Figure out the features that go into the nextrelease, through prioritization and groupestimation.Small releases– Release the minimum amount of valuablefeatures to production and then follow up withsubsequent releases.Metaphor– Provide a shared story about the software underdevelopment.94
  95. 95. Extreme ProgrammingSimple design– Design the system for simplicity and– Remove complexity when identified.Testing– Team members and customers execute tests tovalidate the software is in good health and featuresare working.Refactoring– Modify the software’s structure through smalland frequent changes that result in betterdesign without affecting the way it functions.95
  96. 96. Extreme ProgrammingPair programming– Two programmers often work together onproduction artifacts.Collective ownership– Any team member can change any part of thesoftware anytime.Continuous integration– Build, integrate, and execute automated testsafter each task is finished.– This happens many times a day.96
  97. 97. Extreme ProgrammingSustainable Pace– Don’t put in overtime hours two weeks in a row.On-site customer– An actual user of the system is available full-timeto the team to answer questions and validatefeatures.Coding standards– Programmers establish guidelines for writing allcode to help communication through thesoftware artifacts.97
  98. 98. Extreme ProgrammingMost teams who say they do XP are onlypracticing a portion of the twelvepractices.Most of the XP practices take asignificant change in mindset to bedone effectively by softwaredevelopment teams.98
  99. 99. Extreme ProgrammingWhen XP is implemented effectively ithas been shown to significantly reduceentropy as software ages.When scaling to teams larger than tenmembers, many of the XP technicalpractices are used within the Scrumproject management framework.99
  100. 100. References