Bpm Camp Prashant Agile

Uploaded on

Prashant Gadgil's presentation on an agile case study.

Prashant Gadgil's presentation on an agile case study.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
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


  • 1. Applying Agile Methods in BPM Development A Case Study Prashant Gadgil
  • 2.
    • Project setting
    • How did we do it?
    • What were the results?
    • How did they compare to other projects?
    • Commitments from management?
    Agile in BPM Outline
  • 3.
    • First pilot process implementation in BPM Initiative
      • High visibility across company
      • Success very critical for first deployment
    • Age-old paper based process to be implemented in TW
      • Big Change Management for Business Users
    • Company/Division in one building
      • All business and technical folks located in same building
      • 20 Business Users
    • Time and Resource bound
      • 3 months due to budget constraints
    Agile in BPM Project Setting
  • 4.
    • Agile vs Waterfall
      • Individuals and interactions over processes and tools
      • Working software over comprehensive documentation
      • Customer collaboration over contract negotiation
      • Responding to change over following a plan
    Agile in BPM Agile Methodology
  • 5.
    • Collocation:
      • Project team co-located in a big conf room for 3 months
      • 2 Business Owners, 1 Data Modeler, 1 QA, 1 Agile Consultant, 2 BPM consultants, 2 Java Developers, Project Manager in same room
    Agile in BPM How did we do it?
  • 6.
    • Requirements and Estimation:
      • Business users walked us through one instance of the current real-life process
      • White boards, Paperboards photos, Verbal discussions, Wall stick-ons were the main source of requirements documenting process
      • High level Business requirements bulleted on whiteboard by process owner
      • Developers estimated the effort for each bullet in terms of points (0.5 developer-day = 1 point)
      • Project Wiki was the common place to store any electronic design docs, assumptions, bugs etc.
      • Talk face to face - No time wasted in emailing/calling back and forth on requirements
    Agile in BPM How did we do it?
  • 7.
    • Iteration Planning:
      • 5 iterations of 2 weeks each in a 3 month project
      • Iteration Cycle:
        • 7 Days: Development,
        • 2 Days: QA/bug fixing,
        • 1 Day: Iteration playback to Management
      • Time bound milestones with developer estimates allowed process owner to prioritize requirements for that iteration
      • 15 min stand-up (literally) meeting at 9 AM every day to update everybody on progress, no need for project progress reports
      • Milestone – Demo of working process model after each iteration
    Agile in BPM How did we do it?
  • 8.
    • Development
      • Data Architect immediately approved/designed any data tables to fit corporate naming conventions etc.
      • Any coach/process playbacks/POCs validated with business users immediately before commencing detailed implementation
      • Project “Velocity” increased from 25 points/week to 50 points/week, iteration was planned for ~50 points worth of requirements
      • Business owner called actual business users as and when needed to show quick mini-playback for feedback
      • What you see is what you will get:
        • No time wasted in writing and reading long requirement docs
    Agile in BPM How did we do it?
  • 9.
    • QA
      • QA was always up-to date on desired functionality due to on-going room discussions.
        • Very concise documentation of test cases, if any
      • Deployment to QA environment every 3 days
        • Partial testing in parallel
      • Bugs found fixed in next push to QA
    Agile in BPM How did we do it?
  • 10.
    • Go Live:
      • Business users daily or weekly saw the screens as they were being developed
      • No surprises to business after deployment to production
      • Deployment was a huge success with only minor data related hiccups
      • Very successful first deployment
        • Business saw the tangible dollar-savings and other benefits of BPM they could not imagine with their older process
    Agile in BPM How did we do it?
  • 11.
    • Key Success Factors:
      • Process owner deeply involved in day-to-day project work, in addition to her day job
      • Actual End users (not just those familiar to process) had played back the process end-to-end “ hands-on” many times long before it went to production
      • Physically collocation boosted team-effort
        • Go TeamWorks !
    Agile in BPM How was it different than my other projects?
  • 12.
    • Commitment From Management
      • Dedicated a conf room for 3 months to such a critical project
      • Allowed other meetings to adjust to give priority to this project work.
      • Allowed various team members to work in this room instead of from their regular department areas
    Agile in BPM Commitments from Management