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.
6. Traditional (=waterfall) development
model
Analysis
Design
Development
Testing and
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
• All value 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 = Able to move your whole body easily and quickly
– Cambridge dictionary”
https://dictionary.cambridge.org/dictionary/learner-english/agile
9. Is Agile is the 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 a software
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 of Agile
• 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 interactions over 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 interactions over
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 over comprehensive
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 over contract
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 change over 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
20. Task – an example
@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
22. Cultural shift
The project culture 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 Finnish Institute 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
26. Caution
@JuhanaOne
Scrum, Kanban, Continuous Integration, 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, Continuous Integration, 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
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.
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.
job satisfaction, cost saving , Improved decision-making,
Laita taustakuvaksi joku bottikuva, liian valkoinen
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