OutSystems Projects: 10 Rules for Business Stakeholders - NextStep 2012

925 views

Published on

In OutSystems agile projects business stakeholders, users and analysts are first class members of the project team and crucial for the success of a project. In this session we will list the top conditions and behaviors that Business Stakeholders need to be aware in order to maximize success of OutSystems application projects as well the top pitfalls they should avoid.

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
925
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

OutSystems Projects: 10 Rules for Business Stakeholders - NextStep 2012

  1. 1. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Agile Platform Projects 10 rules for success According to the OutSystems Professional Services Team sampled from 200+ engagements Paulo Rosado @ NextStep 2012, Lisbon, May 11
  2. 2. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Why do (big) IT projects fail? (common wisdom) 1.  Unclear business objectives 2.  Decrease of business sponsorship & participation 3.  Failure to control scope 4.  The world changes 5.  Poor architecture 6.  Unforeseen surprises (integrations...) 7.  No dev process, or... 8.  Focus on process, audit, management not outcome 9.  The fact that it is BIG
  3. 3. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Agile ProjectsThe OutSystems way
  4. 4. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved.Copyright outsystems @ All Rights Reserved. Initial Analysis (Sprint 1) Sprint 2 Sprint 3 Sprint 6 Tuning... Demo 1 Demo 2 Production Release 1 Release 2
  5. 5. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The things that are not as critical… because we have the Agile Platform •  Closing the scope –  We can sustain changes (scope creep) without substantial increase in cost •  Poor architecture –  Platform enforces a lot of good practices. Large portions of the application can be refactored at a reasonable cost. •  The world changes –  Short, highly productive projects. 2x to 4x time compression. •  Having extensive team management –  Large OutSystems projects are done by small teams of less than 8 people. They are on avg. 11x times more productive. •  Violations in latency/capacity of integrations –  The Agile Platform allows for extreme flexibility in overcoming deficient integrations. We care about the politics of the thing, not so much about the technical aspects of integrations
  6. 6. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. What’s left?
  7. 7. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. 0# Be One Team ban the “us vs. them”
  8. 8. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The typical OutSystems project team •  Two headed team •  Engagement Team –  EM = PM + BA + Scope Creep Negotiator –  BA –  Business Stakeholders •  Delivery Team –  DM = Senior Dev + Architect + Team Leader –  Senior Dev, Dev –  Architect
  9. 9. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. What they don’t know (and should) BUSINESS PEOPLE •  How long things take •  Tradeoffs of scope creep •  Status of the project •  Integrations cost •  They are bad at UI design TECHNICAL PEOPLE •  Why we are building this app •  Benefits for the Business •  Detailed use cases and pains •  They are bad at UI design
  10. 10. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #1 Have a Vision for the app. Make sure everyone knows it
  11. 11. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Developers are usually insulated from the business. They don’t understand the pain the users go through. Bridge this gap. •  Create a Vision document –  Why the app and what are the benefits (make money, save money, compliance). –  Who is going to use it (the User Profiles). –  The top 10 to 20 most important user stories (tasks) of these Profiles. –  The Glossary of relevant business terms •  Make sure all developers (including the junior ones) understand the Vision doc
  12. 12. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #2 Enforce/welcome business participation (the golden rule)
  13. 13. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. All projects that did not involve the Business have not gone well •  Remove IT buffers –  Do not isolate the Business from design decisions. •  Force business team members to never miss Sprint Demos and Analysis sessions. –  Business folks are crucial at Sprint Demos. Their capacity to tell you what they need skyrockets. •  Business project members need to be empowered to make decisions & tradeoffs. –  Make sure their bosses will not undermine them later. •  Bring real users that represent the Profiles –  Beware of Business Managers that are not users. Beware of Extranet Profiles’ representation (they are not part of the organization…).
  14. 14. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #3 Think win/win when negotiating scope creep TOUGH
  15. 15. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Features and Functions Used in a Typical System Source: Standish Group Study Reported at XP2002 by Jim Johnson, Chairman
  16. 16. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved.Copyright outsystems @ All Rights Reserved. Total project budget = Timebox Features that are used: always or often sometimes rarely or never
  17. 17. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved.Copyright outsystems @ All Rights Reserved. Sprint 1 Sprint 2 Sprint 3
  18. 18. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved.Copyright outsystems @ All Rights Reserved. Sprint 1 Sprint 2 Sprint 3 new features Features for next release TOUGH
  19. 19. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Why is it TOUGH? •  Requires maturity from everyone... •  ...especially under stress –  Last sprints –  Remaining features need to be prioritized –  ... and some will not be implemented •  Easy to break Rule #0 TOUGH
  20. 20. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. If a new feature is added to the Scope something will need to be pushed out •  Agile methods are great to understand what features are MUST HAVEs •  In the course of a project new MUST HAVE requirements will appear. Other initial requirements of less priority will be pushed out •  Business people should understand the cost magnitude of certain features and changes –  So that everyone understands the tradeoffs and negotiation flows •  Avoid forcing the Delivery Team to implement EVERYTHING, at the same cost and within the same deadline. That will be impossible and the project will fail. •  Less is more. Avoid adding NICE TO HAVE features. TOUGH
  21. 21. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #4 Build the smallest possible system TOUGH
  22. 22. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Risk of Delay & Overbudget increase exponentially with app size (even with the Agile Platform) •  Don’t do a big bang. Release one Function, one Product line, one Country, etc first and then follow- on with the rest –  The extra cost more than gets compensated by the absence of risk •  Train the organization in releasing often and iterating •  2,500 FPs seems to be the limit for one release TOUGH
  23. 23. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #5 Remove adoption pains
  24. 24. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Extend life of a project until you assured the users are truly satisfied w/ the app •  Give high priority to changes reported by Trainers •  Make a great First Impression •  Use the Tuning Sprint to correct the top 5-10 “adoption killers” of the app •  Focus on a great UX for common tasks •  Use email as a way to bring back occasional users to the app •  Lower average response time to <1s. Common tasks should have 200 ms response time
  25. 25. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Agile in a Nutshell •  Focusing on what is important: –  Delivering a great app that users love to use and that maximizes business benefit •  Collaborating to the end goal –  Trying to bridge knowledge gaps •  Making tradeoffs and NOT doing things
  26. 26. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The next 5 rules 6.  Prepare early for rollout 7.  Adapt testing 8.  Beware of integrations 9.  Overcome releasefobia 10.  Control multiple stakeholders
  27. 27. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved.
  28. 28. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #6 Prepare early for rollout
  29. 29. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Design for adoption •  Involve Trainers and Influencers in early design decisions •  Trainers will tell you if something is going to be a pain to teach which will give you an idea that people won’t understand it very well •  Business people are the best sellers for a new app; let them own it by involving them early on
  30. 30. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #7 Adapt testing to the right situation
  31. 31. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Testing/QA procedures will need to adapt to an agile way of doing things •  Add QA team early in the project –  With the variation in scope it is impossible for QA to define test plans based on initial scope documents •  Classify apps in 1.  UI centric: focus is in showing data and capturing data (e.g. CRM system) 2.  Batch/engine centric: focus is on processing according to complex processing rules (e.g. Billing System)
  32. 32. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. UI-centric app •  QA team should leverage business stakeholders for testing. Users will –  Find a lot of bugs out of the system –  Provide invaluable usability feedback •  Activate ECT (Embedded Change Technology) •  Use real data in QA environment •  QA is diminished –  The Agile Platform already produces highly robust code anyway.
  33. 33. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Batch/engine app •  Establish Unit/Regression testing platform –  Beware of added cost to the project. Regression Testing platforms are expensive •  Add a Control UI to browse intermediate steps in data processing –  Transform a Batch into an UI-centric system •  Some large apps have a bit of both natures. Use both methods
  34. 34. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #8 Beware of integrations surrounded by hostile teams TOUGH
  35. 35. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Legacy apps and hostile teams •  If the app needs to integrate with a legacy system the legacy system might need to be changed in order for the new app to integrate Agile Platform Application Legacy System Work to be done
  36. 36. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The team maintaining the legacy lost the new app project and is not motivated to see this project succeed Agile Platform Application Legacy System Work to be done Of course, we will do our part... ... we will not offer any extra advice and we will do it as slow as possible.
  37. 37. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The team is swamped with work and deprioritizes the integration work Agile Platform Application Legacy System Work to be done I will see what I can do. But you should see my backlog... I have everyone asking me for stuff. You are one more and I don’t even understand what you do.
  38. 38. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Consider the integration work the top Risk of the project •  Create a formal visible protocol where lack of cooperation is obvious to an Executive Sponsor. •  Report on Delays and Overbudget consequences early on. Agile Platform Application Legacy System Work to be done This is important! This is why it is important! You have to do it! Have you done it?
  39. 39. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Don’t integrate at all •  Consider building an extra UI and put a person in the middle entering data between the systems •  If real-time access is not needed this is actually not a bad contingency option. Agile Platform Application Legacy System
  40. 40. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The API provided has problems •  no documentation •  not scalable •  too slow Agile Platform Application Legacy System
  41. 41. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. No documentation •  Create a quick and dirty Web app that inputs data and displays results to reverse engineer the API Web App to Test API Legacy System
  42. 42. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Not scalable. Too slow •  Use Database and Schedulers platform artifacts to create Caching patterns •  This shields the backend system from high loads •  And shields the web app from the backend slow response times Agile Platform Application e.g. Cache + Schedulers Legacy System
  43. 43. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. The Agile Platform can overcome these 3 issues •  Start integration work early •  Add a small “surprise integration buffer” to the project budget •  If you do it early no integration work will fail Agile Platform Application Legacy System Extra work to be done
  44. 44. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #9 Overcome releasefobia
  45. 45. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Some organizations are afraid of releasing an app •  “We want perfection!” –  Business stakeholders are unsure about what users will say. Not sure if the system does what it needs to do –  Too big a system will require an exponentially larger roll- out that will consume a large investment from the users •  “We don’t want a second release” –  We need people in other projects. –  We don’t want to support the cost of releasing changes.
  46. 46. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Create an habit of releasing often •  With the Agile Platform you can correct usability and performance mistakes very fast and robustly. There is no reason to delay releasing. •  Business users will get confortable with the occasional bug (they know you will correct it fast) •  But if not confortable deploy in stages 1.  train the Trainers, 2.  release to a small set of users 3.  go wider.
  47. 47. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. #10 Control Multiple Stakeholders TOUGH
  48. 48. fjksdhfjhfkhdjfh Copyright outsystems @ All Rights Reserved. Multiple stakeholders usually have conflicting requirements. Minimize the conflict. •  Put enough Business Analysts understanding the total system and arbitrating conflicting tasks •  Make sure the Profiles and the Top Use Stories are very well defined •  Have only one Executive Sponsor whom everyone reports too who needs to be committed and accessible TOUGH

×