Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Web Development, Exove seminar August 15th, 2013


Published on

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

Published in: Technology
  • Be the first to comment

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
  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 • 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 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! •, 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
  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 See you at: • DrupalCamp Baltics 23.8. Tallinn • WordPress Café 10.9. 16-18 Exove • DrupalCon Prague 23.-27.9.