• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Powerpoin
 

Powerpoin

on

  • 959 views

 

Statistics

Views

Total Views
959
Views on SlideShare
959
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • We used to spend months planning out large projects in detail, gathering the business requirements, analyzing everything, working with the clients to plan out all the system requirements in detail. An example of the project documents we would create for one single project
  • Clients would meet with the project leader to sign off on a complete set of project requirements before development work could commence Once the project proposal was signed it was a formal process to change a requirement Analysis of a process is not a perfect science, if anything was missed it, adding affected the whole project schedule The weighty tomes of project documents we’d created weighed us down, how could we respond to change and still deliver everything we’d promised in the timeframe allotted?
  • Clients would meet with the project leader to sign off on a complete set of project requirements before development work could commence Once the project proposal was signed it was a formal process to change a requirement Analysis of a process is not a perfect science, if anything was missed it, adding affected the whole project schedule The weighty tomes of project documents we’d created weighed us down, how could we respond to change and still deliver everything we’d promised in the timeframe allotted?
  • The client and the development team were disconnected, the project lead was charged with brokering all communications at the start of the project As the project progressed the team would enter specific process questions into our change tracking system, the customer and/or their staff would receive an email from the generated from the system with the developer’s question, by responding to that email the developer would get the answer and either write back or proceed with the change No team dynamic was involved, the clients rarely met the developers, they were faceless names and occasionally a disembodied voice on a conference call They seemed very nice, but who were they? How could we have a team dynamic when the client didn’t know who was on the team?
  • The client and the development team were disconnected, the project lead was charged with brokering all communications at the start of the project As the project progressed the team would enter specific process questions into our change tracking system, the customer and/or their staff would receive an email from the generated from the system with the developer’s question, by responding to that email the developer would get the answer and either write back or proceed with the change No team dynamic was involved, the clients rarely met the developers, they were faceless names and occasionally a disembodied voice on a conference call They seemed very nice, but who were they? How could we have a team dynamic when the client didn’t know who was on the team, and
  • The team would meet every so often and be assigned independent tasks, then return to their office down the hall or on another floor of the building Communication on key questions would be brokered by the project leader, causing more bottleneck issues and capping the creativity of the team We needed to break down the barriers to communication We sent a lot of email, then tried instant messages, then moved on to the XP style of programming with 2 people at one computer for some of the larger design tasks We found our most creative solutions came from project meetings that had a good discussion which turned into a design meeting with all members present in the room, we needed more of the group dynamic so the whole team could build on each other’s ideas
  • As project leaders we spent all our time figuring out what work to do, documenting it, then tracking work in progress, and documenting that too, doing masses of paperwork than adding value to the project Change required following a formal change management process. We were the contact between the team and customer for all decisions, changes and requests, and working on multiple projects meant we could be the bottleneck. No, waste removal doesn’t mean removing the project leader It means removing any processes that aren’t adding value, did we really need all those documents we spend all our time keeping up to date? There had to be a better way to track progress and respond to the changes we knew would be requested. Since we have a chainsaw analogy, let’s use that for our team. We needed to chop down the walls between our team, our disconnected setup was a barrier to communication and sharing ideas to design better solutions
  • - The requirements change as we’re writing the systems. How can we stay on top of never ending changing requirements?
  • - The requirements change as we’re writing the systems. How can we stay on top of never ending changing requirements?
  • Yes, there is a better way to manage projects, the Agile project methodology There are a few variations of Agile project managements techniques, we chose scrum (like a team huddle in sports) Here’s how agile differs from the traditional approaches, I’ll walk you through one of our projects that we ran scrum style, from beginning to end
  • “These are the people in your neighborhood” The project kickoff involved the client and all members of the development team, everyone met face to face Everyone gets to know each other, it’s a good foundation for building a relationship between the client and team The kickoff meeting takes a whole day, the morning focus is on the project, the afternoon focus is on how to deliver what’s needed The project backlog would be created, a team agenda for what tasks need to be completed, in what order to deliver the product
  • “These are the people in your neighborhood” The project kickoff involved the client and all members of the development team, everyone met face to face Everyone gets to know each other, it’s a good foundation for building a relationship between the client and team The kickoff meeting takes a whole day, the morning focus is on the project, the afternoon focus is on how to deliver what’s needed The project backlog would be created, a team agenda for what tasks need to be completed, in what order to deliver the product
  • We used to try various estimation techniques to determine what we could deliver in the time allotted for the project Everyone’s natural inclination is to gear their estimate to the time available Each and every one of our estimation techniques failed, and took a lot of time to figure out how to do Now with scrum we forecast one month of work at a time, the client is involved in analyze upcoming tasks as required

Powerpoin Powerpoin Presentation Transcript

  • Agile Project Management Using Scrum Presented by: Dave Hallett & Ruth Butlin Queen’s University, Information Technology Services
  • Background on Speakers
    • Dave Hallett
      • 15 years software development experience
      • MBA, Info Technology Mgnt
      • Agile Alliance Member
      • CSM
      • Manager, University Information Systems, ITS
    • Ruth Butlin
      • 10 years software development experience
      • Agile Alliance Member
      • CSM
      • Manages all student systems activity, mainframe and e-business
      • Senior Systems Specialist, University Information Systems, ITS
  •  
  • Background on ITServices
      • ~100 FTE staff
  • Background on ITServices
      • 5 Main Departments
        • University Information Systems
        • Servers, Operations
        • Support Services
        • Campus Telecom & Networks
        • Sales & Service
  •  
  • Background on UIS
        • 3 DBA, application server admins
        • 14 Internet app developers
        • 7 Mainframe developers
        • 1 Manager
  • Background on UIS
      • Student, HR, Finance,
      • eBusiness, Portal,
      • Contract programming
  • Objectives for Today
  • Objectives for Today
    • What are we trying to manage?
      • Projects and ongoing support at Queen’s
  • Objectives for Today
    • What’s the problem ?
      • Why traditional PM strategies didn’t work for us.
  • Objectives for Today
    • Why choose “Agile”?
      • Transparency, flexibility
      • Short-term predictability
      • Long term vision
  • What are trying to manage? UIS Activity And now some pan-ITS projects
  • UIS Activity
    • 25 year old mainframe applications
      • Ongoing list of change requests
      • Requirements for significant enhancements (i.e. differential fee increases)
  • UIS Activity
    • eBusiness applications
      • 20+ new applications in last 4 years
  • UIS Activity
    • Portal development
      • Coordinating multiple campus interests
  • UIS Activity
    • Contract programming
      • Setting expectations when billing for development services
  • What’s the Problem? Why Have Traditional Project Management Strategies Failed Us?
  • Overplanning
    • Project proposal
    • Project plan
    • Use cases
    • Workflow diagrams
    • MS Project
      • Gantt charts & WBS
    • Risk Minimalization checklist
    • Project status reports
    • Project close report
  • Locked in
    • Clients sign off on a complete set of project requirements before development begins
  • Locked in
    • Timetable is set after requirements gathered
  • Locked in
    • Then
    • Systems analysis
    • &
    • system design occurs
  • Locked in
    • Change requires formal
    • Change Request
  • Locked in
    • Client now waits for delivery of the product they want
  • Locked in
    • Not the necessarily the product your team is building
  • The invisible team
    • Client and development team are disconnected
  • The invisible team
    • Client explains requirements to Project Manager
  • The invisible team
    • Project Manager explains requirements to developers
  • The invisible team
    • Developer questions go back through Project Manager
  • The invisible team
    • Project Manager asks question of client
  • The invisible team
    • Client explains answer to Project Manager
  • The invisible team
    • Project Manager explains answer to Developers
  • The invisible team
    • Developers translate requirements into code
    • Meanwhile…
  • The disconnected team
    • Project Manager
    • assigns tasks
    • to developers
    • with timetable
  • The disconnected team
    • Developers
    • work independently,
    • asking occasional questions
  • The disconnected team
    • Testing and integration planning happened independently
    • (if it happened)
  • Waste removal
    • Project plans that try to capture every feature in advance
  • Waste removal
    • Fantasy Gantt charts that predict what we will be working on 173 days from now
  • Waste removal
    • Non-synchronized
    • teams
    • &
    • clients
  • Why choose Agile?
      • Transparency, flexibility
      • Short-term predictability
      • Long term vision
  • Why choose “Agile”?
  • Why choose “Agile”?
    • “It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change .”
    - Charles Darwin, The Origin of Species
  • Agile with Scrum
    • “ When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.”
    • Process Dynamics, Modeling, and Control, Ogunnaikeand Ray, Oxford University Press, 1992
  • Defined Process vs. Empirical
    • Defined Process Management
    • Great for known activity
  • Defined Process vs. Empirical
    • Not great for unknown activity
    $7 million budget $120 million final
  • Agile Project Methodology
    • Empirical management & control process
  • Agile Project Methodology
    • Inspect and adapt feedback loops
  • Agile Project Methodology
    • Used to manage complex projects since 1990
  • Agile Project Methodology
    • Delivers
    • business functionality
    • in short iterations
  • Agile Project Methodology
    • Scalable to
    • distributed, large, and long projects
  • Agile Project Methodology
    • CMM Level/3
    • and
    • ISO 9001 compliant
  • Agile Project Methodology
    • Extremely simple
    • but
    • very hard
  • Agile Project Methodology
    • Trade-off
    • Less Predictable Outcomes
    • vs.
    • False Confidence
  • Agile Project Methodology
    • Extreme Programming
    • Evo
    • Iterative Development
    • Feature Driven Development
    • Lean Development
  • Agile Project Methodology
    • Scrum
    • Scrum recognizes that…
    • Scrum
  • Agile With Scrum
    • We are skilled problem solvers,
    • experts at devising long-lasting solutions.
  • Agile With Scrum
    • The problem in our profession
    • is not process or technology …
    • it is people and dysfunctional interactions .
  • Agile With Scrum
    • It can only be solved
    • person by person
    • Scrum provides the mechanism
    • for making the people and process problems apparent so they can be solved.
  • What is Scrum Methodology?
      • Business Vision
      • Project Backlog
      • Sprints/Iterations
      • Daily Communication
      • Frequent Demonstrations
  • What is Scrum
    • Scrum is a very simple process:
      • a management technique
      • encompasses almost any good engineering technique
      • a relatively small set of interrelated practices and rules,
      • is not overly prescriptive,
      • can be learned quickly and
      • is able to produce productivity gains almost immediately.
  • What is Scrum
    • Scrum focuses an organization on:
      • building successful products
      • delivering useful features at regular intervals
      • expecting requirements, architecture, and design changes
  • Waterfall project management Planning Analysis Design Coding Testing Performance User Acceptance Pilot Live Time
  • Scrum Project Management *Scrum refers to the Product Backlog and Product Owner – ITS will refer to the Project Backlog and Project Owner to lessen the commercial tone of the methodology
  • How do you do Scrum?
  • Understanding Roles
    • Create a Project Team
    • 3 sets of Roles
  • Understanding Roles
    • Project Owner
    • Scrum Master (Project Manager)
    • Scrum Team
  • Understanding Roles
    • Project Owner
    • Owns the vision
    • Owns the priorities
  • Understanding Roles
    • Scrum Master (Project Manager)
    • Protects the team from interference
    • Ensures daily team communication
    • Further defines next deliverables
  • Understanding Roles
    • Scrum Team
    • Owns the sprint tasks
    • Self assigns tasks
    • Can add to sprint
    • Demonstrates product
  • Project kickoff
    • Start Project with a
    • Full Day Kick Off Meeting
  • Project kickoff
    • ½ Day with Project Owner
    • Project Vision & Deliverables Backlog
  • Project kickoff
    • ½ Day with Scrum Team to
    • organize plan estimate
  • Project kickoff
    • Output is Product Backlog
    • List of deliverables
    • High-level dependencies
    • Effort estimate
  • Project Backlog
    • Owner Prioritizes backlog deliverables according to Business Value
  • Sprint Backlog
    • Team
    • selects deliverables they can deliver in calendar month
  • Sprint Backlog
    • Scrum Master (Project Leader)
    • Communicates current sprint deliverables
    • Chairs daily meeting
    • Addresses obstacles
    • Schedules demonstration
    • Further defines deliverables for next sprint
  • Daily Scrums
    • Daily 15 minute status meeting;
    • Same place and time every day;
    • Three questions;
      • What have you completed since last meeting?
      • What will you complete before next meeting?
      • What help do you need?
    • Any decisions to be made?
  • Monthly Demonstration
    • The Team presents
    • “ Production quality” features to Owner
    • Unfinished/Next items are discussed
  • Scrum Process
  • Why Chose Agile/Scrum Development?
    • Know where you are every day with Scrum
    • - or -
    • Think you know where you are on your well-formed plan
    • and discover that you are very wrong, very much later
        • Minimum Process, Maximum Value
  • Agile/Scrum Benefits?
    • Promote rapid delivery of value to customers
    • Provide timely and regular visibility of the solution to customers, product owners, and stakeholders
    • Deliver increases in productivity, quality & ROI for software development organizations
        • Minimum Process, Maximum Value
  • What project management paradigms are we breaking? Agile vs. Plan-Driven Development
  • The Agile Paradigm Shift Constraints Estimates Requirements Schedule Cost Schedule Cost Features Plan Driven Value /Vision Driven The Plan creates cost/schedule estimates The Vision creates feature estimates Waterfall Agile
  • Scope vs. Schedules
    • Everyone remembers a
    • schedule slip,
    • but almost no one
    • remembers a scope slip.
  • How is it working at Queen’s UIS?
  • Scrumming at UIS
    • Student Information Systems maintenance requests
      • ~100 open maintenance requests
      • Monthly updates between UIS PM & Assoc. Registrar
      • Reprioritize list monthly according to most important and feasible.
  • Scrumming at UIS
    • Faculty of Education – Continuing Ed Registration System
      • One year planning
      • Two years development with twice a year releases
      • Switched to billable Monthly Sprints in Jan 2006
      • Prioritize deliverables every month
      • Release to production monthly
      • “ Finally, I’m getting the system I want” ConEd Dir
  • Scrumming at UIS
    • Awards Office – Application for Financial Aid
      • Given limited time window to build enhancements
      • Assoc Registrar prioritized first Student then Admin priorities
      • Time dictated deliverables.
      • At the end of each of three Sprints, functioning code was put into production.
      • Client happy with delivered products (not so happy with time allotted.)
  • Scrumming at UIS
    • Library Portal Channels – 6 channels identified for September release
      • Initial meeting with several librarians & UIS dev’s
      • Approximate effort assigned to each channel
      • Asked library to focus on one at a time
      • First channel will be ready this month
  • Scrumming at ITServices
    • JES Implementation – implement new mail, calendar, portal, SSO…
      • September goal
      • Three ITS units (Servers, UIS, Support Services)
      • Moved from managing >175 lines of Gantt chart to ~35 lines in Excel
      • Difficulty getting norms
  • Scrumming at ITServices
  • Scrumming at ITServices
  • Difficulties?
  • Difficulties?
    • Change is difficult
      • Clients initially reacted against frequent meetings
      • Team members react against daily meetings
      • Team members react against co-locating for work
    • Identifying Impediments is threatening
      • Daily meetings highlight impediments
      • Some impediments are cultural
      • Some impediments systemic
  • Pay Off?
  • Pay Off?
    • Improved Productivity
    • Better Communication
    • More Predictable Results
    • Better Team Interaction
    • Better Code
    • More Frequent Deliverables
    • Happier Clients
  • Additional Sources
    • http://wiki.its.queensu.ca/display/UIS
    • http://www.agilemanifesto.org
    • http:// www.agilealliance.org
    • http://www.scrumalliance.org
    • http:// pmdoi.com
    • http:// www.jimhighsmith.com
    • Agile Project Management with Scrum by Ken Schwaber
    • Agile & Iterative Development - A manager’s guide by Craig Larman
    • Agile Project Management by Jim Highsmith
    • Servant Leadership by Robert K Greenleaf
    • Extreme Programming by Kent Beck
    • Lean Software Development by Mary and Tom Poppendieck
  • Thank You! Questions? [email_address] [email_address]