Anti-patterns for not-so-smart processes: Avoiding the BPM and SOA pitfalls. A short presentation to focus your project on success - featuring the "magic progress fairy"

1. Richard Whyte, CEng, CITP, FIET, FBCS
CTO IBM-Middleware Services Europe https://uk.linkedin.com/in/whyterichard
Materials created by Richard Whyte and Andy Garratt
Anti-Patterns for
Not-So-Smart Processes:
Avoiding BPM and SOA pitfalls
MQ User Group – Hursley July 2015

2. Agenda
Anti-patterns meet
Smarter projects
So what is a “Smarter”
process
Learning from our
mistakes
Questions
2

3. Agenda
Anti-patterns meet
Smarter projects
So what is a “Smarter”
process
Learning from our
mistakes
Questions
3

4. BPM projects are challenged from several directions
Governance
• Fail to Measure
• No Reviews
• Everyone in Command
Resources
• Wrong Staff
• Wrong Skills
• Needed Tomorrow
• Unmatched working styles
Environment
• Ignorant of Barriers
• Try to change Culture
• Constraint blindness Assumptions
• Expect Fast learners
• Everyone thinks the same
• We all understand what
Quality, Duration, Cost
mean
Technology
• No Automation
• Ignore Reliability
• Misunderstand
Suitability
4

5. Unclear objectives lead to failure
5
"this nation should commit itself to achieving the
goal, before the decade is out, of landing a
man on the moon and returning him safely to
the earth.” JFK May 1961
Who, When, What
NOT Why, How, or Cost

6. Reality TRUMPS theory
§ Magic Progress Fairy !! Actuals trump plan
– Progress is 10 units/day: Why does the plan predict 30?
– Adding staff will make it faster
– Doing more will take the same time: Changes don’t affect plan
§ Magic Data Fairy
– Data appears anywhere in the process
– Integration is not required – until the end
– Cross referencing is simple; we wont mention it
§ Magic Function Phairy !! Magic business adapter
– Integration often takes longer than UI development
– Not sure how this bit works but it will be ok by tomorrow
– Everything we were promised will be available as described
6
A quart does not fit into a pint pot (Even with magic)
European: “1.13652 litres does not fit into a 10.43579872 cm cubic container”

7. Reality TRUMPS optimism
§ We test because the plan says so
– Reality: Testing without fix time seems “Optimistic”
– Reality: Design to support testing – and facilitate fixing
§ Agile means we can change anything anytime at no cost
– Reality: Changes cost time, money, and confusion
– Reality: Changes only on sprint (iteration) boundaries
– Reality: Overall Outcomes and expectations are fixed
§ Clever is not the same as experienced
– Reality: Experience allows the RIGHT shortcuts
– Reality: Clever means get there in the end
– Reality: Your Cobol, Assembler, Java programmers need help
§ Develop a Business Process using assembler best practice?
7
The Guide plan is definitive: Reality is frequently inaccurate1
Please recalibrate your equipment accordingly.
1 Hitchhikers Guide to the Galaxy, Douglas Adams

8. Don’t rely on magic
8
Source unknown

9. Agile is not another word for chaos
§ Uncontrolled Change leads to chaos
– Don’t change specification between reviews
– Only allow Changes to stretch
– Changes aligned to defined outcomes
§ Undocumented requirements lead to chaos
– Stakeholders entitled to understand likely outcomes at the start
– We are building a Yacht not a Ship: Radical change is a new project
– Documentation is required – it is just not the focus
§ Going to the moon in one leap fails to deliver
– We’re not going live until it’s ‘Pixel Perfect’
– Release 1 will do everything we need
– Plan for what can be delivered
9
Project
Release 1
Playback
1..n
Release
Review
Release 2
Playback
1..n
Release
Review
Release 3

10. Process is not another word for application
§ Building a Victorian house in the style of the 1960s
– BPM gets money therefore my project is BPM
– A team with experience in another technology will not deliver an efficient process.
– Don’t build a process in the style of an ecommerce website
§ The picture is not the WHOLE process
– You still need integration
– You still need exception handling
– You still need flashy screens
§ BPM is not ever finished
– Continuous improvement is the mantra
10

11. Bottom line
§ Governance:
– Plan time to plan
– Set policy and standards and control procedures
§ Resources:
– Agile projects suffer from distraction and varied working practices
– Unmatched skills and experience cause friction
§ Environment:
– Know the process and authorisation to get to production
– Know the constraints that apply to the enterprise
§ Assumptions:
– Review designs to remove the assumption of MAGIC happens
– You cannot beat the numbers: if its never happened before…
§ Technology:
– Automation is important: Plan its purchase or creation
– Purchased solutions need to be installed, learned, and configured
11

12. Agenda
Anti-patterns meet
Smarter projects
So what is a “Smarter”
process
Learning from our
mistakes
Questions
12

13. Smarter Processes improve measurable outcomes
– A Process is a set of activities acting on a common context to achieve a defined
goal: operate a business
13
If your Process is not
smarter then what is
the benefit?
Automate badly:
improve nothing…
Faster Better Cheaper Smarter

14. § Agile projects succeed 3 times more than waterfall.
§ SPRINTS demonstrate progress
– RELEASES deliver value
Architecture and design sprints are obviously needed
Agile projects deliver visibility and iterative value
14

15. Larger projects fail more often
15
0
10
20
30
40
50
60
70
80
90
100
10 100 1000 10000 100000
81
75
61
28
14
Canceled
Delayed
On Time
Early
Function Points
Make a big leaps in small increments
Source: IBM GBS research into
project outcomes

16. Smarter Agile meets Smarter Process
16
ü Agile is a great way to deliver BPM projects
ü Leadership is clearly defining objectives and approach
ü Small steps are less risky than giant leaps

17. Agenda
Anti-patterns meet
Smarter projects
So what is a “Smarter”
process
Learning from our
mistakes
Questions
17

18. Learn from your mistakes
• Indicate lack of understanding, complexity, experience.
• How will you test if you cannot predict how it will fail
Track UNEXPECTED problems
• Listen to your worries and feelings – don’t ignore concerns.
• Lunch and learn (brown bag)
Record and share
• Runners rest after a sprint
• Allow time to reflect and learn
Schedule reflection, improvement, and recovery time
• Beware of MAGIC. Track actuals and trust them
• 75% of projects fail to achieve over 80% of requirements
Track and trust the numbers
18

19. Avoid the ANTI-Patterns: SCOPE
Fail
Smart vs
Smartest
Perfect WIP >
Good in PROD
Context:
Magic > Reality
Ignore the
Numbers
Opportunities
Ignore
experience
Fail to automate Principles &
Architecture
Speed > Quality
Inconsistency
Expectations
R1 does everything
Clever =
Experienced
19

20. SCOPE: Smarter is not Smartest
• Define the deliverable and deliver the 70% path
• Standard-variants and exception paths are phase II
Good in Production trumps Perfect in progress
• I’ve used a website now I’m a UI expert
• I’ve been to a retail store so now I’m an expert in supply chain
Sponsors are not designers
• Is your wireframe screen accessible?
• Have you got ALL the validation?
• What about your data types?
The picture is not the whole process
20

21. SCOPE: Context makes decisions relevant
• Project Poker – Who will admit first that they are late?
• ‘It’s OK, I’ll have it finished by Friday’
Don’t be in Denial
• Planning and estimation is based on experience.
• New challenges need latitude to learn and begin-again
Don’t plan for everyone to be an instant Expert
• How long to build a WARP-DRIVE?
First of a Kind should be called out and planned
• “My AGILE team is self organising and doesn’t need a PM”
Agile does need change control
21

22. SCOPE: take Opportunities to improve
• Automation supports consistent outcomes (no fat fingers)
• Smaller teams (supported by automation)è less coordination
• Continuous integration
Don’t work manually when you can automate
• Use waterfall where appropriate
• Take advantage and share the skills and knowledge you have
Don’t blindly follow agile ; don’t hoard knowledge
• Slightly late is better than Slightly broken
• Same action è same outcome
Don’t repeat mistakes
22

23. SCOPE: Principles
• Do enough to get to the next sprint – not too much – not too little
• Resist pressure to move on before you are ready
Don’t leave tasks partially complete
• Balance long term strategic gains against short term needs
• Maintain structural integrity of the overall architecture
Don’t forget strategic goals - Balance
• Give people a shared philosophy not a rule book
• Empower everyone to make right and appropriate decisions
Don’t be bureaucratic - Establish principles not rules
• Plan to the facts, not to the people. Don’t punish honest estimates!
• Assign responsibilities and empower
Don’t expect order from chaos - Establish control
23

24. SCOPE: Environment / Experience
• People are NOT equal
• Distributed teams are NOT the same as co-located ones
• An interruption takes about half an hour to get productive again
PEOPLE: You need to pick your team
• The user interface is not everything
• Stubs and test data are not REALITY
• Each re-plan or re-location takes about 2 days to settle
PLANNING: Allow time to learn and order the build
• You cannot plan to blame others for late or failed projects
• Technology does not solve everything: Its about people
• You must keep on top of progress, barriers, and priorities
RESPONSIBILITY: Its your company, your project
24

25. Agenda
Anti-patterns meet
Smarter projects
So what is a “Smarter”
process
Learning from our
mistakes
Questions
25

26. Key Messages
GREAT
• Governance
• Resources
• Environment
• Assumptions
• Technology
SCOPE
• Smarter <>Smartest
• Context
• Opportunities
• Principles
• Expectations
26

27. There is nothing new in this presentation
§ Fred Brooks: The Mythical Man Month
– 1 Good programmer = 100 programmers
– Adding people to a late project slows progress
§ David Platt: Why Software Sucks
– You are not your own user
– You must complain
27

28. Linkedin/in/whyteRichard
Thank You

29. Questions?
︎ IBM MobileFirst http://www.ibm.com/mobilefirst/us/en/
︎ IBM MobileFirst Case Studies http://www.ibm.com/mobilefirst/us/en/see-it-in-action/
︎ IBM MobileFirst Solutions http://www.ibm.com/mobilefirst/us/en/offering s/
http://Linkedin/in/whyteRichard