Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mqug2015 july richard whyte


Published on

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"

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mqug2015 july richard whyte

  1. 1. Richard Whyte, CEng, CITP, FIET, FBCS CTO IBM-Middleware Services Europe 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. 2. Agenda Anti-patterns meet Smarter projects So what is a “Smarter” process Learning from our mistakes Questions 2
  3. 3. Agenda Anti-patterns meet Smarter projects So what is a “Smarter” process Learning from our mistakes Questions 3
  4. 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. 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. 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. 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. 8. Don’t rely on magic 8 Source unknown
  9. 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. 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. 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. 12. Agenda Anti-patterns meet Smarter projects So what is a “Smarter” process Learning from our mistakes Questions 12
  13. 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. 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. 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. 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. 17. Agenda Anti-patterns meet Smarter projects So what is a “Smarter” process Learning from our mistakes Questions 17
  18. 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. 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. 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. 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. 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. 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. 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. 25. Agenda Anti-patterns meet Smarter projects So what is a “Smarter” process Learning from our mistakes Questions 25
  26. 26. Key Messages GREAT •  Governance •  Resources •  Environment •  Assumptions •  Technology SCOPE •  Smarter <>Smartest •  Context •  Opportunities •  Principles •  Expectations 26
  27. 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. 28. Linkedin/in/whyteRichard Thank You
  29. 29. Questions? ︎ IBM MobileFirst ︎ IBM MobileFirst Case Studies ︎ IBM MobileFirst Solutions s/ http://Linkedin/in/whyteRichard