Why it happens that many of software projects fails? Why in the beginning everything looks great ? Why during development everything looks fine ? Why when client receive first ‚test version‘ there is a first disappointment ? When during ping-pong problems arise and finally finish as dead end ? In this presentation you will find answers for these questions. The problem start from wrong approach to collecting requirements. Next - software house starts to develop based on their assumptions and imagination - 'how they understood'. Typical deaf phone effect. When client receive first test version - suddenly figure out that deliverables are not as expected... and ping - pong starts. Dead end is a only a matter of time. What is a result? You stay with tons of unusable code without proper documentation... But it can be done differently. If you follow the rules 'build the right software and build the software right' and you really understand principles then you can deliver a great results. Contact me to get more :)

1. <a better way for great apps>
How to Develop a
World-Class Application
without Getting Lost
during the IT Process?

2. <a better way for great apps>
Who we are ?
 Managing Partner in Leaware software house
 I live in Aachen – 150 km from Luxembourg
 Involved in many projects as PM, Product Owner,
CTO
 Examples of clients:
 BNP Paribas, Axa, E&Y, Trooper.be, Bruk Capital,
COWI, many others
 Business Director in Luxembourg
 Office: Regus, 46 A avenue J-F. Kennedy
 Business lead for customer facing projects
TOMASZ SOROKA
JOONA MÄNTYVAARA

3. <a better way for great apps>
How can we help you ?
 Help in setting up a development of your project
 Help in project, product development
 Be your CTO
 Setup collaboration process with nearshore development team –
I‘m from east Europe – i know them 
 Find to you best development team
 Help in different IT challenges
 Other things? Just ask !

4. <a better way for great apps>
Challenges in
software
development

5. <a better way for great apps>
deaf phone effect

6. <a better way for great apps>
When problems arise ?
start game
over
Scope / project
definition
start of development first ‚test version‘ ping-pong dead end

7. <a better way for great apps>
stakeholders involved in a project don‘t understand requirements in the same way

8. <a better way for great apps>
In most cases – there is NO ANY documentation
There is no definition of what is important to
be delivered as documentation ?

9. <a better way for great apps>
• No any architecture of proposed solution.
• No information about patterns, good practices which should be used in chosen
technologies
• No synchronization between developers - they don’t follow best practices – every
developer develop in a different way.

10. <a better way for great apps>
• Lack of communication between business and technical people in the project
• Developers are writing lines of code – they don‘t deliver solution for a problem
• No clear goals, scopes/versions
• Poor communication with a client
• Lack of environments and deployment control
• Poor control on project flow
• Requirements
• Architecture
• Patterns, best practices
• Quality of the code
• Project team
• Misunderstanding of SCRUM, waterfall and other methodologies

11. <a better way for great apps>
EFFECT ?
You stop collaboration with
current supplier and
you start looking for a new one
BUT …

12. <a better way for great apps>
New supplier after digging in code says:
“I can‘t overtake the responsibility
for the application development –
it‘s a total mess! - We need to
rewrite it from scratch!“

13. <a better way for great apps>
SUMMARY
• You lost lot of
• You lost lot of
• You lost your market timing
• You have uselless code and no documentation

14. <a better way for great apps>
HOW TO DO IT BETTER ?

15. <a better way for great apps>
Behavior Driven Development – focus on
communication between stakeholders

16. <a better way for great apps>
WHAT ELSE IS IMPORTANT ?
• DDD (Domain Driven Design) - Good understanding of
business domain by developers and good reflection in
architecture of the code
• Good testing process on a different levels
• Unit tests – TDD (Test Driven Development)
• Integration tests – TDD + BDD
• User Acceptance Tests – BDD
• Checklists with checkpoints for performing boring but
important steps during development
• Systematical control of deliverables (code, architecture)
• Transparency and good communication between
stakeholders (BDD)

17. <a better way for great apps>
CONCLUSION
 30 % of success – WORKING SOLUTION
 70 % of success – ANY OTHER SUPPLIER CAN
SMOOTHLY OVERTAKE FURTHER DEVELOPMENT
Only then you are really secured with your investment – you
can‘t become a hostage of any software house

18. <a better way for great apps>
QUESTIONS ?

19. <a better way for great apps>
Thank you!