Agenda
14.00 Opening words Janne Kalliola
14.10 Summary of agile methodologies Kalle Varisvirta
14.30 What kind of project...
WHY AGILE?
Typically, you need to
Achieve more with less resources.
Be among the first ones to launch your
service.
Constantly upgrad...
User satisfaction
Time to market
Return on investment
Agile focuses on flow of information
and embraces changes instead of
trying to control them.
Lean focuses on results and s...
About us
Exove is a leading Northern European
company specialising in open source
web services design and development.
We enable companies to conduct
better business on the Internet
through best-of-breed personnel
and solutions
Our Approach
Understanding
your business
Our Approach
Understanding
your business
Our expertise
Our Approach
Understanding
your business
Our expertise
Power of open
source
Results
Beautiful,
functional &
business-
driven
services
Over 60 people, over 150 customers,
over 3.5 MEUR revenue 2012, profitable,
offices in Helsinki, London & Tallinn
Agenda
14.00 Opening words Janne Kalliola
14.10 Summary of agile methodologies Kalle Varisvirta
14.30 What kind of project...
AGILE METHODS IN
BRIEF
Kalle Varisvirta
Technology Director
History
 The history of software development processes
is quite long
 Originally the projects were small and thus no
pro...
WATERFALL
Waterfall
 Waterfall gets usually credited to Winston Royce
because of his 1970 article
 However, the seven-step process...
Royce (in the article):
“Either the requirements
must be modified, or a
substantial change in the
design is required. In
e...
Waterfall taken into use
 After Royce’s article, Waterfall model was taken
into use via the official recommendations by e...
Agile Manifesto 2001
 Agile methods started appearing into scientific
articles and general knowledge during the
1990’s
 ...
Agile manifesto
We are uncovering better ways of developing software by
doing it and helping others do it. Through this wo...
SCRUM
Scrum
 Scrum is the most popular of agile methods
today
 The iterations of Scrum are called sprints and
they span usuall...
Scrum
 Sprint starts with a two-part sprint planning
 Inthe first part the client representatives choose the goals and
t...
Scrum - roles
 Customer– Product owner
 One person (!), who’s responsible for the creation
and the prioritization of the...
Scrum - roles
 Development – Scrum team
 Development team
 Process manager – Scrum master
 Usually mostly one of the d...
Scrum
 In Scrum, tasks are usually categorized to a
abstraction hierarchy
 Epic – too big to be done in one sprint, esti...
How to fail in Scrum
 The number of sprints is set at the project kickoff
or the tasks of sprint are set earlier than in ...
EXTREME
PROGRAMMING
Extreme programming
(XP)
 XP is older than Scrum and less known
 Even still, many of it’s practices are used today
 XP ...
Extreme programming
(XP)
 XP has 12 core principles
 These include the most famous, pair programing
 All XP principles ...
XP practices
 Pair programming
 Planning game
 Test-driven development
 Whole team
 Continuous integration
 Refactor...
XP practices (cont)
 Coding standards
 Collective code ownership
 Simple design
 System metaphor
 Sustainable pace
Extreme programming
(XP)
 XP has the whole team in the same room and the
customer representative (one or more) always
the...
XP
 Because of the customer in the room always –
requirement and the pair programming, XP is
very expensive to take fully...
LEAN
JA KANBAN
Lean
 Lean is an old production principle that aims for
removing all waste
 Toyota’s production system (TPS) from 1948 –...
Lean - principles
 Elminatewaste
 Eliminateunnecessarycodeandfunctinality
 Eliminatedelayinthesoftwaredevelopmentproces...
Lean - principles
 Deliver as fast as possible
 Create a feedback loop as soon as possible
 Release as frequently as po...
Lean
 As you can see, lean doesn’t dictate rules or
procedures, but bases on principles
 Thus lean integrates well with ...
Kanban
 Kanban is one of the lean software processes
 It’s based on a Kanban board, that shows the
state of all tasks
 ...
Kanban – core practices
 Visualize
 Limit word-in-progress
 Manage flow
 Make policies explicit
 Implement feedback l...
Combinations
 Frequently we see multiple of the processes in
use at the same time
 As long as you make sure you follow t...
Lean
Think big,
act small,
fail fast;
learn rapidly
Agenda
14.00 Opening words Janne Kalliola
14.10 Summary of agile methodologies Kalle Varisvirta
14.30 What kind of project...
PROJECT FIT TO AGILE
DEVELOPMENT
JanneAlho
ProjectDirector
Basic Project variables
 Project Budget
 Project Schedule
 Project Scope and Target
 Team
Project budget
Agile vs. Waterfall
 Waterfall
 Fixed provider commitment, prior tp project start -> risk included in pro...
Project schedule
Agile vs. Waterfall
 Waterfall
 Projectphasing
 Phasesneedtobebeforehandsetforcontentinordertogetcommi...
Project scope and target
Agile vs. Waterfall
 Waterfall
 Requires detailed scope definitions beforehand
 Project target...
Project team
Agile vs. Waterfall
 Waterfall
 Requirements writer is in key role
 PM manages the development to be done ...
Experiences
 Janne Alho
 1989 -2013 Nokia Business Communications, Comverse, First
Hop, Airwide, Mavenir, Exove
 Teleco...
THANK YOU!
Questions?
Agenda
14.00 Opening words Janne Kalliola
14.10 Summary of agile methodologies Kalle Varisvirta
14.30 What kind of project...
Sitra’s agile web project
15.8.2013 Laura Halenius
© Sitra
About Speaker
• Laura Halenius, MSc (Econ)
• Eight year experience in developing and directing communications
• In...
© Sitra
Sitra.fi
• Published at the beginning of 2012
- First Finnish responsive websites
- Agile tendering with a test sp...
© Sitra
Why agile project
• …Wanted to implemented the best possible website for Sitra
• …Aimed to prevent sitra.fi to be ...
© Sitra
Agile prerequisites
• Sufficient resources
• Light enough contracts
• Trust on vendors
- Close collaboration
- Dir...
© Sitra
Product owner in the center
• Responsibility for quality and order of tasks
• Requires diplomatic skills and stron...
© Sitra
Commitment from the organisation
• There is easily really lot work during sprints
- Resourcing is very important t...
© Sitra
Summary
• It pays off to familiarise with agile methodologies with an open mind
- Talk with people that are experi...
© Sitra
Thank you!
• Laura.halenius@sitra.fi, p. +358 40 716 7885
• Twitter: @laurahalenius
15.8.2013Sitra’s agile web pro...
Agenda
14.00 Opening words Janne Kalliola
14.10 Summary of agile methodologies Kalle Varisvirta
14.30 What kind of project...
Trust
 Agile practices place great emphasis on the
team
 Encourages autonomy
 Leadership is shared
 Team has substanti...
Definition of Trust
 When you trust to someone, you are willing to
be vulnerable to the actions of another party
 Based ...
Definition of Trust, cont’d
 Trust is not a behaviour or a choice
 But a psychological state that cause or result
from a...
And?
 This means that trust must be built, not
purchased or ordered
 Building is a long and fragile process
 Requires p...
The Basic Needs
 In order to create and grow trust, the basics
need to be in a good shape:
 The goals are well-defined a...
How to Build Trust?
 Trust is created with small actions that stay
constant
 Everyone respects the others
 Communicatio...
Threats to Trust
 Not enough external visibility to the project
 Team need to keep everyone on the same page about
the p...
What You Gain from
Trust?
 Trust reduces extra work
 Focuses everyone’s attention to things that matter
 Less controls ...
Onward
 Trust helps everyone to get things done in a
pleasant way
 It should be one of the primary goals in a successful...
Agenda
14.00 Opening words Janne Kalliola
14.10 Summary of agile methodologies Kalle Varisvirta
14.30 What kind of project...
HOW TO BUY
AGILE
PROJECTS?
15.8.2013
Mikko Hämäläinen
About Speaker
 Mikko Hämäläinen, DI
 Responsible for Consulting at Exove
 Over 15 years of industry experience
 Produc...
What’s Agile Buying?
 The goal is to do a truly agile project
 Focus on skills & experience of the vendor – not
just bud...
Anatomy of an Agile
Online Project
Creativeprocess
Concept  Userinterfaces/visuals
Technicalvendorpartofprojectfromthesta...
Two Models for Buying an
Agile Online Project
1. Buy resources
 An agile team or part of it for a specified time
 Custom...
Two Models for Buying an
Agile Online Project
2. Agile project
 Implementation of certain scope defined on high level
 C...
Budget, Scope, and Schedule
– Contractual Model for Agile
 Splitscope in 2-3 categories
 Max.50%mandatoryfeatures
 Esti...
Buyer’s Checklist
1. Clearly define big goals – and prepare for changes
during the project
2. Work with known and trusted ...
Agile online project works for everyone
willing to get better results more effectively
THANK YOU!
Seminar materials and contact information
on www.exove.com
See you at:
• DrupalCamp Baltics 23.8. Tallinn
• Wor...
Agile Web Development, Exove seminar August 15th, 2013
Upcoming SlideShare
Loading in...5
×

Agile Web Development, Exove seminar August 15th, 2013

14,109
-1

Published on

Seminar slides from Exove's agile seminar held on August 15th, 2013

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
14,109
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • ArvontuottoRajattubudjettijaaikataulu,muttaeiominaisuudet
  • Vaativa:OsaamisenverifiointiProjektinohjaaminenBudjettiavartenarvioprojektinlaajuudesta, jottapäästäänvähintäänminimiin (MVP=
  • Vaativa:OsaamisenverifiointiProjektinohjaaminenBudjettiavartenarvioprojektinlaajuudesta, jottapäästäänvähintäänminimiin (MVP=
  • Aseta selkeät isot päämäärät – ja valmistaudu muutoksiin matkallaMitoita budjetti oikein suhteessa toiveisiinVarmista oikea osaaminen projektissaValitse kumppaneiksi tunnettuja ja luotettavia verkkoalan toimijoita Valitse tarpeeksi suuri kumppani, jonka kanssa jatkoyhteistyö on turvattua. Suunnittelun ja toteutuksen yhteispeli toimivaksiOikeat teknologiat tarpeisiin nähdenPanosta tuoteomistajuuteen – tarvittaessa kouluttaudu ennen projektiaTuoteomistajalle (ja toimittajalle) valta päättää yksityiskohdistaRiittävästi aikaa tuoteomistajalleYksityiskohtien loputon hiominen harvoin parantaa tulostaPyri julkaisemaan mahdollisimman aikaisin – ja anna asiakaspalautteen ohjata (osaltaan) jatkokehitystä
  • Agile Web Development, Exove seminar August 15th, 2013

    1. 1. Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? Janne Alho 14.50 Break 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
    2. 2. WHY AGILE?
    3. 3. Typically, you need to Achieve more with less resources. Be among the first ones to launch your service. Constantly upgrade your offerings. Satisfy your business needs and keep your bottom line in shape.
    4. 4. User satisfaction Time to market Return on investment
    5. 5. Agile focuses on flow of information and embraces changes instead of trying to control them. Lean focuses on results and strives to reduce all redundant work.
    6. 6. About us
    7. 7. Exove is a leading Northern European company specialising in open source web services design and development.
    8. 8. We enable companies to conduct better business on the Internet through best-of-breed personnel and solutions
    9. 9. Our Approach Understanding your business
    10. 10. Our Approach Understanding your business Our expertise
    11. 11. Our Approach Understanding your business Our expertise Power of open source
    12. 12. Results Beautiful, functional & business- driven services
    13. 13. Over 60 people, over 150 customers, over 3.5 MEUR revenue 2012, profitable, offices in Helsinki, London & Tallinn
    14. 14. Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? Janne Alho 14.50 Break 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
    15. 15. AGILE METHODS IN BRIEF Kalle Varisvirta Technology Director
    16. 16. History  The history of software development processes is quite long  Originally the projects were small and thus no processes were needed  Later on the projects become to grow and suddenly a need for a process was created  First recognized (non-agile) software development process was Waterfall
    17. 17. WATERFALL
    18. 18. Waterfall  Waterfall gets usually credited to Winston Royce because of his 1970 article  However, the seven-step process created from the article was a misunderstanding  In the article, Royce was explaining the process that’s currently in use and how broken and non- functional it is  He never called it good, nor he named it the waterfall model – that all came later
    19. 19. Royce (in the article): “Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”
    20. 20. Waterfall taken into use  After Royce’s article, Waterfall model was taken into use via the official recommendations by e.g. the DOD  In 1995, DOD was researching the results of software projects between 1988 and 1995 and concluded that 46% of the built systems missed their real needs that they were never taken into use
    21. 21. Agile Manifesto 2001  Agile methods started appearing into scientific articles and general knowledge during the 1990’s  In the year 2001, 17 agile method enthusiasts wrote and published the “Agile Manifesto”
    22. 22. Agile manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
    23. 23. SCRUM
    24. 24. Scrum  Scrum is the most popular of agile methods today  The iterations of Scrum are called sprints and they span usually from 2 to 3 weeks  Scrum is based on the “backlog” which is a prioritized list of tasks yet to be done  Backlog can and should be updated constantly, but the tasks in a sprint can’t be changed during a sprint
    25. 25. Scrum  Sprint starts with a two-part sprint planning  Inthe first part the client representatives choose the goals and tasks for the sprint  Inthe second part the customer /product owner meets the scrum master or the whole team and chooses the actual tasks from the backlog for the sprint  Sprint ends with a sprint review  Team or the scrum master shows the goals met and demoes thetasks done  Also the tasks that didn’t get done are gone through and prioritized back tothe backlog  Every day the teams holds a status meeting, the daily scrum
    26. 26. Scrum - roles  Customer– Product owner  One person (!), who’s responsible for the creation and the prioritization of the backlog  Selects the tasks for the next sprint  Together with other representatives of the customer, reviews the sprint results in the sprint review
    27. 27. Scrum - roles  Development – Scrum team  Development team  Process manager – Scrum master  Usually mostly one of the developers, scrum master role is only part-time  Handles Scrum’s ceremonies, sprint starting, ending and daily scrums
    28. 28. Scrum  In Scrum, tasks are usually categorized to a abstraction hierarchy  Epic – too big to be done in one sprint, estimating very hard, needs to be split into smaller pieces  User story – part of an epic, a single feature or a business demand  Task –Asingle tasks. One or more is needed to accomplish a single user story
    29. 29. How to fail in Scrum  The number of sprints is set at the project kickoff or the tasks of sprint are set earlier than in the sprint planning  New tasks are added to a sprint while the sprint is running  Product owner isn’t participating, can’t or isn’t allowed make decisions
    30. 30. EXTREME PROGRAMMING
    31. 31. Extreme programming (XP)  XP is older than Scrum and less known  Even still, many of it’s practices are used today  XP is the first somewhat popular agile method, it was around in the 1990’s and thus leading the way for the popularity of agile
    32. 32. Extreme programming (XP)  XP has 12 core principles  These include the most famous, pair programing  All XP principles are very rarely used, but some are very popular, for example continuous integration
    33. 33. XP practices  Pair programming  Planning game  Test-driven development  Whole team  Continuous integration  Refactoring  Small releases
    34. 34. XP practices (cont)  Coding standards  Collective code ownership  Simple design  System metaphor  Sustainable pace
    35. 35. Extreme programming (XP)  XP has the whole team in the same room and the customer representative (one or more) always there, too  All tasks are just written with one, two words or a sentence to post-it notes or similar  When work starts on a task, the developer goes through it with the customer  One test engineer is dedicated to producing acceptance testing with the customer, preferably automated
    36. 36. XP  Because of the customer in the room always – requirement and the pair programming, XP is very expensive to take fully into use – usually impractical, too  XP practices are commonly borrowed into a process that is mainly based on Scrum
    37. 37. LEAN JA KANBAN
    38. 38. Lean  Lean is an old production principle that aims for removing all waste  Toyota’s production system (TPS) from 1948 – 1975 is considered to be it’s base  To the software industry, lean has arrived only during after the year 2000
    39. 39. Lean - principles  Elminatewaste  Eliminateunnecessarycodeandfunctinality  Eliminatedelayinthesoftwaredevelopmentprocess  Eliminateunclearrequirements  Eliminatebureaucracy  Amplifylearning  Insteadofdocumentationorplanning,ideasshouldbetestedby coding  Useshortiterationcycles  Decideas late as possible  Don’tplanahead  Decodewhenyouhaveenoughinformation  Rathertrydifferentoptionsthanbaseyourdecisiononassumptions
    40. 40. Lean - principles  Deliver as fast as possible  Create a feedback loop as soon as possible  Release as frequently as possible to get the feedback into the development  Empower the team  Self-guided team  Build integrity in  Refactor the architecture frequently  See the whole  Everybody should know the product’s business demands, purpose and see the whole
    41. 41. Lean  As you can see, lean doesn’t dictate rules or procedures, but bases on principles  Thus lean integrates well with otherAgile or Lean methodologies  The key is just to remove everything that doesn’t produce value to the customer
    42. 42. Kanban  Kanban is one of the lean software processes  It’s based on a Kanban board, that shows the state of all tasks  The states move from left to right as they get done  The key function of the board is to limit the work that’s in-progress
    43. 43. Kanban – core practices  Visualize  Limit word-in-progress  Manage flow  Make policies explicit  Implement feedback loops  Improve collaboratively, evolve experimentally
    44. 44. Combinations  Frequently we see multiple of the processes in use at the same time  As long as you make sure you follow the key rules, it might work well  Often combinations are used to circumvent the most important (and hard to implement) rules  Scrumwaterban
    45. 45. Lean Think big, act small, fail fast; learn rapidly
    46. 46. Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? Janne Alho 14.50 Break 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
    47. 47. PROJECT FIT TO AGILE DEVELOPMENT JanneAlho ProjectDirector
    48. 48. Basic Project variables  Project Budget  Project Schedule  Project Scope and Target  Team
    49. 49. Project budget Agile vs. Waterfall  Waterfall  Fixed provider commitment, prior tp project start -> risk included in project offer price  Buyers plans for changes  Change budgeting (typically 10%-20%)  Change Requests handling is a hard “playing field” between parties  What is additional effort to manage/negotiate and get approval to Change Requests  What is buyers knowledge level in handling technical details related to CR’s  Agile  Full project budget visible to both parties  Risk sharing needs to be agreed during contract negotiation  Change needs is part of joined estimates, as part of targets ambiquity and order of importance evaluation  Managing changes is part of normal Agile project handling – no need for separate CR handling  Budget control becomes a joined cause
    50. 50. Project schedule Agile vs. Waterfall  Waterfall  Projectphasing  Phasesneedtobebeforehandsetforcontentinordertogetcommittingagreements  Changesinsidephasesorbetweenphasesneedseparateagreementandmaybedifficult toagree  Delaysanctionsareoftennotdirectlytighttoimportanceofdelayedparts  Providertargetistoavoiddelay,nottooptimizebuyersbusinessgoals  Agile  Projectphasing  Phasegoalsaresetduringproject–alllowsreactiontochangedneeds  Businessdrivenphases(MVP–MostValuableProduct)  Delay/Schedulecontrol –jointlymanagedrisk  Vendorfirstpriorityistoprovidebusinesscriticaldeliverableswithinscheduleorasearlyas possible
    51. 51. Project scope and target Agile vs. Waterfall  Waterfall  Requires detailed scope definitions beforehand  Project targets can not change much during project  All changes require separate handling  In problematic projects mutual agreement may be very difficult to achieve  Provide can progress project more independently. The end result is needed to be verified only in the end of the project  Agile  In order to start, project scope is needed only in overall level  Project target is allowed to change according to buyer needs  In order to get good results efficiently, a strong guidance is needed. Guidance need to be given by person who has full and detailed understanding of customer needs  Project results are being validated throughout the project
    52. 52. Project team Agile vs. Waterfall  Waterfall  Requirements writer is in key role  PM manages the development to be done according to requirments and reports to both organizations  Developers are often far from requirements writer  Agile  Product Owner – Owns requirements during project  In key position to make sure that requirements are clear to developers  Works close to both organizations  Developers (Tech Lead and other developers)  Take part in understanding targets and reasons behind requirements  Role and commitment is bigger than in waterfall  Project Manager  Provides material required to follow up project (hour reports, progress reports, excecutive summaries)  Monitors and plans resources and reacts to exceptions  Normally less involved than in waterfall
    53. 53. Experiences  Janne Alho  1989 -2013 Nokia Business Communications, Comverse, First Hop, Airwide, Mavenir, Exove  Telecom tele, Telecom Web, Web solutions  Personal experiences  Lead time from requirements definition to market launch has been significantly reduced all the time  Waterfall projects provide results too late for business needs  Solutions are very strongly tuned during development, and further tuned during production life  Agile model provides clear ground rules to all players  Agile provides ways to take learnings found during project better into account  Agile provides possibility to give developers more understanding on all overall goals in order to reach them  Customer PO, and the support that provider can give to him/her is one of the key success factors in agile projects
    54. 54. THANK YOU! Questions?
    55. 55. Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? Janne Alho 14.50 Break 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
    56. 56. Sitra’s agile web project 15.8.2013 Laura Halenius
    57. 57. © Sitra About Speaker • Laura Halenius, MSc (Econ) • Eight year experience in developing and directing communications • In Sitra from 10/2012 • Responsible for Sitra’s digital communications, including development • Twitter: @laurahalenius 15.8.2013 58Sitra’s agile web project
    58. 58. © Sitra Sitra.fi • Published at the beginning of 2012 - First Finnish responsive websites - Agile tendering with a test sprint • Web changes rapidly -> the site is developed continuously with two week sprints • Exove started as a development partner on 2/2013 • About 30,000 monthly visitors 15.8.2013 59Sitra’s agile web project
    59. 59. © Sitra Why agile project • …Wanted to implemented the best possible website for Sitra • …Aimed to prevent sitra.fi to be outdated immediately after the launch • …Wanted to utilise the learnings taking place during the project Agile methodology works very well with projects that develop a site continuously 6015.8.2013Sitra’s agile web project
    60. 60. © Sitra Agile prerequisites • Sufficient resources • Light enough contracts • Trust on vendors - Close collaboration - Direct communication • The other parts of the organisation must be agile • Big and complex enough project The way of working is very different compared to waterfall projects - Big change and learning experience for a newcomer 15.8.2013 61Sitra’s agile web project
    61. 61. © Sitra Product owner in the center • Responsibility for quality and order of tasks • Requires diplomatic skills and strong vision • Prioritisiting thousands of wishes from the organisation 15.8.2013 62Sitra’s agile web project
    62. 62. © Sitra Commitment from the organisation • There is easily really lot work during sprints - Resourcing is very important to ensure that PO is not a bottleneck - We had, for example, a separate technical project manager during the development project - Testing is a continuous part of the process - Two or three people are testing during sprints It is advisable to find the best suited agile way of working for own organisation through testing and experimenting 15.8.2013 63Sitra’s agile web project
    63. 63. © Sitra Summary • It pays off to familiarise with agile methodologies with an open mind - Talk with people that are experienced • Agile methodologies are no silver bullets • Reserve more resources • Trust on vendor • Commit your self to the project 15.8.2013 64Sitra’s agile web project
    64. 64. © Sitra Thank you! • Laura.halenius@sitra.fi, p. +358 40 716 7885 • Twitter: @laurahalenius 15.8.2013Sitra’s agile web project 65
    65. 65. Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? Janne Alho 14.50 Break 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
    66. 66. Trust  Agile practices place great emphasis on the team  Encourages autonomy  Leadership is shared  Team has substantially more control  Trust is required from managers and clients to avoid micromanagement or falling back to non- agile methodologies
    67. 67. Definition of Trust  When you trust to someone, you are willing to be vulnerable to the actions of another party  Based on the expectation that the other party will perform an important action  Irrespective of the ability to monitor or control the other party
    68. 68. Definition of Trust, cont’d  Trust is not a behaviour or a choice  But a psychological state that cause or result from aforementioned actions  That is related to both rational and emotional skills of the people involved
    69. 69. And?  This means that trust must be built, not purchased or ordered  Building is a long and fragile process  Requires participation from each party  Blunders are ok when they are not repetitive or malicious
    70. 70. The Basic Needs  In order to create and grow trust, the basics need to be in a good shape:  The goals are well-defined and reachable  The client loosens the control – at least somewhat – to allow vendor to perform on its own  The vendor is able to run with the ball
    71. 71. How to Build Trust?  Trust is created with small actions that stay constant  Everyone respects the others  Communication is open, honest and immediate  Expectations are managed by all parties  People are not punished for making mistakes
    72. 72. Threats to Trust  Not enough external visibility to the project  Team need to keep everyone on the same page about the progress  Demos and shared environments  Tensions between developers and the product owner / customer  Everyone needs to agree on the shared goals and means to reach them  Underestimations  Team need to assess its capability to estimate and make changes as required
    73. 73. What You Gain from Trust?  Trust reduces extra work  Focuses everyone’s attention to things that matter  Less controls and meetings  The project generates more customer value with the same investment  Trust allows people to talk about difficult or painful matters openly  No issues are swept under the carpet  Trust makes the project team happier -> improves productivity and work meaningfulness
    74. 74. Onward  Trust helps everyone to get things done in a pleasant way  It should be one of the primary goals in a successful IT relationship  Sell the idea of trust to your team  Guide their steps when they try to build and maintain it  If possible, participate actively  If you have trustworthy teams, vendors or project, remember to praise them from time to time
    75. 75. Agenda 14.00 Opening words Janne Kalliola 14.10 Summary of agile methodologies Kalle Varisvirta 14.30 What kind of projects does agile fit in? Janne Alho 14.50 Break 15.00 What agile project means to the client? Laura Halenius, Sitra 15.20 Trust in agile projects Janne Kalliola 15.40 How to buy agile projects? Mikko Hämäläinen 16.00 Discussion
    76. 76. HOW TO BUY AGILE PROJECTS? 15.8.2013 Mikko Hämäläinen
    77. 77. About Speaker  Mikko Hämäläinen, DI  Responsible for Consulting at Exove  Over 15 years of industry experience  Product management, project management, SW development  Web & mobile, identity management  Currently working on…  Online business, best practices, how tocreate value?  Studies, e.g. what direction totake in online development  Product ownership  Marketing automation @mthamalamikko@exove.fi
    78. 78. What’s Agile Buying?  The goal is to do a truly agile project  Focus on skills & experience of the vendor – not just budget, schedule, and scope  Flexible contract model – 2 out of 3 can be fixed: Budget ScopeSchedule
    79. 79. Anatomy of an Agile Online Project Creativeprocess Concept  Userinterfaces/visuals Technicalvendorpartofprojectfromthestart Design&technologydonetight,agilecollaboration Contentcreation andinput Launch! Initial definition and vendor selection Technicalimplementation Iterative,agileproject Deploy- ment
    80. 80. Two Models for Buying an Agile Online Project 1. Buy resources  An agile team or part of it for a specified time  Customer is responsible for driving the team  Very flexible and powerful – when product ownership is good  Decision factors: skills, references, and daily price  Buyer must define the skills that are needed to get to the goal  Vendors&consultantscanhelphere  Make use of vendor’s special skills outside core team
    81. 81. Two Models for Buying an Agile Online Project 2. Agile project  Implementation of certain scope defined on high level  Customer is responsible for requirements & priorities, vendor organizes the implementation work  Often budged & schedule are fixed, scope is flexible  Agile backlog collaboratively refined during the project  The service can be published once key features creating value have been implemented (MVP)  Decision factors: References, skills, project model and daily price
    82. 82. Budget, Scope, and Schedule – Contractual Model for Agile  Splitscope in 2-3 categories  Max.50%mandatoryfeatures  Estimateall work and create budgedbasedon the total  Actualtime spenton each feature realizedduringthe project  The goalis to publisha working,valuableservice in budgetand schedule ProjectManagement Design Implementation:Priority1 Priority2-3 Wk 1 2 3 4 5 6 7 8 9 10 11 12 Production Scheduleandbudgetlimit Mandatorywork grows/shrinksduringthe project Restofthebudget& timespenthere Maintenance /furtherdev.
    83. 83. Buyer’s Checklist 1. Clearly define big goals – and prepare for changes during the project 2. Work with known and trusted vendors 3. Emphasis on product ownership – buy help when you need it 4. Launch as early as possible – let the customer feedback guide further development Consulting before and during the project can save a lot of money during the implementation phase
    84. 84. Agile online project works for everyone willing to get better results more effectively
    85. 85. THANK YOU! Seminar materials and contact information on www.exove.com See you at: • DrupalCamp Baltics 23.8. Tallinn • WordPress Café 10.9. 16-18 Exove • DrupalCon Prague 23.-27.9.

    ×