Your SlideShare is downloading. ×

Agile and ToC - Case Study

3,318
views

Published on

This lecture was given by me during the latest PMI 2010 Conference - the annual event of the Project Management Community in Israel. …

This lecture was given by me during the latest PMI 2010 Conference - the annual event of the Project Management Community in Israel.
It outlines a case study we performed in utilizing Theory Of Constraints best practices in the macro level of a complex, multi-site project and Agile best practices in the micro-level of the various teams

Published in: Technology, Business

1 Comment
4 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,318
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
16
Comments
1
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Agile & ToC
    Size Does Matter
    Aviram Eisenberg
    Ignite
  • 2. Size Does Matter!
    Place Holder for a Joke on:
    Size Does Matter!
  • 3. About Ignite
    A SW Development Management company
    Expertise in Project Management
    Expertise in SW Development methodologies
    Agile/Scrum
    TOC
    Lean/Kanban
    Customized flavor
    Expertise in Global Delivery models
    Distributed development
    Senior onsite Israeli R&D managers
    Offshore centers in Ukraine, Belarus, Russia and Mexico
  • 4. One Size Doesn’t Fit All
    Agile has very good best practices for SW dev
    Agile is best suited for:
    New project development
    Single, co-located homogeneous team
    Projects that has some level of freedom
    Projects that has some level of customer collaboration
    Agile and TOC
    For complex projects
    Multi-teams
    Multi sites
    Low level of freedom
  • 5. Agile Highlights
    Claims that SW development is a spiral process hence waterfall model is usually not effective
    Develop in short iterations (sprints) that contain that each contain the spec analysis, estimations, design develop and testing
    Working software must be delivered at each iteration
    Due dates are fixed, scope can be changed
    Pareto: 80% of SW value comes from 20% of the features
    Customer collaboration – prioritization of backlog
    User stories vs. system specifications
    Self Organizing teams
    Test Automation
    Continuous integration – code cannot break!
  • 6. Agile – take 1
    Planning I0
    Task 1
    Task 2
    Testing
    Planning I1
    Task 3
    Task 4
    Testing
  • 7. Agile – take 2
    Planning I0
    Task 1
    HL Planning
    Task 2
    Testing
    Integration
    Integration
    Planning
    Planning I1
    Testing
    Task 4
    Task 3
    Testing
  • 8. TOC Highlights
    Improve throughput of complex projects
    Identify and protect the critical chain
    The TOC process:
    Identify the system’s constraint(s)
    Decide how to exploit the system’s constraint(s)
    Subordinate everything else to the decision in step 2
    Solve the system’s constraint(s)
    Return to step 1 if the system’s constraints were changed
  • 9. TOC Highlights
    Plan all activities according to 50% probability estimations – Parkinson’s Law
    Add time buffer at the end of each path (feeding/project buffers)
    Add resource buffers to assist on bottlenecks
    Avoid multitasking along the critical chain
    Monitor buffer consumption as opposed to task schedule
  • 10. TOC
    Architecture
    Design
    Task 1
    Task 2
    Testing
    Design
    Task 3
    Design
    Design
    Design
    Design
    Integration
    Integration
    Task 4
    Testing
    Task 4
    Testing
    Task 4
    Testing
    Task 4
    Management
  • 11. TOC
    Architecture
    Architecture
    Architecture
    Architecture
    Architecture
    Design
    Task 1
    Task 2
    Testing
    FB
    Design
    Task 3
    FB
    Integration
    PB
    Task 4
    Testing
    Resource Pool
    Management
  • 12. TOC vs Agile
  • 13. Statistics
    The standard stats:
    More than 60% projects fail to meet budget and due date objectives by more than 200%
    30% of projects are cancelled
    70% fall short of scope
    Agile stats:
    99% chance to meet due date
    Better quality software
    Improved customer satisfaction
    TOC:
    10% to 50% improvement on throughput
    90 to 95% chances to meet due date and budget
  • 14. Agile or TOC
    So, Agile or TOC?
    It depends on project characteristics
    Why not use both?
  • 15. TOC with Agile
    Planning I0
    Iteration 0
    FB
    Task 1
    HL Planning
    Task 2
    Testing
    Integration
    Integration
    Planning
    Integration
    PB
    Planning I1
    Testing
    Iteration 1
    Iteration 1
    Task 4
    Task 3
    Testing
  • 16. Agile-ToC Simulation
    Let’s Start with the Simulation!
  • 17. The Project
    Company A has a major project: developing a new module: “Zubora”
    The company has 12 months and 40 people for this mission
    The teams are distributed:
    15 people in Ukraine: 12 testing engineers and 3 UI developers with low experience
    20 in US: 2 team leaders, 12 developers, 3 DBAs, 3 testing engineers
    5 in Israel: developers + highly experienced UI engineers
  • 18. The Challenge
    There are 10 potential customers for this new module in the coming year
    Many RFPs talking about features that would be enabled by the new module
    Prioritization is tough
    The market is quite new
  • 19. Observations
    We have a hard stop after 12 months
    Throughput is critical (isn’t it always???)
    Prioritization is tough
    We have to complete the full scope on time
    Teams are distributed all over the globe
    Creates a lot of waste due to excessive communication
    Time zone differences: longer decision/resolution time = waste
    Market is new = changes will come
  • 20. Delivery Model
    Team 1
    US: DBA+Server Side
    US: Testers
    UKR: Test Engineers
    Team 2
    US: DBA+Server Side
    US: Tester
    UKR: Test Engineers
    Team3
    ISR: UI Developers
    UKR: UI Developers
    UKR: Test Engineers
    Team 4
    UKR: System Testers
  • 21. Agile & ToC
    T1: Infrastructure
    T1: Infrastructure
    T1: BL
    FB
    FB
    T2: BL
    T2: BL
    FB
    T2: BL
    FB
    Release
    Planning
    PB
    T3: UI
    T3: UI Infra
    T3: UI
    T3: UI
    All:Tests
    UI Design
    UI Design
    UI Design
    FB
    FB
    FB
    T4: System
    Tests
    T4: System
    Tests
    FB
    Resource Pool
  • 22. Things We Take from Agile
    Incremental Development (sprints)
    Agile Estimation
    Early integration cycles
    Embedded QA
    Continuous Integration
    Just enough design
    Just enough documentation
    Customer engagement
  • 23. Things We Take from TOC
    High Level Planning Principles
    Optimistic estimates planning
    Critical Chain Management
    Buffer Management (with Agile twist)
    Bottleneck monitoring and resolution
  • 24. What Do We Do If
    Sprint scope is only 50% done
    This is natural and integrated into the plan
    BL/Infra teams are falling behind schedule
    We add sprints, consuming feeding buffers
    Design team is falling behind schedule
    We add sprints, consuming feeding buffers
    Prioritization is changed
    Move stories from one sprint to another, across all teams
    Change requests are added
    Remove lower priority stories or extend the project
    UI team falls behind schedule
    Utilize resource pool as much as possible
    Add sprints and consume project buffer
  • 25. Q&AAviram EisenbergIgnitewww.igniteoutsourcing.comaviram@IgniteOutsourcing.com
    Q&AAviram EisenbergIgnitewww.igniteoutsourcing.comaviram@IgniteOutsourcing.com