outsystems projects: 10 rules for business stakeholders - nextstep 2012
DESCRIPTION
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.TRANSCRIPT
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
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
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
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
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 !exibility in overcoming de"cient integrations.
We care about the politics of the thing, not so much about the technical aspects of integrations
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
What’s left?
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
0#
Be One Team ban the “us vs. them”
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
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 • Bene"ts for the Business
• Detailed use cases and pains
• They are bad at UI design
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
#1
Have a Vision for the app. Make sure everyone knows it
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 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
Copyright outsystems @ All Rights Reserved.
#2
Enforce/welcome business participation
(the golden rule)
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 Pro"les – Beware of Business Managers that are not users. Beware of Extranet
Pro"les’ representation (they are not part of the organization…).
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
#3
Think win/win when negotiating scope creep
TOUGH
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
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
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved. Copyright outsystems @ All Rights Reserved.
Sprint 1 Sprint 2 Sprint 3
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved. Copyright outsystems @ All Rights Reserved.
Sprint 1 Sprint 2 Sprint 3
new features
Features for next release
TOUGH
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
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 !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
Copyright outsystems @ All Rights Reserved.
#4
Build the smallest possible system
TOUGH
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 "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
Copyright outsystems @ All Rights Reserved.
#5 Remove adoption pains
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
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
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 bene"t
• Collaborating to the end goal – Trying to bridge knowledge gaps
• Making tradeoffs and NOT doing things
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
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
#6
Prepare early for rollout
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
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
Copyright outsystems @ All Rights Reserved.
#7
Adapt testing to the right situation
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
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
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.
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
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
#8
Beware of integrations surrounded by hostile
teams
TOUGH
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
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.
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.
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?
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
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
The API provided has problems
• no documentation • not scalable • too slow
Agile Platform Application
Legacy System
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
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
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
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
#9
Overcome releasefobia
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.
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.
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
#10
Control Multiple Stakeholders
TOUGH
fjksdhfjhfkhdjfh
Copyright outsystems @ All Rights Reserved.
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