• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile pm v2
 

Agile pm v2

on

  • 1,627 views

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.

Statistics

Views

Total Views
1,627
Views on SlideShare
1,494
Embed Views
133

Actions

Likes
3
Downloads
67
Comments
1

1 Embed 133

http://www.scoop.it 133

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Thanks for the very focused approach
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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)

Agile pm v2 Agile pm v2 Presentation Transcript

  • Agile Project Management
    Maria Horrigan and Matthew Hodgson
    Senior Consultants
    SMS Management and Technology
    1
  • 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).
  • 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
  • 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.
  • 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
  • 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?
    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
  • 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
  • What is Agile?
    10
  • When we think about ‘agile’ it is..
    Light
    Fast moving
    Nimble
    Flexible
    Iterative
    Changes direction easily
    like a Cheetah
    11
  • What ‘agile’ is not
    Slow moving
    Hard to move/change direction
    Heavy
    Laborious
    like an Elephant
    12
  • 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 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
  • 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
    Complex
    Chaotic
    Unstructured
    • About 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 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)
    16
  • (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
  • 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
  • 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
  • Reaction against Waterfall
    20
    • 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?!
  • 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
    21
  • 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
  • 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
  • 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
  • Agile Today
    25
  • 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
  • Scrum, FDD, XP
    Agile Methodologies
    Project Management
    Engineering
    FDD
    Scrum
    XP
  • Early Agile Case studies
    Case 0: Daimler Chrysler Chrysler Comprehensive Compensation System (C3) payroll project
    28
  • 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
  • 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
  • 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
  • Scrum: Roles
    • Alternative 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 Owner
    • Alternative 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 Master
    • Alternative 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: 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
  • 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
  • and there are others . . .
    Crystal Methods
    Dynamic Systems Development Method (DSDM)
    Lean Development (LD)
    Adaptive Software Development (ASD)
    ... etc ...
    35
  • 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
  • Why Agile?
    37
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Cost to Change Curve
    $
    $
    Cost of Change
    $
    $
    $
    Lifecycle Stage
  • 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
  • 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
  • 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
    CostEffort of development
    Governance framework, funding model
    Uniqueness
  • The Agile Lifecycle
    Planning and Analysis
    Effort
    Time
    Project Duration
  • 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
  • Agile is a standards based approach
    50
  • 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
  • User centered design
    52
  • 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
  • User Involvement
    Agile characteristics to promote user involvement
    Frequent “releases”
    Daily stand up
  • Analysis of Business and User Needs
    55
  • 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 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
  • 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
  • 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
  • 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
  • Misconception that agile = no documentation and no rigour/discipline
    61
  • 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
  • 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
  • Stand-up meetings
    Risks
    Scope
    Change management
    Reporting
    64
  • 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
  • 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
  • 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
  • 68
  • 69
  • 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
  • 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
  • 72
  • 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
  • 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
  • Twitter
    75
  • Flickr
    Photographs demonstrating engagement with stakeholders
    76
  • Delicious
    Sharing 'discoveries'
    77
  • Dopplr
    Sharing project milestones
    Calendar/workshop dates
    78
  • 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
  • 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
  • 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
  • So what is agile really about and how can we use it on our projects?
    82
  • 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
  • Work smarter
    Become creative with the documentation we do create
    Leverage existing practices within your teams/divisions
    Leveraging existing expertise
    Leverage existing knowledge
    84
  • Pass on learnings
    Add through issues logs
    Risks
    Scope changes
    Knowledge gained
    Capturing resourcing requirements per iteration
    Pass on experience
    85
  • Next Steps
    86
  • 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