agil bpm - ibm af bo ebro christensen, ibm
DESCRIPTION
Oplægget blev holdt ved arrangementet "Get F'IT september 2013: Agil Business Process Management i Finans", der blev afholdt den 24. september 2013.TRANSCRIPT
© 2013 IBM Corporation
1 Bo Ebro Christensen 9/24/2013
CFIR 24/9 2013 Agility and BPM - IBM
Bo Ebro Christensen Niels Agersnap
Josefine Moussa
© 2013 IBM Corporation
Introduction – agile BPM
2 Bo Ebro Christensen 9/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
© 2013 IBM Corporation
Agile = rask, adræt, behændig, hurtig
9/24/2013 4 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.
© 2013 IBM Corporation
Quick Win Project - Project Phases / Sprints
9/24/2013 5 Bo 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
S
yste
m
Wo
rks
ho
p
Invo
lve
d P
art
y
Wo
rks
ho
p
Pa
ym
en
ts
Wo
rks
ho
p
....
W
ork
sh
op
Docu
me
nt
Ma
na
ge
me
nt
Wo
rks
ho
p
KPI
Op
era
tio
na
l G
ove
rna
nce
&
Im
ple
me
nta
tion
Security & Roles Infrastructure
Implementation As required...
Infrastructure Work stream
© 2013 IBM Corporation
Sprints are followed by playbacks
9/24/2013 Bo Ebro Christensen 6
2 – 4 Months
1-2 Weeks
2-3 weeks
2-3 weeks
2-3 weeks
3-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
© 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
© 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 Christensen 9/24/2013
Manifesto for Agile Software Development Individuals and interactions over (development) processes and tools
© 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 Christensen 9/24/2013
© 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 Christensen 9/24/2013
Manifesto for Agile Software Development Customer collaboration over contract negotiation
© 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 Christensen 9/24/2013
© 2013 IBM Corporation
Lessons learned
9/24/2013 Bo Ebro Christensen 16
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.
© 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 Christensen 9/24/2013
Traditional BPM
Agile
Waterfall
© 2013 IBM Corporation
Questions ?
18 Bo Ebro Christensen 9/24/2013
Do one brave thing today … then run like hell !