The document describes an agile project to implement a business process using BPM (Business Process Management). Key points: 1) An agile methodology was used with daily standups, 2-week iterations, and demos after each iteration. Requirements were documented on whiteboards. 2) Collocating the entire project team in a conference room facilitated communication and rapid feedback. 3) Involving end users throughout helped validate the process model before deployment. The first deployment was successful with only minor issues.

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