5 secrets to successful software development
- 1. 5 ancient secrets to enlightened software development Jukka Talvio https://www.linkedin.com/in/jukkatalvio/ Sources The Standish Group: Chaos Report Harvard Business Review Agile Manifesto Various internet articles on failed software projects
- 3. Reasons for failures 1. No clear vision and objectives, no management support and guidance 2. Requirements unclear to the point the user problem to be solved is unclear 3. No user involvement 4. No project planning or visibility to the progress 5. Unrealistic expectations 6. Delivery of the working software only at the end 7. Unexperienced and or incompetent team 8. Complexity of the system and development environment
- 4. Reasons for successes 1. Clear vision and objectives for what problem are we building a solution 2. User involvement 3. Continuously Integrated working software delivered to the user for comments and feedback 4. Skilled people 5. Simplicity of product and production architecture. Modular and loosely coupled architecture
- 5. Reasons for success 1. Clear vision and objectives for what problem are we building a solution 2. User involvement 3. Continuously Integrated working software 4. Skilled people 5. Simplicity of product and production architecture. Modular and loosely coupled architecture 1. No clear vision and objectives, no management support and guidance 2. Requirements unclear to the point the problem to be solved is unclear 3. No user involvement 4. No project planning or visibility to the progress 5. Unrealistic expectations 6. Delivery of the working software only at the end 7. Unexperienced and or incompetent team 8. Complexity of the system and development environment Reasons for failure
- 6. Reasons for success 1. Clear vision and objectives for what problem are we building a solution 2. User involvement 3. Continuously Integrated working software 4. Skilled people 5. Simplicity of product and production architecture. Modular and loosely coupled architecture 1. User Stories 2. Objectives and Key Results – OKRs 3. User involvement Modern methods 1. Frequent releases, frequent feedback 2. A/B Testing 3. Analytics and telemetrics 4. Face to face feedback 1. Automated Continuous Integration – Keep Green 2. DevOps 1. Talent is overratted 2. Mastery, Purpose, Autonomy 1. Microservices 2. APIs 3. Design Patterns 4. Re-engineering 5. Simplexity Methods evolve Have not changed.
- 7. 1970 1980 1990 2000 Clear vision and objective 2010 Winston W Royce - Management of Large Software Systems Requirements DoD SW Development Standard DOD-STD-2167 IEEE standards for requirements Software Maturity Model Use Cases User Stories Agile “Responding to change over following a plan” OKR - Objectives and Key Results Methods evolve
- 8. User involvement 1970 1980 1990 2000 2010 Winston W Royce - Management of Large Software Systems Prototype DoD SW Development Standard DOD-STD-2167 Requirement Elicitation IEEE standards for requirements Spiral model Requirement Elicitation Paper prototypes Agile ”Customer collaboration over contract negotiation” User Participation Monthly releases A/B Testing At least daily releases for feedback Analytics NPS
- 9. Continuously Integrated working software 1970 1980 1990 2000 2010 Winston W Royce - Management of Large Software Systems Prototype Software Architecture Design to ensure smooth integration Software Architecture Design to ensure smooth integration Modeling tools and languages Code generation Agile “Working software over extensive documentation” A/B Testing Limited blast radius Rollbacks Analytics Telemetrics
- 10. Simplicity of product and production architecture 1970 1980 1990 2000 2010 Winston W Royce - Management of Large Software Systems Prototype Software Design Software Design to ensure smooth integration Object Oriented Programming Libraries Software Architecture Design to ensure smooth integration Modeling tools and languages Code generation Agile Emerging architecture Unit testing allows re- engineering Simplexity Microservices Continuous integration automation Deployment automation
- 11. Skilled people B.C. 1980 1990 2000 2010 Master and Apprentice Certifications Software Science Degrees Linus Torwalds Software Architecture Patterns Agile eXtreme Programming Pair Programming GIT Blogosphere Master and Apprentice Intrinsic motivation Purpose, Mastery, Autonomy Mob programming Master and Apprentice
- 13. Summary
- 14. Reasons for success 1. Clear vision and objectives for what problem are we building a solution 2. User involvement 3. Continuously Integrated working software 4. Skilled people 5. Simplicity of product and production architecture. Modular and loosely coupled architecture 1. No clear vision and objectives, no management support and guidance 2. Requirements unclear to the point the problem to be solved is unclear 3. No user involvement 4. No project planning or visibility to the progress 5. Unrealistic expectations 6. Delivery of the working software only at the end 7. Unexperienced and or incompetent team 8. Complexity of the system and development environment Reasons for failure
- 15. Reasons for success 1. Clear vision and objectives for what problem are we building a solution 2. User involvement 3. Continuously Integrated working software 4. Skilled people 5. Simplicity of product and production architecture. Modular and loosely coupled architecture 1. User Stories 2. Objectives and Key Results – OKRs 3. User involvement Modern methods 1. Frequent releases, frequent feedback 2. A/B Testing 3. Analytics and telemetrics 4. Face to face feedback 1. Automated Continuous Integration – Keep Green 2. DevOps 1. Talent is overratted 2. Mastery, Purpose, Autonomy 1. Microservices 2. APIs 3. Design Patterns 4. Re-engineering 5. Simplexity Methods evolve Have not changed.
- 17. Requirements – the silver bullet? baseliningand change managemenet ( The i m p o r t a n t birth story of Scrum )
- 18. Baselining all requirements can increase risks • Often lists detailed goals rather than an objective or a user problem for a team to solve • Making changes to requirements becomes costly • User involvement as a source of understanding what requirements/solution best serve the user becomes bureaucratic and slow • Suggests monolithic delivery to customer. • Leads to fixed scope, fixed budget projects which in practice are very difficult to get right. 1. No clear vision and objectives, no management support and guidance 2. Requirements unclear to the point the problem to be solved is unclear 3. No user involvement 4. No project planning or visibility to the progress 5. Unrealistic expectations 6. Delivery of the working software only at the end 7. Unexperienced and or incompetent team 8. Complexity of the system and development environment Reasons for failure Aims to solve but adds risk Contradicts and adds risk Aims to help Aims to solve