Agile Web Development, Exove seminar August 15th, 2013

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

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.

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

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 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 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
(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
 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

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

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

© 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

© 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

© 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

© 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

© Sitra
Thank you!
• Laura.halenius@sitra.fi, p. +358 40 716 7885
• Twitter: @laurahalenius
15.8.2013Sitra’s agile web project 65

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

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.

Agile Web Development, Exove seminar August 15th, 2013

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (12)

Semelhante a Agile Web Development, Exove seminar August 15th, 2013

Semelhante a Agile Web Development, Exove seminar August 15th, 2013 (20)

Mais de Exove

Mais de Exove (20)

Último

Último (20)

Agile Web Development, Exove seminar August 15th, 2013

Notas do Editor