Downloaded 18 times
Uploaded byJuhana Huotarinen
(Agile) software development in a nutshell
This document provides an overview of agile software development. It begins by noting the increasing dependence of companies on software. It then contrasts the traditional waterfall model with agile principles, noting that agile focuses on iterative delivery of working software, customer collaboration, and responding to change. The origins of agile are explained through the agile manifesto's values of individuals, working software, customer collaboration, and responding to change. Benefits of agile include more frequent delivery of value and better engagement. Examples of successful agile implementations at Gofore and the Finnish Institute of Occupational Health are also provided.
More Related Content
Similar to (Agile) software development in a nutshell
(Agile) software development in a nutshell
- 1. (Agile) software development ina nutshell Juhana Huotarinen
- 2. Juhana Huotarinen • GoforePlc • Current: Advisor in Agile transformations and a Product Owner • Previously: Software developer, project manager, project director & executive committee • Twitter: @juhanaOne • Blogs: www.linkedin.com/in/juhana- huotarinen-16ab301 @JuhanaOne
- 3. @JuhanaOne https://www.marketresearchengine.com/digital-transformation-market https://go.forrester.com/blogs/15-12-08-the_state_of_digital_business_2016_to_2020/ Over the last20 years, the number of top-100 product and service companies that are software dependent has doubled to nearly 40 percent. https://www.mckinsey.com/business-functions/digital-mckinsey /our-insights/an-executives-guide-to-software-development
- 4. @JuhanaOne https://www.marketresearchengine.com/digital-transformation-market https://go.forrester.com/blogs/15-12-08-the_state_of_digital_business_2016_to_2020/ https://www.mckinsey.com/business-functions/digital-mckinsey /our-insights/an-executives-guide-to-software-development “We believe thatevery industrial company will become a software company” - Jeffrey R. Immelt, GE Chairman & CEO 2001-2017
- 5. Traditional (=waterfall) development model Analysis Design Development Testingand integration Deployment Feedback @JuhanaOne https://en.wikipedia.org/wiki/Waterfall_model
- 6. Traditional (=waterfall) development model Analysis Design Development Testingand integration Deployment Feedback @JuhanaOne Assumptions with the model • Requirements are well-defined • Changes will be small • System integration will go well • We can deliver on schedule Scaling Software Agility: Best Practices for Large Enterprises
- 7. Side effects • Allvalue is delivered at the end of the project • Delays or lack of value generally aren’t recognized until the end • Real visibility is missing - only budget and milestone updates are reported @JuhanaOne https://www.boost.co.nz/blog/2015/10/waterfall-and-why-its-not-suitable-for-software-development
- 8. @JuhanaOne ”Agile = Ableto move your whole body easily and quickly – Cambridge dictionary” https://dictionary.cambridge.org/dictionary/learner-english/agile
- 9. Is Agile isthe right approach? • Agile is optimized for complex projects • Complex projects are not fully knowable, but reasonably predictable. • Cannot solve problems with best or good practices alone, experiments are needed Agility means low cost of change https://blog.crisp.se/2017/09/11/henrikkniberg/agil e-where-are-we-at
- 10. @JuhanaOne Agile in asoftware development context is an iterative approach to product development that delivers a product in small batches https://appinventiv.com/blog/reasons-why-we-trust-agile-for-our-mobile-app-development-process
- 11. The benefits ofAgile • Value is delivered frequently • Risks are identified early • Better business engagement and customer satisfaction • More accurate view of the cost of future development activities • Early visibility of quality issues • Changes are accepted and expected @JuhanaOne
- 12. Origins @JuhanaOne Individuals and interactionsover processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan https://agilemanifesto.org/
- 13. Individuals and interactionsover processes and tools • The most important factors are the people and how they work together • Co-located and cross-functional teams • One process and tool doesn’t fit all projects • Processes evolve • Tools can be replaced • Data shows more than a 10-fold difference between the best programmers and the worst. @JuhanaOne https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/
- 14. Working software overcomprehensive documentation • The primary goal of software development is to create software, not documents • The more detailed the documentation, the bigger risk that documentation is outdated • Agile doesn’t mean no documentation - documentation has its place @JuhanaOne
- 15. Customer collaboration overcontract negotiation • Only your customer can tell you what they want • The team and business demonstrate the prototype to users and other stakeholders regularly (e.g weekly) • The faster you are able to verify the feedback, the more nimble you’ll be at responding to market demands • Sometimes feedback can be gathered automatically (data analytics) • Feedback works as a baseline for future requirements Agile is a market driven approach @JuhanaOne
- 16. Responding to changeover following a plan • It is still important to start with a plan, but it is even more critical to recognize and respond to the many hazards, delays, and diversions • Change is a reality of software development • The problem understanding • The business environment • Technologies • Nothing wrong with project plans as long as they are adaptive @JuhanaOne
- 17. Software factory –an example @JuhanaOne MVP PRODUCT BACKLOG US US BUG US OPS BUG OPS END USERS Plan 5 Plan ready 5 Dev 6 Dev ready 6 Test 4 Test ready 4 QA 10 QA ready 10 DoD DoD DoD STAKEHOLDERS RELEASE Cycle Time Throughpu t Traffic CPU Conversio n Rate Feature Usage PO DEV UX OPS SM
- 18. Discipline method Regular delivery Quality Stakeholderinvolvement Transparency Teamwork Scale @JuhanaOne http://www.drdobbs.com/architecture-and-design/the-discipline-of-agile/201804241?pgno=1
- 19. Schedule example @JuhanaOne Monday TuesdayWednesday Thursday Friday Week 1 10:00 -12:00 Planning 09:00-9:15 Daily 09:00-9:15 Daily 12:00-13:00 Pre-planning 09:00-9:15 Daily 09:00-9:15 Daily Week 2 09:00-9:15 Daily 09:00-9:15 Daily 09:00-9:15 Daily 12:00-13:00 Pre-planning 09:00-9:15 Daily 09:00-9:15 Daily 14:00–15:00 Review 15:00–16:00 Retro
- 20. Task – anexample @JuhanaOne Title: Snow forecast report Description:. Our detailed Snow Reports and live updates are submitted by local Ski Clubs, ski resort staff and our users. Interactive weather maps show the amount of predicted snowfall as well as the current snow conditions and weather observations. Who Skiers Acceptance criteria - Weather forecast accuracy is 95% - Updated 4 times a day - forecast for the next 3 days - PDF-format
- 21. Continuous improvement viaretrospective @JuhanaOne
- 22. Cultural shift The projectculture The product culture Timeline Formal start and end dates Continuous, product can be retired Requirements Gathered from stakeholders upfront. Focus on documentation Customer feedback & interaction, data driven. No single source Process Static project plans, heavy releases Incremental, iterative, small releases Target Optimised for individuals Focused on team collaboration Funding A pre-defined solution or requirements gets funded A product-mode team is funded on a rolling basis Organisation Matrixed Teams working full time, breaking down silos and specialization Metrics Output - delivery on time and budget. Outcome - customer satisfaction, profit, market share, ROI https://magenic.com/thinking/mobile-project-vs-mobile-product
- 23. Case Slackbots • Background: •Gofore wanted to automate routine work • Results • A small cross-functional team • New features are deployed weekly • Continuously feedback • Feature prioritisation against pre-defined factors • The product has pivoted once • Implementation • Over 30 bots implemented • Customer survey results - 95% useful, 30% vital @JuhanaOne
- 24. Case the FinnishInstitute of Occupational Health • Background • the Finnish Institute of Occupational Health current services are being renewed and new service concepts are created • Results • Ability to release a new version at anytime • Full transparency – the situational picture visible all the time • Dedicated team room – no electric tools (e.g Jira) • Business and team work together daily • Implementation • Several new services have been successfully created @JuhanaOne
- 25.
- 26. Caution @JuhanaOne Scrum, Kanban, ContinuousIntegration, Continuous Delivery, Extreme programming, Product Owner, Scrum Master, DevOps, TDD, Lean, Velocity, SAFe, LeSS, Scrum of Scrums, Burndown Chart, Burnup Chart, Definition of Done, Definition of Ready, Pair Programming, User Stories, Story points, User Story Mapping, Acceptance Criteria, Sprint Backlog, Product Backlog, Sprint, Iteration, Mob Programming, Working agreement, Impediment, Retrospective, Lean Startup, Acceptance Testing, Feature Teams, Release Train, Epic, Backlog Grooming, Daily Standups, Cross-functional team, Spikes, Refactoring, Work in Progress, Lean UX, Hackathon, Technical debt, Pull system, Minimum Viable Product…
- 27. Caution @JuhanaOne Scrum, Kanban, ContinuousIntegration, Continuous Delivery, Extreme programming, Product Owner, Scrum Master, DevOps, TDD, Lean, Velocity, SAFe, LeSS, Scrum of Scrums, Burndown Chart, Burnup Chart, Definition of Done, Definition of Ready, Pair Programming, User Stories, Story points, User Story Mapping, Acceptance Criteria, Sprint Backlog, Product Backlog, Sprint, Iteration, Mob Programming, Working agreement, Impediment, Retrospective, Lean Startup, Acceptance Testing, Feature Teams, Release Train, Epic, Backlog Grooming, Daily Standups, Cross-functional team, Spikes, Refactoring, Work in Progress, Lean UX, Hackathon, Technical debt, Pull system, Minimum Viable Product… Don’t do Agile, be Agile
- 28. @JuhanaOne Scaling Lean &Agile Development: Thinking and Organizational Tools for Large-Scale Scrum Theories behind Agile • Queuing theory • Control theory • Information theory • Game theory
- 29.
- 30.
Editor's Notes
- #4 First, it means that digital transformation is fundamentally about how your business responds to digital trends that are occurring whether or not you initiated them, like them, or want them. Second, it means that how an organization implements technology is only a small part of digital transformation. In cases where digital transformation does involve implementing new technologies, the technology is only part of the story. Other issues, such as strategy, talent management, organizational structure, and leadership, are just as important, if not more important, than technology for digital transformation.
- #5 First, it means that digital transformation is fundamentally about how your business responds to digital trends that are occurring whether or not you initiated them, like them, or want them. Second, it means that how an organization implements technology is only a small part of digital transformation. In cases where digital transformation does involve implementing new technologies, the technology is only part of the story. Other issues, such as strategy, talent management, organizational structure, and leadership, are just as important, if not more important, than technology for digital transformation.
- #24 job satisfaction, cost saving , Improved decision-making, Laita taustakuvaksi joku bottikuva, liian valkoinen
- #29 Queuing theory – jonoteoria Control theory – miten systeemi toimii Information theory – esim cost of delay Game theory – miten ihmiset tekevät päätöksiä eri skenaarioissa