Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Agile pm v2

•Download as PPTX, PDF•
•
Mia Horrigan
Mia Horrigan

Presentation we did to a group of project managers who had not had any exposure to using Agile methodologies. Gives a basic overview of Agile with a User Centered design approach.

1 of 87
Agile Project ManagementMaria Horrigan and Matthew HodgsonSenior ConsultantsSMS Management and Technology1
Traditional PM MethodologiesPrince2 - PRojects IN Controlled Environments (PRINCE) PMBOK - Project Management Body of Knowledge PMBOK describes many processes and activities, though the PMBOK can be seen as being descriptive (what), while in contrast Prince2 is more prescriptive (how).
Prince2Developed by the UK’s Office of Government Commerce Prince2 describes many processes and activities covering the management, control and organization of projects, and is deliberately not restricted to IT projects.Structured approach, provides a method for managing projects within a clearly defined frameworkDescribes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it doesn’t develop as plannedEach process is specified with its key inputs and outputs, specific goals and activities, which gives an automatic control of any deviations from the plan
Processes involved in Managing Prince2 Projects4Even though Prince2’s popularity makes it a de facto standard for project management , it is criticized for being too prescriptive, too big and not easily customisable.
PMBOKDeveloped by the US-based Project Management Institute (PMI). Internationally recognized standard providing the fundamentals of PM, not limited to IT-projects. Five process groups: Initiating, Planning, Executing, Controlling and Monitoring, and Closing. Nine knowledge areas: Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, and Project Procurement Management.
6
What is a Successful Project ?On time?On budget?Met users' expectations?Met business objectives?Are these the only measure of a successful project?Can a project be considered successful if it is NOT delivered on time, on budget, meeting specifications?7
What about the Sydney Opera House?BudgetEst$425M to buildActual $2435MTimeframeEst1965 due dateActual 1973 first openedDelivered Changed the face of Sydney HarbourMost iconic, recognised symbol of AustraliaLeading edge engineering inventedRevolutionised pre-fabrication-8
Sydney Opera House – an agile projectDesign team went through twelve iterations before a workable solution was completed.Use of structural analysis to understand the complex forces to which the shells would be subjected2400 precast ribs and 4000 roof panels prefabricated on the ground in an on-site factory, instead of being stuck on individually at height.9
What is Agile?10
When we think about ‘agile’ it is..LightFast movingNimbleFlexibleIterativeChanges direction easilylike a Cheetah11
What ‘agile’ is notSlow movingHard to move/change directionHeavyLaboriouslike an Elephant12
When people talk about ‘agile’ “rapid iterations”, “working software”, “coping with change”, “communication”, “flexible”, “adaptable”, “eliminate waste”, “accepting changes”, “small iterations”, “feature-driven”, “continued integrations”, “test driven development”, “no documentation”, “people before process”, “adapt to change”, “the name”, “the team sets their own priority”, “early stakeholder involvement”.13
People, not process make projects workThat is, while there is value in the items on the right, we value the items on the left more.”http://www.agilemanifesto.org
What Agile “IS and ISN’T”Agile Isn’tAgile IsA “Silver Bullet” solution An excuse for poor requirement definitionAn excuse for poor design An excuse for reducing qualityAbout failure to control the scope of a project, its about managed changeDoing more with fewer peopleDoing more with less resources or budgetComplexChaoticUnstructuredAbout people and collaboration
About mutual respect and ownership
About actions rather than discussions
Focused on delivery and outcomes
About delivering real business value
Producing “just enough” documentation to get the job done
Managed iterations
Responding to business changes
Managing change
Simple, fast and efficient
Based on industry best practice
Disciplined and structuredAgile is a lot like lifeThings changeWe adaptWe learn from our mistakes (hopefully)When one thing doesn't work we then try something else (mostly)16
(Application of) Agile as a philosophy17A set of values (or practices as Ivar Jacobson suggests), rather than a processIdentify need/featuresPrioritise featuresDocumentation is a placeholder for a conversationChoosing the best people and the best approach for the right jobMultidisciplinary approach
Agile not FragileDeveloping by feature with business involvementUse of teams with business involvementIndividual class ownershipRegular iterations Regular Inspections of design Configuration ManagementReporting / High visibility of resultsClearly defined rolesEncourage culture that embraces change and innovation
Where did Agile come from?Originally developed as a software engineering methodologyEvolved in the mid 1990s as part of a reaction against “heavyweight” methods, as typified by a heavily regulated, regimented, micro-managed use of waterfall model of developmentInitially agile methods were call “lightweight” methodsAdapted to project management19
Reaction against Waterfall20 Idea that we have to complete it from end-to-end and know everything up front in order to cost and understand the what the solution will look like
and if we don't then somehow we've failed?! WaterfallSequential process“Analysis Paralysis”One iterationLong timeframesDoesn’t cater for changing business environment.linear processlittle flexibilitylimited ability to cope with change21
Do we know all the requirements up front?people often say they know what they wantbut people often don't actually know what they want until they see it"that's not what I want!"too expensive to go back nowmaybe we'll try and train people how to use 'it' this way more expense more change management broken expectations about solution/delivery22
Waterfall – takes time and $$$$In this appraoch, you could be trying to understand your requirements (design phase) for years before anything gets implemented(Project example)Only ever end up incorporating 50-60% of your requirements anyhowmeans wastage of time (40-50% of requirements work becomes useless)That’s expensive!23
Business Drivers - So why do Agile?Maximise business valueReduced time to marketImproved qualityReduce waste/costMinimise risk profileImprove responsiveness to businessImprove service levels to business
Agile Today25
Formal methodologiesTakes from the best of a number of practices from the disciplines of Project Management and Engineering But these won't teach us how to be Agile, they'll only teach us yet another process
Scrum, FDD, XPAgile MethodologiesProject ManagementEngineeringFDDScrumXP
Early Agile Case studiesCase 0: Daimler Chrysler Chrysler Comprehensive Compensation System (C3) payroll project28
Extreme Programming (XP)Pitched as: Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements”Invented by: Kent Beck who preferred being a Technical Lead to being a Project Manager.Year first used: Pre-2000First used on: C3 project ChryslerXP is a set of best practices of which some are taken to an "extreme" level. In the selection of its practices XP leans towards the daily software engineering activities of developersNow used on: All over the place by different groups/people29
Requirments in XPAs with other agile methods, XP regards ongoing changes to requirements as a natural and desirable aspect of software development. XP view of requirementsOnsite customer (implied singular customer)Recognition that customer could be a team of peopleRecognition of the role of a customer representative30
Scrum“Management and control process that cuts through complexity" Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior managers wanting to get product out faster. Year first used: 1994 - now used all over the place with different groups/peopleFirst used on: Advanced Development Methods - process automation software Scrum is a skeleton that includes a small set of practices and predefined roles Scrum is becoming a de facto standard for managing agile software development projectsConsists of a few common sense practices that can be applied in many situationsScrum by itself is never enough, and that development teams have to shop in other methods (usually XP) for additional practices31
Scrum: RolesAlternative Name: User, Customer
Role Definition: The Product Owner represents the custumer/user/sponsor of the project, and is part of the team which will deliver the product.
Main Activities: Define the vision for the product, manage the Return On Investment (ROI), present the needed requirements to the team for the product delivery, prioritize requirements, manage addition/changes to requirements, plan releases, assure the Domain Experts are available to the team.Product OwnerAlternative Names: Project Manager/Leader, Coach
Role Definition: The role of Scrum Master, unlike a Project Manager in many practices and methodologies, differ from the traditional “command and control”. In Scrum, the Scrum Master works with and, more important, for the team.
Main Activities: Allow the team to be self-managed, guide and help the team to correctly follow Scrum practices, remove any impediment found by the team, protect the team from external interference, facilitate the daily meetings.Scrum MasterAlternative Names: Developers, Technicians, Testers
Role Definition: A team member is someone committed to do the necessary work to achieve the Sprint goal.
Main Activities: Define the Sprint goal, be committed to the work and to the high quality, work towards the product vision and the Sprint goal, estimate items on the Product Backlog, attend the daily meetings.Team members
Scrum: Lifecycle6. Day7. Daily StandupMeeting5. Sprint(2-4 weeks)4. Tasksdetailedby the team8. Product Increment(potentially shippable)3. Sprint Backlog1. Vision(ROI, milestones, releases)2. Product Backlog, with featuresprioritized by the Product Owner9. Inspect and Adapt
Feature Driven Development “A framework of controls and best practice to enable and enforce the repeatable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project”Invented by: Peter Coad, Jeff De Luca, Steven PalmerYear first used: 1997First used on: Hong Kong Banking Corp on a large 200 person Java projectFDD blends a number of industry-recognized best practices into a cohesive wholeThese practices are all driven from a client-valued functionality (feature) perspectiveIts main purpose is to deliver tangible, working software repeatedly in a timely manner.34
and there are others . . . Crystal MethodsDynamic Systems Development Method (DSDM)Lean Development (LD)Adaptive Software Development (ASD)... etc ...35
CommonalitiesIterativeEvolutionary, not revolutionary (big bang)Continuous learningFocus on Effective communicationMulti-disciplinary teamsAdding value, not 'deliverables' or 'products'What will add value to the 'end-user'36
Why Agile?37
Underlying PrinciplesContinuous improvement is the cornerstone of Agile Focus is not on perfection but just getting better.Conversation is the most effective way to clarify what may seem to be a complex requirementNeed to provide clarity and answer the question “when are we done”?Prototyping mitigates risk by focusing on just enough to gain the understanding neededIteration is the heart-beat of Agile Estimation of all requirements before a project starts is unrealistic - learn over time, refine and update plans Prioritise to deliver the most business critical pieces38
Key Features of AgileBreakdown of work into small, incremental work packagesdelivered in 2-4 week cyclesAdaptability to new or changed requirementsClose involvement of end users and business ownersHighly business and end user focussed activities and outputsFocus on face-to-faceworkshops and communicationsProactive Change Management to embed business change 39
Benefits of AgileSmarter way of working - innovativeCross-functional teamsContingent outcomesContingent processes and methodologiesIs about users and adding value, rather than 'managing deliverables/productsLess riskLess waste40
How Agile Promotes InnovationNot locked into one way of doing thingsTake learnings from previous iterations and previous projects and apply directly, instantly, rather than having to wait til the next project41
Less riskEasier to apply what you learn as you goEncouraged to take things one step at a timeBuild a skinny 'system' to work out the basics of what you needBase decisions on light-weight requirementsEasier to change direction of scope as required when uncovering new issues42
Less wasteEncourages re-use90-59% of requirements built rather than 50-60%Means you could waste up to 50% of project costs on things you don't need, don't want, or don't work properlyFocus on documentation only when requiredLess costly as a result43
Cost to Change Curve$$Cost of Change$$$Lifecycle Stage
Use of Cross Functional TeamsChoose the best skills for specific jobsIncorporate best knowledge from across an organisation, not from within a single teamutilise network-information flow inherent in new information transfer45
Change management is built into the processUsers involved in developing solution increased ownershipdevelops 'champions'Users validate solutionmeans the result better aligns to what people want (they get to be involved with each iteration and see the results i.e.: what they'll get)not as much training requirednot as much change management required46
JIT Requirements Elaboration vs Up front elaboratioJIT (Just in Time)Rapid progress earlyEarlier customer feedbackCould get blind-sidedUp front ElaborationMore up front effort, more time till customer feedbackClarify overall scope and size soonerConsiderationsCostffort of developmentGovernance framework, funding modelUniqueness
The Agile LifecyclePlanning and AnalysisEffortTimeProject Duration
Disadvantages of AgileIt's relatively 'new' (people aren't as familiar with it as they are with Waterfall)People are afraid of what they don't knowPeople tend to want to know what they're getting up front before they commit budgetTends toward fragmentation of solutionDifferent people working on different components means UX suffersDifferent incompatible solutions may arise out of each component/iteration49
Agile is a standards based approach50
ISO 13407Understand context in which solution needs to operateInvolve users in developing a solutionRefine solutionTest solution with usersIf solution validates, implement/build itRoll onto next user need/feature51
User centered design52
ContextGood Requirements (IEEE definitions)Set is completeSet is consistentSet is modifiableDecompositionOrganize stories by relating to higher level artifacts“If you lose a card, and if the customer does not detect that loss, then the card wasn’t very important.”Robert C. Martin
User InvolvementAgile characteristics to promote user involvementFrequent “releases”Daily stand up
Analysis of Business and User Needs55
User Stories“A User Story is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. The User Story promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation.”
User StoriesThree CsCard – encourages brevity, format easily used in prioritisingPromise for a conversation, not a fully-articulated requirementConfirmation details enable us to know when we are done57
Stakeholder segmentationMain target audienceWho can influence the main target audienceWho are the (community) gatekeepers who also need influencing to share what they know or lobby on your behalf?Channel identificationWhat channels do we use to communicate most effectively with these people?What messages to useidentifying user need/value – user stories58
Kernel Approach from Ivar Jacobson (UML God) Things to produceThings to applyThings to doCompetencies to performConcept, Feature problem, Work package iteration, but its not a deliverable or a productYour Own Best Practices59
Other Practice from many other sourcesUse CasesArchitectureIterative approachWaterfall approachTeamUser StoriesProcess MapsStoryboardsCard SortingPersonasNon-functional HTML prototypesFully-functional prototypesContextual inquiry60
Misconception that agile = no documentation and no rigour/discipline61
A "place-holder" for conversationsStory cardsPersonasStoryboardsInteraction design mapsCard sortingConversations become formalised to tell the story for those who followUser requirementsBusiness requirementsSystem requirements62
Build a skeleton solution firstAssess need for parallel iterationsestablish baseline assess solutions according to baselineBiggest/first major iteration cycle is about 6-8 weeksEnd with fully-functional solution at the endforms the baselineAdd bits to the skeleton, as identified by prioritisation/value proposition/need/funds63
Stand-up meetingsRisksScopeChange managementReporting64
Sprint Planning MeetingTurns product backlog into the sprint backlogGets the Team to commit to a level of delivery during the SprintProduct Owner, Scrum Master &Team attendElaborate the features in the product backlogRefine understanding & acceptance criteriaCreate sub-tasks Re-estimateFeatures the Team commits to delivering form the Sprint Backlog. Once formed the Sprint Backlog should not change
Daily Scrum & Impediments ListQuick meeting to synchronize Team Chance to escalate to Scrum Master15 mins, 3 questions eachWhat did you do yesterday?What are you going to do today?What problems/issues do you have?Issues go on an Impediments ListThe Scrum Master is responsible for removing items from the Impediments List
Adoption of Agile within Prince2 environment67Allowed client to address scope and requirements one piece at a time, which allowed the project to evolve and change on a ‘just-in-time’ basis, with risks identified and mitigated as required
68
69
Key Agile activitiesDiscovery of current processes and end user needs, issues and requirements through workshopsCollaborative development of process refinements and end user experience improvements through visual storyboarding from the point of view of different usersBusiness process modelling derived from validated storyboardsDetailed user interface prototypes derived from business process mapsIterative improvement of prototypes through validation with business ownersThe prototypes form the basis of the features that will drive the strategic, business and user requirements specification for the resulting technology70
71Workshopping current processes and requirementsIterative improvements to user interface prototypesProcess refinement through visual storyboardingbusiness process map (‘swim lane’ or cross-functional flow chart)Refined visual storyboard mapping user experience and high level business processes

More Related Content

Agile pm v2

  • 1. Agile Project ManagementMaria Horrigan and Matthew HodgsonSenior ConsultantsSMS Management and Technology1
  • 2. Traditional PM MethodologiesPrince2 - PRojects IN Controlled Environments (PRINCE) PMBOK - Project Management Body of Knowledge PMBOK describes many processes and activities, though the PMBOK can be seen as being descriptive (what), while in contrast Prince2 is more prescriptive (how).
  • 3. Prince2Developed by the UK’s Office of Government Commerce Prince2 describes many processes and activities covering the management, control and organization of projects, and is deliberately not restricted to IT projects.Structured approach, provides a method for managing projects within a clearly defined frameworkDescribes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it doesn’t develop as plannedEach process is specified with its key inputs and outputs, specific goals and activities, which gives an automatic control of any deviations from the plan
  • 4. Processes involved in Managing Prince2 Projects4Even though Prince2’s popularity makes it a de facto standard for project management , it is criticized for being too prescriptive, too big and not easily customisable.
  • 5. PMBOKDeveloped by the US-based Project Management Institute (PMI). Internationally recognized standard providing the fundamentals of PM, not limited to IT-projects. Five process groups: Initiating, Planning, Executing, Controlling and Monitoring, and Closing. Nine knowledge areas: Project Integration Management, Project Scope Management, Project Time Management, Project Cost Management, Project Quality Management, Project Human Resource Management, Project Communications Management, Project Risk Management, and Project Procurement Management.
  • 6. 6
  • 7. What is a Successful Project ?On time?On budget?Met users' expectations?Met business objectives?Are these the only measure of a successful project?Can a project be considered successful if it is NOT delivered on time, on budget, meeting specifications?7
  • 8. What about the Sydney Opera House?BudgetEst$425M to buildActual $2435MTimeframeEst1965 due dateActual 1973 first openedDelivered Changed the face of Sydney HarbourMost iconic, recognised symbol of AustraliaLeading edge engineering inventedRevolutionised pre-fabrication-8
  • 9. Sydney Opera House – an agile projectDesign team went through twelve iterations before a workable solution was completed.Use of structural analysis to understand the complex forces to which the shells would be subjected2400 precast ribs and 4000 roof panels prefabricated on the ground in an on-site factory, instead of being stuck on individually at height.9
  • 11. When we think about ‘agile’ it is..LightFast movingNimbleFlexibleIterativeChanges direction easilylike a Cheetah11
  • 12. What ‘agile’ is notSlow movingHard to move/change directionHeavyLaboriouslike an Elephant12
  • 13. When people talk about ‘agile’ “rapid iterations”, “working software”, “coping with change”, “communication”, “flexible”, “adaptable”, “eliminate waste”, “accepting changes”, “small iterations”, “feature-driven”, “continued integrations”, “test driven development”, “no documentation”, “people before process”, “adapt to change”, “the name”, “the team sets their own priority”, “early stakeholder involvement”.13
  • 14. People, not process make projects workThat is, while there is value in the items on the right, we value the items on the left more.”http://www.agilemanifesto.org
  • 15. What Agile “IS and ISN’T”Agile Isn’tAgile IsA “Silver Bullet” solution An excuse for poor requirement definitionAn excuse for poor design An excuse for reducing qualityAbout failure to control the scope of a project, its about managed changeDoing more with fewer peopleDoing more with less resources or budgetComplexChaoticUnstructuredAbout people and collaboration
  • 16. About mutual respect and ownership
  • 17. About actions rather than discussions
  • 18. Focused on delivery and outcomes
  • 19. About delivering real business value
  • 20. Producing “just enough” documentation to get the job done
  • 24. Simple, fast and efficient
  • 25. Based on industry best practice
  • 26. Disciplined and structuredAgile is a lot like lifeThings changeWe adaptWe learn from our mistakes (hopefully)When one thing doesn't work we then try something else (mostly)16
  • 27. (Application of) Agile as a philosophy17A set of values (or practices as Ivar Jacobson suggests), rather than a processIdentify need/featuresPrioritise featuresDocumentation is a placeholder for a conversationChoosing the best people and the best approach for the right jobMultidisciplinary approach
  • 28. Agile not FragileDeveloping by feature with business involvementUse of teams with business involvementIndividual class ownershipRegular iterations Regular Inspections of design Configuration ManagementReporting / High visibility of resultsClearly defined rolesEncourage culture that embraces change and innovation
  • 29. Where did Agile come from?Originally developed as a software engineering methodologyEvolved in the mid 1990s as part of a reaction against “heavyweight” methods, as typified by a heavily regulated, regimented, micro-managed use of waterfall model of developmentInitially agile methods were call “lightweight” methodsAdapted to project management19
  • 30. Reaction against Waterfall20 Idea that we have to complete it from end-to-end and know everything up front in order to cost and understand the what the solution will look like
  • 31. and if we don't then somehow we've failed?! WaterfallSequential process“Analysis Paralysis”One iterationLong timeframesDoesn’t cater for changing business environment.linear processlittle flexibilitylimited ability to cope with change21
  • 32. Do we know all the requirements up front?people often say they know what they wantbut people often don't actually know what they want until they see it"that's not what I want!"too expensive to go back nowmaybe we'll try and train people how to use 'it' this way more expense more change management broken expectations about solution/delivery22
  • 33. Waterfall – takes time and $$$$In this appraoch, you could be trying to understand your requirements (design phase) for years before anything gets implemented(Project example)Only ever end up incorporating 50-60% of your requirements anyhowmeans wastage of time (40-50% of requirements work becomes useless)That’s expensive!23
  • 34. Business Drivers - So why do Agile?Maximise business valueReduced time to marketImproved qualityReduce waste/costMinimise risk profileImprove responsiveness to businessImprove service levels to business
  • 36. Formal methodologiesTakes from the best of a number of practices from the disciplines of Project Management and Engineering But these won't teach us how to be Agile, they'll only teach us yet another process
  • 37. Scrum, FDD, XPAgile MethodologiesProject ManagementEngineeringFDDScrumXP
  • 38. Early Agile Case studiesCase 0: Daimler Chrysler Chrysler Comprehensive Compensation System (C3) payroll project28
  • 39. Extreme Programming (XP)Pitched as: Addressing “the specific needs of software development conducted by small teams in the face of vague or changing requirements”Invented by: Kent Beck who preferred being a Technical Lead to being a Project Manager.Year first used: Pre-2000First used on: C3 project ChryslerXP is a set of best practices of which some are taken to an "extreme" level. In the selection of its practices XP leans towards the daily software engineering activities of developersNow used on: All over the place by different groups/people29
  • 40. Requirments in XPAs with other agile methods, XP regards ongoing changes to requirements as a natural and desirable aspect of software development. XP view of requirementsOnsite customer (implied singular customer)Recognition that customer could be a team of peopleRecognition of the role of a customer representative30
  • 41. Scrum“Management and control process that cuts through complexity" Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior managers wanting to get product out faster. Year first used: 1994 - now used all over the place with different groups/peopleFirst used on: Advanced Development Methods - process automation software Scrum is a skeleton that includes a small set of practices and predefined roles Scrum is becoming a de facto standard for managing agile software development projectsConsists of a few common sense practices that can be applied in many situationsScrum by itself is never enough, and that development teams have to shop in other methods (usually XP) for additional practices31
  • 43. Role Definition: The Product Owner represents the custumer/user/sponsor of the project, and is part of the team which will deliver the product.
  • 44. Main Activities: Define the vision for the product, manage the Return On Investment (ROI), present the needed requirements to the team for the product delivery, prioritize requirements, manage addition/changes to requirements, plan releases, assure the Domain Experts are available to the team.Product OwnerAlternative Names: Project Manager/Leader, Coach
  • 45. Role Definition: The role of Scrum Master, unlike a Project Manager in many practices and methodologies, differ from the traditional “command and control”. In Scrum, the Scrum Master works with and, more important, for the team.
  • 46. Main Activities: Allow the team to be self-managed, guide and help the team to correctly follow Scrum practices, remove any impediment found by the team, protect the team from external interference, facilitate the daily meetings.Scrum MasterAlternative Names: Developers, Technicians, Testers
  • 47. Role Definition: A team member is someone committed to do the necessary work to achieve the Sprint goal.
  • 48. Main Activities: Define the Sprint goal, be committed to the work and to the high quality, work towards the product vision and the Sprint goal, estimate items on the Product Backlog, attend the daily meetings.Team members
  • 49. Scrum: Lifecycle6. Day7. Daily StandupMeeting5. Sprint(2-4 weeks)4. Tasksdetailedby the team8. Product Increment(potentially shippable)3. Sprint Backlog1. Vision(ROI, milestones, releases)2. Product Backlog, with featuresprioritized by the Product Owner9. Inspect and Adapt
  • 50. Feature Driven Development “A framework of controls and best practice to enable and enforce the repeatable delivery of working software in a timely manner with highly accurate and meaningful information to all key roles inside and outside a project”Invented by: Peter Coad, Jeff De Luca, Steven PalmerYear first used: 1997First used on: Hong Kong Banking Corp on a large 200 person Java projectFDD blends a number of industry-recognized best practices into a cohesive wholeThese practices are all driven from a client-valued functionality (feature) perspectiveIts main purpose is to deliver tangible, working software repeatedly in a timely manner.34
  • 51. and there are others . . . Crystal MethodsDynamic Systems Development Method (DSDM)Lean Development (LD)Adaptive Software Development (ASD)... etc ...35
  • 52. CommonalitiesIterativeEvolutionary, not revolutionary (big bang)Continuous learningFocus on Effective communicationMulti-disciplinary teamsAdding value, not 'deliverables' or 'products'What will add value to the 'end-user'36
  • 54. Underlying PrinciplesContinuous improvement is the cornerstone of Agile Focus is not on perfection but just getting better.Conversation is the most effective way to clarify what may seem to be a complex requirementNeed to provide clarity and answer the question “when are we done”?Prototyping mitigates risk by focusing on just enough to gain the understanding neededIteration is the heart-beat of Agile Estimation of all requirements before a project starts is unrealistic - learn over time, refine and update plans Prioritise to deliver the most business critical pieces38
  • 55. Key Features of AgileBreakdown of work into small, incremental work packagesdelivered in 2-4 week cyclesAdaptability to new or changed requirementsClose involvement of end users and business ownersHighly business and end user focussed activities and outputsFocus on face-to-faceworkshops and communicationsProactive Change Management to embed business change 39
  • 56. Benefits of AgileSmarter way of working - innovativeCross-functional teamsContingent outcomesContingent processes and methodologiesIs about users and adding value, rather than 'managing deliverables/productsLess riskLess waste40
  • 57. How Agile Promotes InnovationNot locked into one way of doing thingsTake learnings from previous iterations and previous projects and apply directly, instantly, rather than having to wait til the next project41
  • 58. Less riskEasier to apply what you learn as you goEncouraged to take things one step at a timeBuild a skinny 'system' to work out the basics of what you needBase decisions on light-weight requirementsEasier to change direction of scope as required when uncovering new issues42
  • 59. Less wasteEncourages re-use90-59% of requirements built rather than 50-60%Means you could waste up to 50% of project costs on things you don't need, don't want, or don't work properlyFocus on documentation only when requiredLess costly as a result43
  • 60. Cost to Change Curve$$Cost of Change$$$Lifecycle Stage
  • 61. Use of Cross Functional TeamsChoose the best skills for specific jobsIncorporate best knowledge from across an organisation, not from within a single teamutilise network-information flow inherent in new information transfer45
  • 62. Change management is built into the processUsers involved in developing solution increased ownershipdevelops 'champions'Users validate solutionmeans the result better aligns to what people want (they get to be involved with each iteration and see the results i.e.: what they'll get)not as much training requirednot as much change management required46
  • 63. JIT Requirements Elaboration vs Up front elaboratioJIT (Just in Time)Rapid progress earlyEarlier customer feedbackCould get blind-sidedUp front ElaborationMore up front effort, more time till customer feedbackClarify overall scope and size soonerConsiderationsCostffort of developmentGovernance framework, funding modelUniqueness
  • 64. The Agile LifecyclePlanning and AnalysisEffortTimeProject Duration
  • 65. Disadvantages of AgileIt's relatively 'new' (people aren't as familiar with it as they are with Waterfall)People are afraid of what they don't knowPeople tend to want to know what they're getting up front before they commit budgetTends toward fragmentation of solutionDifferent people working on different components means UX suffersDifferent incompatible solutions may arise out of each component/iteration49
  • 66. Agile is a standards based approach50
  • 67. ISO 13407Understand context in which solution needs to operateInvolve users in developing a solutionRefine solutionTest solution with usersIf solution validates, implement/build itRoll onto next user need/feature51
  • 69. ContextGood Requirements (IEEE definitions)Set is completeSet is consistentSet is modifiableDecompositionOrganize stories by relating to higher level artifacts“If you lose a card, and if the customer does not detect that loss, then the card wasn’t very important.”Robert C. Martin
  • 70. User InvolvementAgile characteristics to promote user involvementFrequent “releases”Daily stand up
  • 71. Analysis of Business and User Needs55
  • 72. User Stories“A User Story is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting estimation of how long it will take to implement. The User Story promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation.”
  • 73. User StoriesThree CsCard – encourages brevity, format easily used in prioritisingPromise for a conversation, not a fully-articulated requirementConfirmation details enable us to know when we are done57
  • 74. Stakeholder segmentationMain target audienceWho can influence the main target audienceWho are the (community) gatekeepers who also need influencing to share what they know or lobby on your behalf?Channel identificationWhat channels do we use to communicate most effectively with these people?What messages to useidentifying user need/value – user stories58
  • 75. Kernel Approach from Ivar Jacobson (UML God) Things to produceThings to applyThings to doCompetencies to performConcept, Feature problem, Work package iteration, but its not a deliverable or a productYour Own Best Practices59
  • 76. Other Practice from many other sourcesUse CasesArchitectureIterative approachWaterfall approachTeamUser StoriesProcess MapsStoryboardsCard SortingPersonasNon-functional HTML prototypesFully-functional prototypesContextual inquiry60
  • 77. Misconception that agile = no documentation and no rigour/discipline61
  • 78. A "place-holder" for conversationsStory cardsPersonasStoryboardsInteraction design mapsCard sortingConversations become formalised to tell the story for those who followUser requirementsBusiness requirementsSystem requirements62
  • 79. Build a skeleton solution firstAssess need for parallel iterationsestablish baseline assess solutions according to baselineBiggest/first major iteration cycle is about 6-8 weeksEnd with fully-functional solution at the endforms the baselineAdd bits to the skeleton, as identified by prioritisation/value proposition/need/funds63
  • 81. Sprint Planning MeetingTurns product backlog into the sprint backlogGets the Team to commit to a level of delivery during the SprintProduct Owner, Scrum Master &Team attendElaborate the features in the product backlogRefine understanding & acceptance criteriaCreate sub-tasks Re-estimateFeatures the Team commits to delivering form the Sprint Backlog. Once formed the Sprint Backlog should not change
  • 82. Daily Scrum & Impediments ListQuick meeting to synchronize Team Chance to escalate to Scrum Master15 mins, 3 questions eachWhat did you do yesterday?What are you going to do today?What problems/issues do you have?Issues go on an Impediments ListThe Scrum Master is responsible for removing items from the Impediments List
  • 83. Adoption of Agile within Prince2 environment67Allowed client to address scope and requirements one piece at a time, which allowed the project to evolve and change on a ‘just-in-time’ basis, with risks identified and mitigated as required
  • 84. 68
  • 85. 69
  • 86. Key Agile activitiesDiscovery of current processes and end user needs, issues and requirements through workshopsCollaborative development of process refinements and end user experience improvements through visual storyboarding from the point of view of different usersBusiness process modelling derived from validated storyboardsDetailed user interface prototypes derived from business process mapsIterative improvement of prototypes through validation with business ownersThe prototypes form the basis of the features that will drive the strategic, business and user requirements specification for the resulting technology70
  • 87. 71Workshopping current processes and requirementsIterative improvements to user interface prototypesProcess refinement through visual storyboardingbusiness process map (‘swim lane’ or cross-functional flow chart)Refined visual storyboard mapping user experience and high level business processes
  • 88. 72
  • 89. Stakeholder Communication is KeyDon't underestimate the value of face-to-face conversationsLeveraging web 2.0 for responsive communication (a vehicle for getting quick feedback and collaboration)Project blogsProject status, Lessons learned, Comments, Criticisms and DiscoveriesAnnouncements Milestones, Blog posts, Media releases, Locations for system prototypes and Locations of solutions toreviewcommentshareCritique73
  • 90. Communicate - formally or informallyFormalgroup workshopscard sortingpersonascollaborative designindividualscontextual inquiryinterviewssurveys/questionnairesprototype testingInformalover coffeeover lunch74
  • 95. WikisBenchmark project documentationIterate project documentationStore for stencils, prototypes and templatesFeatures to manage projectsUser sign-onsVersion controlRoll-backsAudit trails79
  • 96. Agile governanceReport lessons Out of each major iterationWhen reaching major milestonesObtain sign-off/approvalWhen major solution components are identifiedTo pass major milestonesWhen new user-groups are identified and require involvement in requirements/validationMajor scope changes80
  • 97. How to budget for Agile Kernel/contingency project model?How many parallel iterations?How many peopleWhat processWhat practicesPayment on first iteration then delivery of each subsequent identified 'feature‘ Payment decisions/perceived valueAssessment of time/materials/iteration requirements81
  • 98. So what is agile really about and how can we use it on our projects?82
  • 99. One size does not fit allNot all projects (or iterations) are suited to Agile techniquesAgile doesn’t fix every problemAgile doesn’t work on every projectChoose the right combination of techniquesLook for opportunities to be more agileAnalysis techniques are important, but as a means to actively elicit information rather than documentConstant evolution of process can be difficult2 steps forward, 1 step backAvoid stagnationVerbal communication and interpersonal skills become more important in co-located team environmentsTraining and mentoring are the key83
  • 100. Work smarterBecome creative with the documentation we do createLeverage existing practices within your teams/divisionsLeveraging existing expertiseLeverage existing knowledge84
  • 101. Pass on learningsAdd through issues logsRisksScope changesKnowledge gainedCapturing resourcing requirements per iterationPass on experience85
  • 103. WorkshopsPresentation will be available on slideshareQRG (quick reference guide) is being developed and will be availableWorkshops with teamsWork through project issues real cases and situationsOne-on-one coaching Tailor training requirement to individual team needs and level of familiarity with agile87

Editor's Notes

  1. And on 17 March 1966 it reported: "It was not his fault that a succession of Governments and the Opera House Trust should so signally have failed to impose any control or order on the project .... his concept was so daring that he himself could solve its problems only step by step .... his insistence on perfection led him to alter his design as he went along."
  2. Payment on first iteration (First major iteration is typically 8 weeks for a largish project) Payment on delivery of each subsequent identified 'feature‘ (Subsequent iterations are approx. 6 weeks, then 4 weeks, then 3 weeks)