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
Agenda
Anti-patterns meet Smarter projects
So what is a “Smarter” process
Learning from our mistakes
Questions
2
Agenda
Anti-patterns meet Smarter projects
So what is a “Smarter” process
Learning from our mistakes
Questions
3
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
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
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”
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
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
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
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
Agenda
Anti-patterns meet Smarter projects
So what is a “Smarter” process
Learning from our mistakes
Questions
12
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
§ 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
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
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
Agenda
Anti-patterns meet Smarter projects
So what is a “Smarter” process
Learning from our mistakes
Questions
17
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
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
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
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
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
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
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
Agenda
Anti-patterns meet Smarter projects
So what is a “Smarter” process
Learning from our mistakes
Questions
25
Key Messages
GREAT • Governance • Resources • Environment • Assumptions • Technology
SCOPE • Smarter <>Smartest • Context • Opportunities • Principles • Expectations
26
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
Top Related