OutSystems Projects: 10 Rules for Business Stakeholders - NextStep 2012

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

fjksdhfjhfkhdjfh


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

fjksdhfjhfkhdjfh


Agile Projects The OutSystems way

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

fjksdhfjhfkhdjfh


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 !exibility in overcoming de"cient integrations.

We care about the politics of the thing, not so much about the technical aspects of integrations

fjksdhfjhfkhdjfh


What’s left?

fjksdhfjhfkhdjfh


0#

Be One Team ban the “us vs. them”

fjksdhfjhfkhdjfh


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

fjksdhfjhfkhdjfh


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 •  Bene"ts for the Business

•  Detailed use cases and pains

•  They are bad at UI design

fjksdhfjhfkhdjfh


#1

Have a Vision for the app. Make sure everyone knows it

fjksdhfjhfkhdjfh


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 bene"ts (make money,

save money, compliance). –  Who is going to use it (the User Pro"les). –  The top 10 to 20 most important user stories (tasks) of

these Pro"les. –  The Glossary of relevant business terms

•  Make sure all developers (including the junior ones) understand the Vision doc

fjksdhfjhfkhdjfh


#2

Enforce/welcome business participation

(the golden rule)

fjksdhfjhfkhdjfh


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 Pro"les –  Beware of Business Managers that are not users. Beware of Extranet

Pro"les’ representation (they are not part of the organization…).

fjksdhfjhfkhdjfh


#3

Think win/win when negotiating scope creep

TOUGH

fjksdhfjhfkhdjfh


Features and Functions Used in a Typical System

Source: Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

fjksdhfjhfkhdjfh


Total project budget = Timebox

Features that are used: always or often sometimes rarely or never

fjksdhfjhfkhdjfh


Sprint 1 Sprint 2 Sprint 3

fjksdhfjhfkhdjfh


Sprint 1 Sprint 2 Sprint 3

new features

Features for next release

TOUGH

fjksdhfjhfkhdjfh


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

fjksdhfjhfkhdjfh


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 !ows

•  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

fjksdhfjhfkhdjfh


#4

Build the smallest possible system

TOUGH

fjksdhfjhfkhdjfh


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 "rst 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

fjksdhfjhfkhdjfh


#5 Remove adoption pains

fjksdhfjhfkhdjfh


Extend life of a project until you assured the users are truly satis!ed 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

fjksdhfjhfkhdjfh


Agile in a Nutshell

•  Focusing on what is important: – Delivering a great app that users love to use and

that maximizes business bene"t

•  Collaborating to the end goal –  Trying to bridge knowledge gaps

•  Making tradeoffs and NOT doing things

fjksdhfjhfkhdjfh


The next 5 rules

6.  Prepare early for rollout 7.  Adapt testing 8.  Beware of integrations 9.  Overcome releasefobia

10.  Control multiple stakeholders

fjksdhfjhfkhdjfh


fjksdhfjhfkhdjfh


#6

Prepare early for rollout

fjksdhfjhfkhdjfh


Design for adoption

•  Involve Trainers and In!uencers 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

fjksdhfjhfkhdjfh


#7

Adapt testing to the right situation

fjksdhfjhfkhdjfh


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

de"ne 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)

fjksdhfjhfkhdjfh


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.

fjksdhfjhfkhdjfh


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

fjksdhfjhfkhdjfh


#8

Beware of integrations surrounded by hostile

teams

TOUGH

fjksdhfjhfkhdjfh


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

fjksdhfjhfkhdjfh


The team maintaining the legacy lost the new app project and is not motivated to see this project succeed


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.

fjksdhfjhfkhdjfh


The team is swamped with work and deprioritizes the integration work


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.

fjksdhfjhfkhdjfh


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.


Legacy System

Work to be done

This is important! This is why it is

important! You have to do it! Have you

done it?

fjksdhfjhfkhdjfh


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.


Legacy System

fjksdhfjhfkhdjfh


The API provided has problems

•  no documentation •  not scalable •  too slow


Legacy System

fjksdhfjhfkhdjfh


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

fjksdhfjhfkhdjfh


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


e.g. Cache +

Schedulers

Legacy System

fjksdhfjhfkhdjfh


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


Legacy System

Extra work to be done

fjksdhfjhfkhdjfh


#9

Overcome releasefobia

fjksdhfjhfkhdjfh


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.

fjksdhfjhfkhdjfh


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.

fjksdhfjhfkhdjfh


#10

Control Multiple Stakeholders

TOUGH

fjksdhfjhfkhdjfh


Multiple stakeholders usually have con"icting requirements. Minimize the con"ict.

•  Put enough Business Analysts understanding the total system and arbitrating con!icting tasks

•  Make sure the Pro"les and the Top Use Stories are very well de"ned

•  Have only one Executive Sponsor whom everyone reports too who needs to be committed and accessible

TOUGH

OutSystems Projects: 10 Rules for Business Stakeholders - NextStep 2012

Business

Transcript of OutSystems Projects: 10 Rules for Business Stakeholders - NextStep 2012