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. Agile Project Management Maria Horrigan and Matthew Hodgson Senior Consultants SMS Management and Technology 1

2. Traditional PM Methodologies Prince2 - 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. Prince2 Developed 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 framework Describes 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 planned Each 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 Projects 4 Even 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. PMBOK Developed 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? Budget Est$425M to build Actual $2435M Timeframe Est1965 due date Actual 1973 first opened Delivered Changed the face of Sydney Harbour Most iconic, recognised symbol of Australia Leading edge engineering invented Revolutionised pre-fabrication - 8

9. Sydney Opera House – an agile project Design 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 subjected 2400 precast ribs and 4000 roof panels prefabricated on the ground in an on-site factory, instead of being stuck on individually at height. 9

10. What is Agile? 10

11. When we think about ‘agile’ it is.. Light Fast moving Nimble Flexible Iterative Changes direction easily like a Cheetah 11

12. What ‘agile’ is not Slow moving Hard to move/change direction Heavy Laborious like an Elephant 12

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 work That is, while there is value in the items on the right, we value the items on the left more.” http://www.agilemanifesto.org

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

21. Managed iterations

22. Responding to business changes

23. Managing change

24. Simple, fast and efficient

25. Based on industry best practice

27. (Application of) Agile as a philosophy 17 A set of values (or practices as Ivar Jacobson suggests), rather than a process Identify need/features Prioritise features Documentation is a placeholder for a conversation Choosing the best people and the best approach for the right job Multidisciplinary approach

28. Agile not Fragile Developing by feature with business involvement Use of teams with business involvement Individual class ownership Regular iterations Regular Inspections of design Configuration Management Reporting / High visibility of results Clearly defined roles Encourage culture that embraces change and innovation

29. Where did Agile come from? Originally developed as a software engineering methodology Evolved 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 development Initially agile methods were call “lightweight” methods Adapted to project management 19

32. Do we know all the requirements up front? people often say they know what they want but people often don't actually know what they want until they see it "that's not what I want!" too expensive to go back now maybe we'll try and train people how to use 'it' this way more expense more change management broken expectations about solution/delivery 22

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 anyhow means wastage of time (40-50% of requirements work becomes useless) That’s expensive! 23

34. Business Drivers - So why do Agile? Maximise business value Reduced time to market Improved quality Reduce waste/cost Minimise risk profile Improve responsiveness to business Improve service levels to business

35. Agile Today 25

36. Formal methodologies Takes 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, XP Agile Methodologies Project Management Engineering FDD Scrum XP

38. Early Agile Case studies Case 0: Daimler Chrysler Chrysler Comprehensive Compensation System (C3) payroll project 28

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-2000 First used on: C3 project Chrysler XP 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 developers Now used on: All over the place by different groups/people 29

40. Requirments in XP As with other agile methods, XP regards ongoing changes to requirements as a natural and desirable aspect of software development. XP view of requirements Onsite customer (implied singular customer) Recognition that customer could be a team of people Recognition of the role of a customer representative 30

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/people First 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 projects Consists of a few common sense practices that can be applied in many situations Scrum by itself is never enough, and that development teams have to shop in other methods (usually XP) for additional practices 31

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.

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.

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: Lifecycle 6. Day 7. Daily StandupMeeting 5. Sprint(2-4 weeks) 4. Tasksdetailedby the team 8. Product Increment(potentially shippable) 3. Sprint Backlog 1. Vision (ROI, milestones, releases) 2. Product Backlog, with features prioritized by the Product Owner 9. 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 Palmer Year first used: 1997 First used on: Hong Kong Banking Corp on a large 200 person Java project FDD blends a number of industry-recognized best practices into a cohesive whole These practices are all driven from a client-valued functionality (feature) perspective Its main purpose is to deliver tangible, working software repeatedly in a timely manner. 34

51. and there are others . . . Crystal Methods Dynamic Systems Development Method (DSDM) Lean Development (LD) Adaptive Software Development (ASD) ... etc ... 35

52. Commonalities Iterative Evolutionary, not revolutionary (big bang) Continuous learning Focus on Effective communication Multi-disciplinary teams Adding value, not 'deliverables' or 'products' What will add value to the 'end-user' 36

53. Why Agile? 37

54. Underlying Principles Continuous 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 requirement Need to provide clarity and answer the question “when are we done”? Prototyping mitigates risk by focusing on just enough to gain the understanding needed Iteration 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 pieces 38

55. Key Features of Agile Breakdown of work into small, incremental work packagesdelivered in 2-4 week cycles Adaptability to new or changed requirements Close involvement of end users and business owners Highly business and end user focussed activities and outputs Focus on face-to-faceworkshops and communications Proactive Change Management to embed business change 39

56. Benefits of Agile Smarter way of working - innovative Cross-functional teams Contingent outcomes Contingent processes and methodologies Is about users and adding value, rather than 'managing deliverables/products Less risk Less waste 40

57. How Agile Promotes Innovation Not locked into one way of doing things Take learnings from previous iterations and previous projects and apply directly, instantly, rather than having to wait til the next project 41

58. Less risk Easier to apply what you learn as you go Encouraged to take things one step at a time Build a skinny 'system' to work out the basics of what you need Base decisions on light-weight requirements Easier to change direction of scope as required when uncovering new issues 42

59. Less waste Encourages re-use 90-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 properly Focus on documentation only when required Less costly as a result 43

60. Cost to Change Curve $ $ Cost of Change $ $ $ Lifecycle Stage

61. Use of Cross Functional Teams Choose the best skills for specific jobs Incorporate best knowledge from across an organisation, not from within a single team utilise network-information flow inherent in new information transfer 45

62. Change management is built into the process Users involved in developing solution increased ownership develops 'champions' Users validate solution means 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 required not as much change management required 46

63. JIT Requirements Elaboration vs Up front elaboratio JIT (Just in Time) Rapid progress early Earlier customer feedback Could get blind-sided Up front Elaboration More up front effort, more time till customer feedback Clarify overall scope and size sooner Considerations Costffort of development Governance framework, funding model Uniqueness

64. The Agile Lifecycle Planning and Analysis Effort Time Project Duration

65. Disadvantages of Agile It's relatively 'new' (people aren't as familiar with it as they are with Waterfall) People are afraid of what they don't know People tend to want to know what they're getting up front before they commit budget Tends toward fragmentation of solution Different people working on different components means UX suffers Different incompatible solutions may arise out of each component/iteration 49

66. Agile is a standards based approach 50

67. ISO 13407 Understand context in which solution needs to operate Involve users in developing a solution Refine solution Test solution with users If solution validates, implement/build it Roll onto next user need/feature 51

68. User centered design 52

69. Context Good Requirements (IEEE definitions) Set is complete Set is consistent Set is modifiable Decomposition Organize 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 Involvement Agile characteristics to promote user involvement Frequent “releases” Daily stand up

71. Analysis of Business and User Needs 55

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 Stories Three Cs Card – encourages brevity, format easily used in prioritising Promise for a conversation, not a fully-articulated requirement Confirmation details enable us to know when we are done 57

74. Stakeholder segmentation Main target audience Who can influence the main target audience Who are the (community) gatekeepers who also need influencing to share what they know or lobby on your behalf? Channel identification What channels do we use to communicate most effectively with these people? What messages to use identifying user need/value – user stories 58

75. Kernel Approach from Ivar Jacobson (UML God) Things to produce Things to apply Things to do Competencies to perform Concept, Feature problem, Work package iteration, but its not a deliverable or a product Your Own Best Practices 59

76. Other Practice from many other sources Use Cases Architecture Iterative approach Waterfall approach Team User Stories Process Maps Storyboards Card Sorting Personas Non-functional HTML prototypes Fully-functional prototypes Contextual inquiry 60

77. Misconception that agile = no documentation and no rigour/discipline 61

78. A "place-holder" for conversations Story cards Personas Storyboards Interaction design maps Card sorting Conversations become formalised to tell the story for those who follow User requirements Business requirements System requirements 62

79. Build a skeleton solution first Assess need for parallel iterations establish baseline assess solutions according to baseline Biggest/first major iteration cycle is about 6-8 weeks End with fully-functional solution at the end forms the baseline Add bits to the skeleton, as identified by prioritisation/value proposition/need/funds 63

80. Stand-up meetings Risks Scope Change management Reporting 64

81. Sprint Planning Meeting Turns product backlog into the sprint backlog Gets the Team to commit to a level of delivery during the Sprint Product Owner, Scrum Master &Team attend Elaborate the features in the product backlog Refine understanding & acceptance criteria Create sub-tasks Re-estimate Features the Team commits to delivering form the Sprint Backlog. Once formed the Sprint Backlog should not change

82. Daily Scrum & Impediments List Quick meeting to synchronize Team Chance to escalate to Scrum Master 15 mins, 3 questions each What did you do yesterday? What are you going to do today? What problems/issues do you have? Issues go on an Impediments List The Scrum Master is responsible for removing items from the Impediments List

83. Adoption of Agile within Prince2 environment 67 Allowed 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 activities Discovery of current processes and end user needs, issues and requirements through workshops Collaborative development of process refinements and end user experience improvements through visual storyboarding from the point of view of different users Business process modelling derived from validated storyboards Detailed user interface prototypes derived from business process maps Iterative improvement of prototypes through validation with business owners The prototypes form the basis of the features that will drive the strategic, business and user requirements specification for the resulting technology 70

87. 71 Workshopping current processes and requirements Iterative improvements to user interface prototypes Process refinement through visual storyboarding business 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 Key Don't underestimate the value of face-to-face conversations Leveraging web 2.0 for responsive communication (a vehicle for getting quick feedback and collaboration) Project blogs Project status, Lessons learned, Comments, Criticisms and Discoveries Announcements Milestones, Blog posts, Media releases, Locations for system prototypes and Locations of solutions to review comment share Critique 73

90. Communicate - formally or informally Formal group workshops card sorting personas collaborative design individuals contextual inquiry interviews surveys/questionnaires prototype testing Informal over coffee over lunch 74

91. Twitter 75

92. Flickr Photographs demonstrating engagement with stakeholders 76

93. Delicious Sharing 'discoveries' 77

94. Dopplr Sharing project milestones Calendar/workshop dates 78

95. Wikis Benchmark project documentation Iterate project documentation Store for stencils, prototypes and templates Features to manage projects User sign-ons Version control Roll-backs Audit trails 79

96. Agile governance Report lessons Out of each major iteration When reaching major milestones Obtain sign-off/approval When major solution components are identified To pass major milestones When new user-groups are identified and require involvement in requirements/validation Major scope changes 80

97. How to budget for Agile Kernel/contingency project model? How many parallel iterations? How many people What process What practices Payment on first iteration then delivery of each subsequent identified 'feature‘ Payment decisions/perceived value Assessment of time/materials/iteration requirements 81

98. So what is agile really about and how can we use it on our projects? 82

99. One size does not fit all Not all projects (or iterations) are suited to Agile techniques Agile doesn’t fix every problem Agile doesn’t work on every project Choose the right combination of techniques Look for opportunities to be more agile Analysis techniques are important, but as a means to actively elicit information rather than document Constant evolution of process can be difficult 2 steps forward, 1 step back Avoid stagnation Verbal communication and interpersonal skills become more important in co-located team environments Training and mentoring are the key 83

100. Work smarter Become creative with the documentation we do create Leverage existing practices within your teams/divisions Leveraging existing expertise Leverage existing knowledge 84

101. Pass on learnings Add through issues logs Risks Scope changes Knowledge gained Capturing resourcing requirements per iteration Pass on experience 85

102. Next Steps 86

103. Workshops Presentation will be available on slideshare QRG (quick reference guide) is being developed and will be available Workshops with teams Work through project issues real cases and situations One-on-one coaching Tailor training requirement to individual team needs and level of familiarity with agile 87