• Save
Agile Web Development, Exove seminar August 15th, 2013
 

Agile Web Development, Exove seminar August 15th, 2013

on

  • 13,312 views

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

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

Statistics

Views

Total Views
13,312
Views on SlideShare
12,903
Embed Views
409

Actions

Likes
1
Downloads
0
Comments
0

3 Embeds 409

http://www.exove.com 289
http://www.exove.fi 109
http://www.exove.ee 11

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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 Agile Web Development, Exove seminar August 15th, 2013 Presentation Transcript

  • 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
  • WHY AGILE?
  • 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.
  • 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 strives to reduce all redundant work.
  • 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 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
  • 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 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
  • WATERFALL
  • 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
  • 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.”
  • 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
  • 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”
  • 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.
  • SCRUM
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • EXTREME PROGRAMMING
  • 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
  • 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
  • XP practices  Pair programming  Planning game  Test-driven development  Whole team  Continuous integration  Refactoring  Small releases
  • 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 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
  • 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
  • LEAN JA KANBAN
  • 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
  • Lean - principles  Elminatewaste  Eliminateunnecessarycodeandfunctinality  Eliminatedelayinthesoftwaredevelopmentprocess  Eliminateunclearrequirements  Eliminatebureaucracy  Amplifylearning  Insteadofdocumentationorplanning,ideasshouldbetestedby coding  Useshortiterationcycles  Decideas late as possible  Don’tplanahead  Decodewhenyouhaveenoughinformation  Rathertrydifferentoptionsthanbaseyourdecisiononassumptions
  • 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
  • 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
  • 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
  • Kanban – core practices  Visualize  Limit word-in-progress  Manage flow  Make policies explicit  Implement feedback loops  Improve collaboratively, evolve experimentally
  • 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
  • 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 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
  • 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 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
  • 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
  • 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
  • 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
  • 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
  • THANK YOU! Questions?
  • 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
  • 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 from 10/2012 • Responsible for Sitra’s digital communications, including development • Twitter: @laurahalenius 15.8.2013 58Sitra’s agile web project
  • © 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
  • © 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
  • © 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
  • © 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
  • © 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
  • © 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
  • © Sitra Thank you! • Laura.halenius@sitra.fi, p. +358 40 716 7885 • Twitter: @laurahalenius 15.8.2013Sitra’s agile web project 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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  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
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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 • WordPress Café 10.9. 16-18 Exove • DrupalCon Prague 23.-27.9.