Your SlideShare is downloading. ×

Agile pm v2


Published on

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.

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.

Published in: Technology, Business
1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • 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."
  • 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)
  • Transcript

    • 1. Agile Project Management
      Maria Horrigan and Matthew Hodgson
      Senior Consultants
      SMS Management and Technology
    • 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
      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?
    • 8. What about the Sydney Opera House?
      Est$425M to build
      Actual $2435M
      Est1965 due date
      Actual 1973 first opened
      Changed the face of Sydney Harbour
      Most iconic, recognised symbol of Australia
      Leading edge engineering invented
      Revolutionised pre-fabrication
    • 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.
    • 10. What is Agile?
    • 11. When we think about ‘agile’ it is..
      Fast moving
      Changes direction easily
      like a Cheetah
    • 12. What ‘agile’ is not
      Slow moving
      Hard to move/change direction
      like an Elephant
    • 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”.
    • 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.”
    • 15. What Agile “IS and ISN’T”
      Agile Isn’t
      Agile Is
      A “Silver Bullet” solution
      An excuse for poor requirement definition
      An excuse for poor design
      An excuse for reducing quality
      About failure to control the scope of a project, its about managed change
      Doing more with fewer people
      Doing more with less resources or budget
      • About 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
      • 21. Managed iterations
      • 22. Responding to business changes
      • 23. Managing change
      • 24. Simple, fast and efficient
      • 25. Based on industry best practice
      • 26. Disciplined and structured
    • Agile is a lot like life
      Things change
      We adapt
      We learn from our mistakes (hopefully)
      When one thing doesn't work we then try something else (mostly)
    • 27. (Application of) Agile as a philosophy
      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
    • 30. Reaction against Waterfall
      • 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?!
    • Waterfall
      Sequential process
      “Analysis Paralysis”
      One iteration
      Long timeframes
      Doesn’t cater for changing business environment.
      linear process
      little flexibility
      limited ability to cope with change
    • 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
    • 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!
    • 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
    • 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
    • 38. Early Agile Case studies
      Case 0: Daimler Chrysler Chrysler Comprehensive Compensation System (C3) payroll project
    • 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
    • 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
    • 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
    • 42. Scrum: Roles
      • Alternative Name: User, Customer
      • 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 Owner
      • Alternative 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 Master
      • Alternative 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: 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.
    • 51. and there are others . . .
      Crystal Methods
      Dynamic Systems Development Method (DSDM)
      Lean Development (LD)
      Adaptive Software Development (ASD)
      ... etc ...
    • 52. Commonalities
      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'
    • 53. Why Agile?
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
      CostEffort of development
      Governance framework, funding model
    • 64. The Agile Lifecycle
      Planning and Analysis
      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
    • 66. Agile is a standards based approach
    • 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
    • 68. User centered design
    • 69. Context
      Good Requirements (IEEE definitions)
      Set is complete
      Set is consistent
      Set is modifiable
      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
    • 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
    • 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
    • 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
    • 76. Other Practice from many other sources
      Use Cases
      Iterative approach
      Waterfall approach
      User Stories
      Process Maps
      Card Sorting
      Non-functional HTML prototypes
      Fully-functional prototypes
      Contextual inquiry
    • 77. Misconception that agile = no documentation and no rigour/discipline
    • 78. A "place-holder" for conversations
      Story cards
      Interaction design maps
      Card sorting
      Conversations become formalised to tell the story for those who follow
      User requirements
      Business requirements
      System requirements
    • 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
    • 80. Stand-up meetings
      Change management
    • 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
      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
      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
    • 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
      Milestones, Blog posts, Media releases, Locations for system prototypes and Locations of solutions to
    • 90. Communicate - formally or informally
      group workshops
      card sorting
      collaborative design
      contextual inquiry
      prototype testing
      over coffee
      over lunch
    • 91. Twitter
    • 92. Flickr
      Photographs demonstrating engagement with stakeholders
    • 93. Delicious
      Sharing 'discoveries'
    • 94. Dopplr
      Sharing project milestones
      Calendar/workshop dates
    • 95. Wikis
      Benchmark project documentation
      Iterate project documentation
      Store for stencils, prototypes and templates
      Features to manage projects
      User sign-ons
      Version control
      Audit trails
    • 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
    • 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
    • 98. So what is agile really about and how can we use it on our projects?
    • 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
    • 100. Work smarter
      Become creative with the documentation we do create
      Leverage existing practices within your teams/divisions
      Leveraging existing expertise
      Leverage existing knowledge
    • 101. Pass on learnings
      Add through issues logs
      Scope changes
      Knowledge gained
      Capturing resourcing requirements per iteration
      Pass on experience
    • 102. Next Steps
    • 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