Oplægget blev holdt ved arrangementet "Get F'IT september 2013: Agil Business Process Management i Finans", der blev afholdt den 24. september 2013.

1. © 2013 IBM Corporation1 Bo Ebro Christensen9/24/2013
CFIR 24/9 2013
Agility and BPM - IBM
Bo Ebro Christensen
Niels Agersnap
Josefine Moussa

2. © 2013 IBM Corporation
Introduction – agile BPM
2 Bo Ebro Christensen9/24/2013
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

3. © 2013 IBM Corporation
Agile = rask, adræt, behændig, hurtig
9/24/20134 Bo Ebro Christensen
•Faster development (40%)
•Faster change of processes (80%)
•Significant reduction in labor time (50%)
BPM is inherently more agile than
traditional development.

4. © 2013 IBM Corporation
Quick Win Project - Project Phases / Sprints
9/24/2013 5Bo Ebro Christensen
Assumption validation – a few hours
Process ”Discovery/kick off” – a few days (time-boxed! )
Infrastructure analysis
- a few weeks
Process
Work stream
•Project team – a few good people - Approximately 10 roles ~ 8 people
•The process in scope is used as a ”Just-in-Time” driver
Milestone / end criteria
All major building blocks
identified, resources/skills
confirmed
All stakeholders and
actors identified (people,
system integration points)
All system/infastructure
requirements identified.
Eg Roles, security,
installation, capacity er
Solution/process
operational (details later)
Duration – a few months
Typically 3-5 sprints
Each sprint ends in a playback workhop
SOA Workshop
GUI Workshop
Core
Syste
m
Works
hop
Involve
dParty
Works
hop
Payme
nts
Works
hop
....
Works
hop
Docum
ent
Manag
ement
Works
hop
K
P
I
Operational
Governance&
Implementation
Security &
Roles
Infrastructure
Implementation As
required...
Infrastructure
Work stream

5. © 2013 IBM Corporation
Sprints are followed by playbacks
9/24/2013 Bo Ebro Christensen6
2 – 4 Months
1-2 Weeks2-3 weeks2-3 weeks2-3 weeks3-5 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. © 2013 IBM Corporation
Sprint 0 theme: Analysis and requirements (4-5 weeks)
7
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

7. © 2013 IBM Corporation
 ”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 Bo Ebro Christensen9/24/2013
Manifesto for Agile Software Development
Individuals and interactions over (development) processes and tools

8. © 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 non-
compatible – but we need to document
lessons learned and adapt for the next
process
11 Bo Ebro Christensen9/24/2013

9. © 2013 IBM Corporation
 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 Bo Ebro Christensen9/24/2013
Manifesto for Agile Software Development
Customer collaboration over contract negotiation

10. © 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 Bo Ebro Christensen9/24/2013

11. © 2013 IBM Corporation
Lessons learned
9/24/2013 Bo Ebro Christensen16
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.

12. © 2013 IBM Corporation
Conclusions from projects where we gradually moved to Agile
 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 Bo Ebro Christensen9/24/2013
Traditional BPM
Agile
Waterfall

13. © 2013 IBM Corporation
Questions ?
18 Bo Ebro Christensen9/24/2013
Do one brave thing today … then run like hell !