CFIR 24/9 2013

Agility and BPM - IBM

Bo Ebro Christensen
Niels Agersnap
Josefine Moussa
1

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Introduction agile BPM

Agile Process
Development

Business Agility enabled by BPM & Business

Rules

Topic of today
- Typically IBM is involved implementing the first process with
the customer
- Lessons learned may be different for later processes
- Based on 3 recent BPM projects in Public and Finance in DK
- Also based on 10 years experience of BPM waterfall
- Also based of several years of IT development Productivity
measurements
- Products used: BlueWorks Live and IBM BPM

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Agile = rask, adrt, behndig, hurtig

BPM is inherently more agile than
traditional development.

Faster development (40%)

Faster change of processes (80%)
Significant reduction in labor time (50%)
4

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Quick Win Project - Project Phases / Sprints

Milestone / end criteria
All major building blocks
identified, resources/skills
confirmed

Assumption validation a few hours

Process Discovery/kick off a few days (time-boxed! )

All stakeholders and

actors identified (people,
system integration points)

All system/infastructure
requirements identified.
Eg Roles, security,
installation, capacity er

Security &
Roles

K
P
I

Docum
ent
Manag
ement
Works
hop

....
Works
hop

Payme
nts
Works
hop

Involve
d Party
Works
hop

Operational
Governance &
Implementation
Core
Syste
m
Works
hop

GUI Workshop

SOA Workshop

Infrastructure
Implementation As
required...

Infrastructure
Work stream

Infrastructure analysis
- a few weeks

Solution/process
operational (details later)

Process
Work stream
Duration a few months
Typically 3-5 sprints
Each sprint ends in a playback workhop

Project team a few good people - Approximately 10 roles ~ 8 people

The process in scope is used as a Just-in-Time driver
9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Sprints are followed by playbacks

2 4 Months

3-5 Weeks

2-3 weeks

2-3 weeks

2-3 weeks

1-2 Weeks

Process & requirements are defined in BlueWorksLive

Primary screen established
Process is running
All screens defined as first draft
All artefacts exist as first draft
All screens complete
Process works
Production

Playbacks a key improvement of agile over waterfall

helps establish buy-in and commitment
6

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Sprint 0 theme: Analysis and requirements (4-5 weeks)

Domain

Result of playback

GUI

Primary screen established in a first version for test purposes and to

support discussion and analysis.

Process

BWL process reflects ALL activities and all major use cases. Business
side approves the major cases.
Delivery: BlueWorks Live documentation.

Backend
integration

Testing prototypes of various types of integration at a sunshine

scenario level.
A process can be started from the triggering component and the result
of the process can be delivered to the receiving component.
Experiments of protocols and integrations are a part of this sprint.

Business
rules

Analysis of rules involved eg application form validation, credit

validation etc.
Business variable are identified at an entity level with major business
attributes documented in text form.

Installation

Developement environment installed.

Testing environment approved and agreed.

Test

User test cases identified (not detailed).

Migration considerations completed.

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Manifesto for Agile Software Development

Individuals and interactions over (development) processes and tools
User stories and personaes helps create
individul stories and helps break down complex
processes into understandable scenarios
Especially helpful if users find the process too
complex and abstract

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Manifesto for Agile Software Development

Working software over comprehensive documentation
Focus on demonstrating running parts in
playbacks and workshops

The BlueWorks Live process model is the

contract between IT and business AND the
documentaiton of the requirements.
DONT spend time documenting (obsolete)
process models

Sprints and process documentation are noncompatible but we need to document

lessons learned and adapt for the next
process

11

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Manifesto for Agile Software Development

Customer collaboration over contract negotiation
The business is involved in sprint 0 (Blue Works
Live) and they CAN define the process models.
DONT establish long requirement documents
from business to IT
The Blue Works Live model is
the process documentation,
the business requirements, and
the contract between IT and business

13

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Manifesto for Agile Software Development

Responding to change over following a plan
Use the default sprint content plan BUT be
willing and able to adapt to changes
At first, a challenge to the Project Manager

15

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Lessons learned
Focus on early demonstration showing running artefacts
improves end-user communication and accellerates learning
curve.
Dont document be lazy - do it automatically !
BPM impacts the way the process participants work
manage the change !! agileBPM reveals it faster.
Sprints of 2-3 weeks is too short but perhaps OK for
smaller processes.
Business MUST be involved AND customer must accept
time-boxing and iterations in some cases business side
there will never be a version 2.
Lots of estimation exercises required we need to develop
key distribution sizing numbers and collect experience.
Initially a Project Managers nightmare.

16

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Conclusions from projects where we gradually moved to Agile

Traditional

BPM

Agile
Waterfall

Agile process development dramatically enhance quality and commitment of

BPM moving abstract concepts into seeing is beleiving
Business agility and process development agility are complementary.
Reduces risk of re-do / late changes Reduces risk of late delivery
Agile process development is good for vendor-customer projects and even better
for in-house development.
You CAN develop large processes in a few months and simple processes in a
few weeks using Agile BPM

17

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation

Questions ?

Do one brave thing today then run like hell !

18

9/24/2013

Bo Ebro Christensen

2013 IBM Corporation