Too many projects are not (fully) successful. In many cases this is caused by issues in the management approach. Clients want to know what they get for a fixed budget. But we all know it's almost impossible to fully specify what you need.
An Agile software approach proved to work for us. After implementing Scrum our projects went more smooth and we were more often delivering the right results on time.
It took time to get this working. For developers it was a bit scary and for our clients it meant they really had to trust us. Today we can see our effort pays off. We wouldn't like to go back to waterfall times anymore.
4. Let’s
Vote
Who
knows
Agile?
Who
uses
Agile?
Who
uses
Scrum?
Image source: European Parliament,
http://www.flickr.com/photos/european_parliament/3480264232/
6. 1. Requirements
Top
causes
of
project
trouble
Unclear, lack of agreement, lack of priority
2. Resources
Lack of resources, poor planning
3. Schedules
Too tight, unrealistic, overly optimistic
4. Planning
Missing items, insufficient details, poor estimates
5. Risks
Unidentified or assumed, not managed
Source: Michael Krigsman (2011)
7. 10
signals
a
project
will
fail
1. Project
managers
don’t
understand
users’
needs.
2. The
project’s
scope
is
ill-‐defined.
3. Project
changes
are
managed
poorly.
4. The
chosen
technology
changes.
5. Business
needs
change.
6. Deadlines
are
unrealisGc.
7. Users
are
resistant.
8. Sponsorship
is
lost.
9. The
project
lacks
people
with
appropriate
skills.
10. Managers
ignore
best
pracGces
and
lessons
learned
Source: John S. Reel, Critical Succes Factors In Software Projects
9. People
related
mistakes
• Undermined
moGvaGon
• FricGon
between
• Weak
personnel
developers
and
• Uncontrolled
problem
customers
employees
• UnrealisGc
expectaGons
• Adding
people
to
a
late
• Lack
of
effecGve
project
project
sponsorship
• Noisy,
crowded
offices
• Lack
of
user
input
• Wishful
thinking
Source: Steven C. McConnell (1996)
10. Process
related
mistakes
• Overly
opGmisGc
schedules
• Insufficient
risk
management
• Abandonment
of
planning
under
pressure
• Inadequate
design
• Premature
or
too
frequent
convergence
• Code-‐like-‐hell
programming
Source: Steven C. McConnell (1996)
11. Product
related
mistakes
• Too
many
and
too
complex
requirements
• Feature
changes
(about
25%)
• Developer
gold-‐plaGng
• Research-‐oriented
development
Source: Steven C. McConnell (1996)
12. Technology
related
mistakes
• Silver-‐bullet
syndrome
• OveresGmated
savings
from
new
tools
or
methods
• Switching
tools
in
the
middle
of
a
project
• Lack
of
automated
source-‐code
control
Source: Steven C. McConnell (1996)
13. It
is
possible
to
do
it
right!
• You
can’t
define
all
your
needs
in
a
contract
• IT
has
to
try
to
understand
the
business
needs
• Agree
about
the
ground
rules
• Cooperate
and
communicate!
That
sounds
Agile,
doesn’t
it?
14. We
decided
to
implement
SCRUM
Scrum is an agile software development framework. Work
is structured in cycles of work called sprints, iterations of
work that are typically two to four weeks in duration. During
each sprint, teams pull from a prioritized list of customer
requirements, called user stories, so that the features
that are developed first are of the highest value to the
customer. At the end of each sprint, a potentially
shippable product is delivered.
Image source: http://news.bbc.co.uk/sport2/hi/rugby_union/7048733.stm
16. Not
just
another
tool!
We
value
• Individuals
and
interacGons
over
processes
and
tools
• Completed
funcGonality
over
comprehensive
documentaGon
• Customer
collaboraGon
over
contract
negoGaGon
• Responding
to
change
over
following
a
plan
Source: http://agilemanifesto.org/
18. We
are
Agile
The
project
budget
can
be
fixed,
the
date
will
be
fixed,
we
only
cannot
fully
predict
the
funcGonality
that
will
be
delivered
19. Tell it with a story: “user stories”
• Write down the story
• Make it clear and understandable for both sides
• Make sure developers fully understand it
• Prioritize together
20. Define needs in terms your
client understands!
As a Role
I require a Feature
To gain a Business Benefit
Business Driven Development
21. People
don’t
like
change
• Business
has
to
take
ownership
and
to
share
visions
• Gedng
a
product
owner
• Project
managers
need
to
be
flexible
• Development
team
has
to
take
responsibility
• Cherry
picking
22. Key
challenges
1. Developer
fear
caused
by
transparency
of
skill
deficiencies
2. The
need
for
developers
to
be
a
‘master
of
all
trades’
3. Increased
reliance
on
social
skills
4. A
lack
of
business
knowledge
among
developers
Source: Key challenges in Agile implementations, Goyelloblog
23. Gains
• More
intense
cooperaGon
with
clients
• Increased
client
trust
• Quick
client
feedback
• Beier
and
more
frequent
results
• Increased
team
responsibility
24. Do
you
want
to
experience
it
yourself?
Join
us!
h;p://kariera.goyello.com
25. Thanks for your attention!
Feel free to contact and follow!
Or ask questions today.
Contact details:
@ peter.horsten@goyello.com
+48 606 699 560
http://goyello.com
http://blog.goyello.com
http://petersopinion.com
http://twitter.com/PetersOpinion
GOYELLO Sp. z o.o.
Al. Niepodległości 606/610
81-855 Sopot
DEDICATED TO YOU T: (58) 555 0073
26. Sources
• Michael
Krigsman,
CIO
analysis:
Why
37
percent
of
projects
fail,
2011,
ZDNet,
hip://www.zdnet.com/blog/projecnailures/cio-‐analysis-‐why-‐37-‐percent-‐of-‐
projects-‐fail/12565
• Steve
McConnell,
Classic
Mistakes
Enumerated,
1996
hip://www.stevemcconnell.com/rdenum.htm
• John
S.
Reel,
Cri>cal
success
factors
in
so?ware
projects,
hip://www2.engr.arizona.edu/~ece473/readings/8-‐CriGcal%20Success%20Factors
%20in%20Soqware.pdf
• OutsourcingNL,
Op
zoek
naar
sourcingsucces
[Looking
for
sourcing
success],
hip://www.vka.nl/publicaGes/publicaGe/outsourcing_in_nl
• Scrum
Alliance,
hip://www.scrumalliance.org/
• Key
challenges
in
Agile
implementaGons,
Goyelloblog,
hip://blog.goyello.com/2011/11/28/key-‐challanges-‐in-‐agile-‐implementaGons/
• Top
10
Project
Management
Challenges,
hip://www.pmhut.com/top-‐10-‐project-‐management-‐challenges
28. Further
reading
• Project
management
2.0
hip://www.slideshare.net/wrike/project-‐
management-‐20-‐1884020
• The
Zen
of
Scrum
hip://www.slideshare.net/jurgenappelo/the-‐
zen-‐of-‐scrum-‐10
29. Disclosure
and
sharing
In
today’s
informaGon
society
it’s
impossible
not
to
be
inspired
by
other
sources.
That’s
applicable
to
this
presentaGon
as
well.
I’ve
tried
to
menGon
the
sources
used
and
to
include
there
copyright
if
applicable.
Please
contact
me
through
my
blog:
hip://petersopinion.com/contact/
if
you
feel
I
reused
your
work
without
menGoning.
Feel
free
to
share
and
reuse
my
presentaGon
taking
the
following
in
mind:
This
work
is
licensed
under
the
CreaGve
Commons
AiribuGon-‐
NonCommercial-‐ShareAlike
3.0
Unported
License.
To
view
a
copy
of
this
license,
visit
hip://creaGvecommons.org/licenses/by-‐nc-‐sa/3.0/.
Notes de l'éditeur
5 years ago we started as very motivated amateurs, guys enjoying their hobby Spent a lot of time to investigate the clients’ needs Were very eager to offer the best deal Concluded too often the client was not fully satisfied with the result When growing we lost control on the team