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

Don’t rely on magic

8

Source unknown

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

Linkedin/in/whyteRichard

Thank You

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