Agile Development Techniques for BPM Initiatives

Agenda

• Introductions

• Agile Adoption

• Agile Values

• Agile Principles for BPM

• Keys to Success

Introductions• InfoZen

– History• Founded in 1995• SBA Certified Small Business • Profitable Since Inception• 57% annual average revenue growth over last 3 years

– Offices/ Locations• Headquarters in Rockville, MD• Top Secret facility clearance• Secure Data Center• Other offices: Columbia, MD, Colorado Springs, CO, Glynco, GA• SCIF

– Staff• 175+ persons • Security Threat Assessment & Fraud Detection • 75% of staff hold security clearances

• Alain Kouyate– Chief Technology Officer– alain@infozen.com

Informal Survey

• How many people have read the manifesto (at least once)?

• How many people have been part of at least one Agile Development Project?

• How many people have institutionalized Agile in their shop?

Agile Successes Surveys

Results from Scott Ambler’s February 2008 Agile Adoption Survey posted at www.agilemodeling.com/surveys642 respondents-

3%6%

14%

48%

29%

Much Lower

Somewhat Lower

No Change

Somewhat Higher

Much Higher

How Have Agile Approaches Affected the Quality of Systems Deployed?

3% 4%

15%

47%

31%

Much Lower

Somewhat Lower

No Change

Somewhat Higher

Much Higher

How Have Agile Approaches Affected the Business Stakeholder Satisfaction?

Compelling Statistics

• 35 percent of requirements change throughout the software lifecycle (Jones, C. 1997. Applied Software Measurement. McGraw Hill.)

• 45 percent of delivered features are never used. (Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.)

• 82 percent of projects cited incomplete and unstable requirements as the number one reason for failure. (Thomas, M. 2001. “IT Projects Sink or Swim.” British Computer Society Review.)

• Large projects, those costing more than $10 million, are successful exactly zero (0) percent of the time. (Johnson, J. 1999. “CHAOS Into Success.” Software magazine.)

Review of Agile Values

• 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 Principles

• 3 out of 12 Principles

– Business people and developers must work together daily throughout the project.

– Welcome changing requirements, even late in development.

– Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.

• What are the implications for BPM vendors?

Business People and Developers Must Work Together

Reconsidering the role of the Business Analyst

Business Owner Business Analyst Developers

Traditional View

Business Owner Business Analyst

Developers

Agile View

Requirements Specification Requirements Specification+

Design

BPM Model and Run-time View

Welcoming Late Changes

• The only thing that does not change is change itself so embrace change as a consequence of your projects being alive

• What is delivered at the end of a cycle will naturally change often. This is the hardest concept to understand by Programs Managers and Business Owners

Deliver Working Software Frequently

BPM occurs for each mini- iteration

• BPM is based on the notion of a cycle of continuous process improvement•Modeling and analysis aren’t just the first step of the BPM project, but are repeated periodically to optimize performance and cope with shifting requirements.

Implications for BPM Vendors

• BPM tools must support the following:

– Rapid assessment of project delivery impact

– Quick turnaround time to implement changes

– Automated testing

– Ability to rapidly deploy changes

– Shared-views of the process and “round-trip” engineering

– Reduce the architecture/design decisions that must be made by the team

Keys to Success

• Faith– Obstacles and bumps on the road will naturally occur

during the life cycle of a project

– Don’t panic after the first issue

– Believe in the experience of many others

• Practice– Program Managers and PMs can’t be on the sideline

waiting for the results. They will not understand and will get too uneasy. They have to be part of the process

• Study– Program Managers and PMs have to learn too. Don’t rely

on just the old techniques or one voice of authority.